►
From YouTube: IETF112-NTP-20211112-1430
Description
NTP meeting session at IETF112
2021/11/12 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
Okay,
I
think
we're
ready
to
get
started
date.
Are
you
ready.
A
The
all
right
so
welcome
to
the
ntp
working
group
at
ietf
112.
A
Starting
out,
we
have.
A
So
I
believe
dieter
is
planning
to
take
minutes
if
anybody
wishes
to
help
him.
That
would
be
great
also,
if
there's
any
volunteer
to
pay
attention
to
the
chat
log.
Sometimes
I
lose
track
of
the
chat,
depending
on
how
much
conversation
is
going
on.
So
if
we
could
get
somebody
to
pay
attention
to
that,
it
would
be
helpful.
A
A
We
have
a
couple
of
online
meeting
things
to
remind
everybody.
As
a
reminder,
this
session
is
being
recorded.
Also
the
chat
is
recorded,
so
you
just
need
to
remember
that
these
are
the
basic
reminders
for
an
online
meeting.
The
one
thing
to
note
is
that
the
blue,
the
blue
sheets,
are
now
automatically
generated
by
data
tracker.
A
The
next
slide
is
a
reminder
about
the
ietf
code
of
conduct
and
some
of
the
key
points
associated
with
that,
the
main
one
being
to
be
sure
that
we
treat
everybody
with
respect
and
courtesy,
and
so
with
that
we
will
move
on
to
the
agenda.
A
Nope,
okay,
so
the
next
slide
begins.
Our
discussion
of
various
working
groups,
document
status,
review
things
that
we
don't
necessarily
need
to
have
presentations
on
today
or
discussion
on
today,
but
just
to
remind
everybody
of
where
we
are.
A
We
have
been
working
through
an
updated
charter.
That's
currently
out
for
external
review.
The
link
to
that
draft
charter
is
is
shown
there.
A
A
A
A
The
next
one
is
the
yang
model,
which
is
also
an
iesg
evaluation
awaiting
an
author
update.
I
know
drove
had
hoped
to
get
that
done
by
monday,
but
the
reality
of
an
ietf
week
has
intervened
drove.
Did
you
have
any
update
you
wanted
to
give?
Are
you.
C
Yeah,
hey
it's
on
top
of
my
queue.
I
will
handle
this
just
post
idea
for
sure.
Okay,
great,
thank
you.
A
Thanks
for
your
patience,
oh
believe
me:
people
need
to
have
patience
with
me,
so
I'm
happy
to
have
patience
with
others.
Speaking
of
patients
with
me,
the
interleave
mode
is
in
iesg
evaluation,
it's
been
deferred
and
it
needs
some
guidance
from
eric.
It
also
needs
the
correct
write-up,
which
is
one
of
the
things
waiting
on
me.
A
The
next
document-
I
I
just
put
this
one
in
this
list
because
we
will
be
finishing
it
up
and
and
then
moving
further
discussion
to
ntp
to
the
mtp
working
group
is
the
ptp
enterprise
profile.
There
was
a
small
update
to
that
done
and
it's
ready
to
go
to
the
isg.
It's
awaiting
a
write-up,
and
one
of
the
things
in
particular
that
it
needs
to
reference
now
is
the
ongoing
ieee
effort.
A
A
Alternative
port
is
in
working
group
last
call.
We
did
not
close
out
that
working
group
last
call.
There
has
been
some
discussion
on
it.
Is
there
anything
anybody
wants
to
say
about
that
here.
A
D
Yes,
you'll
probably
note
that
I
I
sent
magnus
will
do
a
early
tsv
area
review
for
the
bits.
Oh.
A
D
Told
that
that
reports
are
old
news,
that's
it
everything
is
alpn
now,
but
anyway,
yeah
we'll
see.
A
So
the
chronos
document
was
updated
in
august,
but
there
has
been
very
limited
discussion
on
it.
I
don't
see
any
of
the
chairs
here
any
of
the
authors
here.
I
don't
believe
looking
through
the
list
again,
so
this
has
been
adopted
as
a
working
group
document,
but
progress
on
it
has
slowed
down
so.
A
A
I
believe
it
can
be
moved
to
work
last
college,
anybody
that
does
not
want
to
see
that
done,
or
anybody
who
thinks
additional
discussion
is
needed
on
this
document
prior
to
working.
For
the
last
call.
A
No
okay,
so
that's
the
all
of
the
documents,
the
in
the
sort
of
quick
document
status,
review,
update
section.
The
next
part
of
the
agenda
is
is
is
rough
time.
Rough
time
is
next,
so
watson
do
you
want
me
to
share
or
are
you
gonna
share.
E
And
the
next
slide
has
the
things
that
we
want
to
talk
about,
so
I'm
going
to
start
by
recapping
the
problem
we
want
to
solve.
So
this
is
for
cases
where
you
have
time.
That
needs
to
be
accurate
in
a
few
seconds,
hopefully
less,
but
that's
what's
guaranteed
and
the
reason
we
need
this
is
for
things
like
certificate
validation,
30
certificate
errors
are
caused
by
inaccurate
client
clocks
and
getting
rid
of
that
would
be
a
very
big
boot
to
cruise
security.
There's
other
applications,
that's
sort
of
the
problem.
E
And
so
there
were,
we
have
a
whole
laundry
list
of
issues
that
came
about
during
the
pretty
active
discussion
on
the
list.
The
past
few
weeks
we
haven't
had
a
chance
to
turn
this
around
into
a
document
update
and
there's.
Another
whole
slide
of
issues.
E
So
all
of
these
issues,
we
we
have
some
conclusions
about.
We
think
it's
on
the
next
slide,
that
most
of
them
are
editorial
and
we'll
move
to
middle
settings
everywhere.
We're
gonna
change,
that's
gonna
affect
the
size
of
the
fields
we'll
see.
If
that
gets
it
down
to
32
bits,
it
might
not
the
comparison
to
rfc
3116
or
whatever
it
was,
is
no.
You
just
write
a
section.
It's
not
not
a
problem,
but
some
deserve
more
discussion,
because
they're
they're,
maybe
a
little
more
contentious.
E
So
the
the
first
thing
is
the
shot
512.
Only
there
was
a
debate
about
whether
or
not
we
need
another
hash
function.
The
reason
we
want
this
is
cross
protocol
signing
is
bad.
E
You
really
don't
have
any
guarantee
of
security
when
you're
using
the
same
key,
two
different
ways:
educate,
519
uses,
sha
512
internally,
so
you're
not
paying
a
penalty
and
code
size
for
it.
We
also
need
to
have.
E
They
need
they
want
to
have
a
very
uniform
playing
field,
and,
as
for
the
question
about
accelerating
roll
out,
you
don't
really
have
a
celebrated
rollout.
If
you're,
if
you
have
sort
of
an
identifier
versus
a
new
version
it
just
doesn't
you
know
this
is
experiencing
tls.
It
takes
a
while,
no
matter
what
you
do
now.
E
There
are
some
kind
of
arguments
that
sort
of
the
the
extensibility
piecewise
is
good
and
that
the
cross
protocol
attacks
are
more
theoretical
than
real
and
those
are
fine
arguments
and
you
know
hopefully,
after
this
presentation
we
have
some
discussion
about
that.
So
it's
another
issue
that
they
think
deserves
some
discussion,
and
this
is
about
greece.
There
were
some
questions
about
using
it.
There
are
some
editorial
questions
about
like
what
exactly
do
you
do,
ignore
it
etc
and
we've
put
those
in,
and
why
do
you
need
this
and
the
reason
you
need
this?
E
Is
you
use
it
or
you
lose
it?
This
is
a
long
and
bitter
experience
in
tls
it,
so
greece
was
introduced
into
tls.
For
this
reason
it's
a
good
idea.
E
It
prevents
you
from
having
situations
where
you
have
intolerant,
firewalls
or
other
middle
boxes
that
prevent
you
from
saying
the
protocol
further,
and
then
we
have
one
or
two
more
issues.
I
think
so
someone
can
talk
about
slow
signatures.
We've
really
tried
to
pick
the
fastest
one
rsa
would
be
even
faster,
but
it's
much
slower
signing.
So
that's
not
a
great
choice
and
we're
talking
about
one
additional
signature,
verification,
it's
not
a
huge
burden,
although
obviously,
if
your
application
is
not
is
different,
it
might
be
a
bird
now.
E
I'd
really
like
to
know
more
about
your
application
and
understand
what
we
can
do
to
speed
it
up
and
there's
two
more
all
right,
there's
also
a
question
not
using
the
only
time
keeper.
So
I
don't
know
what
I
don't
think.
There's
protocol
changes
we
need
to
make.
I
think
it
should
just
work
like
ndp.
E
We
can't
really
put
in
a
center
time
because,
especially
after
signing,
because
that
just
won't
work,
but
we
need
to
do
some
experiments
to
really
see
how
bad
the
result
is.
It's
not
going
to
be
as
great
as
ntp,
but
we
really
need
some
experiments
to
see.
E
The
the
leap
seconds
are
so
the
thing
is
they're
there,
they're
optional
tags,
row,
server
and
client,
there's
a
lack
of
standardized
distribution
service
data
and
the
itu
is
recommending
that
you
include
these
things
in
time.
Signals
and
you
know
time.
Minus
utc
is
sort
of
understandable,
ut1
minus
utc
a
little
more
exotic,
but
you
know
people,
people
do
sometimes
want
it
and
the
itu
recommends
you
have
it.
So
why
not?
You
know
it's
optional.
A
Okay,
everybody
does.
A
I'm
not
seeing
anybody
in
the
queue.
So
do
you
have
a
rough
time
so
right
now,
there's
two
documents:
do
you
have
a
rough
time
frame
of
what
you
want
to
do
next,
with
those
two
documents.
E
System,
one
up
yeah,
so
we
have
the
ecosystem
one
and
that
one
is
a
bit
stalled.
We
really
would
like
input
from
other
people
who
are
running
servers
or
running
clients
and
into
what
they
see
from
the
ecosystem,
the
wire
protocol,
one
I
I
think,
we're
going
to
revise
and
submit
a
new
version
in
next
few
weeks.
I
would
like
to
note
that
eric
klein
has
said
in
chat
that
I
suspect
you
should
ask
for
an
early
section
review.
Probably
around
the
same
time,
the
doc
is
considered
ready
for
working
group.
Last
call.
A
Okay
makes
sense,
it
seemed
like
a
fairly
extensive
list
of
issues.
So
do
you
think
the
next
revision
will
be
ready
for
working
your
glass
call
or
will
it?
I
guess,
it'll
depend
on
the
comments.
After
the
revision
comes
out.
E
Well,
I
thought
this
revision
was
ready
but
turns
out.
It
turns
out
a
bird,
so
I'm
I'm
not
going
to
be
as
optimistic
with
the
next
revision,
but
I
do
think
we
can
address,
because
a
lot
of
these
issues
were
editorial
and
I,
but
I
do
think
you
know
if
the
next
revision
comes
out.
It
would
be
nice
to
get
comments
from
people
who
still
don't
agree
with
the
way
we've
handled
the
issues.
A
All
right,
thank
you
still
still
seeing
nobody
in
the
queue
to
ask
any
questions.
We
will
thanks.
Watson.
A
The
next
thing
on
the
agenda
is
the
ntp
v5
use
cases
james.
Would
you
like
to
run
your
own
slides?
I
think
I
messed
up
with
watson.
I
think
he
actually
asked
to
run
his
slides
and
then
I
did
it.
F
There
we
go
okay,
so
I
kind
of
lied
last
ietf
meeting
and
I
I've
sort
of
the
interim.
I
can't
remember
which
I
said
that
I
was
not
going
to
do
any
more
work
on
this,
but
my
ability
to
focus
got
the
better
of
me
and
I
did
a
version
o2,
which
there's
obviously
been
a
lot
of
robust
debate
about
some
of
the
high
level
topics,
but
just
about
cover
what
I've
changed.
F
I
have
done
a
very
initial
threat
model
on
ntp
and
its
usages
as
a
whole,
a
very
high
level
stuff.
I've
added
in
some
net
requirements,
changes
to
some
of
the
other
requirements
and
lots
of
myths
and
spelling
mistakes
and
so
forth.
I've
also
done
some
other
further
work
after
the
o2
release.
That's
not
published
yet
restructuring,
basically
restructuring
a
huge
amount
of
the
documents,
so
it's
using
the
iana
and
security
recommendations
as
they
were
intend
supposed
to
be
used.
F
F
That
may
be
important
when
considering
ntp,
v5
and,
and
so
the
next
couple
of
slides,
I'm
just
going
to
talk
about
what
I
found
and
and
leave
some
ideas
for
people
to
to
have
a
mull
about
when
this.
When
we
discuss
this
document
and
its
progressions
further,
so
I
found
over
80
rfcs,
I
didn't
read
all
of
them
at
length,
but
at
least
skim
through
what
I
thought
was
the
most
important
bits.
10
of
them
obviously
are
docs
that
have
come
out
of
this
working
group.
F
Most
are
informational,
most
are
just
fulfilling
a
requirement
to
say
you
must
have
accurate
time
or
you
must
have
a
reliable
time
source.
Maybe
you
should
use
ntp,
but
where
there
are
other
dependencies
on
on
5905,
they
saw
I've
sort
of
lumped
them
into
three
sort
of
subjects
of
the
usage
of
date.
Formats
of
mtp,
epoch
of
metadata
and
identifiers
and
service
discovery,
so
I'll
just
talk
through
those
really
quickly.
F
So
what
I
mean
by
this
is
I'm
referring
to
the
the
ntpe
poc,
which
is
obviously
different
from
unix
epoch,
gps,
so
on
and
so
forth,
and
also
around
the
way
that
ntp
represents
time
stamps
date
and
other
such
information
turns
out
that
there's
quite
a
few
protocols
out
there
that
are
effectively
lifting
copying
and
pasting
or
referring
to
directly
those
formats
and
are
expecting
to
have
those
epochs
to
be
used.
F
F
The
other
big
users-
and
these
are
used
by
media
protocols
and
also
used
by
the
time
and
by
protocols,
are
used
for
performance
or
at
least
latency
measuring
jitter
measuring
of
networks
as
as
themselves,
and
this
is
probably
because
a
lot
of
these
implementations
are
not
only
doing
these
measurements
but
they're,
also
using
ntp
services
to
to
generate
those
values
and
there's
some
thinking
we're
probably
going
to
have
to
do
when
getting
around
to
the
designer
v5.
F
The
second
one
is
metadata
and
identifiers.
There's
a
few
documents
out
there
they're,
mostly
yang
related.
I
don't
see
any
huge
issue
with
ntb
v5
and
these
obviously
we
will
have
to
consider
doing
a
yang
model
for
ntbv5
if
it's
substantially
different
or
regardless
and
the
last
one
service
discovery.
F
Ntp
v4
doesn't
really
have
the
dhcp
version,
4
option,
it
does
have
v6,
which
is
5908
and
there
are
there,
isn't
a
icmp,
v6,
ra
and
so
there's
a
there'll
be
a
kind
of
an
orthogonal
question
about
whether
or
not
we
need
to
potentially
do
a
document
that
defines
dhcp,
slash,
ipv6,
r8
options
for
ntp
v5
in
the
future,
and
we
don't
have
to
answer
that
as
part
of
the
protocol
design,
but
there
may
have
to
be
a
consideration
about
what
information
would
be
included
in
the
option.
F
So
what's
left,
if
you
ask
me-
and
we
haven't
even
adopted
this
document
left,
there's
a
handful
there's
only
a
small
handful
of
things
that
I
think
need
doing
apart
from
a
bit
of
editorialization,
I
think
that
there's
a
bit
more
work
that
needs
to
be
done
on
the
threat
model,
a
bit
more
covering
rate
limiting
data
minimization,
and
I
would
also
open
it
up
to
discussion
about
whether
there's
anything
else.
This
document
is
lacking
every
time
I've
posted
on
the
on
the
list,
a
new
version.
F
We
seem
to
end
up
going
down
the
road
of
talking
about
either
time
scales,
leap,
seconds
or
or
mandatory
security
or
not
and
I've.
F
I've
said
this
in
the
past,
and
I
I'll
say
it
again:
those
things
are
still
up
for
the
negotiation
and
what
I'd
like
to
do
is
have
this
adopted
as
a
working
group
document,
so
that
those
those
quite
frankly
controversial
things,
can
then
be
sort
of
bound
by
working
group
consensus
as
a
means
of
attaining
agreement,
rather
than
just
being
an
individual
document
and
me
being
able
to
put
whatever
I
want.
A
While
we're
looking
for
any
questions,
the
the
one
thing
that
you
mentioned
was
that
it
has
not
been
adopted,
and
I
think
now
that
we're
pretty
close
to
having
an
updated
charter.
I
think
it
probably
makes
sense
to
go
ahead
and
do
a
call
for
adoption
on
this
document
unless
somebody
thinks,
unless
somebody
has
a
reason
why
we
shouldn't
do
that.
F
G
Hello,
so
you
you
mentioned
sort
of
the
top
three
things
that
people
love
to
debate
about
this,
and
one
is
the
the
security
thing
and
you
do
have
statement
in
there
here
about
making
security
mandatory,
but
really
not
not
much
else.
G
I
I
wonder
if
it'd
be
worth
the
and
I'm
not
saying
we
shouldn't
adopt
this
as
a
working
group
document
anyways,
but
some
kind
of
elaboration
like
how
would
that
look
in
the
requirements
document?
If
it's
not
enough,
just
to
say
security
should
be
mandatory,
we
need
to
have
a
little
more
discussion
on
like
it.
Okay,
it
needs
to
be.
You
know
one
of
these
mechanisms
or
you
know.
How
does
that
look.
F
F
You
know
one
of
the
things
I've
tried
to
be
adamant
about
is
it's
my
preference,
that
the
protocol
have
mandatory
authentication
but
optional
confidentiality
and
then,
in
terms
of
how
that
is
implemented.
Well,
I'm
I'm
open
to
you
know.
I
don't
think
the
require
that
that's
a
solution
and
I
think
that
requirements
draft
shouldn't
be
overtly
descriptive
about
what
that
solution
is.
I
think,
the
consensus
that
I've
understood
so
far
is
maybe
it
should
just
use
nts,
because
you
know
it's
it's
there
and
it
works.
F
I'm
not
sure
what
else
needs
to
be
elaborated
on
on
that
topic,
asides
from
the
threat
model
that
I've
include.
I've
started
to
work
on
which
the
outcome
of
it,
which
includes
both
the
risks
and
what
I
believe,
potential
mitigations
in
the
protocol,
which
thus
become
requirements.
If
there's
anything
else
there
that
should
be
part
of
it.
Can
you
give
me
maybe
a
bit
more
of
a
specific
example
of
what
you
mean
by
more
detail.
G
Well,
I'm
thinking
about
someone
trying
wanting
to
do
maybe
some
kind
of
lightweight
security
for
simple,
simple
devices.
What
would
be
the
minimum
requirements.
F
F
If
there's,
if
there's,
I
think
about
the
best
way
of
saying
this,
if
there's
a
if
there's
sort
of
performance
requirements
in
terms
of
thinking
about
embedded
devices-
or
you
know,
power,
compute
and
with
crypto
constrained
in
requirements
that
you
think
should
be
part
of
it,
it'd
be
good
to
know
what
those
are
not
sure
that
answers
your
question.
F
A
One
question
james:
you
said
you
wanted
to
do
one
more
spin
of
the
document
before
we
did
a
call
for
adoption.
Do
you
have
a
rough
time
frame
for
when
you
expect
to
do
that?.
A
F
So
my
biggest
concern
is
just
the
structure
of
the
document.
I've
restructured
it
quite
a
fair
bit
in
the
past
couple
of
weeks.
Maybe
maybe
what
I
can
do
is
just
publish
the
restructured
bit.
Maybe
with
one
or
two
small
changes
push
that
out
as
a
as
an
o3.
F
F
No,
what
I
can
do
is
I
can
probably
have
a
crack
at
tying
things
off
this
weekend,
because
I
have
a
whole
bunch
of
other
ietf
related
chores
to
do,
and
then
you
know,
maybe
sort
of
next
week
or
the
week
after
have
something
actually
published,
does.
Does
that
sound
a
bit
more
timely?
F
F
A
All
right,
thank
you,
james.
So
the
next
item
on
the
agenda
that
I
have
is
ntp
v5.
We
do
have
an
updated
document.
We
don't
have
a
presentation,
I'm
not
sure.
If
there's
anything
mayor
slav.
Do
you
want
to
say
anything
with
respect
to
this
or
just
ask
for
additional
comments
on
the
mailing
list.
A
I
I
There
are
no
real
changes
in
the
protocol
and
I
think
the
dependency
here
is
on
those
requirements
that
are
still
not
clear,
and
I
would
yeah
ask
for
making
those
requirements
clear
as
dark
commented
on
specifically
about
the
security
part.
Like
my
draft,
does
it
meet
those
current
requirements
or
does
it
not?
I'm
not
sure.
I
Yeah,
that
would
be
nice
if
I
could
see
how
my
draft
fits
into
those
requirements,
and
maybe
it's
just
my
observation.
It
seems
to
me
that
there
are
two
groups
of
people
and
they
are
putting
on
opposite
sides
of
the
rope
like
one
group
is
seems
to
me,
is
interested
in
extending
the
use
cases
that
are
currently
exist
for
ntp
before,
but
the
other
group
is
trying
to
restrict
them
like
make
one
proper
way
to
use
ndp,
be
it
fully
secured
or
not
secure.
A
Yeah,
that's
a
I
think,
you're
true,
I
think
you
are
correct
that
there
are
difficult
to
resolve
differences
of
opinion
right
now
and
what
ntp
v5
should
do.
A
What
the
solution
to
that
is,
I'm
not
really
sure
that's
why
I'd
like
to
see
that
requirements
finished
sooner
rather
than
later.
G
Yeah
just
to
comment,
I
wanted
to
say
I
really
like
that.
The
way
leap
smearing
is
made
transparent
in
this
proposal,
because
I
think,
in
you
know,
hidden
leap,
smearing
is
is
just
a
catastrophic
data
center
failure.
That's
waiting
to
happen
as
more
and
data
centers
are,
are
adding
becoming
more
dependent
on
precise
timing,
and
they
they
all
tell
me
they
want
to
do
leap.
Smearing,
like
google,
does
and.
A
Okay,
so
everybody
please
take
a
look
at
the
ntp
v5
draft
that
miroslav
has
and
also
take
a
look
at
james's
draft
and
think
about
how
we
can
figure
out
a
way
forward
for
these
there's
nothing
else
on
that.
The
next
topic
is
ntp
over
ptp
mayor
slav.
Did
you
want
me
to
share
slides,
or
are
you
gonna
do
it?
I
Yeah
just
a
short
presentation.
I
First
slide,
please,
okay,
so
with
any
time
synchronization
protocol
like
ntp
or
ptp
accuracy
of
the
synchronization
depends
on
how
accurate
are
the
times
times
of
the
messages
that
the
protocol
is
using.
Absolute
accuracy
is
not
as
important
as
symmetry
in
the
errors
in
the
receive
and
transmit
timestamps.
I
I
I
I
I
I
I
I
I
I
I
Okay,
this
is
one
of
the
controls
I
tested.
It's
a
cheap
on-board
make
that's
widely
available.
I
There
two
identical
machines
and
they
are
connected
directly
without
any
switches
between
them.
The
graphs
show
the
offset
measured
by
ntp.
This
is
the
row
offset
not
the
offset
of
the
clock.
It's
yeah
with
plain
ntp
we
can
see
the
offset
is
jumping
around
by
tens
of
microseconds,
not
great,
but
when
we
wrap
ntp
in
ptp,
we
get
the
missing
hardware
received
timestamp
and
offsets
dropped
by
three
orders
of
magnitude.
I
There
is
likely
a
significant
asymmetry
in
the
in
the
receive
and
transmit
timestamp
that
this
hardware
is
generating,
but,
as
the
hardware
is
identical
on
both
sides,
these
asymmetries
cancel
out.
So
it's
now
very
close
to
zero.
There
is
some
small
asymmetry
left
about
10
nanoseconds,
as
we
can
see
in
the
graph,
and
I'm
not
sure
where
that
comes
from
could
be
difference
on
pci
latency.
I
I
B
Hi
thanks
for
the
presentation,
I
have
two
questions.
The
first
one
is:
is
this
approach
or
this
protocol
only
for
an
intern
for
a
local
network,
and
the
second
question
is
why
we,
what
is
the
advantage
of
ntp
over
ptp
instead
of
plain
pdp
in
the
local
network,
or
if,
if
we
run
it
in
the
local
network,
is
the
first
question.
I
I
I
I
B
G
Yeah,
so
just
a
couple
of
comments:
one
is
I'm
dubious
about
this
over
wide
area
networks,
because
if
you
go
through
enough
routers,
then
ptp
is
not
really
any
more
accurate
than
ntp,
because
the
error
comes
mostly
from
cueing,
not
from
hardware
time,
stamping.
At
the
end
point.
G
G
You
know
in
theory
you
can
make
you
can
have
multiple
grand
master
clocks
in
ptp
and
then
combine
them
in
a
voting
algorithm,
but
none
of
the
implementations
do
that
and
that's
sort
of
the
default
for
ntp
and
they
they
really
like
that
that
aspect
of
npp.
So
that
would
be
another
reason
why
people
might
want
to
do
this.
A
Okay,
go
ahead.
J
Okay,
no
just
okay.
I
I
would
like
to
to
also
to
to
say
the
same
comment
when
you
are
trying
to
synchronize
about
internet
you,
you
got
a
several
problem.
This
is
one
of
the
problem
that
I
address
with
the
the
draft
that
I
presented
to
tiktok,
but
my
question
to
mirolab:
is
you
always
find
the
same,
the
same
bias
to
the
to
the
transmitter
or
to
the
receiver?
J
Nowhere,
even
if
you
try
to
invert
the
transmitter
and
recycle.
This
is
just
a
question
about
curiosity.
A
J
Cyber
or
the,
but
if
you
invert,
recycle
the
machine
trying
to
to
to
send
the
the
the
the
client
and
the
server
you
if
you
invert
the
machines,
the
the
real
machines,
do
you
observe
that
the
the
bias
is
immersed
or
you
always
got
a
bias
in
the
same
idea?
It's
always
imagine
the
reciter,
for
instance,.
I
Okay,
yeah.
I
think
I
tried
this
experiment
to
swap
the
cards.
It
was
different
cards,
not
this
one
and
sorry
I
forgot
less
result.
I
think
I
think
it
was
something
with
the
machine
itself,
like
the
the
the
sign
of
the
asymmetry,
stayed
with
the
machine.
That's
how
I
remember
it,
but
I
could
be
wrong.
I
I
have
in
those
machines
there
are
different
cards,
they
are
in
the
same
pci
slot,
so
the
order
is
the
same.
The
cpus
are
configured
to
the
same
frequency,
so
the
reading
over
pci
takes
the
same
time,
but
there
was
always
some
asymmetry
and
I
think
it
was
slightly
different
between
different
cards
within
few
nanoseconds.
J
Okay,
because
I
I
I
used
to
synchronize
microcontrollers
and
I
have
problems
with
the
even
if
the
microcontroller
seem
to
see
seem
to
be
the
same.
There
are
always
some
some
bias
which
normally
depends
on
on
the
hardware.
It
depends
on
the
on
the
on
the
the
machine
itself,
but
sometimes
it's
always
in
the
in
the
function.
It
depends
just
the
the
recycler
has
always.
I
don't
know
it's
always
late
for
interest,
something
like
that.
I
A
G
Yeah,
I
just
you
know
when
you
get
down
to
when
you
get
below
a
microsecond,
then
there's
like
a
lot
of
well-known
asymmetries
like
the
differences
between
fives
forward
and
reverse
transmission
and
and
cables.
If
you
have
long
cables
all
have
skew
in
them
as
well.
A
All
right
so
miroslav
do
you
have
anything
else?
You
want
to
say.
A
All
right,
thank
you
very
much.
So
we
have
five
minutes
left.
Martin
was
going
to
give
us
a
quick
update
on
the
progress
on
the
nts
for
ptp
work.
B
Yes,
hi.
Yes,
at
this
point,
some
information
about
ptp
security.
So
far
we
have
two
nts
based
draft
documents
for
securing
pdp.
B
B
The
goal
is
to
use
ntsc
establishment
protocol
as
a
key
distribution
mechanism
for
pdp.
However,
we
cannot
yet
say
when
the
first
draft
will
be
ready,
but
we
are
making
progress.
I
think,
maybe
in
two
or
three
months,
maybe
faster,
but
there's
a
lot
of
discussions
currently
but
we're
working
together
and
we
won't
push
one
document,
one
protocol
nts
for
pdp,
so
yeah
so
far
for
the
on
the
topic
of
ptp
security.
A
So
that
update
went
really
quick,
so
that
brings
us
to
any
other
business
we
had
out
of
our
last
meeting.
We
had
had
agreed
to
do
virtual
interims,
which
we
did
not
do
given
what
some
folks
have
said
about
when
they
planned
some
updates.
A
F
A
Is
that
okay,
anything
else
go
ahead,
rich.
H
First
update
to
my
computer,
which
rebooted
what
happened
at
the
beginning
with
the
registry
draft
updating
registration.
A
A
All
right
anything
anything
else,
my
goodness
we're
gonna
end
pretty
much
exactly
on
time.
Thank
you,
everybody
for
coming,
and
we
will
see
you
at
the
next
meeting.
We
are
done.