►
From YouTube: IETF103-NTP-20181106-1610
Description
NTP meeting session at IETF103
2018/11/06 1610
https://datatracker.ietf.org/meeting/103/proceedings/
A
And
you've
seen
it
several
times
this
week,
so
you're
good
to
go
I
think
they
just
adjusted
my
volume.
My
female
I
feel
louder
all
of
a
sudden
our
agenda
for
the
day.
This
is
the
agenda
and
administrative
section
of
the
agenda.
We
have
a
bunch
of
really
short
stuff
to
discuss,
we're
going
to
be
marching
through
a
whole
bunch
of
our
work
items
and
discussing
the
status
and
what
the
next
steps
for
each
of
them
are.
A
A
A
Experience,
yes,
exactly
all
right,
so
the
rest
of
the
agenda
is
tick-tock
status
and
ntp
status.
The
guidelines
for
defining
Paquette
time
stamps
in
general
the
way
I
try
to
organize
these
meetings
is
our
working
group
drafts
our
adopted
working
group
drafts
first,
individual
contributions,
second
and
then
any
other
business.
Third,
there's
a
little
bit
of
variation
in
this
today
because
of
various
scheduling
considerations
that
we
have
people
that
will
be
joining
the
meeting
late
people
that
will
be
leaving
early.
A
So
that's
the
reason
for
this
so
guidelines
and
then
we
have
basically
three
security
items
on
the
agenda.
The
NTS
draft
that
we
currently
have
a
little
bit
of
discussion
on
NTS
implementations
and
interoperability,
and
that
is
presentation
on
a
secure
selection,
filtering
mechanism.
Then
we're
going
to
talk
about
the
BCP.
There's
a
quick
item
on
leap.
B
A
In
the
any
other
business
as
Harlan
on
Harlan
is
on
okay,
I
didn't
notice
yesterday,
but
I
see.
I
saw
today
that
there
is
an
additional
draft
on
the
ref
ID
for
leap
smear.
So
we'll
just
talk
about
that
briefly
in
the
any
other
business
section.
So
is
there
any
agenda,
bashing,
nope,
alrighty,
then
so
on
the
tick-tock
working
group
status,
we
have
two
documents
that
we
are
progressing,
the
first
one
being
the
yang
data
model
for
1588,
and
that
has
gone
out
for
a
second
IETF
last
call.
C
So
like
what
I've
done
is
like
put
in
like
kind
of
disclaimer,
it
says
the
standard
itself
is
not
openly
available,
so
there
was
like
an
issue
in
the
a
is
she
that
some
people
thought
like:
okay,
maybe
because
the
standards
not
openly
available
it
didn't
get
good
enough
review.
So
Karen
made
an
arrangement
to
get
a
copy
of
the
document.
C
If
somebody
asked
for
it,
so
we
don't
a
second
ITF
last
call
that
the
node
and
there
it
says
like
hey
if
you
want
the
1580
document-
will
get
a
copy
for
you
until
now
nobody's
requested
one.
So
once
that
second
last
call
finishes
like
I'll,
just
push
it
back
to
the
ESG
and
try
to
get
the
discusses
cleared
based
on
this
criteria.
So,
okay,
so
we
had
a
discussion
regarding
this
like
at
the
sunday
meeting
of
the
ESG.
C
It's
not
related
to
this
traffic
generally
when
getting
a
document
requires
paying
for
it
like
so
should
we
do
standards
track
documents
in
IETF
like
that?
Okay
and
we
haven't
concluded
on
it,
but
that's
probably
not
gonna
block
this
document
anyway,
okay,
so,
but
that,
if
something
happens,
that's
gonna
be
IDF
wide.
It's
not
gonna,
be
just
for
tik-tok
right.
A
C
So
that
I,
don't
think
that's
gonna
happen
in
a
hurry,
because
it's
not
something
we
can
do
trivially
because
there's
other
class
of
documents
that
are
not
freely
available
either
so
like
freely
meaning
not
it's
not
just
about
money,
it's
also
yeah.
So
the
one
of
the
things
is
like
you
know.
There
was
like
a
document
I
heard,
which
costs
forty
thousand
dollars
to
buy,
and
that
was
like
a
nominated
reference
for
a
document
so
V,
not
at
least
in
this
class.
C
So
is
it
gonna
be
like
some
dollar
value,
or
is
it
like
more
I
would
think
an
idea
that
people
are
posting?
That's
something
that's
not
clear
to
me
so
once
that's
clear,
I'll
probably
write
something
up
as
an
IAC
statement
and
to
the
community
and
then
go
from
there,
but
I.
Don't
think
it's
gonna
happen.
If
you
send
it
to
me
in
the
next
month
or
so.
A
A
D
C
Okay,
so
so
year-long,
so
the
if
the
thing
is
like
it's
just
a
sentence
as
an
editorial
clarification,
just
send
it
to
me,
don't
even
publish
in
your
draft
I'll,
just
put
it
as
an
ala
see
at
Northern
Pass
it.
But
if
it's
something
substantive
then
run
it
through
the
working
group.
But
if
it's
just
like
some
clarification
text,
just
send
it
to
me,
you
don't
need
to
publish
new
draft
yeah.
Okay,.
A
A
A
C
A
C
What
I've
done
is
I've
extended
the
last
call
so
because
the
ITF
we
came
in
between
so
I
just
extended
it
to
make
sure
that
people
still
had
a
chance
to
comment
on
it,
because
people
usually
say
like
how
don't
run
it
through
the
ITF
week,
but
I
wanted
to
get
it
on
the
Nextel.
A
chat
which
is
25th
of
November,
so
I
didn't
want
to
leave
it
until
the
idea
finishes
just
at
the
last
call.
C
C
C
E
A
C
So
the
one
thing
I
kind
of
wanted
to
focus
on
the
website
is
like:
should
it
be
a
BCP
or
not
right?
That's
kind
of
something
that
came
up
during
the
last
call
right.
So
what
should
be
the
SATA?
So,
in
addition
to
anything
else,
you
wanna
discuss
right.
I
just
want
you
to
think
about
that
too.
Okay,.
A
Actually,
dentists
and
ditcher
and
I
had
some
fairly
extensive
conversations
about
that
and
I
asked
for
some
review
from
Brian
Haberman
to
look
at
it
and
give
me
his
opinion
on
whether
he
thought
it
should
be
informational
or
BCP,
and
his
assessment
was
that
it
should
be
a
BCP.
So
we
and
dennis
is
going
to
talk
about
this
more,
but
we
intend
to
do
a
scrub
once
we
finish
addressing
all
of
the
ietf
last
call
comments.
A
A
The
shepherd
right
up
might
have
failed
on
that,
so
that-
and
that
was
my
fault
I
indicated
in
the
Shepherd
right
up-
it
was
informational
because
I
wasn't
paying
attention
in
my
head
at
BCP
is
informational,
but
it's
actually
not
technically
informational,
it's
it's!
So
what
is
it
the
all-caps
versus
a
little
so
anyway?
So
we'll
talk
about
that
more
when
we
get
to
that
point
in
the
agenda.
A
F
F
The
goal
of
this
draft
there
are
two
goals
actually
and
it's
intended
for
people
who
design
network
protocols
that
require
the
use
of
packet,
timestamps
and
the
goals
are,
first
of
all,
to
define
a
set
of
recommended
time
stamp
formats
that
you
will
typically
be
able
to
choose
from
and
the
second
goal.
If
you
were,
if
you
don't
think
any
of
the
recommended
time
stamp
formats
fits
what
you
need.
This
draft
also
defines
guidelines
that
specify
how
a
new
time
stamp
should
be
defined.
F
The
status
of
the
current
draft.
We
haven't
made
any
changes
since
the
last
IDF
meeting.
The
draft
is
currently
in
working
group.
Last
call.
We
have
received
some
comments
while
ago
from
Miroslav
from
Varna,
and
we
intend
to
address
these
comments
together
with
the
rest
of
the
comments
in
working
group.
Last
call.
F
So
at
this
point
the
next
step
is
the
complete
working
group
last
call
any
last
comments
will
be
appreciated
and
we'll
address
these
and
we'll
be
as
responsive
as
possible.
From
our
perspective,
try
to
do
this
as
quickly
as
possible.
Hopefully
we
can
send
the
drafts
to
the
ICG
pretty
soon
any
questions
or
comments
will
be
welcome.
A
Okay,
thank
you
and
for
those
of
you
paying
attention
that
the
actually
the
working
group
last
call
notice
went
out
about
an
hour
ago.
So
it
is
technically
in
working
group.
Last
call.
I
did
did
extend
it
through
the
end
of
November,
because
both
this
is
IETF
week
and
the
Thanksgiving
holiday
coming
up
so
and
I
expect
coming
out
of
this
meeting.
B
A
Or
comment
so
just
to
be
a
tad
bit
clearer,
a
tad
bit
more
clear:
we
did
it.
We
we
had
a
draft,
we
did
the
hackathon
event
in
March,
based
on
that
we
fed
all
the
feedback
into
the
document
and
then
in
July
we
had
another
set
of
excellent
contributions,
and
at
this
point
all
of
the
authors
agreed
with
the
documents
ready
to
go
to
working
group.
Last
call
right.
Is
there
any
to
this
going
to
work
from
a
bless,
call
Dania.
H
G
A
A
You
look
at
the
the
draft
IETF
dense,
RA
NTS,
then.
Basically,
it
was
incorporating
the
changes
they
suggested
there
into
the
core
NTS
specification.
Because
of
the
way
the
document
was
done,
it's
a
little
bit
hard
to
parse
it
because
you
can't
really
do
a
diff
I
mean
you
can
do
a
diff
between
the
two
versions
of
the
NTS
document,
but
you
can't
do
a
diff
between
the
didn't
sorry
in
it
is
that
Daniel?
Does
that
answer
sufficiently?
What
you
wanted
to
indicate
about
the
difference
between
those
two
drafts.
A
Sufficient
summary
excellent,
so
I
know
this
doesn't
get
into
a
lot
of
detail.
You
came
to
find
out
the
status
now.
We're
telling
you
is
we're
gonna
send
the
document
to
work
in
your
last
call,
but
this
document
has
been
progressing
for
quite
a
while.
We
do
have
some
preliminary
implementations
of
it.
If
there's
no
objection,
we're
going
to
send
this
to
him.
Your
last
call.
So
the
next
item
on
the
agenda
is
to
talk
a
little
bit
about
implementation
status
and
plans
for
interrupt
testing.
A
As
I
indicated
we
have
done,
we
have
done
hackathon
projects
in
both
London
and
and
Montreal.
We
didn't
do
one
here
because
a
number
of
our
key
implementers
we're
not
coming
here
so
but
I
know
that
Richard
I
believe
you
said
you
were
going
to
talk
a
little
bit
about
the
status
of
your
implementation
and
you
need
to
get
in
the
queue.
So
we
can
let
you
talk.
I
Never
going
to
cube
before
so
I
wasn't
sure
what
button
to
push
the
short
version.
The
last
week
we
were
able
demonstrate
partial
or
operability
with
our
patient,
and
there
are
some
bugs
which
we
are
going
to
correct
in
order
to
allow
interoperability
testing
with
martens
version,
but
we
are
expecting
to
release
that
version
for
testing
purposes
in
the
very
near
future.
The
one
caution
I
have
that
this
is
not
in
any
way
can
ready
version
reference
implementation
for
these
drafts.
A
I
I'm
not
sure
how
it
comes
off:
okay,
okay,
there
so
in
any
case,
we're
hoping
within
the
next
two
weeks
to
demonstrate
proper
ability
with
martin
Langer's
code
and
as
I
was
saying,
I'm,
not
a
production
ready
to
release.
In
particular,
we
were
writing
and
we
chose
not
to
attempt
to
implement
the
idea
of
a
key
exchange
server
separate
from
the
regular
NTP
servers
and
that's
something
that
we're
going
to
have
to
talk
about
an
MTF.
How
we
want
to
hear
that.
A
E
I
am
planning
to
do
an
implementation
for
interoperability
testing
next
in
the
next
ITF,
specifically
in
GU
language.
So
if
someone
is
interested
in
contributing,
please
let
me
know
also
I
think
Karen
we're
going
to
announce
some
mailing
list.
That
probably
will
help
all
of
us
coordinate
like
what's
going
on
on
the
implementations.
Oh
right.
A
So
look
for
that
in
the
next
day
or
two
and
I
will
announce
it
on
the
ntp
mailing
list
and
anybody
who
anybody
who's
interested
in
getting
some
of
these
initial
implementations
out.
That'd
be
great
at
this
point.
What
I'm
hoping
is
that,
if
the
working
group
last
call
goes
as
smoothly
as
I
hope
it
will
and
we
get
the
changes
incorporated
into
it,
that
we
will
be
perhaps
this
the
end
of
this
year
early
next
year
for
publication
all
right
anything
else.
Yes,.
G
Not
long
ago,
at
implementation
we
tested
in
London,
together
with
Martin,
miss
Daniels
in
imprint
implementation.
He
supervised
an
additional
project
at
his
university.
That
was
a
student
object
who
also
implemented
and
and
yes
independently,
so,
and
he
also
reports
that
they
have
interoperability.
A
A
J
J
So
a
short
reminder
is
that
we
consider
the
following
treat
model
where
we
swing
zoom,
that
the
attacker
have
fully
put
a
control
of
a
large
function
of
MTP
server
in
the
pool
sake,
water,
and
we
also
assume
that
he
can
and
most
decided
the
content
of
the
NTP
and
at
the
timing,
when
they
respond,
are
going
to
arrive
to
the
client.
And,
of
course
we
assume
that
these
militias
and
try
to
M
shift
declines
Suzy
and
no
no
just
a
moment.
I
came
back,
yeah
Indian
a
situation.
J
J
So
chorus
architecture
is
built
on
several
ingredients.
On
the
one
hand,
we
rely
on
many
NTP
server,
we
generate
large
server
pool
hundreds
of
servers
be
climbed
in
order
to
raise
and
the
threshold
needed
by
the
attacker,
and
on
the
other
side
we
cry
only
fused
them,
but
they're
randomly
chosen
and
in
order
to
avoid
overloading
the
NTP
and
service.
And
finally,
we
use
smart
filtering
in
order
to
remove
outliers
and
make
it
hard
today
man-in-the-middle
to
contaminate
the
choosen
samples
next
slide,
please.
J
So
in
our
new
draft
we
address
the
trade-off
between
precision
and
security.
Kronus
use
a
greater
variety
of
servers
that
are
trending
over
time.
It
also
avoids
and
NTP
filters,
and
this
allow
us
to
achieve
provable
security
guarantees.
However,
it
can
also
affect
the
precision
and
the
currency,
and
this
in
fact,
is
bounded
by
Kronos
Omega
parameter,
which
is
in
default.
J
25
millisecond
and
this
parameter
expressed
the
time
diversity
between
a
good
samples
and
their
distance
and
from
the
UTC,
since
it's
not
accommodated
time,
their
version
of
five
millisecond,
it's
insignificant
for
many
application
for
the
other
application
were
precision
and
a
currency
are
critical.
We
suggest
the
hybrid
approach
and
were
by
default.
Ntp
updates
the
clock,
but
one
would
faith
a
threat
or
there
is
an
evidence
of
a
check.
Then
we
can
use
Connors
time
and
next
slide.
Please.
So
far
we
got
mainly
cheese
suggestion
of
how
to
combine
Connors
and
in
the
corn
ntp.
J
The
first
one
was
to
run
hollows
externally
and
gather
data
statistical
data
over
a
malicious
server
in
order
not
to
use
them
or
avoid
using
them
in
the
NTP,
and
the
second
suggestion
was
to
use
Connors
as
a
new
file
filter
inside
the
NTP,
and
we
thank
dieter
and
Greg
for
the
useful
discussions
and
next
slide.
I
think
this
is
it
so
thank
you
and
I
can
take
questions
now.
J
A
J
A
A
A
B
So
I'm
sure
you've
all
seen
a
lot
of
the
traffic
on
the
mailing
list.
That's
discussing
the
last
call
for
the
BCP.
There
were
several
very
well-thought-out
comments
and
I
think
at
this
point,
we've
integrated
most
of
the
Commons
that
we
most
of
the
specific
comments
that
we've
seen
into
a
new
version
of
the
draft
which
will
be
posted.
B
8
I
mean
check
yes,
but
then,
as
Karen
alluded
to,
there
have
been
a
number
of
general
comments
about
the
the
language
in
the
document
and
about
the
tone
and-
and
those
are
things
that
we
intend
to
address
in
a
pass
afterwards,
taking
a
look
at
the
document
as
a
whole
and
seeing
where
we
can,
where
we
can
strengthen
the
reservation
there.
The
recommendations.
B
So
we
want
to
be
able
to
strengthen
the
recommendations
in
certain
places,
but
still
keep
the
document
as
a
general
best
practice
guide
and
there's
a
bit
of
a
balance
there.
But
we're
gonna
go
and
and
take
another
stab
at
that,
and
so,
at
least
in
my
mind,
my
view
would
be
to
submit
the
8
soon
and
then
do
a
general
tightening
up
in
the
language
and
submit
a
9.
And
then
at
that
point
we
would
move
forward.
I.
A
B
B
A
C
A
So
Oh
submissions
are
open
Dennis,
so
you
can
submit
a
submit
the
revised
the
revision.
Do
we
have
a
timeframe
for
the
revision
I
mean
so
I
mean
we've
got
the
revision,
that's
going
to
go
right
away
and
then
there's
the
next
one
and
then
the
next
one
is
one
will
go
back
to
the
iesg
and
say:
okay,
we
think
we're
done
with
all
these
last
call
comments.
Do
we
have
a
time
frame
for
that
next?
One
I'm.
B
Hoping
to
have
that
in
the
next
week
or
two,
it
really
depends
on
on
my
schedule
and
and
when
I
can,
when
I
can
make
time
for
it.
You
know
I've
been
very
busy
the
last
few
weeks
and
that's
part
of
the
reason
why
it's
taken
as
long
as
it
has
and
so
I
apologize
for
that.
But
I
do
want
to
push
to
get
this
done,
certainly,
certainly
before
the
end
of
the
month,
but
I'm
hoping
well
before,
then.
C
C
A
C
A
So
then,
the
next
item
on
the
agenda
is
a
really
short
one.
What
brought
this
item
up
initially
was
actually
a
trouble
ticket
that
went
into
the
ietf
website.
It
turns
out
that
this,
the
reason
I
put
it
next
to
the
BCP
and
the
agenda,
is
that
the
the
BCP
also
refers
to
it.
There
is
a
file
on
the
IHF
I'm,
looking
at
my
notes,
but
there
is
a.
A
A
It's
just
something
that,
in
the
process
of
the
website
being
IETF
website,
being
redesigned
was
sort
of
identified
as
something
that
is
not
what
was
up
on
the
old
legacy
website
moved
to
the
new
website
and
it
was
sort
of
an
orphan
on
the
website.
So,
like
some
perspectives
on
whether
this
is
still
being
used
or
not
in
the
implementations,
and
if
so,
we
need
to
document
how
that
gets
maintained
in
a
way.
That's
a
little
bit
more
obvious
than
it
currently
is
so
thoughts
from
implementations.
B
A
A
A
A
No
yeah
Harlan
is
yelling
at
us,
so
Martin
says
that
in
fact,
the
leap
second
file
is
retrieved
from
a
time
zone
database
file
and
it's
included
for
completeness
I,
think
that
the
key
is
there's
this
one
file
on
the
IETF
website.
That
does
not
appear
to
be
maintained
as
part
of
that
and
I
think
what
I'd
really
like
is
a
couple
of
volunteers
to
help
me
clarify
if
there's
something
that
needs
to
be
updated
somewhere
if
this
particular
file
is
still
being
used
and
how
to
do
that.
So,
if
Martin,
if
you
understand.
A
So
I
think
that
what
the
if
I,
were
an
IETF
website,
maintainer
person,
I,
think
what
I
would
really
like
to
do
is
get
rid
of
this
file
if
it's
not
actually
being
used.
That
would
be
the
key
thing.
So
perhaps
I'm
wording
the
question
a
little
bit
too
wishy-washy.
Can
we
get
rid
of
this
file
and
do
we
need
it?
A
K
Karen
hi
Jason,
Jared,
Mancha,
Akamai
I
I
would
suggest
that
we
remove
it,
especially
if
there's
no
document
referencing
the
data
file
and
if
it
breaks
something
you
know,
then
we
can
quickly
submit
a
document
stating
warrior
and
why
that
file
lives
there
as
a
reference
for
whatever
implementations
may
use.
It
right.
A
A
We
can
write
I
think
what
we'll
do
is
we'll
take
this
offline
as
a
project
and
Martin
and
Harlan
and
I
will
get
back
to
you
all
and
what
the
right
answer
is,
but
I
think.
If,
if
it's
not,
if
it's
not
referenced
by
specification,
if
it's
not
used
in
a
protocol
somewhere,
we
should
probably
get
rid
of
it.
A
A
A
L
L
L
B
A
H
L
Similar
approach
like
in
PTP
with
the
follow-up
message,
but
for
NTP
that
would
be
a
problem
because
it
would
amplify
the
traffic.
So
we
need
to
make
a
compromise
here,
and
that
is
that
we
need
to
keep
some
small
state
for
each
client.
It's
about
16
bytes,
depending
on
the
implementation
and
that
state
can
be
lost
and
nothing
bad
will
happen,
because
the
protocol
can
fall
back
to
the
basic
mode.
So
yeah
some
state,
it's
required,
but
it's
very
small
and
it's
not
critical.
A
E
Hello
today,
I'm
going
to
talk
about
talk
something
on
implementing
time.
This
is
the
second
draft
that
we
submitted
and
we
have
made
changes
based
on
the
comments
on
the
previous
draft,
and
this
work
is
jointly
done
with
Christophe
from
ptb
Martin
Huffman
from
open
net
labs
and
vilem
from
NL
net
labs.
E
So
the
motivation
behind
the
work,
so
we
cannot
understate
the
importance
of
time
and
today's
digital
systems,
so
functionality
and
security
of
all
the
applications
hinges
on
some
notion
of
time
and
for
the
implementers
who
implement
these
applications
that
rely
on
time.
They
have
to
choose
from
multiple
clocks
that
are
available
on
digital
systems,
and
the
problem
is
that
these
applications
choose
one
of
these
clocks
but
are
oblivious
to
the
implications
of
choosing
one
or
the
other
clock
for
implementation.
E
E
So
first
this
document
will,
in
this
document
we
explain
different
kinds
of
time:
different
kinds
of
methods
that
are
used
by
different
applications
to
express
time.
We
then
talked
about
different
how
different
how
digital
systems
keep
time.
That
is
the
different
kinds
of
clocks
that
are
available
on
today's
digital
systems
and
their
properties.
Then
we
discuss
the
trade-offs
of
using
one
or
the
other,
a
one
crop
over
the
other
for
different
applications,
and
we
hope
that
this
will
provide
some
guidance
to
the
implementers
to
make
an
informed
choice
while
by
implementing
applications
that
use
time.
E
E
E
This
document
doesn't
deal
with
the
question
of
how
these
did
so
will
I
will
talk
about
different
kinds
of
plots
that
are
available
on
the
digital
system,
but
this
document
doesn't
deal
with
the
question
of
how
these
clocks
are
available
on
different
pcs
or
other
devices
like
the
API
is
that
are
available.
We
don't
talk
about
it
in
the
in
this
document
and
we
do
not
recommend
one
time
over
the
other
for
all
the
applications
like
there
is
no
set
in
stone
final
recommendation.
E
We
just
provide
the
different
properties
of
these
times
and
the
trade
security
properties
and
other
properties
of
this
time
and
the
trade
offs
of
using
one
of
over
one
of
the
crocks
over
the
other,
but
the
fine,
the
final
decision
of
which
talk
to
use.
We
are
very
depending
on
the
availability
of
the
clock
on
the
system
and
the
security
requirements
of
the
specific
application
that
is
under
implementation.
E
So
expressing
time
how
so
we
define
two
kinds
of
time
in
which
most
applications
Express
time,
so
the
first
is
absolute
time
absolute
time
as
I
expresses
an
absolute
fine
point
in
time
or
say,
for
instance,
November
6
2018
a
specific
time
and
absolute
time
is
typically
used
to
indicate
the
validity
of
objects
which
have
a
limited
lifetime
that
can
be
shared
over
the
network.
For
instance,
the
signature
has
a
validity
period,
it's
pretty
old,
it's
expired,
probably
so
it
has
2017
it
this.
This
timestamp
is
an
absolute
timestamp.
E
Then
we
have
some
applications
Express
time
in
terms
of
relative
time,
which
is
a
measure
of
the
time
interval
that
has
passed
from
a
fixed
reference
point
so,
for
example,
time
to
live
TTL
values
that
determine
the
determine
the
length
of
time
for
which
an
object
is
valid
or
usable
that
uses
relative
time.
Applications
that
use
TTL
use
relative
time,
for
instance,
this
is
the
TTL
for
this,
our
our
set,
which
means
that
this
record
should
be
considered
valid
for
seven
five
nine
eight
seconds,
and
then
it
should
be
reached
from
the
source.
E
So
these
are
the
absolute
time
and
relative
time
at
the
two
tech
kinds
of
time
that
they
are
most
applications
express
time.
Now,
how
different
a
how
different
of
how
digital
systems
keep
time.
That
is
the
different
clocks
that
are
available
on
digital
systems,
the
first
one
we
call
it
native
rock.
This
is
something
that
is
very
its
systems
own
perception
of
time.
It's
very
subjective.
It
is
obtained
by
the
systems
by
Counting
the
cycle,
let's
say:
scouting
the
cycles
of
an
oscillator
or
by
using
process
CPU
times
or
thread,
CPU
timers.
E
So
what
are
the
properties
of
this
time?
It
is
monotonic,
it
would
always
go
in
one
direction.
It
is.
It
is
immune
to
vulnerabilities
from
external
time
sources
it's
it
is
not
affect.
It
cannot
be
said
this
time
cannot
be
set,
it
cannot
be
set
manually
or
from
other
external
sources
of
time,
since
it
is
not,
it
cannot
be
set.
Its
quality
depends
on
the
stability
of
its
the
stability
of
the
oscillator
or
CPU
timer
of
the
system,
and
there
is
crop
drift.
E
E
With
other
properties
of
this
time,
so
since
it
is,
it
can
be
set
manually
or
from
external
other
external
sources
of
time.
It
compensates
for
the
clock
drift,
so
this
time
can
be
in
sync
with
other
systems,
so
this
time
has
the
potential
to
stay
in
sync
with
other
systems.
However,
it
is
since
it
is,
it
can
be
set
manually
it
as
vulnerable
to
miss
configuration
errors.
E
Second,
hardware,
clock
access
is
resource
intensive
and
the
quality
of
the
hardware
proper
me
note
may
not
be
very
high
in
in
many
digital
systems,
which
could
lead
to
a
large
clock
drift
drift
if
it
is
not
compensated
for
the
clock
drift.
That
is
one
reason
why
why
it
is
why
world
clock
uses
external
sources
of
time
to
adjust
for
the
clock
drift
and
since
it
is
adjustable
by
the
external
sources
of
time,
it
opens
up
the
world
cloth
to
the
vulnerabilities
that
are
present
in
these
external
sources
of
time.
E
E
So
these
are
the
two
kinds
of
on
a
very
broad
level,
two
kinds
of
time
that
are
available
or
two
kinds
of
clocks
that
are
maintained
by
digital
systems.
Now,
how
do
software
implementations
deal
with
relative
time
in
application
when
applications
use
relative
time?
How
do
software
implementations
deal
with
you've?
Seen
that
most
common
approach
that
the
implementers
take
is
to
convert
relative
time
to
absolute
timestamps
to
absolute
time
and
then.
E
E
E
But
what
we
talk
about
and
discuss
in
this
document
is
that,
in
case
of
where
applications
use
relative
time
and
where
the
implementers
have
to
implement
a
relative
time,
they
should
not
use
absolute
time.
Instead,
they
may
consider
using
the
native
clock
that
is
available
on
the
on
the
digital
systems
and
we
discussed
the
trade-off
security
trade-offs
in
our
document.
E
And
in
the
end
we
provide
we
talk,
we
discuss
a
little
bit
about
the
API
is
that
are
available
on
the
POSIX
and
Microsoft
Windows
systems
for
optic
obtain
native
time,
so
on
POSIX
system,
this
function,
clock
get
time,
provide
all
kinds
of
different
times
that
are
all
kinds
of
different
clocks
that
are
available
on
this
operating
system.
So
one
of
the
so
this
function
takes
as
an
argument,
clock
identifier,
one
of
which
may
provide
native
time
and
on
Microsoft
Windows.
E
A
H
E
M
Cairo's
Akamai
I
mean
I,
think
it.
This
reminds
me
a
lot
of
the
considerations
for
randomness
are
that's
what
it
reminds
me
of,
so
it's
not
it's
not
providing
it's
providing
sort
of
guidance
to
implementers
for
how
to
properly
deal
with
these
things,
based
on
the
experience
based
on
on
the
experience
of
people,
who've
implemented
systems
that
need
to
use
time
and
on
just
like
careful
analysis,
so
I
mean
I,
it
seems
useful
and
it
seems
like
there's
precedent
for
documents
like
this
being
published.
So.
C
Like
no
ad
had
like
I
thought,
the
document
was
useful
like
for
me
and
I
think
it
should
be
published
like
if
it's
not
published
like
keep
it
on
a
group
week
here,
something
at
least
so
just
make
sure
that
people
can
get
to
it
and
I.
Don't
so
one
of
the
reasons
I
thought
it's
better
to
publish
is
like
I.
Don't
see
this
like
changing
very
much
so
if
I
thought
this
would
like
be
like
something
that
could
get
out
of
date
quickly.
C
A
C
Again
so
one
of
the
reasons
people
say
putting
some
of
your
keys,
like
things
are
dynamic,
so
one
of
the
things
that
vent
actually
from
an
RFC
to
Vicki
right
is
the
Tao
of
the
idea
for
Dow
or
the
idea
of
division.
How
you
wanna
say
it
that
went
from
an
RFC
to
a
wiki
because,
like
we
realized
that,
like
by
the
time
it
gets
published,
like
things,
are
already
out
of
date,
right
like
that's,
so
that
at
that
point,
when
something
is
very
dynamic,
you
put
it
in
a
wiki.
C
A
And
I
it's
it's!
It's
been
a
while
since
I've
is
implementing
anything
with
time,
but
I
think
some
of
the
issues
that
that
I'm
challahs
talking
about
some
of
the
same
issues
that
that
that
we
worked
on
when
I
was
writing
code
that
implemented
time
in
various
system.
Various
real-time
systems,
so
I
personally
think
it's
useful
chair
hat
completely
off.
So
all
right,
so
I
think
then,
with
that
the
is
anybody
opposed
to
us
doing
a
call
for
adoption
on
this
document.
A
A
A
This
particular
document
started
out
as
three
different
proposals
for
f4f
IDs
I
asked
them
to
combine
all
of
those
proposals
into
one
and
then
what
happened
was
is
that
two
of
those
proposals
are
pretty
solid
and
the
third
one
was
more
controversial,
and
so
what
we
wanted
to
do
then
was
to
pull
the
pull
them
back
apart.
I
asked
them
again
to
pull
them
back
apart,
so
go
ahead.
Harlan.
A
A
Okay,
so,
oh
that's
me
deco
talking
to
him
so
Mike,
so
the
proposals
haven't
changed,
they're
pretty
much
as
they
have
been.
I
asked
on
child
to
take
a
quick
look
at
this
for
me
and
and
make
sure
that
the
the
other,
the
original
well
I'm,
drawing
a
complete
blank
one
as
I
do
and
I,
and
the
other
ones
in
ipv6
something
I'm
drawing
a
complete
blank.
This
is
embarrassing,
but
but
anyway
there's
two
RF
IDs.
They
haven't
really
changed.
A
We've
pulled
out
all
the
leap,
smear
stuff
which
was
controversial
and
so
at
this
point
I
think
this
document
is
also
ready
to
go
to
working
group.
Last
call
it's
been
here
for
a
long
time
and
when
we
pull
out
the
leap,
smear
stuff,
it's
it's
pretty
stable.
So
is
there
any
questions
or
comments
on
this
going
to
working
group
last
call
now
one
of
the
things
I'm
doing
by
putting
you
know
three
or
four
documents
out
for
working
group.
Last
call
is
we
have
a
bunch
of
stuff
to
read
and
comment
on.
A
L
Can
you
can
you
speak
up
a
little
bit
Marisol?
Please,
there
was
a
new
version
submitted
and
the
main
change
was
that
it
now
uses
the
format
of
the
PTP
correction
field
to
allow
some
existing
hardware
to
support
this
NTP
correction
field.
So
they
don't
have
to
support
two
different
time
scales
and
the
PTP
correction
field
is
using
nanoseconds,
and
so
this
is
this
feels
a
bit
foreign
in
the
NTP
protocol,
but
I
think
it
will
make
it
easier
for
implementation.
A
L
L
L
The
main
idea
is
that
is
compatible
with
RFC
7
822,
and
there
is
no
ambiguity
in
parsing.
That's
it.
These
are
the
two
main
points
and
it
allows
shorter
extension
fields
to
be
saved
in
a
ntp
packet
with
Meg
and
everything
together
and
don't
waste
much
space
on
padding,
because
7t,
a
22
requires
padding
to
prevent
ambiguity
in
parsing,
and
this
proposal
gets
around
that
by
packing
multiple
extension
fields
together.
A
H
H
A
What
so
we
had
a
call
for
we
had
a
call
for
adoption
on
the
last
extension
field,
so
I
think
we
divided
the
extension
field
stuff
into
two
categories.
One
was
clarifications
or
extensions
on
how
the
extension
field
mechanism
itself
is
designed
and
works,
and
then
the
separate
thing
is
proposals
for
new
types
of
extension
fields.
So.
A
A
A
The
next
set.
The
next
agenda
item
is
actually
going
to
be
a
little
bit
tough
to
do
if
Harlan
doesn't
have
audio.
There
are
currently
four
drafts
for
extension
field
proposals.
These
extension
field
proposals
are
intended
to
be,
or
the
the
guidance
given
as
far
as
they
need
to
be
compliant
with
seventy
eight
twenty
two
they
are
extended
information
I,
do
last
EF
and
should
suggest
ref
ID.
A
A
H
A
A
A
A
A
A
A
A
A
Will
point
out,
the
Medeco
actually
provides
a
number
of
tests
for
folks
to
try
in
advance
to
make
sure
that
their
audio
and
video
is
working
and-
and
that's
that's-
really
helpful.
I
know
it's
not
a
tool
that
a
lot
of
people
use
every
day,
but
it
and
and
I
know
that
the
me
deck
I've
actually
driven
me
to
echo
guys
crazy
on
a
couple
of
calls
where
I've
had
problems.
But.
H
A
This
is
a
leap,
smear,
not
the
leap.
Second,
no,
he
says
leap
second
here,
but
I
think
the
problem
is,
is
that
there
there
doesn't
seem
to
be
consensus
on
whether
the
leap
smearing
is
a
good
thing
to
do
or
not
and
I
think
there's
a
there's,
a
set
of
people
who
feel
like
we
should
not
be
allowing
it
and
then
there's
a
set
of
people
that
say
people
do
it
anyway,
so
we
should
go
ahead
and
do
it
all
right
go
again.
Let's
try
again
Harlan.
A
A
A
A
A
Look
for
the
mailing
list
if
you're
interested
in
planning
the
the
implementers
coordination
list,
look
for
a
hackathon
effort,
doing
interrupt
testing
and
implementation
of
NTS
in
the
March
timeframe,
and
we
will
attempt
to
do
two
interim
two
virtual
interims
one
in
the
you
know
we'll
figure
out
the
winds,
but
you
know
early
to
mid
December,
late
January
or
something
like
that.
Like
January,
early
February,
I,
think
the
last
one
that
we
had
was
a
little
bit
too
close
to
this
meeting,
but
part
of
the
reason
for
that
was
we.
A
We
ran
into
scheduling
difficulties
so
other
than
that.
Please
reply
to
the
working
group.
Last
call's,
oh
yeah,
there
we
go
rich
says
it
very
well
see
you
on
the
mailing
list
in
the
interims
and
on
the
net.
Thank
you
all
very
much
I
think
we're
getting
some
stuff
done.
It's
a
good
idea
to
clear
out
some
of
our
overdue
work
items.
Thank
you.
Everyone
and
have
a
lovely
evening,
thank
you
to
everyone
who
joined
remotely
I,
know
it's
strange
hours
for
a
lot
of
you.