►
From YouTube: IETF101-NTP_TICTOC-20180322-1550
Description
NTP TICTOC meeting session at IETF101
2018/03/22 1550
https://datatracker.ietf.org/meeting/101/proceedings/
A
B
C
C
B
C
C
D
C
You
can't
sit
up
here.
I
will
say
also
that
we
are,
it
hasn't
been
the
top
priority
thing,
but
we
are
planning
to
combine
the
two
working
groups
and
we've
been
talking
about
it
too
fast,
and
we
will
get
that
done
at
some
point.
So
this
is
the
note.
Well,
it's
the
new
note
well
that
you
have
seen
many
times
this
week.
C
E
E
C
C
F
F
F
F
F
So
if
you
leave
now
it's
clear
and
also
there
was
quite
a
bit
of
discussion
on
the
mailing
list
about
leap
seconds,
whether
they
need
to
be
included
in
the
specification
or
not,
and
actually
we
also
had
quite
a
bit
of
discussion
between
the
authors
about
this,
because
it's
not
a
trivial
issue,
but
we
decided
to
include
it
in
the
specification
template
so
right
now,
you'll
actually
see
a
subsection
there
about
whether
the
time
stamp
is
affected
by
leap
seconds
or
not.
So
there's
in
the
current
version
of
the
draft.
F
So,
first
of
all,
thanks
to
the
people
from
the
network,
Time
Foundation,
which
gave
us
good
inputs
about
this
and
in
general,
quite
a
bit
of
text,
was
added
here
so
now
the
section
includes
a
subsection
about
requirements
and
the
subsection
about
features
and
the
elements
so
we'd
really
like
some
feedback
about
that
next
slide.
Please.
F
Ok,
so
one
thing
we'd
like
to
discuss
with
the
working
group
is
a
possibility
to
split
the
draft
into
two
drafts
and
we're
considering
to
split
it
to
one
draft
which
includes
the
time
span:
time
stamp
specification,
template
plus
the
recommended
time
stamps
and
the
other.
The
other
draft
would
include
the
control
field
specification.
F
So
obviously
there
are
pros
and
cons
here.
So
obviously
we
started
out
as
a
single
draft,
because
these
two
things
are
tightly
coupled
the
control
field
and
it
defines
how
to
use
the
time
stamp
itself.
But
at
this
point
or
the
last
few
months
we
realized
that
the
control
field
specification
seems
to
have
a
life
of
its
own.
It's
it's.
There
are
a
lot
of
details
which
we
didn't
think
about
when
we
started
this,
and
it
seems
like
there's
quite
a
bit
of
work
that
we
want
to
to
do
about
this.
F
So
it
looks
like
the
first
part
of
the
draft,
which
is
the
time
stamp
specification.
Template
is
almost
ready
and
the
control
field
still
needs
a
lot
of
work,
so
we
are
considering
to
split
these
two
drafts.
If
that
is
the
case
and
assuming
that
people
think
that's
the
right
thing
to
do,
we
can
do
that
after
the
current
IDF
meeting
and
we
will
probably
be
able
to
send
the
first
part
into
working.
Your
last
call-
and
the
second
part
will
need
some
more
work
on
that.
G
Last
time
I
think
indirect
spoke
about
it.
There's
some
mpls
working
group
MPLS,
really
the
working
group
that
is
doing
a
different
kind
of
time.
Sam
and
I
thought
you
were
gonna
sync
with
him
regarding
that
and
then
like
do
a
division
by
so
like
same
thing
can
be
used
in
multiple
places.
At
least
I
understood.
That
was
there
like
the
conclusion
from
the
last
meeting.
G
D
H
H
I'm
looking
at
the
draft
man.
Excuse
me
for
not
keeping
up,
but
another
comment.
I
have
you,
you
don't
seem
to
differentiate
between
the
old
PDP
for
math
and
the
new
one,
and
the
reference
is
only
to
v2
and
the
what
you
call
truncate
is
actually
like.
Let's
say,
Y
1731
actually
references.
The
2010
help
me
2002
is
the
original.
The
v1
v1.
A
C
H
Yakov
again
I'm
just
reading
it
now
in
real
time,
since
this
is
a
document
which
we,
which
would
help
people
who
are
trying
to
use
time
stamps
who
apparently
are
not
used
to
them,
I
will
actually
prefer
a
single
document
rather
than
having
to
it
simply
is
more
load
for
someone
who
would
like
to
use
this.
So
if
you're
trying
to
help
people
put
it
all
in
one
place.
Obviously,
if
it's
a
constraint
that
means
that
it's
going
to
delay
the
document
too
much,
then
maybe
we
have
to
compromise.
C
F
Personally,
would
prefer
to
split
it
into
two,
but
I
think
you
know
we
had
some
discussion
between
the
authors
and
it
wasn't.
You
know
completely
clear
to
us
whether
it
would
be
the
right
answer.
That's
why
we
are
raising
this
as
a
question
to
the
working
group,
but
I
think,
like
Leah
Cove
said,
if
we
want
the
first
part
to
be
published
soon,
the
right
way
to
go
would
be
split,
the
two
documents
and
if,
if
we
prefer
to
have
no
self-contained
document
at
the
expense
of
having
it
earlier,
then
keeping
it
this
one
document.
H
Sounds
good
just
one
more
question:
you
have
again
looking
through
the
document
quickly
and
once
again,
excuse
me
for
not
having
to
look
at
it
ahead
of
time
in
MTP,
there's
also
a
difference,
a
time
difference
and
I,
don't
see
you
referencing
anything
how
to
do
that.
We
needed
a
delta
T
in
a
specification.
Is
that
part
of
the
scope
of
this
document.
D
C
Excellent,
so
moving
on
the
next,
so
the
the
conclusion
of
that
document
is
tau
is
going
to
send
an
email
to
the
mailing
list
asking
for
a
review
of
it
and
also
asking
whether
we
should
split
it
or
not.
I
think
this
document.
This
is
the
fourth
version
of
this.
There
was
two
versions
of
it
as
an
internet
draft
and
two,
but
this
is
the
second
version
as
a
as
a
working
group
document
I
think
it's
it's
time
for
everybody
to
start
taking
a
look
at
it
and
review
it.
Okay,
so.
C
C
Okay,
so
I
don't
hear
I,
don't
see
onchao
I'll
keep
an
eye
up
for
when
she
comes
on
online
I
will
bring
her
back
in
I.
Do
know
that
we're
in
that
sort
of
awkward
period
when
the
US
has
already
gone
to
daylight
savings
time,
and
you
all
haven't
and
I
already
know
that
one
person
I
expected
in
the
meeting
I
was
like
you
do
know.
It
starts
in
25
minutes
and
they
were
like.
Oh
no,
so
I
imagine
there
might
be
a
few
other
people
that
would
apply
to.
So.
D
J
D
J
But
sick,
so
I
I
think
the
document
is
in
a
very
stable
State
as
far
as
I
can
tell
it
captures
all
of
the
mode
six
commands
that
were
documented
in
RFC,
1305
I
believe
it
also
includes
a
couple
of
additional
commands
that
implementations
have
put
in
I
have
a
pending
change
to
address.
One
comment
on
security
requirement,
or
there
were
security
considerations
section
just
adding
a
reference
to
BC
p38
two
to
try
and
keep
malicious
mode
six
commands
out
of
the
off
your
server.
J
So
there
was
some
discussed
on
the
mailing
list
about
either
adding
new
commands
or
changed
the
way
they
work.
I.
Think
the
goal
of
this
document
is
to
stay
informational
and
simply
reflect
what's
been
implemented,
either
out
of
the
1305
specification
or
up
to
this
date.
I,
don't
think
it's.
If
we
were
going
to
change
the
mode
six
commands
I
think
it
would
require
a
whole
new
document
with
with
a
whole
bunch
of
other
considerations
put
into
it.
J
I
J
C
Right
so
with
that
lion
plans
to
publish
real
soon
so
there,
if
there's
anything
else
and
then
at
the
end
of
that
we
will
go
to
working
group
last
call
on
that
document.
So
ancho
is
back
online,
so
I
think
ancho.
You
need
to
get
in
the
virtual
queue
because
we
didn't
schedule
you
as
a
remote
presenter,
because
you
didn't
have
slides.
K
K
K
So
for
the
latest
Mac
draft,
there
are
two
main
changes.
One
is
to
the
language
with
we
had
some
confusion.
Some
doubts
about
must
ensured
in
section
in
the
recommendations,
a
recommendation
section
that
I
will
change,
and
the
second
was
the
second
change
was
in
response
to
Todd's
tal's
comments
on
his
his
the
interoperability
with
the
older
implementations
and
I
fixed
that
in
section
3.
So
those
are
the
only
two
changes
that
I
made
from
the
earlier
draft.
I
didn't
see.
Any
further
comments
will
be
addressed
for
the
in
front.
K
C
Itf
NTP
Mac
yeah,
so
it's
the
message,
authentication
code
for
the
network,
time
protocol
and
it's
basically
up
just
updating
the
algorithm
that
the
Mac
uses
so
I
think
this
one
has
been
around
for
quite
a
while
now
I
think
we're
probably
ready
to
move
it
on
is.
Are
there
any
questions
or
concerns
about
that
and
just
to
clarify
and
chaough,
you
had
no
further
changes
that
you
needed
to
make.
No.
C
K
C
D
L
Our
second
last
weekend,
exactly
okay,
the
goal
was
to
find
remaining
issues
in
the
current
and
yes
draft.
The
big
question
was
okay.
How
can
we
achieve
it?
So
we
started
and
operability
test
between
two
complete
independent
proof
of
concept
of
limitations
of
NTS,
and
actually
we
have
three
of
them
next
slide.
Please:
okay.
L
First
of
all
limitations,
so
first
implementations
mine
is
based
on
C++
14
and
it
support
platforms.
So
Windows
and
Linux
on
32-bit
architecture
are
supported.
Linux.
This
ARM
architecture
has
support
for
the
two,
so
I
can
use
NTS
for
small
single
circuit
boards,
like
raspberry
PI's,
to
transmit
secure
time
informations.
L
My
implementation
is
currently
92,
95
person
complete,
so
it's
the
working
on
the
protocol
side.
One
feature
is
missing
so
error
and
warning
because
and
CITS
key
exchange
still
need
to
be
edit,
but
it's
not
a
problem.
It's
more
informational
for
the
client.
Why
I
serve
on?
Maybe
reviews
requests
NTS
user
own
ATP
implementation,
so
this
implementation
was
provide
by
some
students
of
the
Phi
University
and
it's
it's
a
small
implementation,
but
it's
they're
useful
and
for
testing
purpose.
Perfect.
H
L
H
L
H
C
Do
have
actually
multiple
independent
implementations
now,
and
so
we
are
it's
it's
on
sort
of
the
back
burner
of
something
we
do
need
to
do
but
wait.
Yes,
you
are
absolutely
right.
We
do
have
that,
so
we
really
will
be
progressing
ntp.
A
full
standard
at
some
point
in
the
what
did
I
say
earlier
not-too-distant
next
little
while
well,
no
I
would
say
I
would
change
it
from
next
little
while
to
not-too-distant
future.
It's
somewhere
beyond
next.
A
C
L
L
L
And
the
ATP
message
exchange
over
MTP
for
the
client
side
finished.
The
solar
side
is
still
working
progress,
so
Daniel
writes
this
program
as
far
as
I
know.
In
a
couple
of
days
and
this
on
the
hey
Cosima,
this
was
the
very
first
test,
but
I'm
so
happy.
We
have
as
I'm
limitation
to
test
against
each
other.
Okay.
L
Today,
I
received
the
mayor,
so
the
establishment
is
ready
now
but
not
tested,
I
think
in
three
or
four
months,
maybe
in
the
next.
Second,
we
can
test
this
implementation
and
then,
if
we
have
more
resides
okay
next
slide,
please
ok!
Back
to
second,
what
we
see
is
the
small
setup
for
second,
so
we
have
ve
Westbury
PI's
single
board,
computers
on
plastic
cases.
L
L
L
To
the
test,
oh,
we
have
three
paths
to
test,
so
we
have
at
first
the
TLS
handshake
tears,
one
part
to
handshake,
maybe
later
to
s1
points
V,
but
could
one
point
to
and
other
words
we
have
the
MTS
key
establishment.
So
in
this
phase
a
client
and
server
expect
some
key
material.
Is
a
server
generate
some
cookies,
but
it's
who
is
a
client
and
we
can
close
a
connection
after
this
we
can
use
the
ntp
connection.
So
a
TS
secured
ntp
over
UDP,
the
client
put
a
cookie
and
the
message.
L
H
L
The
first
test
scenario
on
the
hackathon:
we
have
one
NTS
clients
the
sustain
its
implementation.
The
speech
you
test
against
my
MTS
server.
The
test
results
were
very
interesting
because
the
NTS
Kea
is
exchange
worked
perfectly.
We
found
some
small
parts
and
implementation.
We
fix
only
small
things,
but
NTP
connection
failed.
That's
the
first
time
because
my
implementation
was
wrong.
L
Next
slide,
please.
The
second
test
scenario
was
on
Tuesday
on
the
code
launch
this
test
we
tested
in
the
other
direction,
so
my
implementation
was
a
client
Daniel,
its
implementation
for
server,
and
we
tested
the
NGS
key
exchange.
This
was
successful
at
first
we
have
had
some
trouble
with
certificates,
but
we
saw
that
the
ntp
connection
is
not
tested
it
because
Daniel's
implementation
was
not
ready
to
test
at
the
moment.
Maybe
he's
finished
yet
I,
don't
know
you
can
see.
Ok
next
slide.
Please
ok.
L
Finally,
last
overview
of
the
results
you
see,
we
have
three
parts
of
the
communication.
We
have
six
test
cases
so
for
each
direction.
One
five
of
six
tests
we
are
successful.
One
test
is
outstanding.
Maybe
we
can
test
it
in
a
couple
of
days.
This
is
perfect
and
yes,
finally,
I
think
it's.
It
looks
very
good.
Okay,
next,
like
this
so
lesson
that
interoperability
test
is
pretty
important
to
find
him
issues
and
specifications
and
what
I
mean
is
misunderstandings
and
draft.
L
Yes,
it
looks
pretty
good
okay.
Next,
let
oh
yes,
okay!
Last
slide!
Yes,
on
the
left
side,
you
see
the
team
members
on
the
hecka.
Some
thanks
about
all
was
very
very
great.
It
was
a
great
experience
and
especially
for
Daniel
Biss
implementation.
I
know
it's
much
work
to
use
it
and
it
was
very
productive
and
where
we
would
be
nice,
so
our
code
is
online
on
the
github
repository.
So
my
code
is
on
Apache
2
license.
You
can
do
whatever
you
want.
Maybe
write
a
comment.
Maybe
it's
helpful.
L
C
So
a
couple
things
first
of
all,
I'd
just
as
a
reminder
to
the
remote
people
that
are
on
me
echo.
There
is
a
button
you
can
push
to
get
into
the
queue
and
I
forgot
to
remind
you
at
the
beginning.
I
Angeles
was
using
it
correctly
to
to
speak
earlier.
So
at
this
point,
does
anybody
have
any
questions
for
Martin
on
the
hackathon
effort.
A
C
C
We
do
hope
to
repeat
it
in
in
Montreal
and
so
I'd
like
everybody
to
be
thinking
now
about
what
what
pieces
of
it
or
what
kinds
you
know
how
far
along
your
implementations
might
be
and
what
kind
of
testing
we
could
do
in
Montreal.
Perhaps
we
would
this
this
one
was
really
about
just
getting
some
initial
code
on
the
table
and
getting
some
preliminary
testing
done.
You
know
we
didn't
do
any
in-depth
testing,
so
it
would
be
nice
to
do
to
a
little
bit
more
structure,
more
advanced
planning
next
time.
So
any
questions
or
comments.
C
So
at
this
point
let
me
ask
them:
did
you
get
that?
Okay?
So
so
we
have
sort
of
a
fork
in
the
agenda
at
this
point
Harlan
we
could
do
the
extension
field
draft
now
or
we
could
do
the
NTS
piece
now.
I,
don't
think
we
have
you
fully
set
up
to
be
a
remote
presenter,
and
so
my
suggestion
it
would
be
for
us
to
control
your
slides
from
here
and
for
you
to
get
in
this.
The
queue
like
a
regular
speaker.
C
C
M
J
M
M
M
M
A
M
M
M
A
M
H
M
M
M
C
Another
thing
I
just
wanted
to
mention
because
I
see
it
in
the
chat
is
Brian
has
mentioned
that
the
hackathon
deserves
a
section
to
be
added
to
the
NTS
draft.
Okay,
so,
and
he's
provided
weapons
here,
the
hackathon
up
that
deserves
an
RFC
79
42
section
to
be
added
to
the
to
the
draft.
So
I
just
wanted
to
call
that
to
your
attention
in
case
you
didn't
see
it
later
in
the
chat.
Okay,
thank.
C
N
C
C
O
O
O
So
the
purpose
of
the
trashcan
ntp
extension
fields
is
to
provide
an
auntie,
I'm
gonna
I
apologize
for
reading
from
the
slides.
You
get
a
part
packet,
parsing
algorithm
that
addresses
issues
for
parsing
ambiguities
based
upon
legacy
mac.
It
removes
mac
and
extension
field
length
restrictions
allow
a
shorter
es
than
what
we've
had
before
next
slide.
Please.
O
It
removes
the
requirement
that
extension
field
proposals
specify
Mac
algorithms.
It
adds
a
note
to
make
sure
that
an
NTP,
packets
and
extension
fields
need
you
know
it
should
be
less
than
the
network.
Mtu
provides
some
expansion
on
the
structure
of
an
extension
field
header
and
it
restructures
the
I.
An
extension
field
table
next
slide,
please
so
the
first
change
the
proposal
does
is
around
5906,
which
has
a
note
in
it
that
says,
extension
extension
field
longer
than
1024
bytes
are
ignored.
O
O
This
was
in
5905
and
got
removed
from
78
22,
so
we
were
moved.
We
followed
78
22,
removing
the
requirement
that
a
Mac
must
be
present
if
there's
an
extension
field,
but
we
note
that
a
Mac
must
be
present
if
a
packet
is
authenticated
and
we
note
that
the
maksud
be
either
a
legacy
Mac
or
the
extension
field
Mac
and
it
may
be
both
I'm,
not
ever
sure,
there's
a
good
reason
for
that.
But
hey
next
slide,
please
the
third
change
we
did.
O
We
removed
the
16
octet
minimum
size
restriction
on
an
extension
field,
because
shorter
extension
fields
are
occasionally
very
useful
and
efficient.
We
also
added
text
there
too.
Specifically,
let
folks
know
about
network
em
to
use
and
some
other
explanatory
descriptive
tax
on
next
slide.
Please,
the
fourth
one
has
to
do
with
the
NTP
extension
field
format.
O
We
copied
some
content
from
5906,
which
is
informational
to
standards
track
document,
and
we
note
that
the
error
flag
that
will
be
deprecated
soon,
because,
while
it
was
specified
for
use
by
Auto
key
Auto
key,
never
used
it
on
the
wire.
One
of
the
things
that
comes
up
is
some
people.
Are
saying
they
don't
want
to
have
to
look
at
an
extension
field,
the
first
two
octets
over
the
extension
field
and
treated
as
subtypes
flag?
O
O
There
were
length
restrictions
inserted
into
78
22
to
avoid
some
extension
field
map,
parsing
ambiguities,
and
in
this
document
we
showed
two
ways
to
avoid
the
parsing
ambiguity
completely,
and
we
also
show
that,
if
you
don't
feel
like
using
either
of
those
there
are,
we
offered
two
ways
to
demonstrate
that
the
parsing
ambiguity
isn't
a
big
deal
providing
pseudocode
for
those
two
examples.
If
you
don't
want
to
do
anything
to
keep
you
out
of
trouble
next
slide,
please.
O
There
are
there's
a
little
addition
to
the
pure
process
operation
to
accommodate
the
fact
that
the
Mac
should
soon
be
available
as
an
extension
field,
instead
of
just
a
legacy.
Mac
next
slide.
Please
vii
change
is
that
we
just
move
some
information
from
5906
to
a
standard
track
document,
and
that
goes
to
you
can
read
I'm
pretty
sure
the
Mac
digest
lengths
go
into
there
and.
O
Okay,
I'm
sorry
I
was
looking
at
the
chat
window
to
make
sure
everybody
is
doing.
Okay,
the
Mac
digest
length.
We
clarify
some
stuff
there
and
we
talked
about
the
the
key
ID
ranges
in
the
key
ID
field.
There
are
some
information
about
auto
key
protocol
messages
that
is
actually
pertinent
to
NTP
itself,
not
just
Auto
key.
We
talked
some
about
error
recovery
and
some
other
items
that
ended
up
in
5906.
That
really
were
more
general
and
then
we.
O
Restated
the
Ayana
table
for
extension
field
type
reservations,
knowing
that
we're
planning
to
get
rid
of
the
error
bit
and
that
table
also
includes
the
checksum
complement
stuff
for
whatever
it's
worth,
I
updated
the
drafts,
10
NTP
extension
fields,
document
I,
think
it
was
last
night
and
I
got
rid
of
some
historical
information
that
is
not
really
useful,
anymore,
apparently
and
I
fixed
the
table
to
be
consistent
with
what
it
was
in
an
earlier
in
the
original
form.
Next
slide,
please!
O
C
P
Jared
montz
from
Akamai,
so
I
think
with
slide
three,
but
you
don't
need
to
change.
You
know
because
you're
number
one
the
extension
fields
longer
than
1024
octet.
Is
there
a?
Is
there
a
max
size
because
there's
a
discussion
unfortunately
can't
remember
which
working
group
earlier
this
week
about
dealing
with
fragmented
packets
and
what
operator,
what
network
operators
do
with
fragmented,
packets
and
I
want
to
just
have
an
idea
of
where
this
is
and
how
how
you're
gonna
handle
packet
fragment
reassembly.
P
O
O
This
proposal
specifically
adds
a
sentence
in
there
that
says,
while
you
can
have
a
really
large
extension
field,
you
want
to
make
sure
that
you
want
to
be
careful
to
not
exceed
the
MTU
along
the
network
path.
So
there
is
no
specific
information
involved
on
what
to
do.
If
you're
going
to
do
that
open
the
suggestion
for
it,
we
tell
people
to
avoid
the
problem.
P
O
C
C
O
Changes
the
I
on
a
table
for
extension
fields.
There
were
a
few
other
cleanups
along
the
way,
but
if
any,
if
anybody
sees
anything
I
think
shouldn't
in
their
in
their
alum,
you
know
there
are
a
bunch
of
places
in
the
text
inside
square
brackets,
where
I
raise
points
that
basically
say
hey.
We
need
to
make
a
decision
about
this.
Does
anybody
have
a
preference
and
those
will
all
go
away
as
soon
as
we
feel
like
either
address
them
or
ignore
them.
O
C
J
C
Yes,
it
would
be
updating
78,
20,
okay,
I
think
we,
we
need
to
I
think
that
we
needed
a
clearly
understandable
document.
First,
before
we
really
understood
the
relationship
between
it
and
78
22.
What
we've
asked
for
is
a
Clara
is
to
get
the
extension
field
stuff,
specified
and
and
separate
out
all
the
new
extension
field
into
other
drafts
so
that
we
have.
This
is
what
NTP
extension
fields
look
like
and
then
go
forward.
N
C
C
Let
me
I,
don't
know
Harlan
if
you
want
to
jump
back
in
the
queue
or
type
in
the
window.
My
question
is:
did
you
want
to
do
another
update
before
we
do
a
call
for
adoption?
Are
you
or
are
you
confident
with
the
or
are
you
ready
to
do
the
conferred
option
with
this
one
I
say
that
having
wait
there,
you
are.
O
C
So
so
you
can,
we
can
have
things
that
we
haven't
made
a
decision
on.
That's
fine,
because
we
expect
that
the
working
group
will
actually
make
some
of
those
decisions,
and
one
of
the
things
is
that
once
it
becomes
adopted,
it's
a
working
group
document.
It's
the
consensus,
the
working
group
for
what
actually
goes
into
the
document.
Okay,
so,
but
but
I,
think
part
of
the
struggle
with
getting
it
initially.
As
a
working
group
document
was
the
the
clarity
of
what
the
document
actually
said
and
I
think
we're
making
steps
in
that
direction.
Q
B
Q
Struggled
with
I
think
the
working
group
should
consider
the
individual
changes
on
their
merit
more
than
the
doc
and
I.
Is
that
making
sense?
I'm
looking
around
the
room
and
getting
puzzle
looks
I
see
that
the
changes
in
here
seem
to
stand
alone
from
each
other,
mostly
and
I.
Think
we
could
make
a
decision
about
which
of
these
we
want
to
do
yeah.
C
Yeah
yeah
I
had
actually
actually
originally
thought.
We
would
just
go
down
this
list
and
and
and
go
one
by
one
and
discuss
them,
but
it
might.
But
then
it
occurred
to
me
it
might
be
easier
to
do
that
on
the
mailing
list.
It
might,
but
I
would
do
that,
but
but
it
was
my
intention
that
each
one
of
these
technical
changes
need
to
be.
We
need
to
make
a
decision
on
this
change.
P
The
working
group
can
adopt
it
and
we
can
decide
to
adopt
seven
documents
or
one,
and
you
know,
do
what
do
it
in
whatever
format
is
necessary
to
make
it
easiest
such
that
we
can
advance
these
things
in
an
appropriate
way
to
ensure
that
it's
well
documented
I
think
my
only
concern
would
be,
and
just
it
probably,
if
we're
doing
at
this
document,
it
probably
does
make
sense
to
have
it
all
together,
but
that's
pretty
much
it.
We
can
do
it
as
one
or
seven
yeah.
N
C
Okay,
so
with
that
I'm
gonna,
kick
you
out
of
the
queue
again
Harlan
and
the
next
thing
on
the
agenda.
Oh
no,
we've
only
done
this
one
so
hold
on
the
the
the
next
thing.
Technically
on
the
agenda
was
the
new
extension
field
proposals,
but
in
all
of
our
activity
over
the
last
few
days
to
talk
about
extension
fields,
I
didn't
actually
focus
much
on
the
new
extension
fields.
C
I
wonder
if
you
want
to
just
step
through
at
a
very
high
level
and
say
what
the
motivation
for
each
one
is,
and
then
we
will
discuss
them
in
more
detail
at
a
virtual
interim
that
we're
going
to
have
I
just
really
thought.
The
more
important
thing
this
time
was
to
get
the
the
drafts.
Nntp
extension
fields
done.
I'll
see
you
back
in
the
queue
so.
R
C
It's
in
the
unless
I
did
a
cup
of
coffee
and
paste.
Oh,
it's
in
the
agenda.
That's
on
the
data
tracker,
but
the
ones
that
I
currently
had
on
the
agenda
were
the
extended
information,
the
math
last
extension
field,
the
idea,
extension
field
and
the
suggester
F
ID
extension
field,
so
they're
referred
I
believe
there
are
four
draft
stands
associated
with
new
extension
fields:
okay,.
O
C
O
So
I
created
an
extended
information,
EF
and
one
of
the
first
things
that
I
put
in
it
was
what's
the
current
ta
i2
UTC
offset,
there's
some
other
information
in
there
as
well
that
we
can
add
into
because
we're
not
really
using
much
of
the
packet
and,
depending
on
what
we're
doing,
we
can
extend
it
pretty
easily
in
a
backward
compatible
fashion.
So
that's
extended
information.
O
This
is
a
combination
of
two
proposals
that
you
asked
me
to
combine
Mac
as
an
EF
and
the
last
EF
into
a
single
proposal,
and
so
we
did
that
there
too
there.
There
are
many
ways
to
go
for
the
for
the
Mac
field
and
in
the
spirit
of
we'll
give
you
a
robust
mechanism,
and
you
can
decide
your
local
policy.
One
of
them
is
to
avoid
ambiguity
in
parsing.
O
One
of
the
things
you
can
do
is
not
send
a
legacy
Mac
so
and
that
for
that
to
happen,
you'd
want
to
put
the
Mac
in
an
extension
field.
So
that's
one
choice.
Another
choice
you
could
do
is
make
sure
that
there
is
a
last
extension
field
which
I
think
is
a
whopping
four
octets
long.
That
says:
hey
I'm,
the
last
extension
field.
O
So
any
data
after
me
must
be
a
legacy
Mac,
not
telling
anybody
to
use
either
of
these,
but
if
they
do,
it
means
that
there
won't
be
any
parsing
ambiguity,
but
in
the
face
of
a
legacy
Mac
with
extension
fields,
the
next
one
was
which
one
the
idea
I
do.
So
if
you've
got
two
arbitrary
NTP
instances
sitting
there
and
you
want
to
know
what
capabilities
each
one
is
willing
to
admit
to
the
other
they
offer,
what
one
side
will
do
is
send
an
I
do
request
that
basically
says
hi
other
side.
O
These
are
the
sort
of
functions
and
extension
fields
and
things
that
I
support.
Please
tell
me
more
and
the
other
side
will
respond
appropriately,
where
appropriately
may
mean
a
crypto
nak,
which
is
interpreted
as
meaning
I.
Don't
know
what
you're
talking
about
with
this
new
extension
field
or
it
could
be
an
I
do
response,
which
is
high
other
side.
These
are
the
things
I'm
willing
to
admit
that
I
do
and
it's
just
a,
and
this
can
be
renegotiated
down
the
line
any
time
either
side
sees
fit
there.
It
uses
the
response
flag.
O
O
You
know
it
creates
an
ongoing
communication
that
just
isn't
necessary,
Daniel
we're
not
using
it
to
signal
it.
It's
what
happens
when
you
send
an
I
do
response
to
an
old
to
an
old
version
of
ntp.
It
doesn't
recognize
it,
so
it
thinks
it's
being
it's
it's
seeing
bogus
like
a
see
Mack,
so
it
responds
to
the
crypto
neck.
O
O
This
is
how
far
off
the
time
is
from
true
time
and
you're
not
expected
to
use
that
for
anything,
except
it's
a
really
lovely
test
to
make
sure
that
the
leaf
smear
is
progressing
as
you
think
it
should
at
this
point
in
time.
But
it
is
a
very
clear
indication
that
you're,
following
a
leap,
smeared
server,
there
is
one
that
says
not
you
that
Sharon
likes
her
proposal
was
that
I
may
not
want
to
tell
you
who
my
system
peer
is
so
I'm
simply
going
to
give
you
a
signal
that
you
won't
know.
O
O
C
O
Haven't
told
you
about
some
of
the
ref
ID
update
proposals,
then
the
suggested
ref
ID
is
different
and
should
be
discussed
in
this
section.
The
trick
is
that
a
ref
ID
is
something
the
other
person's
tells
you
know
that
I
tell
other
people
what
my
system
pier
is.
There
is
currently
no
way
for
someone
to
say
if
you
use
me,
use
your
system
P
or
use
this
as
the
ref
ID
and
the
suggested
bref.
O
Id
proposal
does
exactly
that,
and
the
reason
for
this
is
that
attacks
can
be
mounted
if,
if
I
know,
who
you're
using
is
your
system
pier
and
their
attack?
I
can
mount
against
you
because
of
what
I
know,
but
the
suggested
rough
ID
is
effectively
a
random
number
and
it
uses
something
else:
I,
don't
remember
what
the
range
might
be
and
the
purpose
there
is
to
say.
C
Alright,
my
point
in
putting
these
on
the
agenda
for
the
working
group
is
the
the
four
extension
field.
Proposals
are
individual
submissions
and
so
we'd
like
to
get
some
review
on
those
at
some
point
and
because
at
some
point
we'll
need
to
make
a
call
about
making
the
working
group
document
and
the
ref
ID
updates
is
a
working
group
document
that
we
we
haven't,
spent
a
lot
of
attention
on,
and
so
it's
time
to
at
some
point,
it'll
be
time
to
move
that
one
forward.
So
I
don't
want
folks
to
forget
about
them.
Thank
you.
C
So,
at
this
point
we're
at
the
end
of
the
NTP
working
group
agenda.
There
are
a
few
other
drafts
that
have
not
had
extensive
update
since
I
find
my
other
since
the
the
last
meeting
and
I.
Don't
want
us
to
forget
about
them.
We
do
have
a
BCP,
that's
ready
to
go
to
the
iesg.
I
wrote
a
note
sent
to
the
iesg,
because
I
promised
myself
I
would
send
it
before
I
got
to
this
meeting,
but
I'll
have
to
say
it's
ready
to
go
to
the
iesg,
the
NTP
data,
the
client
data
minimization.
C
C
C
Right
there
is
also
an
NTP
correction
field
and
there's
been
no
updates
to
that,
but
that's
also
sort
of
blocked
on
us
resolving
the
extension
field
issue
and
then
there's
the
NTP
interleave
modes.
This
is
one
that
I
do
believe
is
ready
for
working
group
adoption.
There
haven't
been
a
lot
of
comments
on
it.
It's
something
we
talked
a
while
about
about
getting
out
there
and
then
there's.
Also
a
draft
on
on
implementing
time
was
presented
last
time
that
was
suggested
that
we
adopt
in
this
working
group
but
I.
C
There
has
not
been
an
update
on
that
one
since
the
last
IETF.
So
if
you
are
not
familiar
with
the
data
tracker,
if
you
look
at
the
NTP
working
group
under
the
under
the
data
tracker
for
this
meeting,
you'll
see
that
all
of
these
drafts
are
attached
to
this
meeting
and
while
I
might
have
gotten
the
slides
out
of
order
for
the
agenda
that
did
get
all
address
attached,
so
so
the
so.
That
concludes
the
ntp
portion
of
this.
This
working
group
meeting.
Are
there
any
other
ntp
issues
that
we
want
to
bring
forward?
C
We
have
two
documents
that
are
also
ready
for
the
iesg
we've
completed,
the
yang
data
modify
Tripoli
1588
b2
and
we've
also
completed
the
enterprise
profile
for
the
precision
time
protocol
for
mixed
multicast
and
unicast
messages,
and
this
profile
actually
also
had
some
has
had
some
some
implementations
in
the
context
of
the
I
Triple
E
1588
plugfest,
that's
done
at
is
PCs,
so
that
brings
us
to
draft
Alvarez
Hamlin
tick-tock-tick,
and
so
are
you
ready
all
right?
So
this
is
presentation
on
synchronizing
internet
clocks
from
Alvarez
mo
Hamelin.
R
R
Then
the
first
thing
that
away
to
to
to
discuss
is
who
is
needing
a
secure
clock
synchronization
next
slide.
Please
then
I
I
put
just
four
types
of
applications
related
with
with
this
problem
in
in
different
way,
but
localization
cryptocurrency,
aims
and
measurements.
My
drive
to
do
that
was
measurements
because
I
am
course
in
IP
PM
go
next
right,
then
the
ids
is
200.
Morale
is
where
the
protocols
works,
and
in
this
graph
we
got
here
there're
more
or
less
an
idea.
R
R
R
There
is
also
well
here
that,
in
the
resourcing
big
difference
with
sick
here
is
a
bit
problem,
normally
PSC,
when
you
are
running
in
in
one
environment
for
hobbies,
not
so
good.
There
is
some
some
kinds
of
that
about
that
next
slide.
Please,
then,
no
okay,
what
is
the
working
principle?
Ok
ads,
as
always
a
client-server
Internet
in
the
middle,
but
we
send
one
packet
per
second
and
we
perform
some
statistical
analysis.
R
In
order
to
security,
we
say
net
each
pocket,
which
means
that
we
can
verify
that
they're,
really
that
information
insides
good,
but
the
one
of
the
problem
when
you
sing
the
pocket
is
the
time
that
you
take
to
sing
the
packets.
Therefore,
we
we
do
do
is
in
in
some
delayed
fashion,
I
mean
we
send
the
previous
signature
in
each
new
packet.
R
Well,
why
we
synchronize
frequency,
essentially
because
there
is
some
asymmetry
in
normality.
Every
read,
Gangnam
back
wrote
has
the
different
different,
but
it
could
be
possibly
to
do
something
absolute,
but
this
is
a
next
step.
Okay,
it's
absolute
when
you
are
in
in
the
in
the
tens
of
milliseconds,
but
if
you
want
to
be
in
the
tens
of
microseconds
absolute
for
now
is
not
possible
with
this
technique
next
slide,
and
this
is
just
to
to
show
what
happened
with
the
minimum
RTT,
because
mostly
of
the
software
based
synchronization
method,
our
path
based
on
minimum
RTT.
R
Here
we
we
got
seven
hours
and
we
estimated
the
mean
RTT
in
each
minute
and
we
design.
Okay,
as
you
see
the
time,
the
minimum
RTT
very
very
eyes
has
a
lot
of
variation.
Therefore,
it's
not
a
good
estimation
just
to
use
the
minimum
RTT.
What
we
do
is
we
study
the
traffic
statistically
how
how
is
working
that
LTTE
in
the
statistical
way,
and
we
found
a
way
to
retrieve
some
something
more
modest
other
than
that
next
slide
please.
R
But
this
is
just
cumulative
distribution
where
we
we
show
two
cases
one
in
every
case
there
is
a
client
in
one
Osiris
and
the
second
client
can
be
in
Buenos
Aires
in
in
another
network
or
in
Los
Angeles
illustrated
in
in
the
table.
The
cartels
q2
is
the
medium
as,
as
you
can
see,
is
it
perform
very
well
in
in
in
comparison
with
with
a
RTT
next
line.
A
R
We
are
focused
on
frequency
because
the
asymmetry
of
the
paths
and
it's
the
client
server,
this
server
distribution.
We
we
already
have
a
1
1
1
implementation
in
github
for
the
secure
part
we
have
just
the
client,
we
are
doing
the
victim,
because
if
the
client
detect
that
the
problem
with
a
secure
signature
we
drop
out
the
synchronization
synchronization
has
different
state.
R
H
H
First
of
all,
let's
talk
about
what
you're
able
to
do
you're,
saying
you're,
trying
to
get
frequency
to
what
scale,
how
many
ppb
or
ppm
do
you
expect
to
get
in
how
much
time
we
know
exactly
given
the
distribution
of
the
delays,
how
good
you
can
do
and
the
ITU
standardized
doing
fpb,
which
you
look
at
your
distribution
and
do
Matt.
You
know
you
don't
actually
minimum
get.
H
You
don't
have
to
get
only
minimum
gate,
it's
enough
to
have
any
weight
someplace
in
the
distribution
which
is
more
than
what
we
find
you'd
find
over
a
smooth
distribution,
and
you
can
lock
on
that
and
it's
well
known
how
to
do
it.
So
what
are
you
looking
to
get
well
and
why
do
you
think
you
have
something
which
is
not
known.
R
H
R
H
R
R
H
H
H
R
Q
Do
have
a
more
basic
request
that
I
took
a
quick
look
at
the
draft
and
there
appears
to
be
a
white
paper
for
a
for
an
algorithm
that
you're
not
using
or
that
you're
improving
upon,
but
no
white
paper
for
this.
This
feels
to
me
like
it's
in
the
realm
of
research
and
so
I'd
like
to
see
what
I'd
like
to
see
the
the
math
and
everything
that
this
is
based
on
before
jumping
into
an
implementation
and
adopting
that
into
a
group.
That's
trying
to
produce
actual
software
in.
Q
C
I
C
Would
I
think
you
did
you?
You
got
some
comments
already
on
this
document.
I
believe
I
might
be
conflating
it
with
another
one
actually,
but
in
any
event,
thank
you
very
much
for
presenting
this
I,
encourage
everybody
to
read
it
and
send
any
comments.
If
you
could
send
you
know
a
little
bit
of
it,
maybe
send
to
the
list
a
few
links
or
some
additional
information
like
Kyle,
was
asking
for
that
might
help
people
as
well.
Okay,
good
true,
thank
you
very
much.
Thank
you.
C
C
C
No
excellent,
so
I
do
appreciate
all
of
you
hanging
out
for
a
a
rather
late
session
on
a
Thursday
of
IETF
Week.
With
this
we
will
adjourn
the
meeting.
Oh
sorry,
one
more
thing
we
will
work
on
a
virtual
interim
meeting
and
I
think
we're
probably
looking
at
four
to
six
weeks
from
now,
and
we
will
send
out
some
sort
of
a
poll
to
get
some
some
scheduling
information
together.
For
that
we
have
a
bunch
of
open
drafts.