►
From YouTube: IETF110-NTP-20210309-1600
Description
NTP meeting session at IETF110
2021/03/09 1600
https://datatracker.ietf.org/meeting/110/proceedings/
A
Okay,
we
are
at
the
top
of
the
hour,
there's
still
a
couple
people
that
I'm
expecting
who
aren't
here
yet.
So
I
might
wait
another
minute
or
two
and
then
there's
one
person.
I
realized
it
did
not
actually
confirm
whether
or
not
he
planned
to
talk
about
his
draft,
but
I
had
put
him
on
the
agenda.
A
A
A
A
So
welcome
to
the
ntp
working
group
at
ietf.
A
110
this
is
the
iepf
note
well,
which
you
have
undoubtedly
seen
a
number
of
times
and
agreed
to
when
you
register
it
has
all
of
the
processes
and
processes
and
procedures,
and
then
there's
a
list
of
documents
and
other
bcps
that
apply
to
ietf
work.
If
you
have
any
questions,
feel
free
to
ask
diaterai
or
rad
eric
who
is
online.
A
This
is
our
agenda
for
today
I
did
not
allocate
time
to
each
of
these
and
it
got
a
little
bit
longer
than
I
expected
so
we'll
have
to
keep
an
eye
on
the
clock.
The
next
thing
so
are
there
so
dieter
has
agreed
to
take
minutes.
Is
there
anybody
else
that
wants
to
help
him.
A
A
Nope,
the
next
thing
is
ntp
working
group
status
document
status,
the.
A
We
are
making
progress,
we
the
yang
data
model,
has
gone
through
last
call.
An
updated
draft
has
been
submitted.
A
And
I
know
that
the
editors
of
that
are
not
available
today.
I
believe
that
the
work
is
between
eric
and
the
chairs
command
modes.
I
just
realized
that
we
lost
track
of
this
one
and
I
believe
erica
has
been
through
last
call.
It
has
a
discuss
on
it
and
I
believe
that
brian
has
answered.
O'brien
has
answered
all
of
the
questions
we
decided
on
a
way
forward,
but
we
have
never
circled
back
to
ben
to
resolve
that
discuss
so.
E
I
have
I
have
tracked
that
there's.
I
thought
there
were
three
things
that
were
not
yet
resolved.
I
took
some
notes.
I
have
a
little
bug
tracking
system.
He
was
okay
with
the
md5
stuff
as
long
as
we
reverted
the
status
to
historic
which
we
did.
E
But
there
was
a
question
of
there's
a
20
bit
versus
24-bit
field.
He
felt
was
then
felt
was
confusing,
and
I
think
there
was
one
or
two
other
points
that
I
did
not
see
any
changes
in
the
doc.
Addressing
that.
A
E
I
think
yeah
I
can
send
you
and
brian
my
recollection
of
the
notes
and
try
to
try
to
pick
that
stuff
up.
Ben
did
ping
me
a
couple
times
saying.
Are
you
waiting
on
me?
Are
you
waiting
on
me
and
every
time
I
was
dealing
with
other
documents
and
other
things
so
yeah?
I
don't
think
we're
waiting
on
him.
E
F
That
would
be
that.
A
A
The
port
randomization
document
is
moving
through,
it
has
been
submitted.
It
has
been
reviewed
it's
on
its
way.
I
don't
think
there's
any
big
blockers
there.
A
Right
so
that's
with
with
you
and
then
that
leaves
two
that
are
ready
for
the
isg
that
need
to
be
submitted.
I
completely
forgot
about
the
tick
tock
document,
so
I
have
moved
it
over
to
here
so
that
we
will
do
a
better
job
of
keeping
track
of
that
one
and
the
ntp
interleave
modes
are
ready
to
go
so
we'll
get
those
done
right
after
this
ietf.
A
And
with
that,
that
is
the
end
of
our
documents
that
we
don't
have
on
the
agenda
to
talk
about
today.
So
next
is
oops.
Sorry
is
the
alternative
ntp
port
miroslav?
Do
you
have
any
thing
you
want
to
say
about
that?
One.
G
Yes,
there
is
a
new
version
that
was
submitted,
but
there
were
no
significant
changes,
just
few
sentences
rewarded
to
make
them
more
clear.
There
were
suggestions
from
steven
summers.
G
A
Okay,
does
anybody
have
any
questions
or
comments
on
this
document.
A
No
all
right,
so,
I
think
you're
right,
I
think
it's
been
around
for
a
while
and
we
are
ready
to
move
it
to
working
group
class
call.
A
H
Sure
so
I
guess
I'm
asking
for
working
group
adoption.
What
I
did
is
went
through
all
of
the
old
v1,
etc.
Ntp
specs
pulled
out
everything
that
looked
like
a
registry
wrote
it
all
up,
because
some
of
them
were
just
sort
of
implied
and
yeah.
There
will
be
an
issue
I
think,
for
discussion
on
the
working
group
list.
Some
of
the
nts
registries
were
partitioned
into
different
spaces.
H
But
since
you
know
it's
like,
oh,
you
can
have
the
low
order
byte
of
a
four
byte
field
or
something
like
that.
It
sort
of
reminds
me
of
the
old
bsd
reserved
ports
thing
so
we'd
have
to
resolve
that
issue,
but
other
than
that,
I
don't
think
there's
any
controversy.
H
I
did
have
iana
pre-review
it
just
to
make
sure
that
it
answered
all
the
questions
and
fit
what
the
current
standards
are
for.
Ayana
request
these
days.
D
Okay,
so
marcus
you're
in
the
queue
yeah.
Can
you
guys.
I
I
Possibly
also
see
me
in
a
few
seconds,
so
I
read
through
the
document
yesterday
and
it
all
makes
sense
to
me
that
we
try
and
make
sure
we
have
the
same
sort
of
requirements
and
specifications
for
the
registries.
I
The
only
thing
I
sort
of
I'm
missing
here
is
a
motivation
for
why
we've
chosen
certain
policies
such
as,
for
example,
specifications
required,
and
I
I
I
have
no
problem
with
picking
that
as
a
policy
for
all
registries,
but
I'm
I'd
really
like
to
read
a
couple
of
sentences
on
why
we
picked
that
one.
H
Sure
I
just
put
it
in
because
I've
been
one
of
the
tls
designated
experts
for
years
and
it
just
seemed
the
way
that
more
things
were
going.
If
we
wanted,
you
know
the
other
advantage.
Well,
yeah.
I
don't
have
a
strong
feeling,
one
way
or
the
other.
Whatever
the
working
group
wants
to
do.
H
I
know
that's
like
sort
of
a
not
answer.
It
was
just
like
arbitrary
based
on
my
experience.
It
seemed
designated.
You
know.
Expert
review
was
better.
It
could
also
the
experts
could
be
given
instructions
to
partition
the
space
for
only
standards
to
track
things
being
having
the
low
order.
Port
number
low
order.
Extensions,
if
that's
really
what
we
want,
but
yeah,
I'm
not
a
complete
answer,
but
the
best
I
got
so
far.
A
A
A
A
All
right,
yakov.
C
Question
is
assuming
this
is
adopted.
This
is
basically
going
to
be
an
rfc,
which
is
only
an
ayana
considerations.
Section.
H
K
H
K
Yeah,
so
I
I
I
think
we
can
make
these
changes
an
iana
request.
We
wouldn't
really
absolutely
have
to
have
a
draft
at
all,
but
I
I
I
think
I
think
I
think
an
informational
rfc
is
the
right
way
to
go
here.
C
So
what
what
the
reason
I
asked
it?
First
of
all,
I've
never
seen
an
rfc
which
has
only
an
iana
consideration
section,
but
what
I
wanted
to
suggest
is
instead
have
first
a
several
sections
which
explain
what
each
of
the
parameters
does
and
then
have
an
a
typical
ayana
consideration
section
which
says:
ayami
is
instructed
on
a
abcd.
C
So
did
you
read
the
draft
yeah?
I
just
read
it
right
now.
C
C
A
Okay,
any
other
comments
on
this
draft
all
right,
so
thank
you
rich.
We
will
do
a
call
for
adoption
on
the
mailing
list.
Next
up
on
the
agenda
is
chronos
neta.
If
you
want
to
do
you
want
to
do
your
own
slides
or
do
you
want
us
to
share
them,
for
you.
A
A
L
L
Yeah
so
a
short
reminder:
we
consider
a
default
tweet
model
where
the
attacker
has
a
fully
controlled
of
larger,
a
fraction
of
the
ntp
pool
so
a
quarter.
He
can
exchange
the
content
of
the
mtp
responses
and
also
delay
them
and,
of
course,
and
that
up
here
is
malicious
and
try
to
shift
the
client's
clock
as
much
as
possible.
As
you
can
see
in
this
picture,
they
claim
to
receive,
as
you
know,
were
both
good
and
bad
samples
and
he
might
choose
the
a
shifted
one.
L
Therefore,
we
suggest
to
the
modified
ndp
clients
named
homos
with
the
following
characteristics:
it
has
a
probable
security,
which
means
that
we
can
bound
the
successful
probability
of
an
attacker
to
shift
time
even
for
a
minute
in
the
middle.
It
has
backward
compatibilities,
since
there
is
no
need
to
change
anything
in
the
mtp
servers
and
we
are
mostly
based
on
the
standard,
ntp
client
and
we
end
only
small,
like
computation
and
communication
overhead,
as
with
very
small
number
of
servers
and
also
a
reminder
of
a
home
solution.
L
Also,
on
the
one
hand,
we
use
a
big,
a
pool
of
ndp
servers.
On
the
other
hand-
and
we
choose
it
random-
only
a
tens,
ntp
servers
and
sample
them
and,
lastly,
we
use
a
smart
filters
in
order
to
remove
small
filters
in
order
to
remove
our
lives.
L
Sorry,
however,
we
found
a
that
calls,
has
some
limitations
and,
first
of
all,
it
relies
on
hundreds
of
servers
which
are
not
available
in
many
regions,
and
the
second
is
that
it's
a
queries
randomly
selected
servers
which
might
be
dependent
on
each
other
due
to
ntp,
hierarchical
architecture
and
therefore,
an
attacker
who
directly
controlled
even
just
few
of
them,
might
influence
many
others
and
we
quantified
the
influence
of
an
attacker
on
the
pool
based
on
the
number
of
servers
he
controlled
in
control.
Sorry,
so
a
server
server
is
influenced
by
an
attacker.
L
As
you
know,
if
the
attacker
controls
the
majority
of
the
servers,
it's
synchronized
with
so
here
in
the
x-axis
of
this
graph
is
the
number
of
servers
directly
controlled
by
the
attacker
and
in
the
y-axis
of
each
of
these
two
graphs,
the
the
shifted
or
the
influence
servers
ratio
out
of
hundreds.
L
So,
for
example,
in
the
I
mean
figure
in
the
left,
an
attacker
who
gains
control
over
20
and
of
the
most
popular
time.
Servers
in
germany
can
shift
time
of
52
percent
of
the
time
servers
in
this
country
and
similarly
and
controlling
44
time
servers
in
north
america
and
is
sufficient
for
shifting
time
or
at
40
percent
of
the
service
in
this
region
out
of
approximately
and
900.
L
Therefore,
we
suggest
a
as
it
was
published
in
the
last
ndss
and
this
february
to
add
a
new
pool
called
which
avoids
the
dependency
issues.
L
The
servers
in
an
ikea
should
be
structural,
one-time
servers
which
are
independent
of
each
other
and
to
make
it
harder
from
the
for
the
attacker
to
inject
time
servers.
The
servers
in
a
9k
should
belong
to
a
reputable
organization
and
if
the
future
servers
may
er
may
be
added
by
some
trust
to
the
authority-
and
I
should
include
hundreds
of
such
servers
for
security
reasons.
However,
their
reliance
on
a
stratum
one
service
only
and
force
us
to
use
geographically
dispersed
servers
which
may
affect
time
and
time
currency
and
precision.
L
Therefore,
we
propose
that
each
and
every
client
will
run
simultaneously
to
parallel
medicine
and
synchronization
process.
This
the
first
one
is
primary
process,
which
is
identical
to
the
one
that
is
used
today,
such
as
the
default
ntp
v4
or
in
the
future
ndp
find
client
and
the
synchronized
with
the
a
pool
sign
servers
in
this
region
and
the
second
one
is
what
you
watch
the
process
and
that
consists
of
honest
clients.
We
synchronize
with
a
service
in
a
number.
L
The
title
of
the
clients
is
a
sorry
and
the
title
of
the
client
is
updated
and
by
the
preliminary
process,
unless
it's
time
dvd.
There
is
time
deviation
between
the
client,
the
entity
before
client
and
the
workshop
time,
and
in
this
case
the
client's
time
is
updated
by
the
watchtower
and
now,
let's,
let's
see
how
enantiomer
may
affect
the
time,
currency,
precision
and
not
balancing
so
to
measure
these
and
differences.
L
We
use
clients
in
different
region
to
query
and
query
ntp
servers
across
other
regions
and,
for
example,
as
you
can
see
here
in
this
figure
on
the
left
and
we
place
clients
in
the
uk
and
query
service
inside
the
uk
pool
in
europe
u.s
and
global
servers.
The
gap
between
the
offsets
achieved
in
by
querying
inside
the
uk
and
query
on
other
regions
were
was
six
milliseconds
and
we
got
the
similar
results
say
for
clients
in
ireland,
germany
and
in
the
us.
L
Following
these
measurements,
we
can
configure
the
watch
that
take
taking
over.
Only
when
the
it's
offset
is
far
from
the
mtp's
offset
like
approximately.
L
Sorry,
50,
milliseconds
and-
and
we
can
see
that
it
provides
both
good
precision
and
security
for
the
four
ingredients
and
in
the
absence
of
of
attack
and
I'm
care
offset
and
will
be
a
only
few
million
seconds
away,
even
when
using
x
region
servers
and
therefore,
in
this
case
an
empty
will
not
be
used
and
the
existing
typical
currency
and
precision
are
maintained.
Only
when
there
is
an
attack.
L
We
expect
to
get
a
large
offset
gap
and
in
this
case,
using
it
out
here
and
will
prevent
time.
Shifting
this
way,
we
accept
to
get
an
offset
within
a
few
milliseconds
from
the
quick
time,
even
during
an
attack
and
regarding
low
balancing
know
that
the
in
the
primary
process
and
tpp
before
low
balancing
is
they
used.
This.
L
We
suggest
that
in
the
watchdog
process,
the
query
rate
of
non-care
service
will
be
much
lower
than
the
ntp
query
rate
and
more
precisely
considering
that
only
around
10
percent
of
the
ntp
servers
are
structuring
one
service,
the
query
rate
of
watch
that
should
be
respectably
and
lower,
and
here
we
show
the
lower
bond
of
the
expected
time
of
successful
time
shift.
L
And
we,
when
we
consider
an
anarchy
pool
with
a
200,
a
time
service
when
they
watch
their
queries,
12
of
them
every
10
sec
hours
and
even
after
an
extreme
case
where,
when
many
of
them,
this
service
in
an
iqr
control,
seventh
of
them
are
controlled
by
the
attacker.
L
Finally,
we
propose
a
scheme
for
improvement
and
db
security
within
again,
which
we
preserve
today
time,
currency,
precision
and
loan
balancing.
L
So,
in
draft
zero,
two
in
the
last
draft
we
addressed
the
comment
we
got
from
the
the
working
group
regarding
the
a
watchdog
mechanism
and
its
a
default
parameters,
and
we
thank
a
ownish
and
what's
up
what's
on-
and
I
hope
I
pronounced
this
name
well
and
sorry
for
having
for
useful
discussion
a
and
next
we
will
update
the
draft
to
include
an
uncaseful
option
and
we
can.
L
We
continue
to
work
on
implementing
a
and
honors
as
a
watchdog
of
mpp
before
and
and
we
continue
to
evaluate
homes
and
enam
performance
and
security,
and
that's
all.
A
A
B
A
Ignacio,
we'll
come
back
to
you
watson.
Do
you
want
to
go
ahead.
B
Yeah,
so
this
what
you
presented
is
different
from
the
draft.
That's
fine,
but
once
we
start
getting
into
saying
we're
going
to
deploy
servers
around
the
world
that
we
trust,
that
is
effort
that
could
get
you
much
stronger
security
guarantees
if
they
were
running
rough
time
and
if
or
if
they
were
running
nts
as
well.
So
it
seems
that
once
you're
putting
a
nanka
in
the
relevance
and
the
other
thing
is
the
issue
with
the
query
rate-
isn't
well-behaved
clients.
The
issue
is
that
any
ntp
server
you
operate
can
be.
M
B
B
M
L
M
The
cloudflare.
M
L
The
question,
but
it
seems
like
what
you
are
asking
is
that
if
you
are
using
an
unkid
pool-
and
we
know-
and
we
all
know
that
it's
a
more
secure
and
and
and
so
on-
and
what
do
we?
You
need
a
a
chronos
at
all,
but,
as
you
were
saying,
every
server
can
can
be
and
can
be
a
talk.
So,
and
this
is
why
I
think
that
if
we
have
calls-
and
if
we
are
going
to
a
to
use
a
water
gun
away.
L
So
why
won't
we
double
the
the
security
we
can
have,
which
means
both
a
using
secure,
more
secure
servers
and-
and
I
used
a
whole
algorithm
for
for
dropping
outliners
among
this
group.
A
L
A
Right
so
next
up
is
so.
Are
there
any
other
questions
for
netapp
nope?
Okay,
great,
so
thank
you.
Thank
you
very
much.
Thank
you.
A
B
Is
your
screen
request?
You
should
present
the
slides
and
I'll
just
okay,
everybody
can
see
me.
Everybody
can
hear
me.
A
A
Okay,
just
give
me
two
seconds
to
make
sure
I
have
what
I.
B
Need
all
right
all
right,
so
I'm
going
to
be
talking
about
the
new
rough
time
draft
next
slide.
Please.
B
B
Okay,
I
can
try
a
different
microphone.
Is
this
better?
That's
perfect!
Okay,
weird
all
right!
So
next
slide,
please!
B
So
rough
time
is
certificate
transparency
for
time.
So
the
idea
is
by
having
servers
sign
their
responses.
We
can
detect
cheating,
we
can
detect
time.
That
is
invalid,
within
the
limits
of
the
round
trip
time.
This
solves
real
problems.
It
solves
real
problems
for
certificate,
verification
in
browsers
it
solves
the
bootstrapping
issues
where
we
need
an
authorized.
C
B
C
B
Okay,
all
right
so,
okay,
I
think
I
know
what
the
problem
is
I'll
fiddle
with
it
later,
but
what's
working
now
is
working,
and
so
this
is
so
draft
dash.
03
is
going
to
be
our
interrupt
target
because
there's
no
wire
changes.
We
think
we
need
to
make
the
changes
have
just
been
editorial.
Then.
The
second
draft,
which
is
much
less
advanced,
is
draft
iatf,
ntp,
rough
time
ecosystem.00,
and
it
defines
a
broader
ecosystem
of
how
do
clients
report
on
malfeasance.
B
B
This
is
an
ecosystem,
it
needs
deployments,
it
needs
independently
operated
servers
and
checkers,
and
this
can
update
much
more
independently
because
servers
do
not
need
to
make
any
changes.
No
matter
what
changes
making
ecosystem
parts
clients
might
need
to
make
small
changes,
but
they
don't
really,
if
you
have
any
sort
of
format
to
store
your
trusted
server
list
in
that
will
work
for
you
and
later
you
can
update
to
use
a
more
standardized
one
for
interoperability
purposes.
If
it
makes
sense,
you
can
always
take
advantage
of
the
checkers
once
we
have
those
defined.
B
Other
changes,
so
marcus
is
now
a
co-author.
It's
extremely
possible
that
when
I
was
chopping
these
apart
that
I
made
mistakes
and
sentences
don't
make
sense
anymore.
There
are
sections
missing
there
have
been
typo
fixes.
There
are
always
going
to
be
typo
fixes.
So
that's
that's
most
of
the
other
changes
and
now
last
slide.
A
Okay,
it
has
been
pointed.
D
A
That
perhaps
I
should
have
done
a
call
for
adoption
for
the
second
document,
so
I'm
asking,
if
there's
any
opposition
to
us,
having
just
accepted
it
as
a
working
group
document
as
they
split
out
of
the
first
document
I
was
assuming,
since
they
were
one
document
on
the
topic
we
were
just
making
it
two
was
not
a
not
an
issue
so.
K
A
Okay,
all
right,
so
these
documents
are
progressing.
If
anybody
has
any
comments,
please
take
them
to
the
mailing
list.
Next,
on
the
agenda
is
a
presentation
that
a
topic
that
came
from
the
dispatch
meeting
yesterday.
N
Okay,
perfect,
thank
you.
If
you
can
share
my
slides,
that'd
be
great.
Otherwise
I
can
try
to
initiate.
N
Okay,
I
see
them
now.
Thank
you,
hello.
Everyone
and
usually
I
work
at
egalia
and
I've
been
working
on
this
format
for
expressing
dates
and
times
on
the
internet,
which
is
something
of
a
solved
problem.
N
If
you
ask
many,
but
it's
not
completely
solved
yet,
as
I'd
show
in
the
next
few
slides,
if
you
could
progress
just
a
little
bit
yeah
so
before
you
ask,
I
am
a
delegate
of
tecma
tc39
we've
been
standardizing
different
additions
to
the
javascript
language,
one
of
which
is
called
temporal,
which
is
what
I'm
working
on.
N
It
is
a
ergonomic
api
for
dealing
with
dates
and
times
something
that
we've
worked
on
for
the
last
couple
of
years
and
and
it
introduces
new
ways
to
think
about
dates
and
times
in
ways
that
we've
not
discussed
previously.
So
that's
really
interesting
the
problem
that
we
come
up
with
once
somebody
deals
with
time
zones
and
calendars.
N
Sort
of
first-class
objects
is
how
do
you
include
that
information
during
persistence
right
and
if
you
progress
these
slides
a
little
bit.
N
N
The
time
zone,
conundrum,
as
one
might
say,
is
different
applications
realizing
that
they
need
a
human
time
zone
in
addition
to
the
instant,
in
addition
to
the
offset
and
therefore
adding
a
time
zone
to
to
that,
if
you
see
a
bunch
of
databases
like
post,
race
or
oracle
or
just
you
know
daytime
apis
like
java
or
linux2
like
the
date
binary,
a
bunch
of
people
have
come
up
with
interesting
ways
to
include
that
information,
none
of
which,
unfortunately,
is
in
the
standard
track.
N
So
it's
it's,
it
needs
to
be
standardized
and
what's
more
is
I
do
not
see
the
screen
yet?
But
okay,
can
you
progress
it
one
more
slide.
N
Okay,
yeah:
these
are
the
different
formats
that
people
came
up
with
and
and
if
you
go
one
more
yeah,
so
we
need
a
generalized
format
to
avoid
you
know
more
people
coming
up
with
these
this
problem
and
trying
to
hammer
their
own
extensions
into
things
right,
there's
so
many
things
that
need
that
can
be
expressed.
In
our
case
there
was
calendars
and
yeah
a
generalized
format
would
help
people
figure
out
the
way
to
add
more
information
in
a
cohesive
manner.
N
So
if
you
progress
to
the
final
fight,
I
think
yeah,
just
just
this
one
is
good.
So
this
is
how
we
use
the
calendar
extension,
which
is
you
know
on
the
left.
You
see
359
format
and
then
there's
an
extension
for
the
time
zone,
which
is,
as
I
mentioned,
not
standardized,
but
I
think
it's
common
you
can
you
can
find
it
on
the
internet
and
then
there's
you
know
a
version
of
the
of
the
proposed
extension
that
can
be
used
to
represent
the
calendar.
So
we've
talked
about
it
in
dispatch.
P
N
Is
that
we're
going
to
stand
sorry
to
charter
a
new
work
group
called
sedate
to
to
discuss
this
and
hopefully
publish
this
as
an
rfc?
It
was
brought
to
my
notice
that
people
here
would
possibly
be
interested
in
this.
So
I'd
love
to
hear
your
thoughts
and
comments.
B
Watson,
hello,
sorry
for
subjecting
you
to
the
noise
of
my
laptop's
fans.
Taking
off
one
issue
is
that
the
choice
of
calendar
will
affect
the
definition
of
day
and
the
other,
and
so
then,
when
you
have
a
time
it's,
it
gets
very
messy,
because
if
you're
representing
another
I
mean
there's
calculations
they're
also
they're
also
dependent
on
where
on
the
earth
you
are.
N
As
specified
by
339,
it's
always
the
left
part
right
in
the
green
part
in
this
particular
slide,
and
any
additional
information
can
be
expressed
in
these
tags,
but
that
doesn't
in
any
way
affect
how
you
interpret
the
the
part
of
the
breed,
so
the
instant
always
comes
from
there
right,
and
that
is
then
you
may
ask:
why
do
we
need
that
information?
Well,
if
you
need
to
do
any
sort
of
arithmetic
on
the
instant
itself,
then
you
need
this
information
right.
N
If
you
want
to
add
a
bunch
of
r's
to
to
a
time
stamp,
you
might
need
to
know
the
time
zone.
If
you
need
to
add
a
bunch
of
months,
you
need
to
know
which
calendar
system
the
the
origin
is
but
yeah
it's
it's.
The
timestamp
itself
always
remains
in
the
gregorian.
The
proleptic
gregorian
calendar.
D
A
O
Yeah,
I
think
part
of
the
confusion
here
is
that
there
are
actually
different
applications
for
date
times
and
if
you
all,
dump
them
into
one
big
bucket,
it's
going
to
become
very
messy.
O
O
Let's
say
non-physical
input.
Well,
okay,
there
are
leap
seconds,
but
in
general
we
can
treat
these
times
as
as
actual
time
whether
they
happened
in
the
past
or
whether
they
will
happen
in
the
future.
But
but
then
there
is
planned
time.
So
if
I'm
going
to
meet
on
christmas
eve
2022
at
the
4
p.m,
with
someone
there
is
no
way
to
map
that
to
a
timescale,
because
I
don't
know
whether
we
will
have
a
daylight
savings
time
next
year
or
not.
O
I
can
make
this
return
disappointment
to
a
timestamp,
that
is
honest
timescale
and
the
more
you
go
into
these
things,
and
then
you
start
to
to
discuss
recurring
events
and
and
all
this
stuff,
the
the
more
complicated
this
becomes,
and
it's
no
longer
about
time,
it's
more
about
calendaring
and
then,
of
course,
there
is
the
third
thing
which
probably
most
people
here,
don't
care
about,
which
is
remembered
time,
which
is
something
that
happened
in
the
past,
and
we
only
have
limited
information
about
what
time
scale
that
actually
was
mapped
to.
O
So
let's
ignore
that
for
the
moment,
but
for
for
actual
time
and
for
plan
time
you,
you
actually
have
to
have
very
different
mechanisms,
because
you
have
to
know
which
part
actually
wins.
O
A
document
that
may
be
useful
to
look
at
in
this
context,
so
in
the
sibo
working
group,
we
are
looking
at
a
way
to
to
represent
time
that
is
a
little
bit
more
flexible
than
the
time
representations
we
already
have-
and
I
expect
some
of
this
to
actually
go
into
this
document
at
some
point,
parts
of
it
are
commented
out
in
in
the
current
submitted
internet
draft,
and
it
could
be
added
at
any
time
that
that's
why
I'm
interested
in
this
subject.
N
Yeah,
thank
you.
I'd
read
deeper
into
the
document.
Your
your
concerns
are
really
valid.
I
talked
about
this
briefly
yesterday
and
the
idea
is
that
the
current
draft
that
I
have
is
is
not
something
that
works
well
with
the
idea
of
plan
time.
So
that's
not
a
scale
that
this
works
with
right
now,
it's
just
just
like
339
works
with
instance
in
time.
This
is
just
in
addition
to
that.
So
you
can
specify
additional
metadata
that
can
help
you.
N
You
know,
construct
similar
objects
or
information
from
the
timestamp
to
to
relay,
as
you
could
say,
important
context
with
the
time
stamp,
but
not
do
things
the
other
way
around.
I,
I
think,
there's
a
lot
of
interest
in
expanding
this
to
actually
include
plan
time.
So
that's
that's
something
that
that
probably
needs
to
be
answered
once
the
working
group
regarding
this
is
up
and
running,
but
it'd
be
really
nice
to
have
your
input
on.
N
F
P
Sorry,
finger
fumble
didn't
mean
to
be
in
the
queue.
P
N
Oh,
thank
you
I'd
reach
out
to,
I
think
kirsten
or
other
people
mentioned
in
the
sea
war
draft
offline
and.
A
A
A
R
R
So
there's
been
over
the
last
few
years,
an
increasing
call
from
network
operators
and
people
making
ptp
profiles
in
various
committees
are
asking
for
secure
version
of
ptp
and
in
the
the
the
last
version
that
published,
which
is
the
2019
edition
of
1588.
We
did
have.
R
A
message
extension
called
the
authentication
tlv,
which
could
be
used
as
a
message:
integrity,
protection,
and
we
had
a
little
bit
of
discussion
on
key
management,
but
but
that
we
didn't
really
have
time
to
finish
that
so
we're
taking
it
up
again
and
in
the
2019
edition.
We
talked
specifically
about
tesla
and
gdoi.
R
Ptp
grandmasters
are
typically
also
ntp
servers,
that's
probably
the
most
more
common
than
not
they're
doing
both
and
so
it
the
implementation
would
be
very
efficient
if
you
had
something
that
was
pretty
similar
for
both
timing
protocols,
and
the
other
thing
is
that
I
hear
from
network
operators
is:
please
don't
make
me,
deploy
and
maintain
another
key
management
protocol.
They
you
know
and
they're
already
doing,
tls
everyone's
doing
tls,
because
it's
used
for
https
and
other
things
that
are
common,
and
so
that's
you
know
another
reason
to
do
it.
R
R
Profiles
are
multicast,
not
unicast.
Most
of
them
of
the
deployments
have
some
or
all
of
the
switches
and
routers
that
are
support
the
protocol
and
that's
a
major
security
challenge,
because
now
every
every
device
in
the
network
is
participating
in
this
information
transfer,
their
pdp
deployments
are
usually
in
small
private
networks.
R
There
are
some
exceptions
to
that,
but
that's
the
by
far
the
most
common
thing
and
that's
an
advantage.
Often
the
thinking
in
it
something
that's
behind
a
firewall.
The
security
requirements
are
less
than
something
that
goes
across
the
public
internet
message
rates
are
very
high.
They
can
be
128,
sync
messages
per
second
and
then
there's
other
ptp
messages
as
well.
So
you
can
have
several
hundred
messages
per
second
coming
and
going
from
the
various
nodes.
R
Now
unicast
ptp
is,
I
don't
know,
client
server
mode.
So
it's
the
one
that's
most
like
ntp,
but
one
difference
thing.
That's
different
is
there's
sort
of
a
negotiation
protocol
that
sets
it
up
and
then
then
there's
the
ptp
time
transfer
aspect
of
the
protocol
and
so
they're.
R
R
And
it's
basically
looks
like
this
there's
a
the
multicast
version
is
uses
group
security
group
based
security,
it's
very
similar
to
gdoi,
where
there's
a
key,
a
key
server
and
everyone
in
the
group
sort
of
checks
in
and
gets
the
same
key.
It's
a
shared
key
and
then
they're
periodically
updated
and
that's
you
know,
has
it's
less
secure
in
some
ways
than
you
know
doing
one-to-one,
but
it's
practical
for
networks
where
every
node
on
the
network
that's
authorized
is
participating
and
then
nts
for
unicast
ptp.
R
The
approach
we
had
outlined
operates
more
like
the
ntp
version.
We
we
put.
The
exchange
of
you
know
the
information
that
goes
from
the
ptp
slave,
going
to
the
ptp
grandmaster
in
what
we
are
calling
a
ticket.
R
And
put
that
into
the
unicast
negotiation
part
of
the
protocol
and
then
the
time
transfer
messages
which
can
be
at
these
very
high
rates,
just
use
the
authentication,
tod
and
then
there's
a
cyclic
updates
for
all
participants
to
you
know
refresh
their
keys
with
the
nts
ke
server.
R
Okay,
so
this
is
currently
it's
being
discussed
in
the
ieee
1588
security
subcommittee,
which
is
also
chaired
by
karen
o'donnell
here.
That
makes
it
easy
to
coordinate
hopefully,
but
what
we'd
like
to
do
is
move
it
here
and
make
it
eventually
an
ietf
rfc.
R
This
working
group
is
familiar
with
nts
and
if
you
want
to
keep
nts
for
ntp
and
nt
and
ptp
coordinated,
this
is
probably
the
best
place
to
do
that.
So
this
this
is
just
kind
of
a
summary.
You
know
what
what
we're
trying
to
do
and
why
and
there's
going
to
be
proposals
submitted
and
discussed
and
debated.
But
this
is
you
know
this
is
what
we're
up
to
so
any
questions.
K
Ahead
daniel,
so
it's
so
dealing
in
the
multicast
case
here,
so
you
so
you're
talking
about
a
group
keying
protocol
that
they've
sent
them
that
that
implies
that
the
clients
have
to
implicitly
trust
each
other,
because
they
all
share
the
same
keying.
We're
trusting
the
switches
and
routers
to
behave
correctly
as
part
of
the
protocol.
K
So
what's
left
is
our
threat
model
here?
What
what
it?
What
is,
what
is
untrusted
that
we're
protecting
ourselves
against.
R
Well,
we're
we're
trusting
pretending
ourselves
against
someone
who
gained
access
to
the
network,
but
don't
hasn't
necessarily
taken
over
any
device.
No,
it's
not
necessarily
a
man
in
the
middle
of
attack,
but
they've
gained
access
to
the
network.
R
K
Are
we?
Are
we
permissioning
clients
what
what
what
parents,
the
adversary
from
from
just
joining
the
group
and
getting
access
to
that
group
heating
material.
R
R
R
K
R
Well,
you
know,
there's
definitely
a
call
for
security.
People
want
to
secure
ptp
and
we've
had
a
lot
of
discussion
on
what
do
we?
What
do
we
do
with
a
network
that
is
every
switch?
Is
a
transparent
clock
and
they're
all
altering
the
messages
as
they
go
through?
What
you
know
are
we
gonna,
have
a
lot
of
secrets
or
are
we
gonna
have
one
secret
that
is
shared
among
authorized
users?
R
It's
you
know,
neither
one
is
perfect,
but
it's
it's
a
you
know
it's
a
kind
of
a
worst
case
scenario
in
terms
of
trying
to
secure
a
protocol,
because
it's
it's
not.
You
know
a
conversation
between
two
nodes
that
is
just
being
moved
through
switches.
They're
every
every
device
is
part
of
the
conversation.
K
Yeah,
I
mean-
and
I
guess
my
position
on
this
is
the
same
as
it's
been
for
years-
that
that
you're,
absolutely
right
it
is
it
is.
It
is
a
worst
case
scenario
and
I
think
I
think
I
think
what
that
forces
is
just
a
fun
is
a
fundamental
trade-off.
K
If
you,
if
you
trust
everything
and
everything
is
behaving
correctly,
then
you
can
get
a
lot
of
you
can
get
a
lot
of
precision
benefit
out
of
ptp,
but
if
things
are
behaving
incorrectly,
then
you
either,
then
you
then
what
you're
ultimately
going
to
get
is
something
that
basically
falls
back
to
to
the
pounds
you
get
out
of
ntp
and
and
no
amount
of
crypto
is
going
to
save
you
from
that.
R
Trade-Off,
I
I
I
don't
think
I
completely
agree
with
it.
I
think
there
are
attack
attack
modes
that
a
group
key
could
help
with
and
and
the
one
I
mentioned
is
because
of
this
you
know
ntp
has
you
can
talk
to.
You
can
ask
lots
of
servers
for
time
and
you
can
run
a
voting
algorithm
and
you
can
detect
that
you
know
one
of
them
has
a
problem
in
in
ptp.
That's
that's
allowed,
but
not
generally
not
done,
and
so
they
are
vulnerable
to
that.
R
You
know
a
device
just
getting
into
the
network,
even
if
they
haven't
taken
over
any
switch.
If
they've
taken
over
a
switch,
they
can
do
all
kinds
of
things
and
maybe
messing
with
the
time,
isn't
even
the
worst
one,
but
if
they
just
get
access
to
the
network,
maybe
they
can't
get
the
group
key
because
they're
not
authorized.
R
And
that
would
be
something
that
would
be
better
than
doing
nothing
and
then
there's
the
the
unicast
case.
Where,
if
you
have
unicast,
then
it
can
be
more
like
nts
for
ntp
and
there
are
a
lot
of
networks
where
you
have
unicast
and
you
don't
have
on-pass
support.
So
it's
more
of
an
end-to-end
point-to-point
conversation
and
it
can
can
be
more
highly
secured.
K
Yeah,
I
I
I
I
mean
that
I
think
the
more
it's
shaped
like
ntp,
client
server
mode,
the
the
the
easier
it
becomes
to
secure
it
with
something
nts
shaped,
but
I'm
not
sure
there's
any
point
on
that
spectrum
where
just
use
nt,
where
we're
either
continue
using
unsecured
ptp
or
you
or
use
nts
secured
ntp.
I'm
just
I'm
just
not
convinced,
there's
any
useful
middle
ground.
There.
R
R
T
About
that,
I
did
also
want
to
point
out
that
I
think
there
is
some
agreement
that,
when
it
comes
to
securing
time
networks
that
the
time
itself
is
not
necessarily
what
we're
securing,
because
the
the
time
is
a
fact
the
moment
and
that
it's
really
associations
we're
securing.
And
so
in
this
case
the
focus
is
going
to
be
on
on
a
secure
ptp
network,
making
sure
that
no
ptp
clients
attach
to
unauthorized
masters.
T
It's
really
protecting
that
association
between
all
the
clients
on
the
network
and
whatever
is
serving
the
time
that
I
think
is
going
to
be
the
focus
of
of
whatever
security
comes
out
of
the
ptp
group,
because,
as
as
doug
observes,
the
the
ptp
best
master
clock
algorithm
was
not
designed
with
security
in
mind
and
it
it
can
be
easy
for
a
rogue
attacker
to
simply
broadcast
better
bmca
credentials
and
now,
all
of
a
sudden,
all
of
the
multicast
ptp
elements
are
taking
time
from
it.
T
A
Okay,
next,
in
the
queue
kristoff,
oh
wait:
doug
did
you
have
anything
you
wanted
to
say
or.
U
Great,
I
was
just
going
to
add
that
I
don't
think
we
should
see
ptp
use
cases
as
set
in
stone.
At
this
point.
U
We
see
popping
up
more
and
more
that
people
want
to
use
pdp
over
like
long
land
lines
or
in
scenarios
that
hasn't
been
used
before
so
maybe
also
just
the
generic
aspect
of
future
proofing
would
be
smart
to
think
about
here,
instead
of
seeing
it
as
a
given
that
pdp
is
always
used
in
like
completely
controlled
networks
as
it
is,
as
it
largely
is
now.
R
M
A
Stated:
okay,
any
other
questions
on
this
draft.
So
doug
was
the
primary
developer
of
this
is
martin.
He
was
unable
to
be
here
today,
so
thank
you,
doug.
I
think
we
sort
of
asked
you
at
the
last
minute
to
do
this
and
there
is
a
zero
zero
draft
that
has
been
posted
and
there's
an
update
coming
right,
doug.
R
Oh
yeah
there'll
be
there'll,
be
updates
and
there's
already
a
counter
proposal
from
some
of
the
details.
So
yeah
we'll
be
discussing
this.
A
All
righty
any
other
questions
on
this
topic
so
with
that
the
next
one
on
the
agenda
is
the
next
topic
on
the
agenda.
Are
the
ntp
v5
drafts
or
the
ntp
v5
discussion?
The
way
we
thought
we
would
organize
this
is
james
has
done
a
requirements
document,
so
you
would
be
first
james.
O
A
You
want,
do
you
want
me
to
do
your
slides
or.
Q
All
right,
excellent,
okay,
so
next
slide,
please
so
a
bit
of
a
brief
overview
of
what
this
is.
So
I
last
itf
I
think
it
was
karen.
A
few
others
discussed
the
idea
of
having
a
requirements
document
to
at
least
collate
the
various
things
that
people
were
interested
in
fixing
with
regards
to
well
in
terms
of
the
design
of
ntb
v5.
Q
I
know
that
there
is
a
lot
of
a
lot
of
people
got
a
lot
of
different
ideas,
so
I
set
forth
and
went
through
track
and
I
went
through
as
many
different
things
that
I
could
find
that
have
they're
covering
the
various
issues
with
ntbv4
and
as
well
as
some
of
my
own
thoughts
about
this
about
what
what
ntb5
ntp,
v5
could
and
couldn't
have,
and
so
the
whole
point
of
this
is
to
to
start
that
discussion
and
and
get
some
consensus
on
some
of
the
difficult
points.
Q
Q
So
I've
got
currently
got
two
versions
of
the
draft
out,
so
I've
got
oh
one
out
at
the
moment.
I've
got
a
few
editorial
changes
sitting
in
the
github
repo,
just
just
a
recap
of
what's
in
the
document,
if
you've
not
read
it,
it
puts
in
requirements
for
a
new
linear
time
scale,
so
no
leap
seconds
in
in
band.
Q
Q
I
think
the
the
least
controversial
thing
that
is
there
is
separation
of
of
steering
algorithms
away
from
the
protocol
specification
authentication
as
a
requirement
with
oxygen
with
optional
confidentiality,
as
well
as
some
some
statements
about
backwards,
compatibility
taking
into
consideration
ossification,
which
I
think
it
was
a
yuki
who
brought
up
on
the
list
not
too
long
ago,
as
well
as
some
extensibility
and
there's
a
there's
a
few
other
next
slide.
Q
Please
there's,
there's
quite
a
few
things
that
have
not
yet
been
covered,
but
some
of
these
are
issues
in
the
github
repo.
Some
of
these
are
just
on
my
to-do
list.
These
things
include
what
might
be
put
in
requirements
to
deal
with
ddos
and
that,
as
well
as
putting
together
a
threat
model
to
at
least
describe
the
kinds
of
things
that
we
will
deal
with
or
or
won't
deal
with,
which
I
think
will
be
a
critical
part
of
dealing
with
the
security
aspect
of
the
protocol.
Q
Design
last
slide,
please
so
I
I
am
asked
kind
of
ask
opening
this
up
to
a
discussion
about
next
slide.
Please,
karen.
Q
The
so
I
would
like
to
open
this
up,
should
we
be
considering
adopting
this
document
and
what
sort
of
process
should
we
be
using
to
apply
to
the
protocol
design?
I
would
like
to
just
leave
that
open
to
people
and
I'd
like
to
hear
what
people's
thoughts
are.
A
Okay,
yakov.
C
Okay,
if
I'm
already
starting,
I
apologize
for
not
having
not
having
read
this
document.
I
will
do
so.
I
just
wanted
to
mention
that
some
work
was
done
on
a
similar
topic
at
the
beginning
of
tiktak
quite
a
few
years
ago,
but
kurt
and
peter
came
up
with
a
document
which
they
called
itp,
which
was
supposed
to
be
the
next
version
of
ntp
and
it's
worthwhile
to
see
if
there's
anything
in
that
document
that
might
be
of
use.
C
I
was
unaware
of
that.
Okay,.
A
Yeah
when,
when
the
tick
tock
working
group
first
started
and
stuart
and
yakov
were
chairing
it,
the
charter
was
actually
to
do
a
a
requirements,
analysis
and
a
gap,
analysis
between
ntp
and
ptp
to
see
what
the
next
generation
of
of
time
synchronization
protocol
should
look
like.
So
there
is
some,
it
was
a
more
open-ended.
C
A
C
L
R
Oh
sorry,
god
I'm
muted
there,
okay
yeah,
I
I
would
say
I
think
it
would
be
very
helpful
in
the
development
of
ntp
version.
Five
to
have
this
document
go
forward.
There's
there's!
You
know
lots
of
ideas
being
debated,
lots
of
passion
and
if
we
can
agree
on
the
requirements,
then
I
think
we
can
help
sort
of
rein
in
the
discussion
and
say:
let's
go
forward
in
that
direction
and
we
have
a
much
better
chance
of
converging.
A
All
right,
daniel.
K
Yeah,
so
I
think
so,
I
think
something
of
this
shape
should
go
forward
in
some
form,
I'm
not
sure
whether
we
really
need
to
advance
it
as
an
internet
draft,
though
it's
just-
and
I
know
this
is
something
that
happens
all
the
time
in
the
itf.
But
it's
something
that
I
grumble
about
every
time.
I
get
a
second
review
of
one
of
these
that
I
don't
see
that
this
is
going
to
have
any
archival
value
once
we
have
an
actual
an
actual
working
group
specification
document,
advanta
it
adopted.
K
A
So
I
I
I
I
hear
what
you're
saying
I
guess
the
thing
that
that
I'm
wondering
about
is
we've
just
had
the
counter
example
to
that,
where
a
draft
that
was
done
13
years
ago,
we
have
just
said
wow.
It
would
be
really
good
to
take
another
look
at
that,
so
I
think
there
is
archival.
A
C
Yakov,
yes,
I
saw
one
point:
is
I'm
getting
into
technical
things?
Maybe
this
should
be
brought
to
a
list,
but
there
was
a
point
there
about
separating
the
steering
from
the
protocol.
C
I
remember
one
of
the
topics
that
we
discussed
at
the
time
was
the
fact
that
ntp,
unlike
ptp,
has
a
lot
of
these
dispersion
parameters
and
things
of
that
sort
in
the
packet
because
of
its
client
server,
rather
than
master
slave
architecture,
and
that
would
be
something
we
didn't
actually
get
into
it
too
much
at
the
time,
but
everyone
realized
that
was
a
part
of
the
problem.
It
would
be
interesting
if
you
could
have
a
separation
that
is
have
a
document.
C
Excuse
me,
I
have
a
protocol
which
does
not
go
hand
in
hand
with
the
algorithm
which
is
used
for
the
stabilization
of
your
of
your
clock,
even
when
it
is
rest
full
that
is,
cure,
client
server
when
the
server
forgets
the
client.
A
A
That
does
seem
like
something
that
we
should
discuss
on
the
list.
James
did
you
have
anything
you
want
to
say
specific
to
that.
Q
A
Okay,
daniel,
are
you
still
in
the
queue
or
is
that
a
q
fragment
and
you're
out
of
the
queue?
Sorry
all
right,
so
the
next
thing
is-
and
we
don't
have
slides
for
this,
so
marislav
has
put
together
a
draft
proposal
for
ntpv5
marislav.
Did
you
wish
to
speak
to
that?
Or
would
you
please
speak
to
that?
A
G
G
There
is
a
new
version
of
the
draft
that
I
uploaded.
The
concept
hasn't
changed.
It
still
looks
mostly
like
dntp
that
everyone
knows
it's
trying
to
address
the
issues
that
we
have
described
and
that
I
thought
we
were
set
on
addressing,
but
from
the
discussions
with
that
it
doesn't
seem
so
so
in
this
version
of
the
draft,
there
are
no
changes
in
the
protocol.
G
There
are
some
general
improvements.
There
is
a
full
description
of
the
correction
field
now
doc,
doug
helped
me
with
this.
G
There
is
a
new
section
on
the
measurement
modes.
There
is
still
a
lot
of
things
missing
to
make
a
full
description
of
the
protocol
and
before
trying
to
finish
this,
I
think
we
need
those
requirements
from
discussions
we
had
on
the
mailing
list.
I
think
it's
clear
that
some
people
want
something
very
different
and
we
need
to
agree
on
what
that
should.
G
A
A
Okay,
so
thank
you
very
much.
Marislav
I
mean
we
did
ask
one
of
the
keys
for
the
ietf
is
that
we
need
contributions
to
drive
our
work,
and
so
I'm
really
interested
in
in
what
you
know.
Implementers
are
interested
in
implementing
and
also
what
vendors
are
willing
to
put
into
products
and
so
go
ahead.
C
Yakov
just
a
short
comment:
I'm
trying
to
read
the
the
draft
right
now.
Once
again,
my
apologies
for
not
coming
having
read
all
the
drafts.
I
can't
sit
on
one
of
the
front
two
rows
of
miteko
here,
however,
it
it
it
looks
very
nice.
C
D
Okay,
doug.
R
Yeah,
I
you
know
some
of
the
the
other
things
that
people
want
to
do
with
ntp.
I
think
I
think
a
real
virtue
of
what
miroslav
has
started
with
is
something
that's
very
flexible,
so
it
can
do
all
the
traditional
ntp.
R
D
B
Watson
go
ahead
speaking
as
an
implementer
yeah.
There's
not.
I
don't
know
that
much
about
the
the
details
of
the
pll,
but
so
whatever
comes
out
of
this
process,
whatever
you
know,
it's
not
really
going
to
push
one
way
or
the
other.
Unless
there's
thing
you
know,
look
at
the
straps
look
at
the
other
proposals.
They
both
look
the
same
to
me.
B
B
G
B
G
Discussed
in
the
draft
of
the
protocol,
I
think
the
protocol
should
just
be
exchanging
times
time.
That's
all
it
is
needed
and
it's
up
to
the
implementation
to
decide
how
the
clock
should
be
controlled
and
what
what
is
the
goal
to
minimize
both
time
and
frequency
error
or
just
one
of
them?
G
G
A
Okay,
daniel.
K
So
before
we
go
forward
with
adopting
any
draft
specification,
I
think
there's
one
really
contentious
issue
that
last
that
last
I
looked
seems
to
be
splitting
this
working
group
about
cleanly
in
half,
which
is
whether
or
not
ntv5
should
support
any
any
unauthenticated
mode
of
operation,
and
I
think
I
think
we
should.
K
I
think
we
should
probably
get
a
formal
consensus
call
on
that
issue
before
we
before
we
do
much
of
anything
else,
because
that's
going
to
be
a
real
blocker
in
in
determining
some
pretty
basic
things
about
the
structure
of
the
wire
format.
A
Yeah,
I
think
that
was
part
of
the
marislav
saying
that
we
needed
to
advance
their
requirements
a
little
bit
before
we
adopted
a
draft,
so
I
think
that'll
happen
as
part
of
that.
C
My
comment
is
actually
about
the
previous
discussion,
the
requirements
one,
but
it
was
triggered
by
the
discussion
of
the
pll,
I
think
in
any
requirements
document
for
a
new
version,
especially
one
that's
going
to
be
doing
other
kinds
of
use
cases
the
discussion
of
what
you
do
or
how
you
can
exploit
the
fact
you
might
get
frequency
from
some
other
source
and
not
from
the
time
itself,
such
as,
which
is
being
done
in
telecom
networks,
where
you
use
sync
eve
to
get
frequency
and
then
1588
only
for
the
time.
D
D
Q
One
of
the
points
that
I
failed
to
mention
when
I
was
presenting
earlier
because
I
turned
into
a
ball
of
nerves,
was
the
the
requirements
that
that
I
have
in
this
document
are
not
set
in
stone.
They're,
just
my
collection
of
things,
and
so
if
the
working
group
wants
to
reconcile
have
a
different
view
as
to
daniel's
point
around
security
requirements
or
whatnot,
and
there
is
then
that's
completely
fine.
So
the
call
for
the
call
for
adoption
and
requirements
document
is
not
necessarily
a
call
for
adoption
on
security.
Q
A
O
Yeah,
thank
you.
I
have
a
simple
point
of
information.
I
just
leave
through
the
the
document
and
it
mentions
leap.
Smearing
and
I'm
wondering
is:
is
there
something
like
a
conversion,
a
convergence
on
on
the
right
way
to
do
leap,
smearing
already
just
a.
K
I
don't
feel
there's
a
convergence,
so
I
I
mean
I
so
so
I
I
I
think
the
answer
to
that
is
sort
of
the.
What
google
calls
their
standard
smear
of
24
hours
noon
to
noon,
linear
smear
seems
to
be
trying
to
assert
itself
as
something
like
a
convergence.
K
P
Q
I'm
I'm
desperate
to
get
rid
of
leap
seconds
for
all
the
paints,
of
course,
or
at
least
putting
them
in
separately
from
from
the
time
information,
so
they
can
be
handled.
O
That's
why
I
was
asking
the
the
the
document
just
mentioned
them
as
if
they
were
done
dealed,
and
I
just
wanted
to
know
whether
I
have
missed
something,
because
I
haven't
been
to
an
ntp
meeting
like
in
10
years
or
something
okay.
That
answers
my
question
so
with
that.
Let
me
just
make
my
my
saturn
sensio
here,
of
course,
any
new
protocol
that
has
extensibility
you
should
use
sibo
for
the
extensibility,
but
I'll
shut
up
now.
A
R
So
enough,
people
who
work
for
large
companies
that
have
large
distributive
databases
have
told
me
they
want
to
do
leap,
smearing
that
I've
given
up
on
talking
them
out
of
it.
I
think
it's
just
going
to
happen
whether
it's
a
good
idea
or
not.
I
I
think
the
justification
for
it
is
that
it's
easier
to
mess
up
the
time
than
it
is
to
get
all
the
database
code
to
do,
handle
leap
seconds
correctly.
K
Yeah
I
mean
I
I
I
so
I
don't
think
there's
there's
that
much
controversy
about
about
that
part.
There's
other.
There
are
always
going
to
be
applications
that
want
to
be
able
just
assume
that
there's
60
seconds
in
a
minute
and
and
and
takes
smeared
time,
but
I
think
what
this
working
group
needs
to
address
is,
whether
is
is
what
ntp
should
be
carrying
on
the
wire
versus
what
is
just
a
translation
performed
by
the
ntp
client
for
the
view
of
the
rest
of
the
operating
system.
R
Yeah,
well,
I
I
think
that,
what's
in
mirasoft's
draft
is
he
is
making
smearing
visible.
So
you
can
see.
Yes,
it's
turned
on
there's
a
flag
for
that
and
and
as
well
as
some
additional
information,
so
I
think
that's
should
be
part
of
ndp
version
product.
K
My
view
on
that
is
that
is
that
the
npp
packets
should
should
carry
all
the
information
necessary
in
order
for
the
client
to
perform
a
leap
smear,
but
we
should
not
actually
be
putting
smeared
timestamps
on
the.
P
A
Wire
all
right
so
enough
about
leap
seconds.
A
Did
you
mean
to
raise
your
hand
or
can
you
join
the
key?
Can
you
turn
on
your
audio.
V
That
yeah
figuring
out
icons
is
always
fun
expecting
clients
to
be
able
to
handle
leap.
Smearing
is
naive,
so
there
are
certainly
that
completely
valid
use
cases
for
for
putting
smeared
time
out
in
an
ntp
time
stamp.
V
B
Take
too
much
time
with
smart,
but
I
think
you,
the
clients,
can
you
know
the
client
implementation,
can
compute
the
smear
and
adjust
the
clock
locally?
It's
more
of
a
problem
for
servers
where
we
have.
If
you
start
changing
the
system,
clock
and
you're
depending
on
packet
timestamps,
this
whole
huge
mess.
B
So
it's
you
know,
and
that's
probably
not
really
a
working
group
thing
so
much
as
a
people
implementing
this
working
with
operating
systems
to
try
and
get
the
interfaces.
We
need
to
implement
smear
time
and
ntp
v5
on
the
same
systems.
If
that's
something
that
people
end
up
doing.
O
O
V
V
There
are
trivial
ways
to
make
sure
that
the
time
you
resp
you
give
somebody
could
be
smeared
or
not,
based
on
what
they're
telling
you
so
this
this
doesn't
have
to
be
complicated
and
from
everything
I've
seen
over
the
last
several
years
of
of
coming
up
with
proposals
around
this.
It's
not
that
big
of
a
deal.
O
A
Okay,
where
am
I
in
the
queue
daniel.
K
So
harlan
this
configuration
of
clients
thing
telling
them
telling
them
what
kind
of
time
the
system
should
use.
That's
that
that's!
That
sounds
like
something
to
put
into
dhcp,
not
directly
into
ndp.
K
A
Okay,
doug.
A
All
right,
so
we
actually
had
one
more
presentation
we
had
had
doug
had
put
together
a
presentation
kind
of
looking
at
the
mailing
list,
discussion
and
marisa's
proposal
and
sort
of
like
key
issues
in
a
way
forward.
I
probably
should
have
moved
to
that
a
little
bit
before
now
daniel
did
you
want
something
else
on
this
or
do
you
want
to.
A
Oh
all
right,
so
let
me
get
these
slides
up.
R
I
did
put
this
at
one
point
on
the
email
reflector,
so
a
lot
of
you
have
seen
it,
but
I
just
sort
of
gathered
together
some
of
the
issues
that
were
being
debated
on
the
email
reflector
next
slide,
please,
regarding
what
ntp
version
5
should
be.
R
I
think
this
is
a
just
a
statement.
It's
going
to
make
ntp
version.
4
works
very
well
for
many
for
most
ntp
applications
as
sort
of
a
general
it
use,
and
we
need
to
preserve
that
yeah.
Everything
startup
issue
is
not
solved
as
we
know,
but
everything
else
works
really
well,
so
this
has
to
be
preserved
next
slide.
R
So
the
question
is
why
why
are
we
doing
it
greater
accuracy,
flexibility
of
for
other
kinds
of
use
cases,
mandatory
security
to
push
users
to
adopt
security?
That's
something
that
has
been
proposed
as
well
as
uniform,
monolithic
time
scales
like
tii,
to
avoid
time
leap
seconds,
at
least
in
the
time,
stamps
and
simplify
ntp
world
by
moving
everyone
to
client
server
mode,
which
also
has
some
security
advantages
next
slide.
R
So
these
these
are
things
that
people
had.
I
said
these
are
what
ntp
version
five
should
should
do,
and
I
think
at
the
time
when
I
did
this,
I
think
this
was
what
I
found
in
terms
of
the
requirements
draft
had
the
flexibility
had
the
mandatory
security,
the
monotonic
time
scale
and
the
draft
so
far
my
miroslav
had
improved
accuracy,
had
the
flexibility
as
well
and
and
client
server
only
mode.
R
R
And
so
they
take
the
ntp
vore
packet
and
they
throw
out
everything
else
and
they
basically
do
high
message
rates
like
ptp
and
and
specialized
algorithms,
with
things
like
lucky,
packet,
filters,
etc,
and
they
are
able
to
do
pretty
well.
R
R
Okay,
flexibility
again
for
these
kind
of
specialized
use
cases,
you
know
when
you
detach
the
algorithms,
then
things
like
chronos
also
becomes
just
another
set
of
algorithms.
That
goes
with
the
ntp.
R
I
think
it
it
might
make
sense
to
have
an
informative
document
at
some
point
saying
hey,
if
you
want
to
get
the
general
it
case
to
work
with
a
very
good
set
of
algorithms,
here's
here's
an
outline
of
how
they
work.
R
Okay,
next
slide,
please
a
mandatory
security.
There
is
some
precedence
for
this
being
you
know,
pushed
into
new
versions
of
protocols
and
people
grumble
at
first
and
then
eventually,
everyone's
saying
well,
of
course,
we
have
to
have
that
maybe
there's
some
niche
applications
that
aren't
gonna
want
that.
I
think
it's
more
likely
that
the
there
will
some
be
some
niche
education
that
might
want
a
different
version
of
security.
R
So
I
think
that's
probably
what
we
are
going
to
want
to
look
at
to
maintain
the
flexibility
that
we
started,
enabling
is
to
say,
okay
here,
here's
the
default
security
mechanism
and
here's
a
couple
of
others
that
have
been
that
can
also
be
used
if
you
have
to
use
one
of
these.
R
So
something
like
that
is
a
possibility,
and
I
also
want
to
put
your
security
tends
to
change
all
the
time:
new
threats,
new
capabilities
among
the
threats
and
so
new
new
algorithms-
and
you
know
these
things-
things
are
always
changing,
so
I
I
think
it
might
be
easier
to
decouple
them
in
terms
of
documents.
Like
the
base
document
says,
you
will
use
one
of
these
and
that's
a
list
that
can
be
just
maintained
easily
and
then
the
other
things
are
developed
separately.
R
Okay,
next
line
the
monotonic
time
scale.
If
we're
going
to
do
amount
of
times
ago,
it
really
should
be
tai,
because
that's
a
international
standard,
not
something
like
that
like
gps
time
or
something
that
doesn't
necessarily
always
make
sense
so
and
that
no
leap
seconds
in
the
protocol.
That's
really
an
overstatement,
because
you
can
do
tai
time
stamps
and
still
have
a
utc
offset.
That's
exactly
what
btp
does
and
if
you
want
ta
time
you
can
ignore
the
utc
offset
and
it's
monotonic,
but
you
can
also
get
utc,
which
is
basically
required.
R
You
have
to
have
utc
so,
but
there
are
other
niche
things
where
people
want
ut1
or
or
some
other
things,
and
you
know
one
of
the
things
that's
in
miraslav's
proposal
is
you
could
you
can
select
other
time
scales
and
just
let
people
know
that
could
also
be
handled
with
time
scales,
always
tai,
but
there's
a
field
where
you
can
put
the
offset
to
whatever
you
want
it
to
be
and
you'd
say
it's
an
offset
to
utc
or
u21
or
there's
some
other
ones
as
well.
R
P
R
R
Please,
okay,
unicast
client
server
only
most
deployed
ntp
devices
do
this.
It
makes
things
makes
the
protocol
simpler
and
help
helps
with
some
security
issues
and
we
don't
have
a
security
standard,
that's
up
to
date
for
the
other
modes.
So
that's
another
another
issue.
Some
of
these
modes
people
are
using
and
they're
happy
to
use
that.
Maybe
we
could
say,
that's
fine.
You
just
keep
using
mtv
version,
4.
R
Okay,
I
think
that's
the
last
one,
so
these
are
just
things
that
were
being
debated.
I
just
saw
you
know
there
was
discussion
on
all
these
things,
so
I
kind
of
gather
them
together
in
one
one
place
and
say
these
are
our?
You
know
issues
that
we
need
to
make
a
decision.
A
A
I
guess
some
of
go
ahead:
carson.
O
Yeah
karen
just
asked
me
on
the
jabber-
and
it's
very
maybe
easier
to
just
say
this.
So
there
was
the
observation
that
the
security
components
are
always
changing
around
you
and
one
strategy
to
to
deal
with.
That
is
to
actually
offload
that
to
some
activity
that
already
has
maintenance
and
one
such
activity
is
cosy.
O
K
R
I
I'd
like
to
comment
on
that.
You
know
I
I've
had
a
lot
of
discussions
with
security
people
and,
if
they're
not
familiar
with
timing,
they
say
a
lot
of
things
that
don't
make
any
sense
for
timing
protocols.
Time
is
not
data,
it's
a
signal
and
it's
different
in
a
lot
of
ways.
Two
times
that
are
very
close
together,
but
different,
slightly
different
are
basically
the
same
and
that's
not
true
of
data.
D
Okay,
dennis.
T
So
since
it's
late,
can
you
hear
me?
Yes,
you
know:
we've
we've
had
a
lot
of
discussion
about
the
philippe
smearing,
and
I
know
there's
been
some
discussion
about
whether
or
not
security
might
be
mandatory
without
rehashing
all
that
I'd
like
to
maybe
suggest
a
different
approach,
and
that
might
be
that.
T
And
maybe
over
the
broader
internet,
we
make
much
stronger
recommendations
about
security
and
in
a
in
a
domain
where
the
customer
has
more
direct
control
over
what
attaches
to
their
network.
Allow
them
to
be
somewhat
relaxed.
B
Watson,
I
just
want
to
comment
on
the
recommendation
thing:
what's
the
cloudflare,
it
is
not
the
way
that
I.t
security
is
going
more
and
more.
The
local
network
is
untrusted
and
its
specific
authorizations.
The
same
you
would
do
as
operating
over
the
internet
and
more
and
more
companies
are
in
the
position
where
they
don't
have
a
network.
A
Okay,
james
really
quickly,
because
I
just
realized
we're
running
out
of
time.
Q
Yeah
really
really
quickly
my
concern
with
having
like
a
best
practices
or
something
to
describe
that
is
it'll,
be
a
serving
suggestion
and
then
we'll
end
up
with
more
insecurity.
So
I
can't
say:
I'm
a
fan
of.
D
It
all
right
watson.
V
There's
still
a
significant
use
case
for
people
on
networks
to
not
have
to
not
to
choose
not
to
use
security
as
part
of
every
packet,
and
I
would
say
that
it
is
not
interesting
to
a
lot
of
people
here
and
perhaps,
and
it
may
not
be
appropriate
for
a
number
of
use
cases.
It's
not
appropriate
to
all
use
cases,
and
I
don't
want
to
see
us
make
a.
I
don't
want
us.
I
don't
want
to
see
us
change
a
policy
choice
into
a
mechanism,
choice
or
into
a
mechanism
issue.
A
Okay,
so
the
next
item
on
our
agenda
was
to
talk
about
chartering.
We
do
need
to
work
on
a
working
group
charter,
I'm
going
to
defer
that
to
our
virtual
interim.
What's
coming
up,
theater
has
worked
on
a
very
rough
draft
of
a
of
a
charter
and
we
will
get
that
out
to
working
group
to
discuss
and
before
I
do,
the
discussion
of
virtual
interims
any
other
business,
and
I
know
that
there's
one
item:
that's
in
the
other
business.
A
So,
while
we're
waiting
for
daniel
to
come
back
online,
there's
a
lot
of
time
between
this
meeting
and
the
next
ietf,
so
I
think
we
need
to
work
really
hard
to
have
at
least
two
virtual
interims
in
that
time,
because
I
think
we
have
a
lot
of
work
to
do.
Sorry.
K
K
Yeah,
so
I
just
wanted
to
put
in
a
a
quick
plug
for
for
biz
time
link
now
in
chat.
So
I
mentioned
this
on
the
on
the
mailing
list
a
couple
of
weeks
ago,
and
I
know
people
are
looking
at
it
because
the
github
repo
keeps
on
keeps
on
piling
up
stars,
but
as
far
as
actual
feedback,
I've
gotten
crickets.
K
So
biz
time
is
byzantine
fault,
tolerant
time
synchronization
between
a
group
of
peers,
when
all
you
care
about
is
keeping
those
peers
in
sync
with
each
other
and
advancing
at
something
very
close
to
one
second
per
second,
without
neces,
without
caring
about
whether
this
drifts
in
the
long
term
from
any
authoritative
time
source
like
tai.
K
So
this
so
this
has
been
in
what
I
have
now
for
this
is
an
implementation.
It's
it's
a
good,
robust,
secure
implementation.
It's
been
in
production
with
us
for
about
a
year.
I
do
not
have
a
draft
at
this
time.
I'm
planning
to
write
it
up
as
a
right
to
I'm
planning
to
write
it
up
as
as
a
as
an
experimental
track
id
since
there
aren't
really
any
stick
any
other
stakeholders
that
I
can
identify
at
this
time.
K
I'm
not
planning
I'm
planning
to
do
this
through
the
independent
stream,
rather
than
a
rather
than
as
working
group
draft.
Obviously,
if,
if
significant
interest
picks
up,
then
we
then
we
could
we
could
we
could
circle
back
and
pursue
something
standards
track,
but
anyway,
at
this
time,
I'm
just
I'm
just
interested
in
hearing
from
people
if
you're
using
this
or
if
you,
if,
even
if
you
just
have
any
any
theoretical
applications
in
mind
other
than
other
than
that
I
haven't
thought
of.
I
just
just
want
just
that.
A
Okay,
this
was
sent
to
the
mailing
list.
I
don't
know
if
you
want
to
send
a
reminder.
A
A
I
don't
know
if
this
is
great
stuff,
is
the
ntp
v5
stuff
or
the
this
time,
watson,
but
or
both?
Maybe
it's
both
all
right,
so
the
so
I
we
like,
I
said
I
think
we
need
to
have
a
virtual
interim
looking
at
the
weeks
of
april
13th
or
april
20th.
A
A
A
A
Never
mind
wait
a
minute
harlan's
in
the
queue.
Okay,
oh
wait:
harlan's
gone,
maybe
harlan's,
not
the
cube.
Go
ahead.
Doug.
R
I
I
see
the
week
of
april
12th
through
the
16th
is
an
itu
meeting.
A
Right
we
could
go
to
the
week
of
april
6th
if
that's
the
week
after
easter,
but
I
guess
it's
since
it's
going
to
be
virtual,
it
may
not
matter
as
much.