►
From YouTube: IETF102-NTP_TICTOC-20180718-0930
Description
NTP TICTOC meeting session at IETF102
2018/07/18 0930
https://datatracker.ietf.org/meeting/102/proceedings/
A
A
A
B
B
B
B
So
we're
gonna
move
the
enterprise
profile
discussion
down
to
the
point,
but
down
later
in
the
agenda
when
it's
ready
and
we
are
going
to
swap
the
NTS
order
of
discussion
but
I
think
other
than
that,
we'll
be
fine,
we're
doing
tick-tock
first
and
then
we're
going
to
be
talking
about
the
NTP
working
group
items.
We
have
a
number
of
drafts
and
the
NTP
working
group
in
it.
B
Basically,
what
we're
the
objective
of
this
meeting
is
to
clear
up
a
bunch
of
the
items
that
have
been
hanging
out
there
for
a
while
and,
as
you
can
see,
we
have
a
quite
lengthy
agenda.
So
the
first
item
was
quickly.
Oh,
no.
The
first
item
is
the
tick-tock
working
group
status.
The
only
thing
that
I
really
wanted
to
mention
here
is
that
we
have
requested
publication
of
the
1588
version
to
mill,
so
it
is
in
the
publication
process.
B
B
B
So
the
next
thing
on
the
agenda
was
the
NTP
working
group
status.
The
only
thing
I
wanted
to
mention
under
that
working
group
status
is:
we
have
submitted
the
NTP
Mac
document
for
publication
as
well,
but
folks
can
look
at
the
data
tracker
and
see
the
status
of
both
of
those
next
item.
I
was
going
to
talk
about.
Very
briefly
is
the
data
minimization
draft.
The
data
minimization
draft
has
been
submitted
again
or
published,
and
we
don't
have
a
presentation
on
that.
B
I've
spoken
to
the
authors-
and
there
has
been
I-
have
not
followed
up
with
the
implementation
experience,
but
there
has
been
some
implementation
experience.
The
plan
is
to
submit
this
for
working
group.
Last
call:
is
there
any
opposition?
Is
there
anybody
who
thinks
that
we
should
not
submit
it?
For
writing.
Your
last
call.
B
D
D
This
slide
tries
to
figure
out
where
the
protocols
work.
Imagine
that
you
have
some
kind
or
RTT
between
your
host
and
the
server
and
then
different
protocols
has
different
error
or
precision
or
they
they
can
be
also
secure
or
insecure.
Our
proposition
is
in
green
is
called
sick,
and
this
provides
frequency
synchronization
for
very,
very
small
error
about
ten
of
microseconds
or,
if
you
want
an
absolute
synchronization,
is
like
NTP
next
slide.
D
Please
well
the
idea
of
our
protocol
each
packet,
its
signal,
then
we
we
can
explain
better
what
security
means
and
error
is
around
20
microseconds
is
based
on
traffic
behavior,
we
just
probe,
which
has
give
frequency
clock
stability
and
it's
the
model.
Client-Server
simple
software
distribution,
and
if
the
exists
asymmetric
paths
between
client
and
server,
you
can
use
this.
This
synchronization
like
absolute
clock,
synchronization,
and
it
is
related
with
another
draft
we
are
presenting
in
AI
ppm.
D
D
D
We
provide
italian
information
about
security
issues
related
with
our
vc
73
84,
and
we
provide
also
on
an
appendix
where
we
we
show
some
limitation
of
ntp,
because
the
deployment
in
in
some
part
of
the
internet
in
this
case
was
in
Buenos
Aires
were
in
for
part
of
different
networks.
At
one
Osiris,
we
showed
the
different
round-trip
time
between
the
NTP
server,
and
this
is
all
my
presentations.
Thank
you
for
your
attention.
B
B
B
B
B
If
you
can
work
off
long,
I,
don't
see
any
consensus
right
now
to
adopt
this
in
the
time
working
group
and
the
NTP
working
group.
Apologies,
so
I
think
what
we're
going
to
need
to
do
is
to
build
some
more
momentum
behind
it
before
we
move
forward
with
it.
So
I
would
suggest
if
you
were
to
post
to
the
mailing
list,
that
you
are
looking
for
collaborators
to
work
on
this
and
see
if
you
can
build
a
community,
a
small
community
of
people
to
help
generate
some
momentum
behind
it
is
that
okay.
D
B
B
H
H
H
However,
if
you're
defining
a
new
protocol-
and
none
of
these
time
stamp
formats
fits
what
you
need
in
that
case,
this
draft
also
defines
guidelines
that
specify
how
to
define
a
new
time
stamp
format.
So
these
are
the
two
main
goals
here.
Next,
please,
the
main
changes
compared
to
the
previous
version
of
the
draft,
first
of
all,
the
control
field
section.
So
this
is
a
section
that
talks
about
control,
related
information
that
may
optionally
be
attached
to
a
packet
timestamp.
H
H
So
when
we
published
the
current
version
of
the
draft,
we
actually
received
some
more
comments
from
Miroslav
from
Varna
and
we
planned
that
there
was
nothing
major
there.
We
plan
to
address
these
comments
in
the
hopefully
in
the
working
group.
Last
call
next,
please,
which
brings
us
to
the
next
step,
and
hopefully
we
believe
that
we
are
ready
for
working
your
blast
gone,
and
hopefully
we
can
do
this
very
soon.
B
I
Seem
to
address
the
thing
that
I
was
hoping
to
get
out
of
it
when
I
voted
for
its
adoption,
which
is
that
I
was
hoping
we
could
come
up
with
a
binary
timestamp
format
which
addresses
the
problem,
with
with
semantic
ambiguity,
well
leap
seconds
in
progress:
is
that
or
are
we
it
are
we
on
the?
Are
we
on
this
it
on
that
60th?
Second
of
this
minute
of
the
61st?
I
H
So
I'm
not
sure
whether
you
read
the
most
recent
version
of
the
draft,
but
there
is
actually
a
subsection
about
leap
seconds.
I
discusses
whether
leap
seconds
affect
the
time
stamp
format
or
not
again.
This
is
a
question
for
the
time
stamp
format
specification.
Okay,
wherever
that
time,
stem
format
is
defined.
It
needs
to
also
address
the
question
whether
a
leap
second
will
address
the
format
or
not.
Now,
specifically,
for
the
recommended
time
stamp
formats,
we
use
format
which
were
already
defined
elsewhere.
H
Ntp
format,
e
TP
format,
so
for
these
formats
were
not
inventing
something
new
were
only
specifying
them
in
a
very
accurate
way
future
formats.
The
guidelines
in
this
draft
tell
you
that
you
need
to
specify
how
the
leap
second
is
going
to
affect
the
time
stamp
format.
That's
part
of
the
guidelines
for
specifying
a
time,
but.
I
H
H
I
H
Just
by
the
way,
the
PTP
timestamp
format
does
not
have
this
issue
around
exactly
right.
You
could
define
the
abacus
it's
defined
in
TA
I,
so
that
means
that
you
count
the
number
of
seconds
regardless
of
the
leap
seconds,
but
I
think
that
the
way
I
see
it.
This
is
more
a
question
to
the
working
group,
whether
you
think
that,
beyond
what
we
already
defined,
whether
you
think
we
should
add
a
new
timestamp
format
that
resolves
the
issue
that
Daniel
presented
here.
J
C
B
Okay,
so
we'll
take
this
discussion
to
the
list.
K
K
They
did
bring
up
something
that
was
brought
up
here.
I
think
Daniel
may
have
brought
it
up
in
that
the
draft,
as
written
does
rely
very
heavily
on
ntpd
and
when
Daniel
brought
that
up.
We
pointed
out
that
part
of
the
reason
for
that
is
that
the
the
draft
was
written.
You
know
all
the
submissions
concerned
ntpd
and
one
of
the
main
motivations
for
the
draft
was
documenting
some
of
the
security
best
practices
from
some
vulnerabilities
that
were
found
a
few
years
ago.
K
K
Not
this
slide
doesn't
have
a
link
to
the
github,
but
I
know
I've
posted
it
on
the
on
the
mailing
list
reflected
before
so
you
can
see
the
current
status
of
the
draft,
with
the
edits
that
dieter
and
I
have
made
if
you're
interested
in
looking
at
it,
but
I.
Think
from
here
are
our
task
is
gonna,
be
to
work
out
with
the
inter
reviewer,
make
sure
they're
satisfied
with
the
changes
we've
made
and
then
it
proceeds
from
there
is
that
right?
That's.
B
Correct:
okay,
the
one
question
for
the
for
the
group
is,
if
they're
just
comfortable
moving
the
implementation
specific
stuff
to
an
appendix
I,
don't
know
if
they're,
if
there's
anybody,
that's
uncomfortable
with
that
I.
B
We'll
be
following
up
with
our
area
director
after
this
meeting,
unfortunately
he's
not
here
this
week,
because
he
has
a
family
medical
emergency
so
but
we'll
be
following
up
with
Suresh
on
a
number
of
items
and
we'll
check
in
on
this
to
see
what
the
timeline
is.
Okay,.
I
B
That's
that
is
true,
that
Nutella
chats,
the
telecasts
are
announced
publicly
and
they
are
bi-weekly
and
the
agenda
for
those
was
published
in
advance.
So
you
can
see
what
drafts
are
on.
There
will
be
notified
in
advance
when
it
comes
up
on
the
tele
chat,
but
there's
there's
some
that
the
fruit
for
those
of
you
who
aren't
familiar
with
the
process
once
it
gets
submitted
to
the
ISD.
The
first
thing
that
happens
is
the
Area
Director
reviews
it
and
then
before
he
submits
it
to
the
rest
of
the
year
to
the
rest
of
the
iesg.
B
K
Pilot
the
update
will
be
submitted-
maybe
not
today.
Maybe
tomorrow
then
yeah.
L
L
B
L
B
So
is
there
any
any
opposition
I
mean
it
probably
should
have
been
expressed
during
the
working
group?
Last
call
I
intend
to
submit
this
for
publication
as
soon
as
possible.
E
E
B
I
I
B
M
Okay
mode
six
commands
are
supposed
to
be
implemented
by
someone
who
does
a
full-on
TP
implementation
mode.
Seven
was
vendor
specific,
so
the
content
of
emotes
mote,
six
stuff
should
be
well
specified
and
easy
for
anybody
to
implement,
and
if
and
that's
about
it,
this,
it
isn't
historic
informational
doesn't,
you
know
is
fine,
but
it
should
be
something
that
a
complete
NTP
implementation
offers.
L
B
So,
just
in
the
I'm
not
sure
how
we
actually
have
a
record
number
of
remote
participants.
So
thank
you
all
for
calling
in
or
meetup
going
in,
I
guess.
I
do
know
that
I
had
this
I
recently
changed
it
from
standards
track
to
informational,
because
Brian
pointed
out
to
me
it
was
supposed
to
be
informational
and
I
had
miss
marked
it.
B
L
B
K
This
is
Dennis
Reilly
again.
I
do
have
a
quick
question
because
I
I
do
have.
There
is
some
content
corresponding
to
control
messages
in
the
ECP
right
now,
because
people
use
them
and
it's
a
good
tool
for
monitoring,
and
so,
when
I
think
about
historical
versus
in
informative.
My
understanding
was
that
it
was.
It
was
documented
in
NTP
v3
and
it
was
left
out
of
me
for
more
like
an
oversight.
It
was.
It
was
an
oversight.
Yes,
so
when
v5
is
made,
would
you
include
it.
B
L
It's
a
dennis
to
get
back
to
your
question.
I
I'm,
almost
thinking
that
the
the
status
of
the
command
document
makes
no
difference
to
what
you
would
actually
put
in
the
BCP
I
would
think
in
the
BCP.
You
would
want
to
put
something
there.
That
looks
a
lot
like
the
security
considerations.
That
says
be
really
really
careful
who
you,
let's
send
these
things
to
your
box,
yeah.
K
B
I
think
I
think
this
is
a
thing
we'll
take
to
the
mailing
list
and
back
I'll
probably
ask
this
would
be
a
good
question
for
sure.
I
should
ask
him
what
his
guidance
would
be,
I
think
if
it,
if
it
is
and
implement
a
and
people
are
using
it
then,
and
it
was
left
out,
then
perhaps
it
makes
sense
to
go
ahead
and
make
it
information.
B
L
Understanding
is
from
at
least
the
the
implementer
said.
I
had
gotten
feedback
from
is.
Is
that
some
of
them
support
it
for
legacy
reasons.
Some
of
them
don't
support
it
at
all.
So,
while
Harlan
says
it's
a
part
of
the
complete
implementation
of
an
NTP
server,
there's
at
least
a
couple
of
examples
of
NTP
servers
that
don't
support
it.
So.
I
M
L
B
B
B
They
believe
the
next
step
for
this
is
to
ask
for
a
yang
yang
expert
review
and
we
could
actually
do
a
working
group
last
call
on
it.
At
the
same
time,
my
only
concern
is,
if
you,
if
you
haven't
picked
up
on
this
yet
my
my
desire
is
to
sort
of
clean
out
all
of
these
small
documents
that
are
sitting
around
and
get
them
processed.
B
So
we
might
want
to
hold
off
a
little
bit
and
let
some
of
the
other
documents
we
need
to
make
get
some
of
the
others
through
the
administrative
process,
but
I
I'm
going
to
go
ahead
and
ask
for
a
yang
yang
expert
review
now
and
I'm
hoping
to
target
a
working
group
last
call,
maybe
in
August
but
in
any
event
prior
to
the
next
meeting.
So
any
questions
or
comments
on
the
status
of
the
yang.
B
N
N
Diagram
was
added
for
the
broadcast
mode,
so
all
three
modes
now
have
a
diagram.
The
second
change
is
supposed
to
handle
a
corner
case
incompatibility
without
clients.
The
specification
now
says
that
the
server
must
respond
in
the
basic
mode.
If
the
request
has
a
transmit
timestamp
equal
to
the
received
timestamp,
even
if
the
origin
times
them
in
the
request
happens
to
match
a
previous
receive
timestamp
of
the
server
and
would
otherwise
look
like
a
request
in
the
interleaved
mode.
N
This
will
prevent
a
client
that
doesn't
support
the
interleaved
mode
and
is
sending
requests
with
transmit
times
x,
equal
to
receive
timestamps
from
processing
and
interleaved
response
as
a
response
in
the
basic
mode
which
would
give
it
an
incorrect
offset
and
delay.
I
haven't
seen
a
real
client
doing
that,
but
I
saw
it
in
test.
N
We'd
randomly
generated
packets
and
I
thought
it
should
be
covered
in
the
draft.
The
third
change
modified
the
check
for
duplicate
packets
from
RFC
five
905
to
compare
both
receive
and
transmit
timestamps.
This
is
needed
to
avoid
dropping
a
valid
response
in
the
interleaved
mode.
If
it
follows
a
response
in
the
basic
mode
and
both
responses
have
the
same
transmit
time
stem
this
can
happen
if
the
server
doesn't
always
have
a
more
accurate
transmit
timestamp
after
the
transmission
I.
N
I
So,
first
of
all,
can
we
get
a
show
of
hands
on
read
the
draft
yeah
so
Miroslav?
First
of
all,
thank
you
for
a
very
clear
and
well
written
document
that
describing
the
intent
but
I
think
there
I
think
there
are
two
serious
problems
in
the
proposal,
both
of
which
have
the
same
solution.
I
I
I
These,
the
these,
the
the
second
problem,
is
really
more
a
matter
just
just
more
more
a
matter
of
good
design
than
a
than
a
specific
issue,
but
that
I
really
dislike
the
idea
that
we're
going
to
take
these
two
timestamps
fields
and
repurpose
them
to
mean
something
completely
different
and
and
rely
on
implicit
context
to
determine
what
they
mean.
This
has
this
that
this
can.
I
Keep
the
head
keep
the
header
fields,
meaning
what
they've
always
meand
and
at
an
extension
field
which
carries
one
an
explicit
session
ID,
so
that
us
that
the
server
doesn't
have
to
guess
about
NAT
issues
and
then
second
and
then,
and
then
after
the
session
ID
the
the
interleaved
timestamps
and
just
do
that
I
think
it
solves
all
our
problems.
Okay,.
N
N
Yes,
I
agree
that
it
could
be
more
explicit,
the
interleaved
mode
in
the
packet,
but
considering
that
it
has
been
used
for
quite
quite
some
time
and
it's
compact,
it's
fully
compatible
with
anything
that
could
be
on
the
path
between
the
server
and
client
doesn't
break
anything
by
design.
So
I
think
that's
one
nice
advantage
of
this
approach.
B
B
B
So
we
had
sort
of
a
hodgepodge
team,
I'll
have
to
say
so
we
had
Martin
Langer,
who
did
their
original
implementation
that
we
used.
Last
time
we
had
Daniel's
implementation
and
we
had
a
young
woman
that
showed
up
to
work
a
little
bit
on
that
we
had
a
team.
I
will
say
we
had
a
remote,
we
had
a
pretty
distributed.
B
B
We
proved
not
proved
I
guess
this
is
something
everybody
in
the
nhf
knows.
An
interoperability
tests
are
indeed
important.
We
also
ran
into
some
issues
that
the
knock
was
able
to
troubleshoot
and
I.
Think
one
of
them
is
going
to
be
an
issue
just
deploying
new
kinds
of
technology
based
on
NTP
going
forward.
We
had
some
sort
of
interesting
filtering
where
packets
were
going.
Nts
packets
was
successfully
going
to
Germany,
but
they
ant
wait.
They
weren't
getting
back,
so
somebody
along
the
line
was
filtering
them.
B
The
original
comment
that
we
got
was
the
the
IETF
Network
is
filtering
in
TS,
packets
and
I'm
thinking,
myself,
I,
don't
think
so,
and
after
a
bit
more
troubleshooting,
we
they
set
up
a
tunnel
from
here
to
there
and
it
worked
fine
through
the
tunnel
but
not
outside
of
the
tunnel.
It
would
go
in
one
direction
and
not
the
other,
and
even
if
you
switched
directions
of
the
client
and
server,
you
still
had
the
problem
from
Germany
to
the
u.s..
So
and
and
in
a
lesson
that
you
don't
have
to
teach
anybody
here.
B
I,
guess
is
that
Wireshark
is
your
friend
so
anyway,
but
I
think
these
kinds
of
activities
are
really
helpful
to
sort
of
gather
momentum
and
see
what
people
are
actually
willing
to
spend
time
on.
We
have
a
very
rough
thought
in
the
back
of
our
head
about
possibly
doing
something
you
know
virtually
or
a
small
group
in
person
in
Europe
in
early
October.
B
B
O
All
right,
I'm,
assuming
you
can
hear
me.
Yes,
you
have
your
quickly
great
good
morning.
Everyone
I'm
Marcus
Ansari,
and
it's
me
and
right
now,
Salem
God
who's,
also
participating
remotely
who
authored
the
suggest
improvements
and
to
them
today
are
scratches
and
I
would
just
like
to
start
by
thanking
everybody
for
this
opportunity
to
present
our
suggestions
so
slide,
please.
O
So,
as
I
mentioned,
my
colleague
Ragnar
is
the
main
designer
and
operator
of
the
Swedish
I
expect
notes
entity
service,
which
they
run
on
behalf
of
the
Swedish
person
telecom
agency
pts.
It
consists
of
eight
high
speed
stratum,
1,
&
2
P
servers
designed
from
the
ground
up
to
be
highly
resilient,
and
each
of
them
can
handle
entity
requests
at
the
full
line.
Speed
of
40
gigabits
per
second
they're
placed
at
forum,
not
nodes,
secure
I
exponents
and
a
fifth
point
with
two
additional
NTP
servers
will
be
set
up
soon.
O
O
O
O
A
new
MTP,
server,
negotiation
and
theists
record
allows
the
server
to
forward
the
clients
to
an
entity,
sir
after
receiving
cookie.
A
secondary
feature
of
this
record
is
that
the
client
can
also
request
cookies
for
a
specific
server
or
servers.
Although
the
aunt
is,
the
exchange,
server
may
choose
to
ignore
the
class
preference.
We've
also
changed
the
requirement
of
TLS
1.2
203,
and
this
is
since
rc8
4
50
should
be
released
in
Dana
and
TLS.
One
country
will
probably
be
in
relatively
wide
use
when
the
MPS
graph
becomes
an
artsy.
O
Furthermore,
the
NTS,
Authenticator
and
encrypted
extension
fields
have
been
changed
to
simplify
implementation.
In
hardware
and
PJ's-
and
we
also
believe
in
informants
to
be
easier
to
understand
in
general
and
finally,
the
addition
of
the
requirements
that
MTS
implementing
servers
always
include
the
unique
identifier
extension
field
in
responses
will
allow
clients
to
ignore
spoofed,
kiss
of
death
packets
from
up
detectors
slide.
Please.
B
O
There
we
go
so
just
to
close
up
I'd
like
to
thank
everyone
who
worked
on
the
previous
drafts
on
which
are
implemented.
Sorry,
our
improvements
are
based
and
the
link
in
QR
code
you
see
here,
will
take
you
to
an
artsy
bit
between
our
draft
and
best
well.
So
thank
you
all
for
your
contribution
to
entity
in
MPs
for
your
attention.
B
Yeah,
okay!
Well,
that
was
great,
so
are
there
any
cool
so
how
many
people
have
read
this
draft
and
you
know
okay,
excellent,
so
are
there
any
questions
or
comments
or
how
do
we
want
to
I'm?
Looking
at
Daniel
here?
Do
you
do
you
want
to.
I
Yeah
so
yet
I
I
have
quite
a
few
comments,
most
of
them
positive,
thank
God,
the
the
reason
that
I
wanted
to
swap
the
order
for
two
presentations-
it's
just
so
I
want
I'm
so
that
since
we're
on
since
we're
on
time,
I
want
to
use
might
use
my
presentation
time
to
to
respond
to
these
proposals.
Okay,.
B
So
at
the
end
of
this
conversation,
I
want
a
pretty
high
level
understanding
of
what
what
part
of
their
proposals
are
being
accepted
and
what
ones
aren't
and
so
you're
going
to
get
to
that
point
then
alright!
So
then
your
Europe,
you
don't
have
slides
that
right.
P
Mine
Berg
builds
NTP
servers
and
in
that
context,
I
talked
to
a
lot
of
network
operators
who
continually
expressed
frustration
that
there
is
no
security
solution
to
replace
AutoKey
and
we'd
be
happy
to
have
something
that
works
for
80%
or
90%
of
the
cases.
Rather
than
trying
to
pick
a
perfect
solution.
So
I
just
thought
I'd
remind
everyone
of
that.
B
The
I'm
doing
actually
forgot
to
pay
attention
to
the
jabber
room.
Actually,
at
the
very
beginning
of
this
I
neglected
to
name
a
jabber
scribe.
So
I
remembered
this
and
then
I
was
trying
to
do
it
myself.
So
there's
a
Danny
Meyer
from
the
room
asks.
Have
you
considered
the
DTLS
connection
ID?
That's
now
in
in
the
draft
mode
and
a
draft
fresco,
leti,
LSD,
TLS
connection
ID
is.
B
O
B
Okay,
I
think
it
probably
wouldn't
hurt
for
boats
that
both
sets
of
you
all
to
take
a
quick
look
at
that
just
so,
we
can
properly
answer
that
question.
Daniel
do
want
to
go.
I
Yeah
so
could
just
flip
back
to
Marcus's
slide
on
on
what
the
changes
are.
There
we
go
yeah,
so
I,
Ames
Ames,
after
speaking
with
my
co-authors,
on
these
proposals.
I
think
I
am
I
I'm
speaking
for
myself
and
them,
but
not
necessarily
for
the
working
group
as
a
whole.
So
I'm
going
to
address
these
in
roughly
reverse
order
on
the
so
on
the
oh
and
they
always
include
unique
identifiers
thing.
So
no
objection
to
that.
I
I
Reducing
the
number
of
yet
equivalents
necessary
to
implement
this
in
an
FPGA
and
I
just
want
to
say
thank
you
for
bringing
this
up
because
by
all
I
have
played
with
FPGAs.
I
am
not
by
any
means
an
AE,
and
this
would
never
have
occurred
to
me
so
I
I,
intended
to
accept
this
change
and
I
am
I'm
happy
that
somebody
I'm
happy.
That
said
that
somebody
brought
this
up
before
I
went
to
the
iesg,
because
no
nobody
on
the
authorship
team
would
have
ever
thought
of
this.
I
That
not
TLS
one
three
is
has
has
some
implementations,
but
is
not
yet
widely
implemented,
and
even
once
it
is
widely
implemented.
It's
going
to
take
a
nut.
It's
going
to
take
another
few
years
for
that,
for
that,
for
that
work
to
to
to
make
it
into
OS
distributions.
I
So
as
much
as
I
would
as
as
much
as
I
hope
that
within
a
few
years,
everybody
has
moved
to
TLS
one
three
anyway.
I
I
think
that
I
think
that
putting
in
a
requirement
now
is
going
to
inhibit
NTS
adoption
on
the
on
the
on
the
proposal
for
the
separation
of
of
NTS,
ke
and
NTP
servers
by
adding
that
adding
that
negotiation
record
after
some.
I
My
first
thought
on
this
is
that
this
would
be
something
better
to
do
in
in
DNS
SRV
records,
rather
than
it's
part
of
the
protocol.
The
Ragnar
talked
me
out
of
talked
me
out
of
that
cannon.
Convinced
me
that
this
approach
is
better.
However,
I
have
I
have
base
I
have
a
slight
objection
to
the
to
the
current
form
of
it.
We're
in
this
we're
in
this
this
this
record
provides
an
ipv6
address
which
may
be
in
v6
and
apt.
Ipv4
address
that
record
should
instead
provide
a
should.
I
It
should
instead
provide
a
provide,
a
hostname
string,
something
that
you've
something
you
can
pass
to
get
a
tour
info
and
there
should
be
a
complimentary
record
for
for
a
service
string.
So
if
you
don't
get
the
host
string,
then
the
default
is
to
cut
is
to
is
to
contact
the
ntp
server
at
the
same
place
as
the
NTS
ke
server.
And
if
you
don't
get
the
service
string,
then
the
default
is
to
use
port
one.
Two
three.
Q
Moulton
levy
CloudFlare,
so
I
was
trying
to
look
up
the
exact
URL,
but
there's
some
pretty
good
library
support
for
TLS
one
three,
and
we
do
that
I'm
trying
to
find
the
blog
entry
that
we
did
that
sort
of
talked
about
the
different
implementations.
So
if
you
think
about
this
as
being
libraries
that
can
be
easily
found
and
added
to
a
codebase,
then
one
three
doesn't
seem
to
be
that
much
of
an
issue
and
this
isn't
meant
to
be
accessed
directly
from
a
browser
but
from
libraries.
Q
R
If
you
want
some
full
disclosure,
I'm
I
am
affiliated,
but
not
with
the
guys
who's
done
this,
but
not
directly
mode
with
the
project.
So
I
was
gonna.
Try
to
argue
both
sides
of
the
TLS
issue,
yes
for
fun,
so
I
can
actually
see
your
point
I.
Think
in
there
are
it's
very
likely
that
when
you,
when
you
deploy
something
like
this
or
build,
distribute,
sounds
like
this
you're
gonna,
you're
gonna
rely
on
the
operating
system.
R
R
I
can
I,
don't
remember
who
made
it
right,
but
but
the
point
was
that
yeah
yeah,
this
sort
of
thing
was
a
lot
worse
and
tell
us
before
TLS
1.3,
when
we
figured
out
how
to
encrypt
all
of
the
relevant
traceable
identifiers
and
that
I
think
you,
it
might
be
a
good
idea
to
actually
go
back
and
investigate
you
know
what,
if
any,
is
here,
because
TLS
is
one
real
thing.
The
own
MTP
is
one
of
those
things
that
you
can't
really
like
not
have
running,
and
it
will
be
it
will.
R
I
So
I
think
we've
all
I'm,
so
I
I'm,
pretty
sure.
We've
we've
take
we've
taken
the
privacy
issues
into
account
so
right
when
I,
when
I,
when
I,
when
I,
when
I
when
I
when
I
designed
the
cookie
scheme
in
NTS
I
was,
I
was
quite
deliberately
copying
what
TL
s13
does
with
session
tickets
and
then
for
the
basic
parts
of
ntp
for
the
non-ips
parts
of
ntp.
That's
what
that's
what
my
I
didn't
date.
A
minimization
draft
is
for
all.
R
Right
that
that's
excellent
right
in
that
case,
maybe
that
part
of
my
argument
is,
will
die
in
that
case,
I'm
sort
of
I'm
still
sort
of
in
practical
terms,
I
think
implementers.
You
know,
even
if
you
read
this
aspect
that
says,
must
use
this
or
that
version
right
in
practice.
That's
going
to
be
configuration.
L
Brian
Everman
and
just
to
kind
of
I,
don't
know
if
I'm
reinforcing
what
ladies
just
said,
but
I
double-checked
with
a
couple
of
people.
You
know
TLS
one
three
is
already
seen
in
implementations
on
the
Internet
and
you're,
not
really
trying
to
deal
with
backwards
compatibility
with
an
existing
implementation.
That
might
be
using
one
point
two.
So
one
point
three
probably
is
the
right
way
to
do
it
because.
S
I
I
We
discussed
this
in
the
hall
yesterday
and
the
conclusion
is
that
it
is
quite
difficult,
probably
some
sort
of
blockchain
thing
needed
in
order
to
enforce
that
in
order
to
enforce
that,
everybody
is
being
handed
the
same
private
key,
the
same
public
keys
that
you
can't
discriminate
them
discriminate
between
them
that
way,
but
so
almost
certainly
not
going
to
be
resolved
in
this
main
document,
but
maybe
something
event
amiss
for
future
extensions.
Sure
and.
S
Then
a
question
to
people
implementing
highly
scalable
NTP
server
offerings.
One
thought
on
avoiding
unlink
ability
is
to
do
key
exchange
more
frequently,
that
has
performance
impacts
and
I'm
curious.
If
anyone
has
any
comments
on
what
might
be
some
appropriate,
maybe
recommendations
or
something
about
a
key
exchange
frequency
that
might
be
appropriate
for
people
who
wish
to
provide
a
link
ability
from
the
perspective
of
the
server.
So
that's
an
open
question
to
the
group,
I
suppose.
E
As
Kent
I've
made
just
because
nobody
else
mentioned
it,
I'm
very
much
in
favor
of
the
changes
to
a
way
to
separate
the
key
exchange
from
the
inter
P
server,
in
particular
for
my
hobby,
Potter
est
interview
pool
and
we
have
other
how
many
into
beakers
a
second
probably
nice,
to
be
able
to
subscribe
them.
A
bit
de
vide
MTS.
C
I
You
take
a
to
list
yeah,
let's,
let's,
let's
take
everything
discussed
your
list.
Okay,.
B
I
B
B
B
B
B
P
Okay,
so
I
went
out
for
for
last
call.
There
are
a
number
of
comments,
mostly
the
little
things
like
grammar,
that
needs
to
be
fixed
to
do
cut
and
paste
errors
or
whatever,
and
also
a
couple
of
things.
Work
has
to
be
clarified
or
explicitly
mentioned
nothing
that
changes
the
way
the
protocol
operates.
So
I
think
we
can
address
all
these.
P
Okay,
one
thing
was
suggested
by
Karen,
actually
is
to
add
into
a
statement
to
this
effect,
so
there's
a
section
for
which
is
a
problem
statement,
which
is
the
first
section
where
we
say
we're:
defining
a
PTP
profile
and
I'm
gonna.
Add
this
statement.
Interoperability
among
if
independent
implementations
of
this
PGP
profile
has
been
demonstrated
at
the
is
PC
has
plugged
this,
so
the
less
and
I'll
be
have
a
slide
on
that
later.
P
P
There
was
a
question
about
there's
a
in
the
PGP.
Every
message
carries
a
log
log
base,
two
message
interval
indicator
and
it
was
suggested
that
in
a
delay
response
message
rather
than
having
the
normal
7f,
which
is
generally
used
for
unicast
and
PTP,
that's
a
value.
It's
what
it
means
is,
if
you
see
a
7f,
that
means
that
rates
have
to
be
negotiated,
but
since
we're
not
negotiating
we'd
give
the
option
of
instead
of
putting
7f
and
the
master
port
could
say.
This
is
the
rate
I'd
actually
like
to
have.
P
P
B
B
G
So
hi
I'm
Nathan,
thanks
for
the
introduction
and
I,
would
like
to
know
how
to
take
it.
Easy,
don't
work
with.
Oh
my
Deutsch
starting
to
live
and
massage
Pyrrha
and-
and
we
also
talked
about
with
so
I'll-
get
the
things
to
speed,
I
guess
the
other
and
that
we're
going
to
focus
a
Mary
on
two
of
the
processes
in
the
NTP.
The
pool
process
with
a
clan
gather
about
the
selection
process,
where
he
and
select
the
best
time.
However,
we
know
that
enemies,
Kalevala
vulnerable
to
many
Takeo,
a
tempered,
an
NTP
response.
G
You
can
also
change
the
kind
of
time
I
simply
drop
in
on
the
pockets
at
your
for
my
service.
That
is
why
an
authentication
here
is
insufficient
and
reduce.
That
is
consider
when,
in
the
middle
is
too
strong
phone
to
be,
but
I
saw
a
vulnerable
if
we
focus
on
the
apoptosis
and
the
selection
process
so
and
if
both
bosses
to
rely
on
small
and
number
of
entity
servers
and
they're,
often
the
in
a
sketch,
which
means
that
they
attack
your
own,
manage
our
abilities.
G
Many
milk
of
about
this
rate,
respect
of
few
entities
servers
in
order
to
maintain
his
attack
over
time
and
in
the
selection
process
algorithm.
They
assume
that,
of
course
he
are
rare
and
most
of
the
entity.
Responses
are
well
distributed,
one
to
see
which
means
that
powerful,
sophisticated
milk
and
whiteness
this
algorithms
and
he's
done
this
cup
of
traditional
models.
This
is
why
we
proposed
a
modified
MVP
client
called
Chronos
every
with
provable
security.
We
can
bound
the
probability
of
successful
time
shooting
index
even
made
by
Tucker.
G
It
has
Beco
ability,
since
there
is
not
even
mean
to
change
anything
in
the
server
side,
only
limited
software,
and
it
is
in
the
client
side
and
it
had
only
low
computational
and
communication
overhead,
since
we
eventually
query
only
few
and
hippie
service.
So
in
order
to
aim,
they
proved
that
night
cross
protect
ntp
and
we
need
to
define
treat
model.
G
We
imitate
attacker
here
has
fully
control
all
the
large
function
of
the
epics,
a
pulse,
a
quarrel
that
is
when
he
can
decide
both
the
content
and
there's
a
time
when
the
responses
are
going
to
arrive
to
defined.
And,
of
course,
we
simulate
his
malicious
and
try
to
make
the
maximum
time
shift
occur
so
how
policies
build.
On
the
one
hand,
we
rely
on
their
aim.
Many
NTP
servers
will
generate
large
pool
of
existing
and
servers
in
order
to
raise
the
threshold
needed
by
the
attacker.
G
On
the
other
hand,
requiring
only
few
of
them
that
I,
randomly
choosing
I,
be
updating
around
terms
normally
that
you
avoid
overloading
their
NTP
servers.
And,
finally,
we
use
small
in
order
to
remove
outliers
and
like
hard
to
demand
middle
Chi
contaminates.
The
cheese
in
thousands
so
informally
and
I
will
describe
how
and
declined
update.
Look
so
out
of
hundreds
of
servers
and
tens
are
honorable
chosen
and
they
are
ordered
from.
G
G
So
basically,
what
we
are
showing
Iowa
paper
is
that
shooting
time
it
was
Hana
c4,
even
100,
millisecond
from
the
UTC
will
take
the
attack
here
at
least
20
years
next
recession,
and
this
is
what
I'm,
considering
the
extreme
case
at
what
we
have,
but
seven
more
fully
controlled
on
it.
We
also
may
see
much.
We
can
we're
expecting
it
service,
berry
and
good
samples,
always.
G
And
the
parameters
of
the
remote
server
and
we
can
achieve-
and
this
turns
of
good
server
examples,
probably
see
it's
a
Porsche.
Only.
The
experience
that
we
conducted
in
May
Amazon
service
was
in
Europe,
and,
and
here
you
can
see
the
benefit
of
using
OCONUS
over
the
the
content
to
be
as
a
function
of
the
number
of
servers
that
we
query
clear,
our
and
so,
for
example,
if
you
will
focus
on
an
area
where
we
have
five
hundred
servers
and
seventh
of
whom
are.
G
Now
I
will
security
analysis
so
out
of
hundreds
of
servers,
mr,
are
choosing
randomly
and
from
each
side.
So
when
we
are
looking
at
all
this
noise
that
can
happen
and
take
there
was
kissing
honor.
In
any
scenario,
listeners
are
going
to
depend
on
the
number
of
malicious
service
that
will
work
very
so
the
first
area
is
one.
The
number
of
good
suppose
is
a
equal
or
less
the
day
and
the
number
of
samples
is
and
higher
than
MIT.
G
So
in
the
worst
case,
we
have
only
registering
in
our
running
set,
but
according
to
our
second
condition,
it
should
be
closed
today,
a
science
time,
which
means
that
we
found
the
the
maximal
ship
that
we
allowed
in
the
Kalos
client,
and
we
have
to
note
that
this
noise
probabilities
extremely
long
since
we
required
malicious
server
to
be
a
randomly
chosen
in
much
higher
rate
than
the
reaching
the
population
and,
of
course,
repeated
shift
is
negligible.
G
That
is
why
we
can
say
that
that
significant
time
shift
here
is
infeasible
and
the
second
scenario
is
doubles
each
one
when
we
have
more
than
a
and
do
deep
samples
unless
them
amongst
the
best
samples-
and
so
the
first
option
is
that
we
have
only
a
server
here
and,
however,
we
have
more
than
bigger
samples
they.
So
we
have
right.
G
G
However,
according
to
our
first
condition,
all
the
samples
in
there
many
said
should
be
close
to
each
other,
which
means
that
again,
we
have
one
good
sample
Omega
from
TCC,
so
all
the
samples
should
be
close
to
do
is
you
see
and
the
average
between
order
to
a
bitter
o'clock,
eventually
a
it
will
be
close
to
the
you
see.
This
is
why
we
can
say
that
these
strategies
are
ineffective.
G
And
can
Vala
it's
one
of
our
condition
hasn't
caused
us
every
sample
and
we
sampled
again
again
will
be
it
will
cause.
A
panic
attack
were
worried,
all
the
serving
in
the
in
the
pool,
and
maybe
most
people
a
panic
mode
for
multiple
chronic
clients
can
create
a
business
Saturday
attack
on
over
there
NTP
servers.
G
However,
we
saw
that,
even
if
we're
sending
low
panic
threshold,
which
means
that
only
after
three
times
we
remove
the,
depending
on
the
probability
of
successful
and
of
shifting
a
1tb
client,
it's
negligible,
which
will
take
the
attacker
years
and
to
cause
us
to
and
to
move
to
the
back
to
the
panic
part.
Another
note
that
I
would
like
to
I
think
that
there.
R
G
Scenarios
where
we
don't
have
a
lot
of
servers
in
the
program
and
then
a
scheme
can
pool
and
yield
and
the
deterministic
security
guarantees
instead
of
probabilities
and
kind
of
some
of
the
the
differences
between
columns
and
and
being
honest
processing,
where
we
gather
all
the
existing
time
and
20
P
server.
Sorry
in
order
to
them,
while
the
content
repeat
service
and
the
selection
process
in.
G
G
Their
average,
but
never
to
the
remaining
set,
but
one
is
that
it's
not
only
if
the
average
is
closed
today
to
the
client's
time
clock
only
if
it's
far
from
the
clients
time
and
so
to
conclude,
you
notice
that
NTP
is
very
vulnerable
time.
She
texts
especially
made
when
many
mills
it's
it,
wasn't
designed
to
protect
it
and
it
from
succeeding
men
in
the
mill.
So
we
present
a
constant
if
ax
client,
a
with
probable
security
and
backward
ability
and
low
computational.
I
We
can
get
a
maximum
air
out
of
the
protocol,
which
is
basically
1/2
the
round-trip
time
and
the
max
disappear
felt
it
built
into
this
built
into
the
NTP
algorithms,
especially
how
large
that
round-trip
time
can
be
before
we
reject
it.
I
think
in
our
FC
5905,
it's
1
seconds,
I,
think
I
think
the
N
PFF
limitation
is
has
has
changed
that
to
one
and
a
half,
but
anyway,
there's
there's
already
an
upper
bound
there.
I
So
if
we
get,
if
we
go
with
that
with
that
with
them,
one
with
the
max
test
is
one
second,
and
that
then,
that
upper
bound
does
have
a
second
I,
don't
quite
understand
how
Chronos
improves
on
that
bound
in
the
MIT
in
the
in
the
man-in-the-middle
case.
If
a
man,
the
middle
is
delaying
is,
is
delaying
all
your
traffic
in
one
in
one
directions
that
everything
comes
back
in
just
under
a
seconds
then
does
Chronos
still
get
time
with
an
error
smaller
than
half
a
second.
G
First
of
all,
we
hope
so-
and
this
is
what
we
started
to
see
really
what
currency
that
we
get
in
and
as
matters,
however,
and
according
to
what
you
were
saying
about,
NTP
have
threshold,
and
so,
though,
there
was
a
working
in
2016
by
showing
all
demand
that
show
that
M,
you
can
shift
the
NTP
clock
by
one
year
by
attack.
And
you
know
you
don't
need
to
me
to
be
man
in
the
middle
attack
here
and
just
to
attack
for
around
100
days.
G
I
I
may
be
remembering
the
wrong
one
of
Sharon's
papers
or
remembering
it
incorrectly,
but
I
could
have
sworn
that
that
those
that
that
that
those
attacks
that
gave
you,
those
big
shifts
were
all
exploiting
implementation
bugs
and
so
I.
It
remains
my
belief
today
that,
when
everything
is
correctly
implemented
and
that
and
that
you
have
a
and
and
that
a
majority
of
responding
servers
are
honest,
that
you
that
that
you
get
the
half
second
upper
bound
on
clock,
shifting.
G
Know
that
part
of
the
work
that
I've
been
done
on
this
subject
really
am
look
at
implementation
flaws,
but
I
think
that
there
is
more
to
it,
because
maybe
we
can
add
another
point
of
view.
The
saying
we
are
not
automatically
thinking
in
out
of
six
NTP
servers
and
may
allow
them
to
shift
us
for
a
time
for
a
long
time.
But.
I
Yeah,
so
it's
so
if
you
had,
if
you're
dealing
with
just
it
with
just
a
minority
of
dishonest
servers,
and
at
that
that
then
then
then
I
do
see.
How
Kronos
gives
gives
you.
So
it
gives
you
some
improvement
Vietnam
to
take
to
get
bounced
tighter
than
have
a
second
but
I
I'm,
not
I'm,
not
convinced
that
it
does
anything
when
you're
dealing
with
a
phenomenal
attacker
or
a
where
a
majority
of
dishonest
service
I
think.
G
That
the
problem
is
it's
not
half
a
second,
because
it's
half
a
second
over
time,
so
I'm
not
looking
at
I,
mean
I'm.
Looking
at
how
many?
How
far
can
you
get
and
in
the
Corinth
MTP
I
mean
I
can
shift
and
if
I
mean
that
I
can
shift
this
time
by
tiny
steps,
maybe,
but
for
a
long
time.
So
eventually,
I
will
succeed
you
to
to
make
a
huge
time
shift.
P
Arnold
from
mine
burg,
just
a
couple
of
comments
I
want
to
make.
First
of
all
real
networks
in
the
field
are
full
of
implementation
errors.
We
try
to
close
them
up
as
much
as
we
can
but
they're
out
there,
but
the
other
thing
is
real
networks
have
all
kinds
of
things
running
besides
ntp.
So
when
we
look
at
house
impervious
to
man
in
the
middle
of
attacks,
we
need
to
make
it.
It
only
has
to
be
less
trouble
than
other
key
protocols
that
are
running
we'll,
never
make
it.
G
Well,
I
suppose
it
I
can't
understand
right,
I
think
that
we
should
do
our
best
to
secure
protocols,
both
ntp
and
others,
and
this
is
why
I,
don't
you
let.
T
You
hear
me:
yes,
go
ahead,
oh
great,
first
time,
I'm
using
it
this
IDF,
okay,
my
question
has
to
do
with
the
trade-off
between
security
and
timing
accuracy.
G
Right
in
in
order
to
to
get
a
frequency
and
and
delay
you
usually
take
for
updates,
for
example,
a
a
per
and
for
each
for
each
time
server,
and
so
what
we
are
a
study
right
now
is
how
we
can
combine
this.
We
can
both
use
Juanes
and
still
have
a
will
that
we
will
be
able
to
be
both
precise
and
and
accurate.
So
no,
you
won't.
T
Be
more
precise
because
you're
not
estimating
the
particular
path
between
the
client
and
the
server
over
a
long
enough
time
for
any
particular
server
in
order
to
get
the
real
minimum
of
the
of
the
delay
so
you're
going
to
be
hitting
it
I'm
just
wondering
if
you
made
an
expense,
an
experiment
where
there
were
no
men
in
the
middle,
no
bad
servers
and
just
check
to
see
what
the
performance
it
is.
Yeah.
G
We
know
we
respect
that
this
in
protocol
to
be
sort
of
suboptimal
in
a
currency.
This
is
why
a
and
we
would
like
to
the
to
present
its
work
and
and
try
to
combine
it
with
within
the
current
ntp,
and
not
just
you
say.
Instead
of
all
the
selection
process,
we
are
going
to
change
it
all
by
just
adding
corners
would
like
to
add
corners
to
the
content
EP
in
order
to
maintain
the
precision
and
I
can
see
that
we
get
from
the
current
one.
G
D
Just
because,
if
you
are
changing
changing
the
servers
it
could
be,
it
could
be
get
more
error
in
in
in
every
time,
calculation
it's
more
or
less
related
with
the
question
about
of
Jakob.
This
is
the
idea,
because,
if
the
time
change
and
okay,
you
have
traffic
into
the
network,
and
so
on,
this
is
this
is
my
my
comment
about
that.
Thank
you.
M
M
M
I'm
not
sure
I
would
use
the
word
reputation
there,
because
we're
not
using
servers
based
on
their
reputation.
We
get
the
pool,
will
offer
servers
based
on
reputation,
but
once
we
hit,
but
once
ntpd
has
them
it
selects,
which
ones
to
use
based
on
actual
performance
and
if
performance
begins
to
deviate,
those
servers
are
thrown
away
and
new
servers
are
solicited,
and
that
happens
dynamically.
M
So
there's
the
ongoing
monitoring
the
pool
does,
which
says:
they're
not
a
given
server
is
even
going
to
show
up
in
the
pool
and
then
once
a
the
pool.
Members
are
selected
by
a
given
ntpd
instance.
That
instance
decide
which
one
decides
which
of
those
servers
to
pay
attention
to
and
which
ones
to
ignore.
G
I
mean
in
our
scenario:
the
attacker
control
have
fallen
control
over
the
NTP
servers,
a
fraction
of
them,
and
what
we
suggested
is
ok,
still
look
at
the
jitter
and
stratum
and
another
a
checks
that
the
content
EP
does,
but
maybe
even
if
certainly
a
server
passed
all
these
checks,
maybe
you
can,
you
can
still
and
identified
it
as
an
attack.
Harry
fees.
M
B
E
Mess
Kenson,
I
guess
in
this
context,
I
maintained
a
into
people
thing
I!
Think
it's
a
lot
of
fun
when
people
do
work
like
this.
Nobody
ever
tells
me
before
and
I'm
happy
to
like
give
your
server
list,
for
instance.
So
if
any
of
you
here,
people
who
are
working
on
this,
this
sort
of
things
I'm
happy
to
to
help
figure
out
how
to
make
it
better.
I
think
Holland's
question
was
sort
of
related.
What
I
was
coming
on
that?
E
It's
not
that
you,
both
the
man
in
the
middle
attack
is
possible,
but
the
order
attacked
as
possibly
it's
just
a
bad
actor.
There
are
someone
else.
Writing
a
paper
some
early
this
year.
Think
about
that
where
you
have
a
bad
actor
joining
into
the
pool
and
tending
to
the
monitoring
system,
depth,
AI
healthy,
serve
effort,
pretending
to
certain
clients
that
they're
not
and
in
most
countries
I
think
right
now
how
it
works
in
most
countries
him.
E
But
Holland
is
five
with
the
pool
directive
in
what's
a
Dennis
I
think
said
before,
with
the
bill
until
into
PD
softwood,
so
it
just
worked,
but
in
some
countries
there
very
few
servers
and
something
like
what
you
were
describing
in
which
bonus
would
absolutely
heal
a
keep
time.
Accurate.
Okay,
thank
you.
Thank
you
for
doing
the
work.
It's
fun
there.
P
Mine
Berg,
you
know
thank
you
as
well.
This
is
very
interesting
I
and
the
subject
of
accuracy.
Certainly
changing
servers
frequently
is
going
to
at
a
certain
Jenner
to
the
server
loop,
but
it
might
also
help
average
out
some
quasi
static
or
static
asymmetries
in
the
network.
So
it
might
be
something
to
think
about.
Okay,.
B
Okay,
yeah.
B
T
Just
one
last
remark,
and
that
is
about
the
extensions,
take
into
account
that
if
you're
going
to
be
looking
at
1588
in
certain
applications
of
1588,
where
we
need
high
accuracy,
it
can
take
literally
an
hour
or
more
and
with
looking
at
a
particular
connection
until
the
accuracy
gets
into
the
area
we
want
and
if
you're
going
to
be
looking
for
a
short
amount
of
time
and
jumping
to
a
different
there.
It's
not
client-server,
obviously
to
a
different
connection.
T
You're
not
going
to
get
anywhere
near
the
accuracies
that
that
we're
talking
about
unless
you
do
one
big
PLL
and
look
at
all
of
them
and
wait
them
all
and
somehow
do
something
very.
Very
sophisticated
and
I
have
seen
such
an
Al
Gore
in
the
past
and
perhaps
actually,
if
you're,
here,
right
now,
I'm
sitting
in
Jerusalem
by
the
way.
So
maybe
some
time
I
can
just
jump
over.
We
can
have
a
discussion
all.
I
On
all
these
accuracy,
issues
we've
been
discussing,
I,
don't
think
we're
going
to
get
anywhere
at
all
by
arguing
about
them.
This
is
a
place
where
there's
there's
just
no
substitute
for
some
for
some
empiricism.
Yeah.
B
S
Ahead
I'm
wondering
if
you
have
thoughts
on
best
practices
for
bootstrapping
the
list
of
that
the
set
that
you
choose
servers
from,
because
this,
the
security
balance
are
not
just
ntp,
is
not
the
only
thing
within
your
chosen
computing
base
for
this
system
as
a
whole.
You
also
have
presumably
DNS
or
something
equivalent
and
I
was
wondering
if
you
have
thoughts
on
ways
which
on
how
to
securely
bootstrap
that
set.
G
B
Quickly,
I,
don't
think
you
sign
this,
so
can
I
think
when
you
go
back.
If
anybody
else
hasn't
signed
the
blue
sheet,
can
you
get
it
from
her
after
she
signs
it?
Alright,
so
the
next
set
of
topics
that
we
have
are
related
to
ref,
IDs
and
extension
fields
and
there's
a
whole
list
of
drafts
that
are
associated
with
them.
So
we're
gonna
start
with
the
ref
ID
topic.
B
B
The
proposal
that
Sharon
and
I
had
talked
about
coming
into
this
was
to
separate
out
the
not
you
and
ipv6
and
and
I
I
know
and
I
apologize
to
the
working
group
that
I'm
the
one
that
suggested
we
put
all
the
ref
ID
updates
in
a
single
draft,
but
a
year
or
so
down
the
road
I'm
I'm
thinking.
That
was
probably
not
the
best
idea.
So
we're
thinking
about
separating
out
not
you
and
ipv6
from
leap,
smear
and
having
the
two
pieces
of
work
advance
separately
and
Sharon
is
not
not
going
to
be
here
today.
M
M
There
was
a
different
US
and
there's
a
suggested
breath.
Id
also
that
also
that
corresponds
to
the
not
you
or
is,
is
orthogonal
or
similar
to
not
you
they're.
There
they've
been
around
for
a
couple
of
years.
These
are
options
that
people
can
use,
we're,
trying
to
specify
a
mechanism,
and
let
people
use
local
policy
choices
to
decide
what
to
do
not.
You
basically
means
that.
M
M
The
purpose
of
not
you
is
that
if
I
think
I
have
enough
information,
I
can
let
you
know
that
you
aren't
my
system
here
and
that
works
great
if
it
works.
If
it
doesn't
work,
Sharon
just
made
a
change
to
this,
to
make
it
more
clear
that
there
is
a
chance
that
that
I
don't
know
something
important.
So
I
may
say
it's
not
you
and
it
really
is
you.
The
ipv6
ref
ID
change
comes
from
a
report.
M
We
actually
had
where
the
current
md5
hash
of
an
ipv6
address
turned
out
to
look
just
like
an
ipv4
reference
for
a
different
machine
in
the
providers
network.
So
the
ipv6
ref
IDs
uses
the
first
octet
of
250,
something
which
is
an
impossible
value
for
an
ipv4
address,
and
that's
the
point
of
the
of
the
proposed
ipv6
ref
ID
and
the
reason
for
the
leap
Smee
RFID
is
that
an
increasing
number
of
time
servers
are
choosing
to
respond
to
client
requests
with
smeared
time
instead
of
accurate
time
and
we
the
last
leap.
M
B
B
M
B
J
A
couple
of
suggestions,
just
using
three
octets
for
the
ipv6
hash,
seems
like
we're
starting
to
spread
things
a
little
bit
thin
there.
So
my
suggestion
is
fill
the
ref
ID
with
all
zeroes
and
come
up
with
an
extension
field
is
actually
big
enough
to
accommodate
ipv6
or
better.
Yet
this
is
in
my
email
earlier.
I'm
have
notches,
negotiated
between
the
two
servers
and
then
use
those
notches
in
hashing.
J
J
Well,
like
Karen
I'm
unclear
what
the
suggested
ref
ID
proposal
refers
to.
So
if
that's
a
separate
document,
I've,
not
I've,
not
read
it
yet,
and
then
the
the
other
thing
that
I
was
I
was
going
to
say
is
the
whole
leap.
Smear
thing,
as
we
used
to
say
at
MIT,
looks
like
a
kludge
on
top
of
a
couch
in
the
paper
bag
and
the
reason
is
you're
you
trying
to
solve
something.
That's
not
really
your
problem.
J
C
Ok,
go.
I
Ahead,
yeah
I'm,
going
to
second
fill
up
on
a
couple
of
those
comments.
First
of
all,
on
the
on
the
ipv6
ref
IDs.
Those
should
really
just
go
into
an
extension
field.
The
proposal
as
it
stands
solves
one
problem
which
is
ipv4
v4
addresses
colliding
with
v6
addresses,
but
it
also
where
it
Liam
greatly
increases
the
probability
of
v6
addresses
colliding
with
each
other.
E
Asked
ensign
I
would
like
to
have
the
leaves
me
information
in
their
packets.
It
would
help
it'll
make
it
easier,
for
least
the
service
that
are
intentionally
doing
it
so
signal
that
they're
doing
so
in
the
leaf
seconds
just
so
incredibly
broken.
That's
anything.
Any
effort
to
make
it
work
better,
at
least
not
have
us
know
better
what's
happening
would
be,
would
be
good,
I,
don't
know
if
they
should
go
into
ref
ID,
but
they
will
be
nice
afternoon
somewhere
in
a
packet
right.
M
B
J
M
J
U
U
P
Dr.
Arnold,
mind
burn
you
coma
comments.
A
retired
officer
in
the
Army
recently
told
me:
it
takes
20
years
for
them
to
update
equipment
and
their
systems,
so
there
are
at
least
some
specialized
systems
that
are
have
a
very
long
time
to
be
updated.
The
other
thing
is
leap,
some
some
lates.
We
are
solving
something:
that's
not
our
problem.
When
you're
running
a
leap
sneer,
that's
not
you're,
no
longer
running
at
a
standard
time
scale,
that's
not
UTC
or
or
anything.
That's
a
standard
time
scale
you're
off
off
on
your
own.
P
B
B
M
M
B
All
of
them
are
at
the
same
level
of
document
maturity,
but
they're
not
so
we
would
like
to
separate
and
I
also
think
the
first
two
are
are
are
slightly
different
nature
than
the
leap
smear
one
I
think
the
leaps
mayor
is
doing
a
kludgy
thing
with
rough
IDs,
whereas
I
think
the
first
two
are,
you
know
a
reasonably
standard.
I
mean
they're
they're
sort
of
in
line
with
what
ref
IDs
were
envisioned
for
so.
B
J
J
M
B
B
B
C
N
There
are
basically
three
groups
of
changes
addressing
some
of
the
issues
raised
on
the
mailing
list.
One
change
is
that
the
fields
that
corrected
delay
were
shortened
from
64
to
48
bits
to
not
waste
so
much
space.
As
was
pointed
out
on
the
mailing
list,
eight
bits
were
cut
from
the
beginning
of
the
field
and
a
bit
were
cut
from
the
end.
This
means
the
resolution
has
decreased
to
about
1
picosecond
and
the
maximum
value
is
now
just
128
seconds,
the
corresponding
change
to
that
was
made
in
the
receive
and
transmit
correction
fields.
N
There
are
now
only
8
bits,
long
in
total.
This
saved
48
bits
in
the
28
octet
extension
of
field
from
that
16
bits
were
used
to
make
the
path
ID
and
original
ID
fields
longer
to
make
collisions
less
likely
and
remaining
32
bits
were
used
for
new
correction
fields
to
extend
the
route,
delay
and
Roo
dispersion
from
the
ntp
adder,
similarly
to
the
receive
and
transmit
Corrections.
N
This
improves
the
resolution
from
about
15
microseconds,
which
may
already
be
a
problem
in
correct
current
applications
to
1/4
of
a
nanosecond,
though
the
order
of
the
fields
in
the
extension
field
has
changed
so
fields
that
may
be
modified
in
the
network
are
together
at
the
end
of
the
extension
field.
I'm,
not
sure
if
this
makes
a
hardware
implementation
easier
or
harder,
but
I
thought
it
looked
better.
J
Yeah
Philip
again
I
have
to
say
I,
don't
understand
the
point
of
the
checksum
compliment.
Having
worked
for
two
different
routing
companies,
I
can
tell
you
that
recalculating
I
checked
some
when
you
decrement
the
TTL.
Isn't
that
much
work
you
don't
have
to
recalculate
the
whole
thing
you
you
have
to
convert
it
out
of
ones:
complement
figure
out
the
dealth
Delta.
J
N
H
Yeah
so
I
want
to
reply.
Tommy's
raha,
marvel
I
work
for
a
chip
vendor
and
we're
implementing
checksum.
Compliments
in
PTP,
for
example,
also
an
NTP
actually
and
the
reason
for
the
checksum
compliment
is
that,
like
Miroslav
said
you're
often
doing
sequential
processing,
where
you
break
the
packet
into
a
few
chunks,
and
then
you
process
each
chunk
and
you
send
it
okay.
So,
by
the
time
you
get
to
the
extension
field,
where
you
have
the
correction,
the
UDP
checksum
may
already
have
been
transmitted.
H
B
H
H
N
B
Okay,
thank
you
any
other
questions
for
Miroslav,
so
this
is
currently
and
and
an
individual
submission.
So
the
the
next
question
this
has
been
around
now
for
a
while,
we've
updated
it
a
couple
times.
We
will
do
a
a
I'm.
Not
will
do
a
call
for
working
group.
Adoption
on
the
mailing
list
is
that,
given
that
it's
1143
I'd
like
to
just
do
that
on
the
mailing
list
and
not
have
a
discussion
about
it
here,
because
we
still
have
a
couple
topics:
okay,.
B
B
J
B
B
B
B
Think
we're
at
the
point
where
we
need
that
we
we
need
to
make
a
decision
that
we're
either
going
to
adopt
this
work
and
move
forward
or
whether
we're
going
to
hold
off
on
any
changes
to
extension
fields.
Until
we
do
an
update
to
the
entire
document
set
for
NTP
and
Philip
is
dashing
back
to
the
microphone
one.
J
B
Okay,
so
the
next
steps
for
this
document
is
to
do
an
on
list
working
group
call
for
adoption,
and
that
brings
us
to
the
the
next
agenda
item,
which
is
the
additional
extension
field.
Proposals
and
I
do
appreciate.
Harlan
doing
all
of
these.
We
currently
have
four
additional
extension
field
proposals
that
are
in
the
data
cracker,
and
these
are.
B
Well,
they're
listed
on
the
slide
there.
The
the
question
I
had
for
you,
Harlan
was
I
was
willing
to
progress,
the
ones
that
were
basically
78,
22
compliant
and
the
ones
that
were
78
that
required.
The
changes
to
78
22
that
you're
proposing
I
wanted
to
defer
those
until
we
had
resolved
the
changes
to
78
22
I.
M
B
M
What
you
want,
then
we'll
go
ahead
and
I'm
happy
to
cap
use
the
wrong
word:
I'm
willing
to
go
ahead
and
throw
language
in
there
that
says.
I
can
find
a
way
to
throw
anything
in
there.
That
says
any
padding.
We
already
know
that
extension
fields
can
be
arbitrarily
padded
with
zero
bytes
for
any
purpose,
so
I'm
sure
we
can
I'm
sure
I
can
come
up
with
with
language
that
will
address
that
concern,
but
I
would
really
want
to
keep
that
really
want
these
things
to
move
forward.
Okay,.
J
B
And
it
may
be
that
that
some
of
the
things
that
you've
identified
it
I
think
some
of
the
opposition
comes
from
people
that
are
unhappy
with
the
changes
that
are
being
made
and
some
of
the
opposition
comes
from
people
that
just
don't
really
quite
understand
the
text.
Yet
so
that's
why
I
that's
why
I
specifically
asked
you
if
you
could
take
a
look
at
it.
J
J
B
J
B
Don't
understand
the
rationale
and
the
rest,
and-
and
the
other
thing
that
I
had
suggested
to
you
is
I,
really
suggest
you
go
back
and
look
at
the
set
of
slides
that
Harlan
did
for
the
March
meeting,
because
he
put
a
lot
of
work
into
clarifying
what
he
was
trying
to
accomplish
at
that
point
in
time.
Okay,.
B
The
the
NTP
draft,
an
NTP
extension
fields,
we're
going
to
do
a
call
for
adoption
on
the
mailing
list
and
we're
going
to
take
a
look
at
as
part
of
that
call
for
adoption
philip's
the
comments
Philip
sent
out
today
and
any
other
additional
comments
that
come
in.
So
that's
the
status
of
that
one.
The
other
four
need
to
be
updated
if
we
want
to
progress
them
now,
sooner
is
better
I.
Suppose
then
yeah.
M
B
B
Adoption
I
did
that,
because
the
file
name
was
named
in
such
a
way
that
it
wasn't
showing
up
in
the
ntp
part
of
the
data
tracker,
because
ntp
wasn't
in
the
file
name.
That
didn't
mean
that
it
was
a
candidate
for
adoption.
Above
all
of
these
other
documents
that
were
sitting
there,
it
just
meant
that
I
wanted
it
to
show
up
in
the
right
place
and
data
tracker.
So
I
will
mark
all
of
these
as
candidates
for
adoption
Harlan,
and
we
can
do
a
quick
working
group
call
for
adoption
on
them.
Thank.
B
And
I'll
try
and
do
a
better
job
of
paint
staying
on
top
of
data
tracker.
So
that's
what
happens
when
you
processes
and
tools
change
and
you
don't
alright.
So
that
brings
us
to
1153
look
at
that
any
other
business.
If.
M
M
M
M
The
whole
reason
for
which
was
already
was
simultaneously
mentioned
by
the
nice
folks
from
that
nod
having
to
do
a
separating
key
exchange
from
the
ntp
server.
The
other
proposal.
There
is
secure
network
time
which
basically
builds
on
the
top-down
architecture
of
ntp.
That
says,
there's
a
black
box
between
two
ntp
processes
that
does
key
exchange,
and
one
of
those
is
the
symmetric
key
file.
Auto
key
was
another
one,
and
the
other
proposals
do
very
similar
things.
M
M
Out
of
the
gate
will
support
client-server
symmetric
mode,
many
caste
and
multicast,
and
that
in
a
nutshell,
is
what
these
proposals
were
for
and
I
apologized
that
we
were
unable
to
come
up
with
a
working
demo
by
the
end
of
the
weekend.
But
we're
supposed
to
be
very,
very
close
on
that
I'm
done.
Ok,.
B
Thank
you
just
just
for
the
the
well
actually
I
said
this
on
the
mailing
list.
So
I
guess
it
doesn't
really
matter,
but
the
the
the
proposals
are
obviously
welcome,
but
we
do
need
more
written
detail
and
and
right
now,
there's
absolutely
there's
not
much
there
so
alright,
so
to
any
other
business.
No,
ok!
So
to
wrap
up
next
steps
for
the
working
group.
B
B
I've
picked
a
couple
weeks
of
opportunity,
and
so
the
objective
at
this
point
is
to
try
and
have
two
virtual
interims
between
now
and
Bangkok
and
and
hopefully
by
then
I'd
like
to
be
getting
a
lot
of
the
little
things
that
have
been
hanging
around
for
a
long
time
out
the
door.
So
anything
else
all
right.
Well
with
that,
you
have
three
minutes
left
in
your
day
in
your
in
your
it's
an
extra
three
minutes,
I
guess!
Thank
you
all
and
thanks
everybody.