►
From YouTube: IETF104-NTP_TICTOC-20190326-1350
Description
NTP TICTOC meeting session at IETF104
2019/03/26 1350
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
A
A
Okay,
so
our
agenda,
this
is
the
agenda
bashing.
We
have
the
tic-tock
working
group
status,
then
ntp
working
group
status
and
basic
both
of
these
are
just
quick
reviews
of
documents
that
would
not
going
to
need
to
spend
a
lot
of
time
talking
about
today
and
just
talk
about
what
status
they're
in.
We
will
cover
the
hackathon
activity
over
the
weekend,
and
then
we
will
talk
about
the
rough
time
draft
that
was
submitted.
A
A
And,
very
briefly,
on
the
yang
data
model:
I
know
the
author's
can't
be
here,
but
I
have
an
update
from
them
and
then
the
piece-
that's
that's
currently
missing
this
any
other
business
and
housekeeping.
So
will,
at
the
end
of
these
we're
going
to
talk
about
a
number
of
the
other
items.
If
you
look
at
the
agenda,
online
you'll
see
the
list
of
other
things.
I
wanted
to
go
through
quickly.
That
did
not
have
updates
in
advance
of
the
IETF.
A
A
So
this
is
not
working
okay,
so
the
tick
tock
working
group
status,
the
yang
data
model-
has
has
made
it
out
and
it's
in
the
editor
queue
now,
which
is,
which
is
great
news,
and
the
second
document,
which
is
the
last
document
remaining
and
the
tick
tock
working
group,
is
the
enterprise
profile.
We
addressed
all
of
the
nits
yesterday
and
an
update
thanks
to
her
Heiko
thanks
Danika,
and
so
that
one
is
ready
for
submission.
We
will
still
have
the
same.
A
B
Thanks
again
so
I'm
trying
to
formalize
the
process
with
that
ESG
for
that,
so
I'm
writing
up
something.
So
you
will
make
this
like
a
standard
procedure
when
the
documents
are
not
freely
available.
So
this
will
be
like
IETF
white
procedure
that
we
follow.
Whenever
some
document
is
not
freely
available,
then
it
goes
telescope.
Okay,.
A
You
always
know
you're
being
successful
when
you
require
the
development
of
a
new
process
or
a
new
procedure.
So
so
that's
where
we
are
with
the
1588
Enterprise
profile,
and
then
we've
had
a
number
of
conversations
about
this.
The
intention
is
when
this
document
gets
through,
that
we
will
close
the
tic-tock
working
group
and
have
a
single
time
working
group
in
the
IETF
consolidate
all
the
resources
in
one
place.
A
So
this
is
the
NTP
working
group
status,
and
these
are
documents
that
we
should
not
have
too
much
to
talk
about.
The
BCP
is
in
iesg
evaluation.
It
currently
has
one
outstanding
discuss
on
it,
and
the
authors
of
the
document
are
working
to
resolve
that
discuss,
and
hopefully
we
will.
We
will
have
that
done
shortly.
B
Thank
you.
So
the
outstanding
discuss
is
from
acre
and
he's
gonna
leave
the
iesg,
so
I
had
to
talk
to
him
and
figure
out
like
you
know
how
he
wants
to
followup
on
the
continuity
or
discuss
so
like
whether
Roman
is
gonna.
Take
it
off
or
like
we
had
to
figure
something
out,
but
either
way
I
will
not
have
enough
votes
on
the
ESG
when
the
iesg
turns
over
tomorrow.
A
A
C
Peter
and
I
have
been
working
directly
on
the
remaining
on
those
remaining
discussed
points,
and
you
know
I
consider
them.
You
know
valuable
feedback,
but
nothing
that
really
changes
the
course
of
the
document.
So,
regardless
of
how
what's
going
on
with
the
iesg
dieter
and
I
have
agreed
on
the
changes
that
need
to
be
made
and
Harlan's
been
involved,
also
in
monitoring
this
and
so
I
plan
to
push
out
an
update
today,
I'm
not
sure
if
that
makes
a
difference
in
terms
of
getting
this
pushed
along.
C
B
Thanks,
hey
thanks:
Dennis,
okay,
like
I,
really
appreciate
your
patience
like
I've,
been
talking
to
a
core
like
it's
discussed,
has
been
there
for
a
while,
but
he's
trying
to
keep
his
own
queue
for
the
incoming
ad.
So
he
prioritize
like
his
documents,
which
I
totally
understand
because
he's
swapping
off,
and
so
thanks
for
your
patience
on
this
and
really
appreciate
you
trying
to
get
this
resolved.
If
you
can
push
a
document
today,
I'll
try
to
get
this
on
the
next
possible
tele
chat
and
we
can
go
from
there.
B
A
We
wrote
in
TP
when
we
did
the
NTP
v4
specification.
It's
cleaning
up
a
piece
that
got
left
out
so
guidelines
for
defining
packet.
Timestamps
is
also
one.
That's
been
ready
for
its
submission.
It's
passed
working
group
last
call
and
we
just
need
to
get
it
processed.
The
next
one
is
NTS
4
ntp.
This
is
one
we
spent
a
lot
of
time
talking
about.
Did
you
want
to
talk
about.
D
E
E
A
A
A
F
Okay
hi,
my
name
is
Chris
Divine,
Eagle
I'm
wondering
you
newbies
here
today,
like
Karen,
wanted
me
to
make.
Have
this
presentation
so
well,
I
was
here
a
sad
day
Sunday
we
sat
in
a
big
room
for
13
hours,
hacking
on
NTS
and
I.
Think
who
were
there
what's
on
I'm
sure
all
the
Richard
dieter
carry
with
her
did
I
forget
somebody.
F
F
So
we
did
a
lot
of
integration,
as
I
said,
got
emptiest
to
work
inside
of
crony
insider
NDP
sake,
Martin
lying
near
who's,
not
here
today
he
has
his
own
implementation
in
c,
plus
plus
it
was
interoperate
with.
I
have
my
own
little
implementation,
a
proofing
concept
in
python
and
that
also
worked
and
most
at
work
here
was
done
on
drop
17.
F
Richard
was
also
there
worker
and
he
was
working
against
version
11.
I
think-
and
next
slide
again
thank
you.
So
this
is
the
compatibility
matrix
right
now
so
australia,
client,
that's
martin,
longish
client
in
c++.
The
chrony
client
was
an
LLC,
that's
Miroslav,
who's
working
chrony,
the
NTP
is
a
client.
F
They
only
have
a
client
so
far,
but
and
it
only
does
the
key
exchange,
but
that
one
works
with
Australia
so
recruit
a
servant.
My
server
in
Python
it
does
not
currently
work
with
the
entropy
six
server,
and
that's
this
due
to
the
NTP
sec
server,
I
think,
is
using
an
old
ssl
library
that
doesn't
support
a
LPN.
So
that's
a
sort
of
known
issue.
F
F
So
all
of
us
have
had
bugs
I
had
a
few
crash
bugs
there
were
some
other
issues
we
we
were.
We
had
an
issue
with
open,
SSL,
open
SSL,
one
with
one
that
one
has
1.1.1
a
has
a
bug
in
the
key
exporter
function,
which
means
that
we
have
a
rather
long
string
for
exporting
key
material
and
that
string
doesn't
work
with
one
with
one
with
one,
so
Martin
Langer
when
he
did
his
implantation,
he
had
to
use
a
shorter
string.
F
So
some
of
the
issues
we
had
was
that
some
people
were
using
long
string
and
their
clients,
while
the
saw
was
using
a
short
string
and
vice-versa,
we've
decided
we'll
just
go
with
long
string
around
or
everybody
has
switched
to
long
string
now,
because
we
there
is
both
a
new
version
of
business
or
so
available
and
an
older
version,
and
we
didn't
really
find
any
issues
with
their
NPS
draft
in
itself.
As
far
as
I
can
tell
not
when
it
comes
to
implementation,
we
we
followed
implementation.
If
we
read
it
by
letter,
it
did
work.
F
A
Thanks
all
right,
so
we've
already
sent
NTS
through
working
group
last
call.
We've
now
done
three
hackathons
on
it.
So
I
think
we
are
they're
going
to
do
that
at
the
we
haven't
done.
No
that
clarification
hasn't
been
pushed
yet
no
I
hadn't
looked
yeah
not
yet
so
we're
gonna
do
a
minor
clarification
on
a
thing
that
a
number
of
implementers
implemented
wrong,
and
then
we
will
based
in
in
the
sense
that
the
spec
was
not
clear
about
what
they
needed
to
do
that.
A
E
Slightly
pedantic
note
on
the
up
on
the
clarity
issue,
the
spit,
so
the
spec
was
perfectly
clear
on
what
NTS
ke
requires
and
everybody
did
that
correctly.
The
the
clarification
we're
going
to
be
inserting
is
is
about
a
is:
is
that
a
lot
of
people
didn't
properly
read
78
22
and
made
an
invalid
assumption
about
that.
So
we're
just
going
to
point
out
that
that
fall.
Okay.
G
Can
you
hear
me:
okay,
hello,
everyone,
I'm,
Anton,
Malhotra
from
Boston
University
and
today
I'm
going
to
talk
about
rough
time,
a
draft
that
be
submitted
in
collaboration
with
Adam
Langley?
Who
is
the
original
author
of
rough
time
from
Google
and
Watson
lad
from
CloudFlare
who
implemented
or
deployed
this
at
CloudFlare
you
and
someone
else
yeah.
We
submitted
the
first
version
of
this
trapped
back
in
January
of
this
year
and
following
that
we
had
a
virtual
working
group
call.
G
Avaran
I
explained
the
protocol
and
we
discussed
the
issues
that
were
not
addressed
in
the
draft
at
the
time.
Some
of
them
we
decided
that
need
to
be
addressed,
and
the
draft
and
some
of
some
other
issues
are
not
that
pressing
post
that
or
we
updated
the
draft,
and
we
had
some
comments
on
the
mailing
list.
Some
clarification
questions.
Some
of
them
have
been
addressed
on
the
mailing
list.
G
There
are
a
few
that
needs
a
resolution
that
needs
some
discussion
so
but
the
questions,
clarification
questions
have
not
been
updated
in
the
draft
that
allowed
will
update
in
the
next
version
of
the
draft.
So
for
today's
presentation,
I'm
going
to
give
a
very
high-level
overview
of
what
the
protocol
is
and
then
open
the
stage
to
comments
and
discussions,
because
that's
what
we
want
to
achieve
at
this
IETF
like
have
people's
input
on
the
outstanding
issues.
G
G
G
Then
we
have
a
symmetric
key
proposal
for
NTP
which
uses
md5.
Although
that's
been
deprecated
now
it
does
provide
authentication,
but
there
are
serious
issues
with
it
which
have
been
known
for
years
now.
So
is
the
case
with
NTP
Auto
key.
However,
the
new
proposal
network
time
security
that
we
just
discussed
that
also
provides
authentication,
but
it
does
not
provide
a
proof
of
server
misbehavior
and
what
that
means.
G
So
what
is
rough
time?
It's
a
protocol
that
achieves
rough
time
synchronization.
It
is
not
as
accurate
as
other
time
synchronization
protocols
as
it
stands
today.
Second,
it
detects
the
servers
that
provides
inaccurate
time
and,
most
importantly,
it
provides
a
cryptographic
proof
of
servers
in
this
behavior
that
can
be
verified
by
a
third
party.
G
There
are
several
applications
for
rough
time.
The
original
motivation
when
Google
and
when
Adam
Langley
at
Google
proposed
this
approach
was
a
certificate.
Verification
Google
did
a
survey
that
found
that
25
percent
of
failures
of
it's
is
because
of
bad
clocks
on
the
clients.
So,
and
we
know
that's
a
certificate,
verification
meaning
does
not
require
accurate
timestamps
does
it
does
not
require
super
accurate
timestamps.
It
does
require
rough
time
a
drop.
G
It
does
require
the
client
to
be
roughly
accurate
and
there
are
several
other
applications
where
the
client
does
not
necessarily
require
super
accurate
and
precise
time.
Information
such
as
delegated
credentials,
lifetime
delegated
credentials.
You
can
think
of
them
similar
to
certificates,
they
have
validity
periods
which
need
to
be
verified
before
they
can
be
accepted.
G
G
G
So
first
issue
is
that
of
time
scale
that
what
time
scale
should
be
used
for
time
stamps
delivered
by
a
server
in
the
response.
So
what
we
have
currently
in
the
draft
are
these
three
values
met
P,
which
are
the
number
of
microseconds
the
server
in
his
response
sends
this
value,
which
is
the
number
of
microseconds
since
the
UNIX
epoch.
Then
we
have
another
variable,
read
ID,
which
is
the
server's
estimate
of
the
accuracy
of
the
time
that
it
sends
at
the
time
that
they
compose
the
response
packet.
G
G
The
misbehaving
misbehaving
servers
that
they
detect
through
this
rough
time
protocol,
and
there
are
several
other
policies
that
the
trust
anchors
can
enforce,
such
as
generally
checking
the
health
of
rough
tine
servers,
whether
they
are
checking
their
uptime
or
how
accurate
they
are
compared
to
some
reference
time.
So
we
need
to
decide
on.
We
need
to
decide
on
who
these
trust
anchors
can
be
and
what
kind
of
policies
they
should
be
enforcing
and
with
that.
H
H
H
H
The
second
thing
is
that
there
is
a
fundamental
problem
of
delay
attacks,
which
is
also
something
we
discussed
on
the
mailing
list
and
right
now
the
draft
doesn't
resolve
this
problem,
understood
from
offline
discussions
that,
in
practice,
the
implementation
of
rough
time
does
deal
with
delay
attacks
in
some
form,
but
this
needs
to
be
described
in
the
draft
and
it
needs
to
be
explained
exactly
what
is
the
scope
of
the
damage
a
delay?
Attacker
can
do
so.
I
think
these
are
two
very
major
issues
right
now
for
this
raft.
G
H
G
G
E
On
the
issue
of
yeah
on
the
issue
of
of
policy
for
maintaining
list
of
servers
end
up
and
what
they
should
be
expected
to
do,
I
think
What's
in
scope,
for
the
draft
is
mechanism
for
getting
trusted
lists
where
end
and
were
how
exactly
to
to
construct
a
proof
of
malfeasance
and
check
that
proof.
I
do
not
want
us
to
get
too
far
into
layer,
8
policy
in
this
draft-
let's
not
be
the
cat
forum
here.
E
Secondly,
though,
I
I
do
hope,
we
can
see
a
see
a
call
for
adoption
for
this
draft
soon.
I
had
I
had
some
earlier
objections
that
the
graft
may
not
be
within
our
Charter,
but
I
got
pretty
clearly
slapped
down
by
that
slap
down
on
that
by
the
area.
Directors
who
basically
said,
take
it
up
here
and
fix
the
Charter
so
fair
enough?
Let's
get
a
call
for
adoption
going.
G
Yes,
regarding
your
first
comment:
I
just
mentioned
it
here
because
it
was
about
the
trust,
anchors
and
policies,
because
it
was
briefly
discussed
in
the
first
virtual
group
meeting
yeah.
But
as
I
said,
these
are
not
depressing
issues
that
need
to
be
addressed
in
the
draft,
but
I
just
put
it
for
the
sake
of
yeah.
I
G
J
It's
a
clarification
yeah.
So
as
a
daniel
mentioned,
the
the
first
policy
question
isn't
really
a
question
saying
policy.
It's
really
a
question
about
mechanism
and,
more
importantly,
I,
do
think
you
want
one
global
place
where
the
reports
of
malfeasance
are
discussed,
because
it
is
going
to
be
a
sort
of
ecosystem
impact.
If
there's
one
server
at
everybody
distress
now,
maybe
not
everybody
trusted
in
the
first
place,
but
I
think
that's
that's
our
thing.
Regrets
and
policy
options
said
it,
but
I'll
emphasize
it.
Unlike
CAS,
there
is
no
cost
to
distrusting
a
server.
J
K
Right,
if
you
want
I'd
like
to
second
the
first
speaker
in
asking
for
a
threat,
analysis
and
the
threat
model,
because
it's
like
the
first
thing
I
did
in
this
industry
back
when
I
was
a
kid-
was
to
set
up
entity,
infrastructure
right
and
the
first
on
the
first
sentence
or
the
first
page
right.
There
was
I
had
multiple
sources
of
time
right
and
the
objective
of
the
exercise
is
not
to
have
I
mean
I.
Don't
I
understand
that
there
is
a
this
attraction
to
having
provable
statements
about
models,
but
the
interesting
model.
K
K
Single
server
malfeasance
in
the
other
protocols
are
having
more
sources
of
time
right.
That's
what
we
traditionally
done
in
in
deployments
of
MTP
infrastructure,
so
I
I
think
if
we're
gonna
have
like
provable
security
proofs,
that's
having
about
models
that
actually
are
relevant
to
like
the
uses
of
secure
time
on
the
operating
system,
and
that's
not
necessarily
about
any
given
statements
about
any
given
protocol.
We
used
to
get
time
onto
the
operators.
M
L
So,
even
though
delay
delay
attacks
are
possible,
they
would
look
like,
like
my
reasons
and
I,
think
at
least
rough
time
should
detect
that
something
is
wrong
and
have
cryptographic
proof
that
something
is
wrong,
although
probably
the
client
could
not
differentiate
between
a
server
that
was
being
attacked
and
I
said
well,
that
was
intentionally
sending
bad
time,
but
still
it
would
have
a
report
that
something
happened.
I
think
that
is
very
valuable.
C
N
N
explicitly
recommends
against
using
T
AI
and
recommends
you
to
C
instead
and
in
connection
with
that
was
also
pointed
out
to
me
that
essentially
any
protocol
that
distributes
time
needs
to
be
able
to
tell
the
user
what
the
source
of
that
time
is.
One
reason
is
so
you
know
which
actual
timescale
you
are
tracking,
which
probably
isn't
that
important
here
since
we're
only
interested
in
rough
time.
But
what
is
important
is
since
first
since
we're
starting
to
track
malfeasance
here
and
we're
starting
to
distrust
servers
that
give
us
the
wrong
time.
N
We
couldn't
enough
end
up
in
a
situation
where
we
have
several
service
that
use
the
same
source
of
time
where
the
client
doesn't
know
that
say
you
have
a
bunch
of
servers
that
are
using
GPS
at
the
time.
Source
and
GPS
starts
distributing
the
wrong
time.
We
can
either
end
up
with
accidentally
starting
to
track
this
erroneous
GPS
time
or
we
can
accidentally
start
distrusting
all
the
servers
that
happen
to
use
GPS.
So
that's
one
argument
friction,
including
some
sort
of
source
information.
N
I
E
E
Between
the
case,
where
the
server
is
two
seconds
slow
versus
the
case,
where
the
the
server
is
accurate,
that
a
network
adversary
delayed
the
packet
for
two
seconds.
Nonetheless,
the
client
can
compute
the
two-second
found
on
on
how
much
the
time
it's
getting
might
be
off,
but
just
the
the
longer
the
network
adversary
delays,
something
the
harder.
It
is
for
the
client
to
construct
a
proform
Alfie's.
E
G
K
A
H
H
But
what
that
server
can
do
is
just
delay
the
message
for
10
seconds
before
sending
it
back
to
the
client
for
10
seconds,
which
would
hide
the
fact
that
it's
time
is
off
and
would
cause
an
error
which
is
on
the
order
of
5
seconds,
and
this
would
would
not
be
identified
by
rough
time,
because
it's
a
positive
delay
rough
time
only
detects
when
there
is
a
negative
difference
between
clocks.
So
if
you
delay
the
message
in
the
server
rough
time
can't
detect
that,
unless
you
add
a
specific
mechanism
to
detect
of
the
attacks.
G
L
I,
don't
we
are
talking
about
request
response
scheme?
Are
we
not
and
if
we
are,
then
the
client
is
going
to
detect
that
the
round
trip
took
a
long
time
which
in
itself
should
raise
a
certain
kind
of
flag,
because
net
rise
was
the
uncertainty
or
I
mean
basically
Daniel.
You
raised
this
issue
the
longer.
L
Trip
is
the
the
less
precise
the
client's
estimation
about
how
accurate
the
service
time
is.
So
that's
a
problem
in
and
of
itself,
and
so
I
don't
see
the
scenario
where
that
the
server
is
off
and
then
someone
beat
an
attacker
or
the
server
themselves
delays
their
packets
to
to
hide
that
they're
off
by
intentionally
making
round
trips
like
unpleasantly
long
I,
don't
really
see
a
case
where
that's
under
the
radar.
Basically
I'm
saying
this
would
raise
an
alarm
and
that's
an
alarm.
H
So
I
think
Lantau,
Thomas,
rahi
I
think
what
you
said
is
exactly
the
solution
which
I'm
looking
for
in
the
draft
by
having
the
client
verify
the
round-trip
time
and
bounded
to
a
specific
value.
That
would
mean
that
rough
time
is
only
accurate.
The
accuracy
is
on
the
order
of
the
maximum
round-trip
time.
So
that's
what
I'm
looking
for
in
the
draft
currently
doesn't
have
that
it's
not
that
I
saw
okay.
J
What's
near
Coe
a
threat,
I
would
very
strongly
appreciate
you
submitting
texts,
saying
exactly
that.
I
think
I
think
it's
important
to
remember
that
what
we're
producing
is
not
a
normal
estimate
of
the
errors
of
its
way.
We're
cruising
a
guarantee
that
you
are
within
when
the
the
time
of
the
server
was
within
this
bound.
Where
you
have
two
delays.
J
There's
some
formula
part
was
pretty
much
this
square
window
and
we're
interested
in
applications
where
you
have
minutes
of
accuracy
required
seconds
of
accuracy
right,
but
this
needs
to
be
very
high
certainty
that
the
server
is
not
lying
because
we
are
not
synchronizing
gos
clock.
The
reason
for
this
is
that
OS
clocks
are
often
deliberately
set
wrong,
especially
on
mobile,
and
this
is
breaking
security
protocols
and
training
people
to
click
through
certificate
warnings.
That
sort
of
the
broader
context
here
explaining
why
we're
making
choices.
Okay,.
K
Last
comment:
if
two
to
two
comments:
oh
I,
think
that
should
go
in
the
draft,
but
the
threat
model
actually
doesn't
again
its
threat
model
right
that
actually
doesn't
involve
the
operating
system.
Clock.
That's
an
important
thing.
The
other
thing
about
Marcus,
think
about
GPS.
You
can
actually
spoofed
GPS,
it's
not
that
hard
right,
and
so
that's
the
reason
I
think
he's
bringing
that
up
right.
You
actually
have
to
point
out
like
time
scale
comes
from
this,
so
you
know.
K
O
A
A
P
P
A
short
reminder-
and
we
consider
the
following
sweet
model,
where
the
attacker
has
full
control
of
a
large
function
of
the
NTP
servers
in
the
pool,
and
he
can
change
the
content
of
NTP
response
and
can
also
delay
them.
Of
course,
the
attacker
is
malicious
and
we
assume
that
he
is
trying
to
achieve
declines
to
the
clock
as
much
as
possible.
In
the
picture,
you
can
see
that
the
clients
still
received
both
good
time
sample
and
bedtime
samples
and
might
choose
that
shifted
one
and
next
slide.
P
Please
thank
you
and
we
all,
and
we
also
wanted
to
remind
a
common
solution
where,
on
the
one
hand,
we
use
large
pool
of
NTP
servers
and
on
the
other
hand,
we
randomly
choose
all
the
tens
and
be
serviced
and
Thumba
them.
Lastly,
we
use
a
small
filters
in
order
to
remove
outliers,
and
next,
like
this
Thanks
and
Ramos,
when
compared
to
you,
NTP
uses
greater
variety
of
servers
changing
over
time
and
avoid
the
current
ntp
filters,
and
this
allows
to
ask
you
achieve
probable
security
guarantees.
A
P
P
What
everything!
Okay,
yeah,
okay
and
you
know
a
new
draft.
We
discussed
preliminary
result
for
evaluating
Hannes
precision
and
the
texts
were
conducted
in
several
locations,
both
in
Europe
and
in
the
US,
and
we
thought
that
the
Economist
chief,
fair
precision
and
less
than
a
three
millisecond
and
moreover,
they
offset
value
in
each
update-
is
similar
to
NTP
less
than
a
two
millisecond
gap.
Well,
these
results
are
not
bad
at
all
and
we
want
to
see
if
they
can
be
improved
without
sacrificing
security.
P
Okay,
yeah,
we
tested
a
juice
smoothie
mechanizing,
the
first
one
was
the
favorite
small
set
values
within
the
remaining
example
after
filtering,
if
they're,
not
a
file
format,
the
average
and
it
proved
to
be
very
effective,
but
in
the
second
and
smoothing
mechanism
was
to
favor
of
previous
query
server.
If
they're,
an
average
of
set
is
not
far
from
random
set
approach,
they
didn't
yells
a
significant
improvement
and
next
slide.
Please
thank
you.
P
P
P
Servers
which
shift
pockets
timestamps
and
the
error
is
growing
linearly
with
time,
and
we
used
two
servers
as
part
of
the
pool.
We
are
DNS
server
to
return
our
better
server
IP.
Instead
of
some
of
the
Severus
IV,
we
saw
that
rapidly
increasing
shifts
didn't
affect
both
corners
and
auntie
P,
probably
the
shift
was
too
high
and
the
bird
servers
were
ignored
next
slide.
Please,
however,
for
slowly
increasing
shifts
the
NTP
is
shifting
while
and
consume
anything.
P
So
aim
to
conclude,
we
tested
a
a
proof-of-concept
course
implementation
under
normal
scenarios
and
Inara
Chuck's,
a
current
say.
We
saw
that
corns
precision
is
closer
than
to
NTP,
then
they
expected
several
minutes
instead
of
25
milliseconds.
Well,
the
smoothing
algorithm
heals
even
better
results,
and
we
also
saw
that
Cronus
is
secure
even
facing
slowly
increasing
shift,
while
NTP
isn't
and
the
smoothing
didn't
affect
corner
security,
and
now
we
are
continuing
to
evaluate
course,
performance
and
security
for
different
attack
strategies
and
different
location,
and
thank
you
and
I
can
take
questions
now.
M
P
Okay
and
yeah
sure,
can
you
move
to
the
to
the
slide
before
the
last
one
yep
this
one.
So,
for
example,
if,
for
example,
when
we
we're
talking
about
rapidly
shift,
we
are
talking
about
a
software
which
ad
a
0.01
second
per
second,
and
here
when
we
are
talking
about
slowly,
increasing
shift,
we're
representing
a
an
attack
of
a
adding
0.001
second
pair
every
second
to
a
time.
P
P
M
P
Q
R
P
Chose
a
for
the
NTP,
it's
basically
a
running
on
the
default
ntp.
Am
I
choosing
a
a
for
NTP
servers
and
the
homes
and
update
every
1664
second
and
four
horse.
We
we
chose
12
servers
and
from
among
them,
who
chose
randomly
for
for
each
time,
but
for
every
update,
which
was
different.
12
servers,
okay,.
A
P
A
Okay,
go
back,
one
slide,
I
think.
Is
it
there?
Oh
no
I!
It's
on
the
agenda
slide,
but
that's
okay!
You
don't
have
to
go
back
because
it'll
only
be
a
sentence,
so
the
next
thing
on
the
agenda
is
actually
the
ntp
yang
module
and
the
authors
are
have
a
conflicting
meeting.
They
have
told
me
that
they
have
some
additional
changes
they
want
to
make.
A
We
have
had
an
initial
mid
doctor
review,
it's
gone
through
that
they
want
to
do
one
more
update
and
then
they
believe
it'll
be
ready
for
working
group
last
call
so
so
that
is
pretty
close.
So
this
brings
us
to
the
end
of
all
of
the
stuff
that
we
got
in
advance
of
the
meeting.
So
if
you
go
to
the
next
slide,
this
is
sort
of
my
was
originally
named
on
the
agenda,
my
housekeeping
section,
so
it
was
drafts
that
we
haven't
made
a
lot
of
progress
on
or
didn't
have
updates
on.
A
So
at
this
point
and
I
have
to
admit
there
is
a
ton
of
traffic
on
this.
This
morning
we
I
had
asked
an
child
to
repost
the
data
minimization
draft
so
that
we
could
yeah
yeah.
It
was
well
I,
guess
the
point
being
it.
It
was
reposted
and
then
there
was
a
ton
of
email,
but
I
haven't
had
time
to
read.
So
is
there
any.
A
S
Yes,
okay,
fair
enough.
I
would
like
to
hear
how
you
make
your
decisions
about
whether
or
not
something
needs
to
be
a
standard
and
then
implemented
versus,
not
because
you
seem
to
switch
back
and
forth
on
whether
or
not
you
want
it
to
be
proven
or
if
you
want
to
wait
to
implement
it
until
the
standard
has
been
passed.
J
My
concern
is
simply
that
one
one
single
implementation
shouldn't
have
a
privileged
position
to
find
the
way
a
speck
works.
I
mean
I,
understand
a
consideration
that
we
need
to
use
these
fields
in
other
ways,
but
I
don't
see
any
conflict
between
having
dynamization
draft
and
then
in
a
later
draft
saying
well,
this
is
the
other.
Meanings
are
needed
for
these
fields.
If
you
wanna
do
this
with
your
dynamization,
don't
see
why
it
isn't
a
suitable
solution
for
everyone.
Okay,.
A
G
L
Regarding
Colin's
comments,
the
thing
that
you
didn't
really
answer
Harlan-
and
maybe
we
can-
this-
can
make
a
skip
a
whole
lot
of
discussion.
The
only
motion
that
I
saw
put
forward
was
to
change
a
few
instances
of
should
language
into
main
language
and
I.
Don't
really
think
that
would
even
make
that
much
of
a
difference
and
also
from
the
definition
of
shouldn't
made
that
is
available.
I
think
that
should
is
just
more
appropriate
in
these
cases,
but
also
I.
S
S
If
this
was
religion,
we'd
be
real
we'd,
be
writing.
Canon,
we're
writing
standards
here
and
I
think
we
need
to
hold
ourselves
to
a
higher
standard
for
what
we
accomplish
and
what
we're
asking
people
to
do.
So,
if
you
don't
agree
with
me
or
you
guys,
don't
feel
that
my
technical
objections
are
worth
it.
That's
cool!
That's
your
choice!
So.
A
I
think
that
the
the
way
the
IETF
deals
with
technical
objections
is
consensus,
calls
and
I
think
what
we
need
to
do
is
take
the
exchange
of
email.
That's
happened
over
the
last
like
12
hours
and
review
that
and
turn
it
into
specific
consensus.
Calls
that
we
can
ask
on
the
mailing
list
because
I
think
that's
the
way.
The
IETF
moves
forward
in
this
space
go
ahead.
E
A
Just
to
respond
back
to
you,
I
agree
that
we
have
had
these
discussions.
I
would
also
agree
that,
and,
and
ditcher
and
I
have
have
discussed
this-
we
have
not
been
as
clear
about
having
a
discussion
and
then
declaring
a
consensus,
and
so
I
think
for
some
of
these.
Even
though
we've
had
the
conversations
we
need
to
go,
we
just
need
to
do
a
tiny
little
exercise
where
we
can.
You
know,
ask
a
clear
question
and
get
a
group
of
people
to
answer
unless
we've
done
this
before
and
I
need
to
go
back
and
look.
E
A
I
was
aware
of
that
so,
and
it
may
be
I
mean.
Maybe
you
can
help
me,
go
back
to
the
archives
and
figure
out
if
we
have
a
consensus
or
not
I.
Just
we
haven't
been
as
clear.
You
know
about
identifying
specifically
consensus
calls,
because
in
general
we
we
get
to
a
point
without
needing
formal
consensus.
Calls
on
individual
issues.
We
just
do
them
on
the
documents,
but
but
in
some
cases
we
might
may
need
to
do
that.
Kristof
I
think
you
are
in
the
speaking
position.
B
A
B
So
one
of
the
things
I
want
to
like
point
out
to
Harlan
is
that
there's
a
reason.
There's
a
shirt
right
like
should
actually
means
that
there
could
be
like
legitimate
exceptions
where,
like
you,
don't
have
to
follow
it
right.
So
that's
if
adding
some
text,
like
you
know,
saying
like
for
example,
or
something
like
that,
some
exemplary
text
we'd
say
leaves
out
some
room
for
you
to
do
the
stuff.
S
A
S
The
normative
reference
for
entia
I
don't
understand
how
that
has
a
play
in
this.
He
was
talking
about
how
he
didn't
want
to
my
understanding,
as
he
didn't
want
to
lend
any
credence
to
my
objection.
Objection
because,
since
there
wasn't
code
out
there
today
in
sufficient
form,
that
would
behave
the
way
I
recommend.
We
should
completely
ignore
that
case
and
discount.
It.
E
E
B
S
B
B
So,
as
I
said
like
don't
make
it
like
anything
concrete
say
like
exemplary,
like
why
somebody
would
not
follow
the
and
then
let's
discuss
that
and
see,
if
that's
something,
that's
gonna
be
useful
right,
so
and
and
and
sometimes
like
you
know,
you're
in
the
rough
I've
been
in
the
rough
like
multiple
times
so,
but
that's
let's,
try
it
out
right.
Let's
try
to
write
some
exemplary
text
and
we'll
go
from
there.
A
Thank
you,
so
the
next
one
I
had
in
my
housekeeping
list
was
interleave
modes
and
I
just
wanted
I
believe
we
talked
about
this.
The
interim
I
was
Mary.
Slava
I
was
wondering
if
you
would
mind
giving
us
a
quick
status
of
where
that
is,
and
what
we
want
to
do
with
that
or
I.
Don't
know
an
chil.
Do
you
have
a
just
leave
it
to
Miroslav.
A
G
A
T
One
remaining
issue,
and
that
was
whether
the
service
should
be
allowed
to
use
the
same
pair
of
x
times
multiple
times
as
it
is
currently
specified.
I
sent
an
email
about
this
and
we
discussed
this
on
the
previous
meeting
and
the
issue
is
that,
as
specified,
it's
not
tolerant
to
errors
in
the
processing
of
packets
and
clients.
T
A
G
A
Do
you
anticipate
continued
work
on
it?
That's
what
I'm!
Yes,
okay!
That's
all!
That's
all
you
really
need
to
say.
I
just
wanted
to
I
just
wanted
to
know
if
there
was
continuing
work
on
it
or
we're
not
so
the
next
set
of
drafts
so
Harlan
you
submitted
a
bunch
of
drafts
last
night,
so
nobody
has
had
any
time
to
review
them.
A
S
A
S
S
A
It
is
a
working
group
document
technically,
according
to
the
to
the
data
tracker,
it's
in
working
group
last
call,
but
basically
what
happened
was
it
went
through
working
group
last
column.
We
had
a
lot
of
issues
and
we
didn't
actually
move
it
out
of
working
group
last
call
so
at
the
very
least
it
needs
another.
Another
revision,
so
I
would
encourage
people
to
read
this
one
and
comment
on
the
list.
A
Well,
the
next
one
that
we
have
here
is
the
that
you
updated
last
night
was
the
extension
fields
document.
What
I'd
like
to
mention
with
that
one
is
we
had
a
working
group
consensus
call
on
that
and
we
declared
it
to
be
a
dead
document
in
a
sense
that,
if
what
you
have
done
is
a
tweak
on
the
previous
document,
then
we've
already
decided
that
this
is
not
work.
We're
going
to
progress,
so
is
the
update,
a
change
in
strategy,
or
is
it.
S
A
A
Then
the
next
is
the
extended
information
extension
field.
Did
you
want
to
talk
briefly
about
the
changes
in
this
one
from
the
and
the
next
set
of
documents?
These
are
all
at
this
point,
individual
submissions.
We
have
not
adopted
them
as
well,
if
items
yet.
The
last
instruction
that
was
given
to
the
working
group
was
that
we
would
proceed
with
extension
field
specifications
that
were
compliant
with
5c,
78
22,
and
so
it's
my
number
was.
A
A
S
They
are
listed
in
a
way
that
works
and
since
78
22
says
things
like
the
size
of
an
extension
field
is
dependent
upon
whether
or
not
it's
the
last
extension
field.
It's
compatible
with
that
I
didn't
see
any
benefit
to
complicating
the
individual
proposal.
Saying
here's
how
long
this
is.
If
it's
the,
if
it's
an
early
packet
and
here's,
how
long
it
is,
if
it's
the
last
packet
78
twenty-two
cares
about
that.
The
proposal
will
all
say:
well,
you
know
make
make
this
extension
feel
the
length
that
is
appropriate.
S
E
By
my
quick
route
by
my
quick
reading
of
suggest,
ref
ID
last
night
and
I
didn't
go.
I
may
be
missing
something
in
the
text
because,
ladies
look
at
the
diagrams,
but
it
looks
like
the
body
for
that
is
only
for
our
cats,
which
can
which
complies
with
RFC
78
22.
In
neither
case
regardless
of
its
position.
S
A
Okay,
so
so
back
to
the
so
I
set
the
stage
by
saying
that
we
are
open
to
extension
fields
if
they
are
compatible
with
RFC
78227
animal.
You
said
that
you
didn't.
Let
me
finish
so
now.
What
I'm
going
to
do
is
go
through
each
of
the
new
drafts
that
you
submitted
not
like.
You
just
speak
specifically
to
to
what
what
has
changed
and
what
action
you
would
like
the
working
group
to
take
on
them.
So
the
first
one
is
the
extended
information
one
yeah.
A
S
It's
just
the
I
do.
Extension
field
has
turned
out
to
be
very
important
when
dealing
with
a
mix
of
new
and
legacy
clients
and
I,
basically
cleaned
up
the
language,
and
hopefully
Sam
will
look
at
it
and
decide
it's
better
than
it
was
before,
but
the
content
of
it
is
pretty
much
the
same.
If
that
isn't
a
working
group
document,
I'd
like
it
to
become
I'd
like
it
to
be
considered
as
one.
S
Similarly,
the
last
extension
field
is
an
unambiguous
way
to
say
I'm
the
last
extension
field,
and
if
you
want
to
make
that
28
bytes
long
great
without
it,
you
know
it
is
everything
I
can
see
says
it's
not
necessary
and
it's
perfectly
fine
as
a
four
byte
last
extension
field,
but
you
can
make
it
as.
However,
big
you
want.
It's
compatible
is
78
22.
S
A
None
of
these
are
currently
working
group
documents,
so
we
will
do
a
call
for
adoption
on
these
and
see
if
the
working
group
is
willing
to
take
them
up.
The
last
document
that
was
submitted
is
the
leaps
may
RFID.
I
know
this
was
originally
part
of
the
other
ref
ID
updates
and
we
pulled
it
out
because
the
leap
smear
piece
was
more
controversial.
S
S
If
you
never
use
leap,
smearing
stuff,
then
you'll
never
see
it.
If
you
are
in
a
situation
where
you
might
see
leap,
smearing
servers,
it
can
be
incredibly
helpful
both
to
the
system
and
systems
in
question,
as
well
as
the
operators
who
want
to
keep
an
eye
on
things
to
know
whether
or
not
somebody's
doing
Lechmere.
A
A
L
D
S
Purpose
of
the
leap
smear
rough
idea
is
to
show
that
this
data
that
somebody's
following
a
leap-
smearing
server-
that
is
different
from
true
time.
If
you
want
to
run
your
systems
in
a
different
time
scale,
that's
not
something
that
I
think
we
can
use
the
ref
ID
for,
because
the
primary
purpose
of
the
ref
ID
is
loop
detection,
and
if
you're
going
to
be
running
a
system
and
ta
I
you
and
you
use
a
special
breath
ID.
You
say
that
my
system
is
Tia,
ta
I.
Instead
of
something
else,
you
then
lose
loop
detection.
S
E
L
J
A
E
A
Okay,
any
other
comments
or
questions
excellent.
The
one
thing
I
meant
to
mention
earlier
that
I
forgot
is
I,
wanted
to
acknowledge
onchao
with
the
new
RFC
on
the
Mac.
So
congratulations
thank
you
for
doing
that
work.
Any
other
business
working
group
items
nope.
We
will
in
all
likelihood
try
to
schedule
a
couple
interims
between
now
and
whenever
the
next.