►
From YouTube: IETF100-NTP_TICTOC-20171113-1330
Description
NTP TICTOC meeting session at IETF100
2017/11/13 1330
https://datatracker.ietf.org/meeting/100/proceedings/
A
B
B
B
B
There's
supposed
to
be
one
on
the
clipboard.
Actually
there
you
go
second
thing:
we
do
have
note
takers,
oh
we
and
but
I
do
need
a
jabber
scribes
anybody
willing
to
jabber
scribe
kyle.
Thank
you.
B
Welcome
to
the
ntp
and
tick
tock
working
group
meeting:
this
is
the
IETF
note
well,
which
you
will
have
seen
before.
I
guess
the
hotel
staff
didn't
want
me
to
leave
the
door
open
because
they
just
closed
it.
Oh
well,
so
anyway,
this
is
the
IETF
note.
Well,
if
you
have
any
questions,
be
sure
to
raise
them
and
recall
that
by
attending
this
meeting
you
are
agreeing
to
abide
by
it
next
slide.
We
have
already
done
the
basic
administrivia
the
agenda
for
today,
so
we
have
our
scribes
and
our
note
takers.
B
The
agenda
for
today
we're
going
to
go
over
a
number
of
drafts
in
the
working
group
status.
Then
we're
going
to
talk
about
the
status
of
the
network,
time
security
work,
the
yang
data
module
model,
the
some
guidelines
for
defining
packet
stamp,
a
packet
time
stance
which
was
adopted
last
time,
ntp
interleave
modes
on
implementing
time.
B
That's
the
end
of
the
ntp
portion
of
the
agenda
and
the
tik
tok
portion
of
the
agenda.
We're
going
to
talk
about
the
working
group
status
and
we're
going
to
talk
about
the
yang
data
model
for
1588
v2.
Are
there
any?
Is
there
any
agenda?
Bashing
questions,
additions,
comments,
okay,
so
go
to
the
next
slide.
Let's
talk
a
little
bit
about
the.
B
Current
documents
that
we
don't
actually
have
or
that
we
want
have
a
little
bit
of
discussion
on
today,
but
not
necessarily
a
lot.
The
first
one
is
the
NTP
control
messages
document
this
document
was
published
by
update,
was
published
by
Brian.
There
were
a
couple
of
open
issues
that
we
discussed
at
the
last
interim
meeting
and
part
of
that
required
getting
some
feedback
from
operators
on
how
they
are
currently
using
ntp
mode
6.
We
have
not,
to
my
knowledge,
gotten
this
information.
Yet
do
we
have
anybody,
that's
willing
to
help
Brian
get
this
information.
B
Ok,
there
was
a
question
about
the
version
numbering
and
then
there
was
a
question
about
adding
additional
modes,
and
the
question
was
whether
we
needed
to
add
adding
additional
commands
to
the
mode
to
the
mode,
6
messages
and
whether
we
needed
to
do
that
or
not
so.
Are
there
any
questions
or
comments
on
this
document?
B
B
The
Mac
Afeni
keishon
code
for
ntp
and
charles
draft
that
went
through
working
group
last
call.
There
was
a
to
my
knowledge.
The
only
there's
a
there
were
a
couple
of
additional
comments
that
haven't
been
addressed,
including
the
need
for
a
security
consideration
section.
Did
you
want
to
address
that
at
all
in
Schuyler
to
you
at
the
microphone?
If
you.
B
B
D
C
D
B
Okay,
yeah,
that
was
what
I
recalled
from
the
mailing
list,
was
there
were
some
additional
comments
that
needed
to
be
addressed.
So,
in
addition
to
the
addition
in
the,
in
addition
to
adding
a
security
consideration
section,
we
need
to
proper,
we
need
to
at
least
figure
out
those
so
other
than
that
I
believe
it's
it's.
You
know
past
working
group
last
column.
We
can
move
on.
B
The
climate
data
minimization
draft
needs
to
be
a
working
group.
Last
call
it's
ready
for
working
group
last
call
and
that
has
not
been
issued.
So
we
need
to
do
that.
The
ref
ID
updates
has
been
parked,
for
the
mean
for
the,
for
the
has
been
part
has
been
temporarily
parked
and
the
NTP
correction
field.
B
B
E
E
E
E
E
E
D
E
E
The
question
for
me
is:
should
we
also
have
a
state
machine
diagram
for
for
at
least
for
the
client
I
personally,
don't
believe
that
that
is
necessary
and
then
there's
also
of
me,
should
they
come
that
this
with
respect
to
the
cookie
format
in
the
current
draft,
cookie
format
is
suggested
and
there's
some
statement
that
this
should
be
normative.
So
these
are
two
questions.
I
have
some
further
backing
hope.
However,
we
should
have
proceeded
at
that
poet.
E
D
F
E
F
E
F
B
B
So
anyway,
this
is
the
current
way
forward
for
this
time
frame.
You
didn't
actually
address
that
ditcher
to
even
Daniel
have
a
time
frame
for
moving
forward.
B
Right
so
part
of
the
reason
why
I'm
sort
of
pushing
this
is
I
was
really
targeting
having
a
hackathon
effort
around
the
NTS
work
at
the
London
IETF,
and
so
it
would
be
I
think
that
that's
a
real
sweet
spot
I
think
it
would
be
very
productive
if
we
could
do
that.
It
also
is
in
a
region
where
we're
we
have
the
best
potential
of
getting
all
the
people
that
we
need
in
the
room.
B
E
G
Okay,
so
hi
I'm,
Keith
and
I
will
be
presenting
the
yam
data
model
for
NTP.
So
we
have
done.
Can
you
move
to
next
slide
yeah?
So
for
Rihanna
later
model
we
have
configuration
state
configuration
and
state
variables.
Apart
from
this,
we
have
added
most
feature
of
NTP
v4
are
covered.
Can
you
please
move
to
the
next
slide
yeah?
So
as
part
of
this
version,
we
have
done
some
recent
changes
which
are
added
differently
on
tree
for
configuring
ntp
unicast.
G
G
Examples
are
added
for
almost
all
the
configuration
and
operation
States
modification
in
clock,
stators
container
is
done
and
interface
container
name
is
updated.
Can
you
please
go
to
next
slide
yeah,
so
for
this
one
for
unicast
we
have
actually
we
have
separated,
unicast
and
Association
and
free.
So,
as
you
can
see
now,
unicast
node
has
two
key
fields
which
is
address
and
type
and
all
the
unicast
related
information
will
be
present
over
here.
The
other
tree
is
association
tree,
which
will
display
all
the
Association
ntp
has,
which
is
learnt
dynamically
or
configured.
G
The
configuration
can
be
a
unicast
or
a
multicast
are
broadcast,
so
these
information
will
be
considered
over
here.
So
we
have
added
two
Leafs
node,
which
is
local
mode
and
is
config
flag,
just
to
make
sure
that
what
is
the
growth
if
the
mode
is
brought
us,
it
will
display
like
broadcast,
and
if
it
is
a
configured
node,
we
will
receive
this
boolean
value
as
true
in
case
of
dynamic.
This
boolean
value
will
be
false.
Can
you
please
go
to
the
next
slide,
so
this
is
the
example
for
unicast.
This
is
a
configure.
G
G
G
When
user
perform
a
get
operation
on
the
same
node,
we
can
see
all
the
information
as
present
except
the
password.
The
password
node
will
not
display
what
user
has
configured
as
the
key.
Can
you
please
go
to
the
next
slide?
This
is
the
example
for
access
rule.
So
here
user
is
configuring
access
rule
as
spear
and
ACLs
mm.
G
This
is
below.
Is
the
get
example
of
access
node?
Can
you
please
go
to
the
next
slide?
This
is
the
multicast
server
configuration
in
which
user
has
confi.
A
user
has
configured
multicast
addresses
224
dot,
one
dot,
one
dot,
one
on
interface,
internal,
three,
zero,
zero,
with
authentication
key
ID
as
10
and
the
code
as
one
zero.
Two
five
same
when
user
performed
the
gate
operation
he
can
use.
He
will
get
this
information,
as
mentioned
over
here,
say:
multicast
address
as
224
dot,
one
dot,
one
dot,
one
with
authentication,
key
10
and
potus
one
zero.
G
Two
five!
Can
you
please
go
to
the
next
slide?
This
is
the
multicast
client
related
configuration,
so
in
multicast
find
user
has
to
configure
the
Ethernet
and
means
the
interface
on
which
you
is
going
to
configure
multicast
light
and
user
has
to
add
the
addresses
to
24
dot
one
dot
one
dot
one
below
is
the
gate
example
of
multicast
client.
Can
you
please
go
to
the
next
slide?
This
is
the
meneka
server
configuration
so
in
mineka,
server
user
has
configured
the
same
IP
address
to
24
dot,
one
dot,
one
dot
one.
G
In
the
example
we
have
took
the
same
IP
address
and
on
the
interface
Ethernet,
three
zero
zero.
In
many
cos.
When
user
do
the
get
operation
on
miracast,
he
can
he
can
see
all
these
information
same
information
whatever
he
has
configured.
Can
you
please
go
to
the
next
slide
yeah,
so
in
many
cos
client
this
is
the
client
related
configuration
where
user
is
conferring
the
addresses
to
twenty
4.1.1,
with
authentication
kit10
and
during
the
gate
operation.
The
client
can
sorry
the
user
can
see
all
the
data
please
go
to
the
next
slide.
G
This
is
a
clock
status
example
which
will
tell
what
is
the
current
ntp
status,
so
it
has
peaks
like
a
clock
state
which
is
sunrise
or
unsink
rise.
What
is
their
stratum?
What
is
the
reference
clock
ID?
Apart
from
this?
We
have
added
this
some
key
nodes
of
association
class
so
that
it
can
directly
refer
to
the
association
with
which
it
has
synchronized.
G
Can
you
please
go
to
the
next
slide?
Oh
yeah,
this
is
the
display
association
example,
so
this
will
display
the
current
Association
present
for
ntp,
so
for
each
Association
it
will
display
the
address
the
stratum,
a
reference
source
of
synchronization.
What
is
the
local
mode,
whether
it
is
a
configured
session
or
a
dynamically
learned
session,
along
with
the
NTP
start
6,
for
this
particular
Association?
How
many
packets
are
sent
and
receive?
Can
you
please
go
to
the
next
slide
yeah?
G
So
now
we
will
talk
about
the
modification
which
we
have
done
in
clock,
sweet
container
so
over
there
you
can
see
that
we
have
added
storekeeper
and
to
the
Association
these
three
keys,
as
we
have
seen
in
the
previous
young
example.
These
keys
are
the
Association
note,
keys,
could
identify
which
Association
is
currently
used
for
time
synchronization.
G
Can
you
please
go
to
the
next
slide?
This
is
the
interface
until
our
name
changes
earlier.
We
had
the
name
as
interface,
then
interface,
then
name
which
was
a
bit
confusing
for
the
user,
so
we
have
referred
the
IETF
interface
yang
model
and
we
have
took
the
naming
convention
from
them.
So
now
our
interface
notice
is
having
interfaces
which
has
interface
and
name
as
the
key
field.
These
are
go
to
the
next
slide
so
about
the
next
step.
So
review
comments
are
welcomed.
G
Some
of
the
reveal
comments
which
we
have
displayed
in
the
example
are
being
updated
in
the
draft,
so
we
actually,
we
have
already
updated
it,
but
we
want
some
more
comments.
You
come
from
working
group
so
that,
along
with
the
internal
comment
and
working
group
comment,
we
can
add
it
and
make
a
new
version
release.
A
Rob
Robin
eggy,
deep
dive,
networking,
I
I'm,
just
gonna
reavoice
that
comparable
and
I
think
even
trying
to
be
closely
comparable
or
functionally
comparable
is
asking
a
little
much
I
think
they
have
to
have
value
and
function
I,
don't
see
why
they
get
compared
to
us
and
impede
which
has
been
around
for
way
longer.
So
I
guess
my
question
really
would
be
what
are
the
next
steps?
When
do
we
stop
versioning
and
say
this
works
it's
useful
today
and
move
forward,
because
we
can
do
this
versioning
and
adding
things
forever.
I
Actually,
I
I
think
that
one
thing
that
we
need
to
understand
that
we
define
the
base
model
and
all
their
extensions
can
go
as
argument
to
the
base
model,
so
really
don't
have
to
incorporate
all
existing
extensions
in
a
base
model.
I
think
that
actually,
we
should
really
identify
the
base,
make
it
standard
and
everything
else
can
just
argument
whether
it's
a
standard,
extension
or
proprietary
extension.
G
Actually,
we
have
not
accommodated
the
mode
six
in
this
one
and
related
to
SNMP,
as
per
the
net
confer
standard
that
animal
is
standard,
we
have
a
updated.
Our
draft
means
as
per
nmda
standard.
We
should
have
a
config
and
the
operation
state
wherever
possible
in
this
inside
the
same
container.
So
if
you
look
to
the
void
version
before
the
working
group
adoption,
it
was
in
different,
different
containers.
Now
we
have
joined
almost
all
the
containers
and
related
to
mode
6.
G
H
The
same
thing
pretty
much
needs
to
happen
with
the
yang
data
model.
We
need
to
make
sure
that
and
that
the
protocol
has
a
set
of
ways
to
do
think
that
the
process
has
a
set
of
ways
to
do
things
to
it.
The
aquarian
information
or
alter
configuration
or
to
other
things,
and
the
ways
that
would
be
done
would
include
mode
six,
SNMP
and
yang
data
model,
and
if
we
start
getting
into
situations
where
one
of
them
will
do
something,
the
others
can't
we're
making
lives
really
hard
on
the
user.
I.
B
Think
the
problem
is
that
mmm-hmm,
the
load
six
is
ten
or
fifteen
years.
Old.
Sp
is
about
ten
years
old.
The
move
anyway,
and
what
people
want
to
do
now
with
yang
might
be
different
than
what
they
would
want
to
have
done
previously.
So
I
don't
think
it's
reasonable
to
hold
the
yang
module
to
the
standard
that
we
have
to
keep.
H
But
the
other
part
is
everybody:
I've
talked
to
who's.
Doing
yang
is
doing
their
own
internal
implementation
of
NTP
they're,
not
doing
a
standalone
implementation
and
so
for
to
end
up
with
a
standalone,
NTP
implementation
that
has
a
yang
interface
to
it.
That
either
means
somebody's
going
to
have
to
implement
a
full
yang
engine
inside
the
NTP
daemon,
which
I
expect
will
not
go
over
well
or
there
needs
to
be
some
external
process
that
does
yang
interface,
that
has
to
communicate
with
the
NTP
daemon
and
right
now.
B
G
How
did
I
got
your
comment?
Let
me
think
over
it.
I
will
discuss
with
other
authors,
also
like
how
the
implemented
part
stand-alone
ntp.
Maybe
we
can
discuss
it
offline
and
earlier
also
we
had
a
meeting
if
you
remember
me
and
chose
trying
committing
yeah.
So
let
me
discuss
with
through
a
once.
He
is
back
from
idea
and
we
will
have
a
one
to
one
discussion
and
we
will
think
like
how
to
implement
it
for
standalone
ntp.
You
are
right,
yeah.
G
J
D
D
One
is
to
define
a
relatively
small
subset
of
recommended
time
stamp
formats,
a
subset
of
all
the
time
stamp
formats
that
we
may
be
familiar
with,
and
we
believe
that
in
most
cases
when
you're
designing
a
network
protocol,
one
of
these
recommended
formats
will
fit
your
requirement
and
for
these
special
cases
were
none
of
these
formats
fits
your
requirements.
This
draft
also
specifies
guidelines
for
how
to
define
a
new
time
stamp
format.
Next,
please
so.
This
draft
was
submitted
a
few
months
ago.
D
It
was
discussed
and
on
the
mailing
list
in
the
last
ITF
meeting,
and
it
was
recently
adopted
by
the
working
group,
the
main
differences
between
the
previous
version
and
the
current
version.
There
are
three
main
differences.
Two
of
them
were
going
to
discuss
in
the
next
slide,
the
third
one.
We
basically
split
the
synchronization
aspects
from
the
time
stamp
format,
and
the
idea
is
that,
when
you're
defining
a
time
stamp
format,
we
don't
want
to
mandate
a
specific
synchronization
method.
D
So
if
you
have
a
specific
time
stamp
format
that
doesn't
derive
how
you're
going
to
synchronize
the
nodes
or
what
level
of
accuracy
is
required,
so
in
different
systems,
you
may
have
different
synchronization
requirements.
The
idea
is
that
when
you
use
us
a
certain
time
stamp
format,
you
will
need
to
define
the
synchronization
aspects,
including
what
is
the
level
of
accuracy?
You
expect
how
you
synchronize
the
nodes
and
so
on
next,
please.
D
Another
aspect
that
was
added
to
the
current
version
of
this
draft,
based
on
feedback
we
received
from
the
working
group
was
more
text
about
things
you
need
to
consider
before
you
define
a
time
stamp
format
or
before
you
choose
a
time
stamp
format.
So,
for
example,
things
you
need
to
consider
the
timestamp
resolution,
the
rapper
on
period.
Obviously
the
number
of
bits
you
have
in
your
bit
budget
and
also
coexistence
with
other
protocols.
D
For
example,
if
you
have
NTP
running
on
your
system,
maybe
it
makes
sense
to
reuse
the
same
timestamp
format
as
NTP
next
slide.
Please
another
section
that
was
added
to
this
version
of
the
draft
is
a
timestamp
use
case
section.
So
this
case
sorry,
this
section
shows
a
list
of
existing
network
protocols
that
use
timestamps
for
each
of
these
protocols
we
show
which
timestamp
format
is
used.
So
in
most
cases
one
of
the
recommended
timestamp
formats
is
used
in
some
cases.
It's
not
one
of
the
recommended
timestamp
formats.
D
In
addition
to
this
list
and
mapping,
this
section
also
presents
a
couple
of
examples
of
how
a
new
network
protocol
specification
should
use
one
of
the
recommended
time
stamp
format.
So
you
can
actually
look
at
one
of
these
examples
and
if
you
were
defining
a
new
network
protocol,
you
can
kind
of
reuse
that
example,
and
do
something
very
similar
next,
please,
okay,
so
the
next
steps
were
expecting.
First
of
all,
there
were
a
few
comments
which
received
on
a
mailing
list
that
we
haven't
addressed.
D
Yet
we
plan
to
address
these
in
the
next
version
of
the
draft
and
another
aspect
that
we
started
working
on
and
is
still
work-in-progress
is
a
control
field,
an
optional
control
field
that
can
be
attached
to
the
timestamp
and
can
specify
various
types
of
information
related
to
that
timestamp.
So
for
now
we
have
a
very
short
section
that
describes
more
or
less
what
we
think
the
control
field
should
include,
but
we
need
to
add
more
text
and
to
have
this
section
be
more
detailed.
D
I
You
Greg
musky
city
I,
really
appreciate
this
work
because
it's
very
helpful,
especially
as
you
mentioned,
as
a
reference
to
other
groups
who
are
not
that
much
spend
time.
So
it
saves
time
couple
things.
First,
I
would
like
us
to
agree
on
a
dictionary
and
differentiate
resolution
of
the
time
stamp
from
the
accuracy
of
the
quark
synchronization,
because
accuracy
quark
of
synchronization
is
a
property
of
synchronization
protocol,
and
you
mentioned
so.
You
stated
that
it's
outside
the
scope
of
this
document.
I
The
resolution
is
something
that
definitely
we
need
to
discuss
because,
as
you
are
presented
in
your
table,
you
have
a
format
that
is,
for
example,
ETP
truncated,
but
there
is
a
larger
PTP
format
that
has
more
nanoseconds,
actually
I.
Think
it's
a
picoseconds
right
and
frankly,
we
we
we
can
discuss
and
think
of
whether
in
some
future
near
future,
we'll
need
more
resolution.
Then
we
have
now
with
a
truncated
format.
So
probably
it's
worth
putting
this
in
the
floor
site
and
discussing
how
we
can
migrate
to
their
high
resolution
of
a
plane
stamp.
I
I
I
B
Greg
just
a
quick
question
for
clarification:
you
started
your
comment
on
resolution
saying
that
we
needed
to
have
a
basically
a
dictionary.
Yes,.
I
B
D
C
Hello:
everyone
I'm
Angela
Malhotra
from
Western
University,
and
this
work.
This
draft
is
jointly
written
with
Miroslav
from
Red
Hat.
In
this
draft
we
basically
specify
it's
an
extension
to
the
specification
of
the
network
time
protocol
in
RFC
five
905,
and
in
this
draft
we
specify
the
new
modes
of
NTP
called
the
interleaved
modes,
which
allow
an
NTP
server
to
provide
a
more
accurate
transmit
timestamp
to
its
clients
or
peers.
C
C
Okay,
so
this
is
how
typically
an
NTP
time
synchronization
packet
looks
like
there
are.
Not
all
fields
are
relevant
to
my
talk
here.
There
are
four
kinds
of
different
time
stamps
here,
the
one
when
the
one
that
we
are
really
concerned
about
here
is
the
transmit
timestamp
on
a
very
high
level.
Transmit
timestamp
is
the
local
time
when
a
packet
leaves
the
system.
Okay,
so
this
transmit
timestamp
can
be
captured
at
several
different
places
on
the
machine.
C
For
instance,
it
can
be
captured
by
the
NTP
daemon
using
the
real
time
it
can
be
captured
at
network
drivers.
It
can
be
captured
at
Mac
layer
of
the
OSI
or
at
the
physical
layer,
and
this
is
the
increasing
order
of
accuracy
for
the
transmit
time
stamp,
based
on
where
data
is
captured
on
the
machine
now
in
basic
mode,
that
is
the
basic
mode
of
NTP
that
is
specified
in
RFC
five
905.
This
transmit
timestamp
is
supposed
to
be
captured
at
the
NTP
daemon.
I
C
C
I
That's
the
thing
is
that
you're
doing
it's
in
software,
yes
right
so
reading
in
the
software
can
cause
you
context.
Switching
and
the
context.
Switching
is
unpredictable
queuing
delay.
So
the
fact
that
when
you
need
this
timestamp
of
the
demon
from
the
kernel
by
the
time
you
return
to
your
user
space,
your
play
is
unmeasurable.
I
C
K
Know
if
you
think
of
it,
as
if
the
demon
is
user
space
and
the
bottom
three
bullets
are
actually
already
in
the
kernel
space,
then
the
closer
you
move
to
when
the
packet
actually
leaves
one
sec
close
you
move
to
when
the
packet
actually
leaves
the
host,
then
it's
a
more
accurate
time
stamp.
It
just
is.
I
C
Okay
will
the
transmit
timestamp
that
is
captured
at
the
NTV
demand?
It
includes
errors
because
it
is
captured
before
the
packet
gets.
It's
misses,
died,
message,
digest
and
all
the
processing
and
queuing
delays
at
the
network
hardware
are
not
included
in
that
timestamp.
So
what
we
need
we
want
to
do
we
want
to
do
better
than
this.
The
RFC
five
905
only
allows
the
packet
to
be
transmitted
that
has
the
transmit
timestamp
that
is
captured
and
the
at
the
NTP
daemon,
but
we
want
to
do
better.
C
C
However,
it
is
difficult
to
implement
the
transmit
timestamp
that
is
captured
at
the
physical
layer
in
the
current
packet,
because
that
is
mostly
available
after
right.
At
the
moment,
when
the
capture
is
the
packet
is
leaving
the
system,
so
the
problem
is
that
RFC,
five
nine
of
five
doesn't
provide
any
specification
for
the
server
ntp
server
to
provide
this
more
accurate,
trying
transmit
timestamp
to
its
clients
or
peers,
and
this
is
the
gap
that
this
draft
tries
to
fulfill.
C
In
this
draft,
there
could
be
several
ways
of
transmitting
there's
more
accurate
timestamp
to
the
clients
or
peers,
but
in
this
draft
we
talk
about
the
interleaved
mode.
So
what's
the
interleaved
mode
of
ntp,
the
interleaved
mode
allows
the
ntp
packet
to
contain
a
transmitted
timestamp
corresponding
to
the
previous
packet
that
was
sent
to
the
client
or
peer
to
be
more
precise.
In
this
draft
we
specify
a
new
interleaved
client-server
mode.
C
We
also
specify
an
interleaved
symmetric
mode
with
some
modifications
to
the
ntp
reference
implementation
and
then
specifying
to
interleave
broadcast
mode
based
purely
on
NTP
reference
implementation.
In
this
try
in
this
talk,
I
will
explain
a
new
interleaved
client-server
mood,
so
the
interleaved
client-server
mode
basically
operates
similar
to
the
basic
client-server
mode
and
by
basic
lines.
Over
mode
I
mean
the
mode
that
is
specified
by
RFC
five
905,
in
which
the
packet
contains
the
transmit
timestamp
that
corresponds
to
the
packet
itself.
C
The
interleaved
client-server
mode
is
similar
to
basic
client-server
mode,
except
that
the
meaning
of
origin
and
transmit
timestamp
changes.
So
what
happens
in
basic
trance
B's
a
client-server
mood.
Well,
this
is
a
client,
a
server
and
a
piece
are
the
request
request
and
the
response.
Packets,
origin.
C
We
have
origin
timestamp,
receive
time,
timestamp
and
transmit
timestamp
on
these
packets,
so
in
basic
mode
in
the
in
the
client
request,
the
origin
timestamp
is
0
or
random,
and
in
the
response
in
the
response
packet
from
the
server,
the
origin,
timestamp
is
equal
to
the
transmitted
timestamp
of
the
client
query.
This
is
how
a
basic
client
server
mode
works
now
notice
that
on
request
and
response
packet,
these
transmit
timestamp
correspond
to
the
packets
themselves
when
they
are
the
local
time
on
the
client
and
the
server.
C
After
the
first
basic
mode
exchange
when
the
client
receives
the
response
from
the
server
the
basic
response
from
the
server
now
in
its
query
for
the
interleaved
mode,
the
client,
the
origin,
the
origin,
timestamp
of
the
client
query
in
the
interleaved
mode
is
equal
to
the
received
timestamp
of
the
previous
spawns
from
the
server
and
in
the
interleaved
response
packet
from
the
server.
The
origin.
Timestamp
is
equivalent
to
the
received
timestamp
of
the
request
from
the
client,
as
opposed
to
the
transmitted
timestamp
in
the
basics.
Basic
mode
now
notice
an
interleaved
mode.
C
C
C
Now
upon
getting
a
request,
the
the
server
has
to
compare
the
origin
on
receiving
this
request.
The
the
server
has
to
compare
the
origin
timestamp
on
the
request
to
the
saved
pair
of
try,
receive
and
transmit
timestamp
from
the
client
from
it's
his
previous,
his
previous
request.
Now,
if
this
these
trying
times
turns
match,
he
will
reply
in
the
interleaved
mode.
C
So
the
server
is
so
two
things
that
the
server
has
to
do,
one
he
has
to
maintain
the
list
of
transmit
and
receive
timestamp
for
the
server
or
for
each
client
and
second
upon
receiving
any
requests.
He
has
to
compare
the
origin
timestamp
to
the
list
of
to
this
received
timestamp
from
for
the
client
in
order
to
see
if
the
packet
is
in
basic
mode
or
the
interleaved
mode,
and
if
it
is
in
the
interleaved
mode.
He
replies
with
this
more
correct,
t3
timestamp
that
he
has
saved
for
the
client
from
the
previous
packet.
C
C
Now
there
could
be
a
quirk
if
somehow
in
the
interleaved
mode,
the
server
receives
a
request
in
the
interleaved
mode,
but
he
hasn't
saved
the
receive
and
transmit
timestamp
for
the
client
or
has
somehow
removed
it
from
his
memory.
In
order
to
make
some
more
space.
What
should
the
server
do?
The
server
should
fall
back
to
the
basic
mode,
so
now
his
origin
time
stand
the
response
packet
for
the
until
you
back
response
should
be
equivalent
to
the
transmit
timestamp
of
the
request
packet
from
the
client.
C
So
this
is
his
fallback
mechanism.
He
should
fall
back
to
the
basic
mode.
Well,
this
was
about
an
interleaved
client-server
mode,
interleaved
symmetric
mode.
It's
it
behaves
on
the.
It
also
works
on
the
similar
principles
as
the
interleaved
client-server
mode.
That
is,
the
response
packet
in
the
interleaved
mode,
contains
the
origin
timestamp
equivalent
to
the
receive
timestamp
of
the
previous
packet
received
from
the
peer.
Now.
What
is
the
modification
from
NTP
reference
implementation?
C
So
that
requires
some
additional
restrictions
that
we
or
specify
in
our
draft
I
do
not
have
time
to
explain
it
here,
but
the
only
thing
that's
different
from
the
NTP
reference
implementation
is
that
we
account
for
these
two
situations
and
it
requires
some
additional
restrictions
on
the
client
on
the
own
book,
on
both
the
peers
and
until
you've
broadcast
mode
that
we
specify
in
the
draft
is
based
purely
on
NTP
reference
implementation.
There
are
no
changes
there,
that'll
be
it.
Thank
you.
Okay,.
D
Event
message
with
the
same
sequence:
number,
and
that
way,
when
a
node
receives
these
two
messages,
it
can
use
the
sequence
idea
to
match
the
timestamp
to
the
corresponding
event
message.
So
I'm,
not
sure
I
understood
in
the
interleaved
mode,
how
you
bind
the
timestamp
you
received
in
the
current
handshake
with
the
correct
packets
from
the
previous
handshake.
So.
C
The
client
compares
the
origin
timestamp
to
the
receive
so
in
basic
mode.
The
client
compares
the
origin
timestamp
of
the
response
to
the
transmit
timestamp
right.
If
it
matches,
then
that
responses
in
basic
mode
and
it
binds
the
request
to
the
response.
However,
now
if
a
client
wants
to
support
interleaved
mode,
he
also
compares
the
origin
timestamp
to
the
received
timestamp
of
his
request,
and
if
these
two
matches
the
packet
is
in
interleaved
mode,
so
then
he
uses
the
other
mechanism
to
compute
the
offset
he
takes
the
timestamps
according
to
so.
D
C
C
D
Are
the
security
implications
because
usually,
if
we
verify
the
Mac
and
we
find
that
it's
wrong,
we
need
to
drop
the
packet.
But
now,
if
we
verify
the
Mac
and
we
find
it
it's
wrong-
we
also
need
to
drop
packets
from
the
previous
handshake
and
from
the
next
handshake
right,
so
there's
kind
of
more
complicated
process.
If.
C
It
depends
if,
if
it
feels
the
check
of
origin,
timestamp,
then
you're
sure
that
it's
not
the
right
packet,
but
if
the
match,
if
it
matches
the
or
if
so,
if
origin
times
10
matches
the
transmit,
timestamp
or
receive
timestamp,
at
least
the
packet
is
from
the
right
source.
There
is
something
wrong
with
the
Mac
right.
Yes,.
D
D
H
The
next
trick
is
Dave.
Mills
did
huge
amounts
of
work
on
this
and
wrote
papers
which
are
on
the
website
that
specifically
address
interleave
mode
and
specifically
address
how
long
it
takes
to
resynchronize
if
a
packet
gets
trapped,
so
those
issues
are
very
clearly
understood.
I
have
not
had
a
chance
to
look
at
this
new
proposal
much
yet.
H
If
we,
if
whatever
we
do
pass,
is
the
basic
time
stamp
checks
and
then
it
Pat
and
then
it
has
to
be
covered
with
a
Mac
either
the
Mac
works
or
it
doesn't,
and
if
the
packet
passes
the
authentication
checks
we
process
it.
If
it
doesn't,
we
drop
it.
One
thing
I
will
say
about
this
proposal
is
I
would
really
love
to
see
the
level
of
analysis
that
shows
how
recovery
happens
from
missed
time
stamps
or
missed
packets,
and
things
like
that,
but
yeah.
This
is
clearly
a
wonderful
thing.
H
There
was
I,
didn't
write
it
all
down,
so
I
forgot,
but
it
would
be
really
good
too.
Oh
I
got
you're
right.
There
was
probably
no
question
there
was
a
some
requests
for
additional
documentation
and
you
know
showing
how
how
the
recovery
process
works
and
I
will
say
that
as
an
child
went
through
her
discussion,
my
eyes
glazed
over,
because
she
looks
at
it
differently
from
the
way
I
look
at
it,
which
is
difference
in
the
way
it
looks
at
it.
C
So
yeah
for
your
first
comment
and
for
everybody
else's
comments.
This
draft
does
not
really
it's
not
about
how
more
accurate
time
stamp
should
be
captured
it's
more
about
how
the
transmit
time
stamp
of
the
previous
packet
can
be
sent
to
the
peer
or
client
in
the
following
packet.
We
don't
care
I,
don't
care
about
whether
that
time
stamp
is
more
accurate
or
less
accurate.
It
just
specifies
a
way
on
how
to
send
the
transmit
time
stamp
of
the
previous
packet
to
in
the
next
next
packet
right.
L
Okay,
so,
first
of
all
yeah,
that's
a
very
important
point
that
you
just
made
on.
So
if
that's
not
heavily
emphasized
in
the
document
already-
and
you
probably
should
think
about
doing
that
on
this
limitation
of
scope
towards
communication
of
the
time
stamp,
then
I
wanted
to
lead
with
first
of
all
for
my
point
of
view
as
a
editor
and
architect
for
the
security
stuff
as
many
headaches
as
this
might
cause
and
how
it
should
actually
behind
her.
L
Obviously
it's
great
because
it
would
fix
the
the
problem
of
group
to
delay
like
absolutely
for
the
first
packet.
So
I
think
this
is
very
important
work
for
that,
and
then
I
have
an
actual
question
or
an
actual
issue
that
I
wanted
to
raise.
L
First,
let
me
clarify
if
I
got
this
right
am
I
correct
in
thinking
that,
with
the
way
it's
currently
specified,
the
server
has
to
keep
pre-emptive
per
client
state,
because
the
question
is
yes:
Association
going
to
be
handled
with
interleave
mode
is
only
resolved
or
can
only
ever
be
resolved
affirmatively
when
the
interleaf
request
comes
and
the
negation
is
never
going
to
be
actually
resolved.
It's
only
going
to
take
forever
and
if
nothing
comes
then
obviously
this
was
intended
to
be
in
a
mode.
L
So
I
would
suggest
that,
if
I'm
correcting,
that
I
would
suggest
that
this
be
changed
in
some
way,
or
at
least
there
should
be
an
option
for
the
server.
The
first
thing
that
came
to
my
mind
was
just
require
the
client
to
put
something
an
extension
field
or
I,
don't
know
some
additional
info
into
the
first,
so
the
basically
the
basic
request
that
somatically
just
says
I'm
going
to
follow
up
on
this
with
an
interleaved
Packard.
L
Please
keep
state,
and
if
that's
not
there,
then
the
server
doesn't
have
to
keep
state
or,
alternatively,
it
could
even
be
handled
in
a
way
that
has
info
in
the
first
request.
L
The
basic
request
that
says
I
want
this
to
have
basically
a
follow-up
packet,
so
even
without
it
could
be
done
in
a
way
that,
even
without
the
second
requested
intellect
request
from
the
communication
scheme
could
be
one
client
request,
and
then
the
server
says
one
response
and
then
the
interleaf
response
and
then
closes
that
piece
of
stage
and
that
would
yeah
that
would
save
the
server
from
having
lots
of
State
and
that's
the
suggestion
and
then
I
guess
some
questions
in
there
implicitly
and
I
say
thanks.
C
So
this
state,
maintaining
another
list
of
transmit
receive
timestamp
is
not
a
big
issue
like
it's,
not
a
lot
of
memory
that
it
takes
for
the
server
to
save
the
state.
I
and
miroslav
actually
had
this
discussion
that
why
not
indicate
it
some
other
way,
and
he
had
better
explanation
of
why
not
doing
that
way.
I'll
leave
it
to
him.
Maybe
we
can
discuss
it
on
mailing
list,
but
yes,.
B
A
Now
I'm
scared
to
talk.
This
is
Rob
from
Deep
Diver.
Networking
I
just
first
want
to
commend
you
and
miroslav
that
I
think
it's
beautiful
that
you
took
just
what
was
already
there
and
figured
out
how
to
make
it
work.
So
for
all
the
comments
and
let's
this
field-
and
let's
have
that
field
to
me-
that
destroys
what
you
just
did
the
simplification
of
what
you
just
did
was
perfect.
Now
it
took
me
a
while
to
follow
it.
I
do
think
and
I
need
to
go
read
the
current
version.
A
The
draft
having
a
dressing
here
are
the
security
things
we
could
see.
Here
are
the
security
things
going
back
and
looking
at
PTP
and
other
things,
we've
done
to
see
what
they
had
to
address
and
make
sure
we've
got
that
if
we
cannot
add
a
field
or
a
signal
or
a
serial
number,
that's
beautiful
work.
Then
that's
me
that's
my
comment,
but
maybe
we
can
address
that
in
a
considerations
field
or
something
it
sounds
like
you
worried,
looked
at
it,
but
no
real
question
just
to
offset
the
other
comments.
Okay,.
I
Greg
no
CCTV
well
I
still
would
like
to
bring
the
follow-up
message
because
to
me
the
question
is
what
the
frequency
of
queries
from
the
client
to
the
server
because,
effectively
what
you
are
doing
by
moving
your
real-time
of
transmit
propagation
to
the
client
to
the
next
query,
you're
dependent
on
this
frequency.
So
the
usefulness
of
your
real-time
decreases
as
you
increase
the
interval
between
the
queries
from
the
client.
Whereas,
if
you
have
a
follow-up
message,
the
value
of
your
real-time
propagation
is
in
control
of
the
server.
I
I
I
I
B
C
F
I
C
I
B
H
First,
inner
leave
mode
has
traditionally
been
considered
to
be
most
useful
in
symmetric
modes,
not
so
much
in
client-server
mode.
It
would
be
interesting
to
get
some
real
data
as
to
how
useful
interleave
mode
is
in
client-server
the
concern
about
follow-up
messages
with
ntp,
as
it
doubles
the
workload
in
traffic
and
from
what
I
believe,
I've
read
out
of
dave's
papers.
Could
I
ask
them
about
this
before
he
said
it's
just
not
worth
it
they're
in
in
all
of
his
research
and
testing.
B
Just
a
sec
I
do
want
to
thank
Angela
and
Marisol.
This
is
a
draft
we've
been
wanting
for
a
long
time
because
the
the
basic
functionality
has
been
out
there.
The
one
thing
that
I
would
encourage
us
to
focus
on
is
getting
the
very
basics
documented
and
and
get
that
done,
and
then
we
can
start
making
it
fancier
and
add
additional
options.
I,
don't
think
this
is
a
case
where
lots
of
different
options
is
necessarily
a
good
idea,
so
it
last
chance.
B
C
Okay,
so
again,
I'm
Angela,
Malhotra
I,
have
to
say
this
from
Boston
University
and
this
work.
This
draft
is
jointly
done
with
Martin
Huffman
from
open
net
labs
and
will
and
her
up
from
NL
net
labs,
both
of
who
are
present
here
and
this
drop
in
this
draft.
We
basically
provides
some
guidance
to
the
implementers
of
applications
on
how
to
implement
time
that
use
the
are
now
to
implement
time
in
applications
that
use
time.
Okay.
C
So
what's
the
motivation
for
this
draft?
Well,
we
all
know
we
are
in
NTP
working
group.
We
all
know
time
is
important
and
without
hesitation
we
can
say
that
the
functionality
and
security
guarantees
claimed
by
many
applications
on
running
on
our
systems
and
in
the
internet
hinges
on
some
notion
of
time.
C
However,
currently
these
applications
and
the
implementers
who
implement
these
applications
that
use
time
seem
oblivious
to
the
implications
of
choosing
one
or
the
other
kind
of
time,
value
that
values
that
are
available
on
our
system
for
implementations,
and
this
obliviousness
can
be
attributed
to
the
lack
of
understanding
of
different,
unique,
specific
properties
of
different
kinds
of
time,
values
that
are
available
on
the
systems
and
also
the
availability
and
compatibility
of
these
time
values
on
different
kinds
of
operating
systems.
So
this
is
what
we
try
to
address
in
this
draft.
C
We
discuss
trade-offs
of
using
one
over
the
other
based
on
application,
specific
requirements
and
all
of
those
provide
guidance
to
the
implementers
of
these
applications
to
make
an
informed
choice
so
for
the
outline
of
the
stock,
I
will
talk
about
different
kinds
of
crocks
that
are
available
on
our
systems,
I'll
define
and
describe
them.
Then
I'll
explain
the
subtle
differences
between
them.
C
Then
Alex
explained
how
different
applications
express
time,
that
is,
it
could
be
time
stamps
and
time
spans
and
I'll
explain
the
differences
between
them.
Then
I'll
talk
about
how
these
times
are
handled
in
current
software
implementations
and
why
is
it
bad
and
then
we
offer
some
alternative
approaches
on
implementing
time,
so
different
crocks.
C
Unfortunately,
we
do
not
have
any
standard
terminology
or
definitions
for
different
kinds
of
clocks
available
on
different
systems.
So
for
the
purpose
of
this
document
we
come
up
with
some
terminology,
so
the
first
is
the
wall
time,
as
the
name
suggests
we
naively
assumed.
This
is
the
time
that
the
crocks
on
our
wall
should
show.
It
is
an
agreed
upon
ideal
time.
C
This
time,
as
it's
an
ideal
time,
it's
not
available,
it's
basically
completed,
you
can
think
about
it
as
most
applications
use
UTC
time
as
the
wall
time
and
the
UTC
time
is
computed
by
averaging
several
high
precision,
timekeeping
machines,
mostly
atomic
clocks.
So
of
all
time,
is
it's
an
idealized
notion
of
time
that
everyone
craves
for,
but
nobody
has
access
to
this
time.
C
Every
digital
system
has
its
own
perception
of
time,
so
the
system
provides
different
kinds
of
times
with
its
own
imperfections
that
are
not
as
perfect
as
of
all
time.
So
the
first
kind
of
time
is
the
raw
time
you
can
think
about
it
as
unadjusted
or
unmodified
system
time.
This
kind
of
time
is
measured
by
computing.
The
cycles
of
the
oscillator
of
a
system,
so
its
accuracy
depends
upon
the
system's
the
quality
of
systems.
Oscillator.
C
Another
kind
of
time
is
adjusted
raw
time.
So
this
is
the
raw
time
which
has
been
fixed
for
clock
drift.
Raw
time
is
completely
unmodified.
Adjusted
raw
time
is
the
time
that
you
give
get
after
adjusting
this
raw
time
for
clock
drift,
and
this
could
be
externally
adjusted
by
networking
protocols
or
it
could
be
manually
set
as
opposed
to
raw
time.
Both
of
these
times
are
monotonic
by
living,
and
then
we
have
another
kind
of
time
that
is
called
real
time.
C
It's
adjusted
raw
time,
which
is
shift
to
add,
to
attach
some
kind
of
value
to
time,
adjusted
raw
time,
which
is
shifted.
It's
shifted
to
match
whole
time
so
that
we
can
actually
use
it
to
compare
with
the
whole
time.
So
these
are
the
four
kinds
of
times
that
may
or
may
not
be
provided
by
the
modern
operating
systems.
C
What
are
their
differences
from
wall
time?
So
these
are
the
three
kinds
of
time,
raw
time
adjusted
raw
time
and
real
time
that
I
talked
about
so
raw
diamond
adjusted
raw
time.
Only
it
represent
difference
in
time
between
two
points,
whereas
real
time
defines
an
absolute
time
value
which
can
be
compared
to
the
wall.
Time.
C
C
Next
I'll
explain
how
different
applications
use
time.
Invert
forms
applications
can
use
time
in
form
of
time
spans
or
time
stamps.
So
what
is
the
time
span?
A
timestamp
span
represents
desired
length
of
time,
for
example,
a
timeout
values
on
protocols
or
time-to-live
values.
It
was
usually
expressed
in
terms
of
length
of
time
it
doesn't
have
an
absolute
timestamp.
C
The
timestamps,
on
the
other
hand,
represent
a
well-defined
point
in
wall
time,
for
instance,
the
validity
of
objects
that
specify
from
and
to
these
inception,
as
well
as
the
expiration
time
of
an
object.
For
instance,
this
signature
has
an
inception
date
that
is
2017
November
29
as
its
inception
date,
which
is
an
absolute
point
in
wall
time,
and
so
is
the
expiration
date
date
that
is
2017
November
10
all
right
said
the
other
way
around
yeah.
C
C
So
how
do
software
implementations
deal
with
these
time
spans
and
time
stamps?
Well?
Currently,
most
most
of
the
software
have
a
common
approach
towards
handling
time
stamps
and
time
spans.
That
is
the
time
spans
are
translated
to
time
stamps
by
adding
and
of
so
to
the
current
real
time
we
add
an
offset
equivalent
to
the
time
span
to
mark
the
end
of
the
validity
of
some
object.
That
is
that
this
that
has
this
time
span
and
then
this
timestamp
is
compared
against
the
current
system.
C
Time
to
see,
if
it's
valid
now
notice
that
this
current
system
time
is
updated
by
network
time
protocol
protocols.
So
why
is
this
approach
bad?
Why
is
this
approach
bad?
Well,
our
using
real
time
is
bad
because
the
real
time
is
updated
by
network
time
protocol
and
it
can
real-time
can
be
it
can
be
set
or
overwritten
manually.
It
is
adjustable.
It
is
subject
to
adjustment
adjustments
by
network
time
protocols,
and
these
protocols
are
not
very
robust.
We
have
shown
several.
We
have
talked
about
it
in
this
session
as
well.
C
Many
decent
works
show
that
there
can
be
off
path,
time,
shifting
and
denial
of
service
attacks
on
these
protocols,
which
can
be
leveraged
to
attack
various
applications.
That
are
you
relying
on
the
time
provided
by
these
protocols.
So
it's
a
bad
idea
to
use
real
time,
but
notice
that
in
case
of
timestamps,
they
are
always
based
on
wall
time.
We
do
not
have
any
option
other
than
using
real
time.
However,
that's
not
the
case
with
time
spans,
so
we
have
better.
We
can.
We
have
better
approaches
to
implement
time
spans.
C
So
what
are
the
alternative
implementation
approaches
for
time
spans
or
first,
we
should
not
use
real
time
because
for
time
spans
we
have
other
options.
What
are
the
other
options
as
I
talk
to
draw
time?
It
shows
you
the
passage
of
time
it
is.
It
is
unmodifiable
by
by
external
means,
by
an
epoch,
time,
protocols,
it
is
unaffected
by
product
time,
protocols
and
their
vulnerabilities.
C
So
the
applications
that
cannot
that
cannot
tolerate
clock
drifts.
They
haven't,
they
have
another
option
of
falling
back
to
adjust
a
draw
time
if
it's
provided
by
the
system
and
the
applications
can
cannot
afford
to
tolerate
the
trough
crop
drift
that
is
not
accounted
for
in
the
raw
time
it
is
accounted
for
in
the
adjuster
draw
time
they
are
just
a
draw
time,
however,
is
is
affected
by
the
network.
It
is
adjustable
by
network
time
protocols,
but
at
least
it
is
monotonic.
It
cannot
make
large
jumps.
C
It
is
adjusted
to
match
the
rate
of
passage
of
wall
time
gradually,
unlike
real
time,
which
can
make
large
shifts
forward
or
backward,
so
it's
at
least
a
better
option
than
real
time.
So,
in
the
end,
I
will
just
say
that
the
applications
that
can
tolerate
clock
trip
to
a
certain
amount
can
use
raw
time,
otherwise
they
can
fall
back
to
adjust
at
raw
time.
These
are
our
recommendations.
I
I
I
C
I
B
I
That's
why
it's
important
to
agree
on
the
dictionary?
Okay,
so
because
again,
I
used
to
understand
the
time
stamp
is
any
reading
of
the
clock.
The
clock
can
be
synchronized
and
unsynchronized.
It's
still
a
time
stamp.
Okay,
the
whole
time
here
you
set
the
context
as
it's
ideal,
synchronized
time
across
the
system.
Okay,
but
it's
not
the
only
type
of
times.
Then
you
can
have
some.
B
B
H
I
just
wanted
to
say,
I
think
it's
I'll
just
say
it's
unfair
to
say
that
some
of
the
issues
you're
bringing
up
with
NTP
and
laying
them
there
whenever
ntp
stops
the
clock.
It
writes
records
in
the
system,
accounting
log.
So
if
you're
trying
to
get
a
timespan
that
way
it
up
to
you
to
go
ahead
and
look
through
the
accounting
records
to
see.
If
any
time
steps
happens,
you
can
account
for
that.
This
is
all
stuff
that
gets
also
covered
for
in
absolute
vs.
and
difference
clocks.
H
So
there
is
a
whole
lot
more
going
on
here
and
the
surface
is
being
scratched
and
the
same
would
be
true
if
you
were
disciplining
your
clock
with
PTP
or
anything
else.
If
you
don't
have
the
appropriate
interfaces
to
do
difference
clocks
and
you
use
time
stamps
to
try
and
calculate
a
time
span
you're
going
to
have
problems.
It
gets
a
lot
worse
with
leap,
smearing
and
some
other
issues
as
well,
so
I'll.
Let's
leave
it
at
that
right
now,.
L
C
L
L
And
the
one
thing
I
wanted
to
actually
talk
about
was
the
the
terminology.
When
you
use
monotonic,
it
seems
to
suggest
you
mean
both
monotonic
and
then
also
some
notion
of
continuous,
because
jumps
in
the
monotonic
direction
are
also
implied
that
that's
not
happening
when
it's
when
it's
monotonic
I
would
suggest
a
clean
that
up
and
we
can
discuss
this
on
the
main
interest.
B
I
C
D
Ahead,
Hal
Tommy's
rahi
I
would
like
to
actually
expand
on
Greg's
comment.
One
of
the
things
I
was
missing
is
scope
of
the
draft
and
the
target
audience
because,
when
I
started
reading
the
draft
I
had
a
lot
of
hopes
and
then,
when
I
continued
reading,
I
saw
that
it
was
a
bit
different
than
what
I
thought,
for
example,
as
a
chip
vendor
I'm,
not
sure
it's
exactly
the
context
that
I
would
be
interested
in,
which
is
okay,
I
mean
if
you
in
the
abstract.
You
explain
exactly.
This
is
the
scope
of
the
document.
D
This
is
the
target
audience.
We
are
going
to
focus
on
ntp
on
implementations
of
ntp.
That
would
be
great.
If
you
think
the
scope
is
different,
then
again
it
needs
to
be
explained
because
it's
it's
very
important
to
define
the
scope.
Also.
Another
comment
is
that
I
think
this.
The
intended
status
should
be
informational.
C
B
I
I
B
B
That
actually
has
some
sense
of
meaning
and
I
think
this
is
a
conversation
we
can
have
on
the
mailing
list,
but
there
are
issues
that
there
are
downsides
to
to
this
approach
or
to
approaches
that
break
the
connectivity
between
real
I.
Don't
want
to
use
the
term
of
all
time
because
we've
already
said
that
all
times
not
a
good
time
necessarily
the
right
term,
but
I
think
we
need
to
be
clear
in
the
consideration
section
here
where
this
might
not
necessarily
be
the
best
idea.
Go.
N
Ahead,
Ethan
Grossman,
Dolby,
Laboratories
I'm,
building
on
what
you
just
said,
I
felt
like
one
of
the
things
that
wasn't
immediately
clear
to
me
was:
to
what
degree
are
you
putting
forth
the
right
way
and
wrong
way
to
do
it
in
terms
of
the
properties
of
the
protocols
themselves
and
as
things
operate
as
they're
in
as
opposed
to
in
the
presence
of
security
threats?
In
other
words,
it
seemed
like
there's.
N
B
The
thing
that
just
occurs
to
me
is:
we
didn't
actually
discuss
next
steps
for
this
document.
I'm
assuming
we're
gonna
rev
it
wants
based
on
the
the
discussion.
Are
you
let
me
rephrase
this?
Are
you
you're
interested
in
pursuing
this
document?
I
assume,
okay,
and
can
we
have
an
update
to
it
before
we
do
a
working
group
call
for
adoption?
Is
that
acceptable?
B
Agree,
I
think
we
need
to
have
discussion
on
the
mailing
list
and
then
that
discussion
would
he
would
result
in
another
individual
submission.
At
that
point,
we'll
talk
about
doing
a
working
group
call
for
adoption,
I
think
having
the
guidance
on
implementing
time
draft,
along
with
the
guidance
on
defining
times
or
choosing
time
stamps.
I
think
those
are
two
complementary
pieces
of
work
that
that
it
would
be
good
to
have.
So
thank
you
to
both
sets
of
people
that
are
working
on
them.
B
So
all
right
so
I
think
this
brings
us
to
the
tick-tock
portion
of
the
agenda.
We
can
move
pretty
quickly
through
this.
The
enterprise
profile
has
undergone
that
has
gone
through
working
group.
Last
call.
We
have
identified
a
one
error
in
the
document
and
that
and
Doug
is
going
to
post
an
update.
He
was
going
to
do
it
as
soon
as
sometime
this
week.
So
at
that
point,
that
document
will
be
going
forward
that
this
at
this
point
is
not
a
it's
not
really
a
technical
change.
B
It's
one
of
the
there
was
a
couple
digits
left
off
a
hex
field,
so
it's
it's
a
the
profile.
Id
had
a
error
in
it,
but
it's
not
really
it
it's
a
technical
change
because
it
was
a
mistake,
but
not
a
technical
change,
because
we're
changing
what
was
intended
so
last
item
on
the
agenda
is
the
yang
data
model
for
1588
v2.
O
All
the
resolutions
are
in
consensus
are
incorporated
in
the
new
version
of
this
document.
I
think
we
have
quite
a
lot
of
editorial
changes
introduced
her
for
these
revisions,
that
the
groupings
are
dropped
and
all
these
articles
are
moved
to
the
containers
respectively,
yeah.
This
is
a
disaster
at
Toro
one.
No,
the
new
code
changes
for
the
module
of
cheese.
O
Thank
you
just
as
you
can
see
from
the
tree
diagram
which
hymns
Mariana
it's
a
similar
fact.
Also,
the
scope
will
be
widened.
We
will
be
a
little
arm.
We
can
augment
her
with
optional
parameters,
just
as
we've
discussed
here
in
the
Middle
East,
but
for
this
for
this
iteration
we
will
not
consider
to
adopt
any
optional
parameters
and
we
also
added
a
root
node
for
PDP.
O
So
all
these
member
IPOs
can
be
belong
to
a
single
G
and
a
single
root
node,
and
then
we
decided
to
remove
gum
disease
such
as
removes
a
porter
identity
and
we
use
reuse
clock
identity
in
the
defaulter.
That
said
again,
we
used
put
a
number
but
her,
we
other
the
type
user
and
then
in
the
16.
So
it's
your
instance
now
for
the
transparent
clock.
We
also
use
the
same
port
number
internal
ended
16,
so
it's
a
and
we
remove
the
product
identity
and
author,
the
Thunderer
put
a
number
or
it's
a
removed.
O
O
Our
teaser
last
corporate
and
also
of
the
publication
of
the
new
revision
we
leave
the
some
more
comments.
Some
more
comments
most
often
are
at
Oriel
one
and
explain
explain
the
neck,
so
we
will
audit
in
the
nest
elevation
for
myself.
I
found
some
something
needed
to
change
it
in
the
INA
consideration
sections
we
also
simplex
and
spent
some
time
in
discussing
the
interaction
tails.
O
O
B
So
there
is
one.
O
B
P
So
the
question
I
had
is
like:
has
this
been
reviewed
by
somebody
with
like
yeah
expertise
because
I
looked
at
it
and
there's
like
something
that
didn't
look
like
to
me
and
not
a
yang
expert
right,
so
I
would
really
think
something
going
through
like
a
yang
doctors
or
something
would
be
like
a
good
idea.
P
B
P
O
We
sent
out
these
dormant
v
revision
towards
a
new
model
and
then,
whatever
one
grew,
I
believe
one
assignment
to
the
young
daughter.
But
we
didn't
say
you
see
where
any
comment
from
young
daughters,
but
other
experts,
such
as
a
margin
and
other
to
have
expressed
our
opinions
on
the
Middle
East
right.
B
B
Thank
you.
There
was
one
other
topic
that
I
I
thought
we
had
on
the
agenda
and
I
just
realized
that
we
did
not
did
not
actually
have
on
the
agenda.
I
should
have
been
back
up
under
working
group.
Ntp
working
group
status.
I
just
want
to
point
out
that
at
the
last
virtual
interim
we
had
a
discussion
about
the
extension
field
issue
we
at
we
went.
We
asked
the
authors
to
go
off
and
see
if
they
could
come
to
some
resolution
amongst
themselves.
B
B
This
has
this
has
not
happened
yet,
and
so
we
will
be
putting
together
some
formal
consensus.
Salt
calls
on
this
topic
for
the
working
group
mailing
list,
because
I
feel
that
we
need
to
decide
whether
we're
going
to
make
any
changes
to
the
way
extension
fields
are
handled
prior
to
actually
publishing
more
documents
that
have
extension
field,
it's
in
them
so
and
with
that
Harlen.
B
H
H
That's
the
case
when
I
strongly
recommend
and
what
I
told
to
dieter
last
week
was
that
if
this
is
something
you
care
about,
I
recommend
you
read
the
documents
that
each
of
anybody
who
cares
about
it
read
the
documents,
decide
what
makes
sense
and
ask
any
questions
they
have,
and
then
we
go
from
there
as
opposed
to
watching.
You
know
me
and
Danny
go
at
it
or
something
like
that.
H
B
Actually,
what
what
I,
what
I
thought
I
just
indicated,
I've
seen
a
couple
summaries
of
the
two
positions:
I
want
to
review
these
summaries
and
determine,
if
I
feel
personally
that
there's
enough
information
in
there
for
people
to
discuss
but
I
at
some
point
at
some
point.
We
need
to
make
a
decision
and
go
forward
yeah
and
so
and
the
IHF
process
to
do
that
is
to
do
a
formal
consensus
call,
and
so
that's
what
we
will
be
doing
and
I
would
I'm.
H
B
All
right
so
with
that
are
there
is
there
any
other
business?
No.
Thank
you
all
very
much.
Thank
you
to
everybody
who
did
lots
of
work
this
time
and
oh,
we
will
look.
Oh
I
see
Greg
getting
then
you
can
go
ahead
and
get
any
any
other
business.
Oh
okay,
so
the
next
thing
I
was
going
to
say
is
we
will
plan
on
a
virtual
interim
meeting,
probably
sometime
in
mid-december,
and
at
that
meeting?
B
I
would
really
like
to
be
ready
to
move
the
NTS
document
forward
so
that
we
can
plan
I,
really
think
we
as
a
working
group
we
need
to.
We
need
to
focus
on
that.
Wouldn't
it
be
great
to
have
a
hackathon
in
March
and
I.
Think
getting
a
couple
different
implementations
of
the
NTS
stuff
together
and
doing
some
testing
and
development
would
be
fabulous.
So
let's
really
shoot
for
that
all
right.
Anything
else.
Thank
you.
All
have
a
lovely
day
with
five
minutes
to
spare.
We
are
concluded.