►
From YouTube: IETF111-NTP-20210727-2300
Description
NTP meeting session at IETF111
2021/07/27 2300
https://datatracker.ietf.org/meeting/111/proceedings/
A
So
detroit
I
see
you,
there
are
you.
I
just
want
to
ensure
your
audio
and
video
is
working.
A
All
right,
so
it
is
on
the
top
of
the
hour,
so
we
will
go
ahead
and
get
started.
A
And
I
know
we're
missing
a
few
key
participants
for
this
session,
so
we'll
see
how
this
goes.
Welcome
to
the
ntp
working
group
meeting
at
ietf,
111
dieter-
and
I
are
your
co-chairs.
A
So
first
of
all
here
is
the
ietf
notewell.
You
will
have
seen
it
in
several
sessions
before
and
you
will
have
agreed
to
it
when
you
registered
for
the
meeting.
This
contains
all
of
the
policies
of
the
ietf,
and
so
please
take
note
of
it.
If
you
have
any
questions,
feel
free
to
reach
out
to
dieter
or
myself
or
eric
klein.
Who
is
our
area
director.
A
This
is
our
draft
agenda
for
the
day.
So
with
that
on
the
admin,
do
we
have
any
agenda
bashing?
Do
we
have
any
additions
or
deletions
from
the
agenda.
A
Okay,
ditter
has
agreed
to
take
minutes
so
with
that
we
will
go
with
him
doing
the
minutes.
He's
going
to
use
the
comedy
note
taker,
so
anybody
can
contribute
as
we
go
along
ms
rich
here.
Yet
yes,
richie's
here,
okay,
great.
A
A
Regularly
in
the
ietf
there
is
a
you
can
you
can
join
a
queue
if
you
have
to
want
to
ask
any
questions,
so
be
sure
to
do
that
anyway.
So
back
to
the
documents,
the
port
randomization
document
is
in
the
rxc
editor
queue.
Their
other
documents
are
in
various
stages
within
the
iesg,
the
interleave
modes.
You
all
will
have
seen
a
lot
of
mailing
list.
Discussion.
A
Marislav
is
not
on
this
call.
I
don't
think.
Let's
say
has
he
joined
us
yet
nope.
So
there's
a
couple
issues
with
them
with
the
interleave
modes.
First,
one
being
that
I
need
to
update
the
shepard
write
up.
Apparently
I
have
overwritten
the
original
one
and
the
one
that's
there
is
the
wrong
document,
so
I
need
to
recreate
it
and
then
the
second
one
is
to
address
the
stuff.
That's
on
the
mailing
list.
A
C
C
I
think
it
was
a
comment
that
was,
it
shows
up
if
you
run
the
the
id
nits
in
the
data
tracker
for
the
document,
but
we
can
talk
about
that
separately.
I
don't
know
what
other
documents
that
have
updated
5905
have
done
about
that,
but
it
was
called
out
to
me
when
I
tried
to
bring
it
to
the
iesg.
C
Maybe
I
can
maybe
we
can
sail
through
on
on
an
established
precedent.
C
Okay,
as
for
as
for
the
other
things
you
know,
yeah,
I
don't
know
we
because
I
because
of
the
other
objections,
I
sort
of
deferred
the
document
from
the
telechat,
so
we
didn't
get
a
chance
to
see
how
many
other
members
of
the
isg
were
bothered,
but
the
early
feedback
was
just
a
lot
of
people.
That
seemed
to
be
very
concerned
about
whether
or
not
this
was
actually
safely
deployable.
What
was
how
I
generally
interpreted
those
comments.
A
I
guess
the
question
I
had
on
all
of
those
comments
was:
does
that
mean
it?
There
seemed
to
be
some
confusion
about
or
not
confusion.
There
seemed
to
be
some
indecision
about
whether
we
needed
to
take
it
back
to
working
group
to
address
them
or
whether
the
iesg
needed
to
have
an
internal
conversation
first,
so
that
they
could
provide
us
guidance,
and
then
we
could
take
it
back
and
address
them
so
that
that
was
sort
of
the
two
state
that
I
was
in
and
I
haven't
figured
out.
C
I
didn't
get
the
sense
that
the
feedback
that
was
coming
in
had
guidance
of
the
form.
If
you
just
do
x,
y
and
z,
then
it'll
be
fixed,
it
seemed
to
be
a
little
more.
C
C
I
know
that
the
document
has
basically
like
three
different
what
you
can
do
in
three
different
modes
and
in
each
one
of
those
modes.
It
says
you
know
a
legacy
in
a
legacy
situation,
if
someone.
If
so,
if
a
node
doesn't
understand
interleaved,
then
this
then
this
is
what
happens.
I
had
wondered
whether
or
not
maybe
there
should
be
a
document
up
front,
that
sort
of
says
what
the
fallback
scenarios
are
and
why
this
is
not
why
this
is
perceived
to
be
safe.
C
I
don't
know
what
other
people
feel
might
address
things,
but
I
think
we
probably
do.
I
don't
know
if
you
need
to
pull
it
all
the
way
back
to
the
working
group.
It
depends
on
whether
we're
going
to
change
anything
if
we're
going
to
change
something.
I
think
we
do
if
we're
just
going
to
like
add
a
clarifying
paragraph
here
or
there,
then
probably
we
don't.
A
C
We
could
take
it
to
the
isg
and
see
see
see
what
everyone
else
says.
Maybe
it
was
just
robin
warren
and
ben
abstained.
So
maybe
I
don't
think
anybody
else
jumped
in
with
comments
really
prior
to
my
having
to
hurt
it
to
to
address
what
I
thought
the
other
issues
were,
but
we
just
we
could
just
bring
it
back
to
the
isg
and
see
what
happens
and
deal
with
the
deal
with
the
fallout
there.
After.
A
C
I'm
wondering
whether
or
not
there's
like
a
adding
a
clear
section
that
says:
here's
why
this
is
operationally
safe
to
do
up
front
and
not
have
it
interspersed
with
various
modes.
Sections
might
have
provided
a
clear
thing
to
point
to
this
says
to
elate
people's
fears
from
the
get-go.
D
Yeah,
so
I
I
mean
I
mean
setting
aside
my
my
personal
opposition's.
The
document
I
it
seems
like
the
logical
course
forward
is
that
is
that
the
working
group
should
first
address
the
feedback
as
far
as
consensus
exists
and
then
from
there
figure
out
whether
it
has
enough
no
objections
to
pass
or
not
and
determine
the
course
from
there.
C
Okay,
well,
it
definitely
won't
have
enough
no
objections
to
pass
yet
because
it
didn't
get
everybody
else's
feedback,
but
I
think
yeah.
If
we,
if
we
tackle
the
the
feedback
that
we
got
now,
we
will
satisfactorily
will
be
able
to
forestall
all
of
the
others.
Other
comments
that
basically
say
yeah.
I
agree
with
warren
and
rob.
I
agree.
I
agree.
I
agree
that
kind
of
thing.
A
Okay,
so
we
will
circle
back
to
marislav
and
see
if
we
can
do
a
better
job
of
addressing
those
comments
in
a
coherent
manner.
So
the
second
one,
that's
in
isg
stages
is
the
yang
data
model
and
I
think
that's
waiting
on
an
update
from
the
authors
and
that's
coming.
I
think
he
has
communicated.
A
So
in
we
have
two
open
working
group
calls
out
of
our
virtual
interim
meeting
a
little
while
ago.
One
was
a
last
call
on
the
alternative
port
document.
A
A
Document
the
second
one
was
the
adoption
call
for
the
update
registries.
A
E
I
can
you
know
when
you
say
it's
been
adopted,
I'll
rename
and
submit,
and
then
we
can
discuss.
I
think,
there's
one
or
two
open
issues
about
whether
or
not
we
want
to
partition
space
number
space
into
three
different
categories:
expert
review,
standards,
tracker
and
so
on,
but
that's
just
general
working
group
discussion
on
it.
D
That
was
that
was
mostly
rich,
and
I
disagreeing
on
that.
I
think
I
I
I
I
favor
adoption
of
the
document,
regardless
afterwards.
A
Same
here
all
right
excellent,
so
we
will
we'll
send
out
a
message
and
change
that
state
to
being
adopted.
Hopefully
this
week.
A
I'm
sorry
oh
hit
too
many
times
all
right.
So
next
up
is
rough
time
and,
as
I
believe,
watson
you
are
going
to
share.
G
G
Slides,
okay,
great
all
right,
so
this
is
an
update
on
the
draft
status
for
itf
11
held
in
well
your
living
room.
Once
again,
so
first,
I
want
to
talk
a
little
bit
about
rough
time
overall.
This
is
you
know.
I've
been
a
working
group
item
for
a
while,
but
I
think
it's
useful
to
review
why
we're
doing
this,
as
this
has
been
a
question
in
some
of
the
comments,
I've
gotten
the
mailing
list.
G
So
it's
certificate
transparency
for
time,
there's
lots
of
applications,
x509
verification,
kerberos,
keys,
etc,
which
need
a
rough
idea
of
the
time
they
don't
need
to
be
microseconds
or
milliseconds.
Accurate,
they're,
fine,
with
a
few
seconds
they're
dealing
with
minutes
or
days
or
or
weeks,
but
they
need
to
have
a
high
degree
of
confidence
in
the
honesty
of
the
servers,
and
this
had
getting
this
sort
of
application
out.
There
is
going
to
have
a
big
impact
on
security.
G
It's
a
it's!
A
huge
fraction
of
certificate
errors
are
due
to
miss
that
clocks
and
so
we're
training
users
to
click
through
get
that
rate
down,
and
you
can
start
thinking
about
certificate
failures
being
a
hard
stop
and
the
rough
time
protocol
doesn't
decide
for
applications.
What
they're
willing
to
accept
it
says:
okay,
here's
the
time
and
here's
the
uncertainty
interval
caused
by
network
delays.
It's
up
to
the
application
to
decide
if
that's
good
enough
for
the
purposes
they're
looking
at.
G
So
this
is
very
different
from
ndp,
where
the
application
really
isn't
interacting
with
ntp
at
all.
It's
the
time
is
getting
set
on
the
computer
and
just
needs
to
trust
that
time
and
usually
there's
very
little
explicit
modeling
of
the
accuracy
you're
deriving
from
ndp.
G
So
now,
let's
talk
about
the
documents,
so
one
of
the
things
that's
happened
is
we've
split
up
the
documents
in
a
two
for
easier
progression
and
sort
of
being
able
to
hammer
out
a
bunch
of
details
on
the
wire
format
and
implementations
and
get
things
off
the
ground,
while
leaving
some
of
the
ecosystem,
things
that
are
more,
that
are
less
well-defined
and
need
a
lot
more
input
to
later,
and
so
this
has
been
a
way
to
sort
of
shrink
the
make
the
burden
manageable.
G
So
the
first
draft
is
draft
itf
and
tp
rough
time
o5.
This
is
very
narrowly
focused
on
the
communication
with
servers
and
clients.
The
so
marcus
and
I
have
sat
down,
have
written
implementation.
They've
pointed
them
at
each
other
and
they
worked
and
we
just
looked
at
the
spec.
We
did
not
and
and
things
you
took
from
the
spec.
We
changed
and
other
people
have
had
reported
success
in
in
doing
this.
So
we
think
that
this
plus
the
maturity
we
didn't
really
have
to
change.
G
Much
we've
gone
through
looked
for
typos,
we
fixed
a
few
so
we'd
like
to
go
to
working
group.
Last
call
after
this
meeting
and
get
this
draft
on
the
progression.
G
So
that's
pr,
you
know
pretty
good
for
this.
One
draft
second
draft
is
in
a
much
more
nebulous
state.
So
this
is
the
draft
iotf
ntp
rough
time,
ecosystem,
zero,
zero!
It's
got
more
complications,
so
it's
talking
about
miss
issuance.
What
does
it
mean
for
a
server?
To
be
honest,
was
it
to
be
dishonest?
G
How
do
you
report
if
you
suspect
this
server
is
dishonest,
because
you
have
measurements
from
different
servers
that
disagree
with
each
other
similar
to
ct?
We
have
servers,
we
have
clients,
we
have
auditors
and
clients
need
to
have
their
own
policies
around
what
they
consider
acceptable
for
servers.
Are
you
gonna.
H
G
Servers
with
certain
uptimes,
whereas
something's
gonna
be
kind
of
beyond
this,
but
I
think
it
needs
more
input
from
people
who
aren't
just
the
draft
authors
and
beyond
sort
of
contributing
to
spec.
It
would
be
helpful
if
you
would
set
up
a
more
servers
that
are
supporting
this
version,
the
protocol
or
previous
version
or
the
wire
format
drafts
version,
not
the
old
one
from
google
and
more
auditors.
We
don't
currently
have
any
auditors
and
we
need
that
for
the
ecosystem
to
work
we
need
to
make.
G
We
need
to
know
that
someone's
checking
up
on
the
honesty
of
servers
now
freely
and
then
complicit
here,
cloudflare's
rough
time,
service
is
still
on
the
google
version
that
will
hopefully
change
sometime
so,
but
I
think
now
it's
time
for
discussion
and
there's
a
couple
questions
that
sort
of
want
some
input
on
who's
interested
in
this
work
beyond
sort
of
the
usual
suspects
from
other
places
who
wants
to
implement
this.
G
Are
there
applications
that
we
should
be
considering
that
we
aren't
yet
that
sort
of
need
more
and
other
questions
and
comments
about
any
aspect
of
the
drafts?
So
with
that,
I
think
I'll.
Stop.
Presenting
and
we'll.
A
E
G
So
I
I
think,
the
for
absolute
minimum
if
there
was
another
server
that
implemented
rough
time
and
a
handful
of
auditors
and
sort
of
we
had
a
format
for
defining
the
the
in
the
detection.
That
would
be
enough.
I
think
it
would
be
a
minimum
of
three
servers
implementing
the
protocol,
because
then
you
could
tell
which
one
was
dishonest.
If
you
just
have
two,
you
don't
know,
and
at
that
point
we
would
have
we'll
be
able
to
say
look.
These
three
servers
are
giving
you
the
right
time.
You
know
they're
giving
you
the
right
time.
G
F
A
I'm
looking
through
this
list,
so
one
of
the
questions
that
watson
has
asked
is
interest
in
implementing.
Do
we
have
anybody
else?
Anybody
here,
who's
publicly
willing
to
say
they're
interested
in.
A
I
can't
hear
you
yet
so
are
you
speaking?
Oh
here
comes
oh
now,
you're
gone.
A
You
should
try
again
james
and
eric
is
in
the
queue
so
go
ahead.
Eric.
C
I
was
just
going
to
say
that
if
no
one
else
from
google
steps
up
I'd
like
to
see
that
someone
from
google
does
it
and
it
might,
it
might
be
me,
but
I'll
need
to
talk
to
some
folks.
A
Oh
james
says:
please
carry
on
james.
You
could
put
your
your
comment
or
your
question
in
the
chat
as
well.
That
would
work
all
right.
Well,
that
was
pretty
pretty
easy,
so
watson,
I
think
the
we
can
do
the
working
group
last
call.
C
A
All
right,
so
I
guess
with
that
so
you'll
see
a
working
group
last
call
on
the
on
my
face
rough
time
document
and
the
ecosystem.
We
ask
for
people
to
review
that
and
provide
any
comments.
That
would
be
great.
Thank
you
very
much.
Watson.
A
So
that
takes
us
back
to
the
the
next
item
on
the
agenda
is
the
way
that
data
and
I
generally
build
our
agendas
as
we
go
and
we
look
at
what
documents
have
been
updated
since
the
last
meeting
and
then
what
topics
that
we
feel
we
need
to
talk
about.
So
the.
A
Is
a
draft
that
marislav
has
put
forward
on
ntp
over
ptp
and
I
don't
miroslav
is
not
here?
Is
there
anybody
that
wishes
to
talk
to
this
draft.
A
A
If
there
are
no
further
discussions
on
the
charter,
I
I
think
it's
ready
to
go
eric
if
you're,
what
what
the
process
you
would
like
us
to
use
to
get
it
moved
forward.
C
I
was
going
to
have
a
pass
if
everyone
was
generally
satisfied
with
the
kind
of
contents.
I
was
going
to
try
to
have
a
look,
and
maybe
we
could
trade
some
edits.
Real
quick,
do
one
more
loop
through
the
working
group
and
then
I'll
take
it
to
the
isg,
where
we'll
suffer
the
slings
and
arrows
of
outrageous
fortune
and
and
then
we'll
we'll
get
what
we
get.
C
A
I
was
what
you
were
planning
on.
I
did
not
I
okay
doug
you're
in
the
queue
go
ahead.
H
I
just
want
to
say
I
thought
the
I
thought
it
is
very
appropriately
flexible
to
cover
a
lot
of
different
timing,
related
work
and
I
think
that's
what's
needed.
So
we
very
much
support
it.
D
Do
we
want
to
keep
the
name
mtp?
If
probably
a
majority
of
the
working
group
at
this
point
is
interested
in
other
protocols?
I've
been
say:
I've
been
I've
been
saying
we
should.
We
should
name
it
time.
Sync,
it's
accurate,
no
matter
how
you
spell
it.
A
So
eric
and
I
had
a
really
short
conversation.
Alright
conditioner
and
I
had
a
short
conversation
on
this
and
we
were
going
to
change
it
to
network
time
protocols
and
add
a
s
to
the
end.
A
To
keep
the
same
acronym,
we
had
previously
talked
about
changing
the
name,
and
I
didn't
know
how
much
confusion
that
would
cause.
So
what
do
folks
think
about
that?
Subtle
change?
I
Anybody,
I'm
not
sure
if
it
works.
H
I
Okay,
so
I
I'm
not
sure
if
it
would
be
worth
the
let's
say,
administrative
hassle
to
to
change
it.
So
I
would
be
in
favor
of
just
keeping
the
old
name
and
leave
everything
as
it
is
mailing
list
names
and
and
data
tracker
links
and
so
on.
A
G
Watson
changing
names
is
I'm
gonna,
say
second
heckle
said:
changing
names
is
extraordinarily
difficult,
we'll
never
catch
all
the
old
places
that
need
to
be
fixed.
E
A
Okay,
well,
that
was
why
I
thought
eric's
suggestion
to
just
add
an
s
to
the
end
was
at
s
to
the
end
of
the
name
of
the
working
group,
not
to
the
end
of
the
acronym.
A
So
it's
network
time
protocols,
which
is
very
subtle,
but
I
think
that
would
work.
A
Numerous
time
protocols,
I
think
the
other
thing
somebody
said
was
that
we
would
primarily
be
working
on
non-ntp
protocols,
and
I
don't
I
don't
know
that.
That's
necessarily
the
case.
I
see
we're
primarily
still
going
to
be
working
on
ntp
and
ntp
related
protocols,
network,
historical
npp,
all
right.
A
So
with
that
the
charter
is
the
draft
charter
is
on
the
mailing
list
and
we
will
update
it
with
eric's
comments
and
send
it
through
the
working
group
one
more
time
and
then
hopefully
send
it
forward.
A
So
the
we
had
a
really
productive
virtual
interim
meeting.
I
don't
know
five
or
six
weeks
ago
and
we
had
a
bunch
of
conversation
on
mtpv5.
We
have
no
new
drafts
since
then,
so
we
went
ahead
and
put
it
on
the
agenda,
but
we
don't
have
any
new
drafts
to
specifically
to
discuss,
and
so
my
I
don't
want
people
to
forget
that
we're
working
on
it,
but
I
also
haven't
asked
anybody
in
particular
to
talk
about
it.
So
is
there
anything?
Particular
people
want
to
talk
about
related
to
ntp,
e5.
H
Well,
I
think
one
of
the
the
non-trivial
topic
that
has
to
be
worked
on
to
move
the
ntp.
V5
draft
forward
is
security.
You
know
how.
How
is
that
going
to
be
handled
or,
if
there's
a
notion
that
we'll
just
say
you
have
to
have
security
and
here's
a
list
of
other
documents,
any
of
which
is
applicable
or
is
there
going
to
be
a
default
security
that
we
define
right
in
the
document
or
yeah
that
it's
sort
of
wide
open
still.
A
B
B
But
the
reason
I
mention
that
is
because
one
of
the
things
on
my
to-do
list
for
the
requirements
draft
is
to
piece
together
a
fairly
rudimentary
threat
model
to
at
least
define
what
things
we're
going
to
worry
about,
or
not
worry
about
for
that
matter,
and
I
think
that
would
set
the
boundaries
in
terms
of
what
kind
of
technical
implementation
would
be
needed.
H
B
A
Yeah
I
mean
right
now
the
the
beyond
the
conversations
in
our
virtual
interim
meetings.
We
have
the
two
drafts,
we
have
james's
requirements
document
and
we
have
marislav's
contribution.
So
I
thought
at
some
point
daniel
you
had
written
something
I
don't
know
if
I'm
imagining
that.
D
A
Okay:
okay,
that's
why
I
remembered
it
and
couldn't
find
it
the
so,
if
is
there
any,
when
we
get
to
the
end
of
this
we'll
talk
about
like
next
steps
and
I
think
one
of
the
things
I
think
the
combination
of.
A
Of
the
time
of
this
meeting
and
a
few
other
things
have
resulted
in,
we
don't
have
any
new
country.
We
didn't
have
a
lot
of
new
contributions
to
this
meeting.
So
perhaps
we
will
discuss
virtual
interim
scheduling,
see
if
we
can
get
that
conversation
moving
forward.
A
We
have
no
updated
ids
on
that.
Yet
I
we
have
the
contribution
from
hico
and
we
have
the
contribution
from
martin
langer.
J
Okay,
yeah,
that's
correct.
I
plan
to
provide
an
update
next
month,
so
many
small
changes
and
currently
we
have
no
further
update.
Yet,
okay.
H
Okay,
there
I'm
unmuted
yeah,
I
just
I
wanted
to
throw
it
out
there.
You
know
I'm
open
to
ideas
on
how
how
we
can
get
a
sense
for
what
the
consensus
is,
and
you
know
do
we
want
to
pursue
one
of
these
two
proposals
or
something
else.
You
know
how
do
we
because
it'd
be
nice
to
get
everyone
behind
a
direction
and
say
okay?
This
is
what
we're
going
to
try
to
do,
but
I'm
not
sure
how
to
organize
that.
G
Shoes,
I
think
one
of
the
issues
is
that
we're
trying
to
boil
the
ocean
there's
so
many
ways.
Ptp
can
be
deployed,
some
of
which
map
less
cleanly
onto
onto
the
structure
we
have
with
nts,
some
of
which
map
more
cleanly
and
it
might
and
identifying
the
cases
that
we're
going
to
start
with
and
try
and
get
something
out
of
is.
I
think
this
place
to
start,
but
that's
obviously
been
hard.
A
I
Yeah,
I
I
I
think
there
was
a
suggestion.
I
don't
know
a
couple
of
days
ago
or
maybe
two
weeks
ago
in
the
mailing
list
that
martin
might
want
to
split
his
documents
into
multiple
parts.
I
I
think
what
we
currently
look
at
is
a
security
mechanism
for
a
multicast
ptp,
a
security
mechanism
for
unicast
ptp,
and
I
think
the
third
topic
would
be
a
protocol.
I
Basically
how
nts
key
exchange
servers
talk
to
the
to
the
let's
say:
ntp
or
ntp,
servers
or
ptp
servers
if
this,
if
if
they
are
operating
in
a
let's,
say,
distributed
model-
and
I
I
think
I
I
would-
I
would
be
in
favor
of
that-
and
I
think
martin
already
indicated
he
would
be-
he
would
be
okay
with
with
doing
that,
and
that
might
make
it
a
lot
easier
to
discuss
those
three
topics
instead
of
having
let's
say,
a
pretty
big,
pretty
large
draft
with
a
lot
of
topics
and-
and
I'm
a
little
bit
afraid
that
that
will
take
quite
some
time
to
to
yeah
to
work
on
that.
I
A
I
think
splitting
it
up
is
fine.
I
think
the
risk
you
run
is
that
you
don't
get
back
to
the
modes
of
service
that
had
less
traction
or
not
modes
of
service
in
the
context
of
ptp
that,
for
example,
when
we
split
out
server
client,
we
expected
to
go
back
and
do
the
others
and
we've
never
gotten
any
contributions
on
that.
So
go
ahead.
Watson.
G
I
think
that's
a
feature
of
a
slight
process,
not
a
bug.
If
the
other
modes
are
are
caught,
creating
problems
of
standardizing
there
isn't
the
impetus
to
move
them
forward
in
terms
of
the
need,
then
chopping
them
out
is
the
right
thing
to
do
and
having
a
split,
split
side
documents
helps
you
realize
that
versus
getting
tied
into
debates
and
never
asking
a
question
well,
do
we
actually
care
enough
to
do
it.
A
That's
true,
I
think
the
the
concern
at
the
time,
although
since
the
other
modes
of
service
have
not
been
forthcoming,
was
that
if
we
defined
something
for
server
client,
that
would
ultimately
prohibit
us
from
solving
the
other
problems.
But
I
think
you
were
right.
It
helps
narrow
the
field
when
you're
unable
to
make
a
decision
so
so
doug.
I
don't
know
that
we
answered
your
original
question.
A
I
mean
heiko
outlined
the
three
documents
that
he
felt
we
were
going
to
be
moving
forward
on
martin
indicated
that
he
was
going
to
provide
an
update.
I
think
the
next
step
is
to
oh
go
ahead.
Doug.
H
This
would
be
a
good
time
for
martin,
perhaps
to
chime
in
and
say
whether
this
is
a
task
that
he's
interested
in
taking
up
or
otherwise
we
would
need
another.
J
Oh,
oh
sorry,
you
mean
to
split
the
draft.
J
Yes,
I
think
I
discuss
it
with
a
whiner
and
maybe
we
should
just
discuss
it
together,
but
yeah.
I
think
it's
possible.
A
Okay,
so
with
that,
so
looking
at
so
the
minutes
we'll
have
a
clear
articulation
of
what
the
three
possible
partitions
of
the
document
would
be.
Martin
will
have
a
new
document
coming
out
in
four
to
six
weeks
and
we
will
have
something
to
discuss
at
the
next
virtual
interim
related
to
this.
Oh
something
in
the
chat-
oh
not
related,
so
are
there?
Is
there
anything
else
that
people
wish
to
discuss
related
to
ntp,
v5.
A
Okay,
so
the
next
item
on
the
agenda,
we
also
don't
have
any
current
id
updates
for
and
that's
the
nts
for
pgp.
We
have
oh
wait.
I
was
talking.
A
I
was
talking
about
nts
for
ptk,
never
mind.
So
that
brings
me
to
any
other
business.
I
can't
even
claim
it's
late
compared
to
all
of
you,
folks,
from
europe
that
are
on
this
call.
Sorry
about
that.
Is
there
any
other
business
before
we
talk
about
scheduling
and
way.
A
A
Okay,
so
with
that
we're
at
the
end
of
july
now,
between
now
and
november,
I
think
it
would
probably
make
sense
so
that
the
ietf
the
next
day,
the
next
full
ietf
meeting
ietf
112,
is
scheduled
to
be
the
week
of
november,
8th.
H
Yeah-
and
I
think
the
scheduling
is
when
you
get
into
the
fall,
there's
a
lot
of
events
of
various
kinds
that
many
of
us
would
be
attending
that
are
virtual
or
not
virtual,
so
it
it
might
be
good
to
do
a
doodle
poll
or
something
to
try
to
find
a
you
know
a
time
a
day
or
a
half
day
or
whatever.
That
would
be
not
in
the
middle
of
some
other
meeting
or
conference.
A
A
Don't
know
if
it's
like
a
year
and
a
half
of
virtual
meetings,
but
I'm
finding
scheduling
to
be
like
one
of
those
really
painful
tasks.
Do
we
think
we
want
to
try
one
or
two
meetings?
A
Six
weeks,
or
at
least
five
weeks,
because
there's
no
point:
if
we're
not
going
to
have
any
new
drafts
to
discuss,
I
think
well,
I
guess
we
would
have
the
working
group
last
call
on
the
rough
time.
So
we
would
have
that
material
to
discuss.
A
I
Yeah,
I
think
two
would
probably
be
be
better
just
a
comment
regarding
the
the
the
draft
I'm
for
the
nts
for
unicast
ptp
draft,
I'm
a
little
bit
stuck
because
I
don't
know
what
what
the
future
of
this
draft
will
be.
So
I
I
don't
really
see
any
comments
or
any
any
significant
comments.
I
Let's
say
that
that
basically
discuss
the
technical
aspects
of
the
draft
last
discussions
were
mainly
focused
around
or
circled
around
whether
this
makes
it
is
it's
worthwhile
or
not,
and-
and
so
until
I
I
don't
think,
there's
there's
a
lot
of
stuff
I
can
address
in
in
in
an
update
for
the
draft.
I
So-
and
I
I
I
assume
that
or
I
I
I
have
the
feeling
that
that's
more
or
less
the
same
for
for
martin's
draft
there's
there's
some
comments,
but
but
not,
let's
say
a
big
bunch
that
that
justifies
that
would
justify
an
update.
So
so
I
think
we
are
a
little
bit
stuck
due
to
the
fact
that
that
the
status
of
the
draft
is
not
yet
or
is
not
changing,
and-
and
that's
that's
probably
one
of
the
reasons
why
there
are
no
no
document
updates.
A
So,
ordinarily,
the
next
step
would
be
a
call
for
adoption.
Maybe
what
we
could
do
would
be
a
consensus
call
on
the
plan
to
pull
apart
the
whole
space
into
the
three
pieces.
We
could
just
do
a
consensus,
call
on
that
and
then
we
would
be
able.
Then
you
would
be
able
to
say
you
know,
I'm
providing
this
document
for
the
unicast
solution,
for
example:
does
that
make
sense?
H
I
think
that
does
make
sense.
I
think
the
the
other
big
sort
of
general
question
is:
is
it
is
it
more
important
to
when
it
comes
to
unicast
ptp
security?
H
Is
it
more
important
to
make
something
that
is
sort
of
clean
and
the
most
sense
for
ptp
by
itself,
or
is
it
more
important
to
make
the
ptp
and
ntp
unicast
security
be
as
similar
as
possible,
because
that
those
are
the
two
drafts,
that's
kind
of
that,
the
general
starting
assumptions
and
in
the
drafts-
and
you
know
if
we,
if
we
had
consensus
on
those
and
we
knew
know
which
which
of
those
approaches
to
follow
up.
A
On
okay,
so
we
we
could
try
to
write,
or
we
could
do
a
couple
of
high-level
consensus
calls.
You
would
want
to
work
on
being
sure
that
we
got
the
questions
right.
A
A
Did
you
in
your
present?
I
don't
remember
doug
in
your
presentation
at
the
last
meeting.
Did
you
have
didn't
you
have
a
concise
way
of
stating
that
perhaps
you
could.
H
Look
and
and
yeah
so
I'll,
take
that
as
an
action
item
to
go
back
and
to
look
at
that
and
try
to
I'll
try
to
phrase
it
in
a
way
that
you
could
put
it
out
to
the
group
that
would
be.
H
A
A
Okay,
that
would
be
great
one
thing
I
wanted
to
be
sure
if
people
missed
it
in
the
chat
was
that
daniel
did
point
out,
provide
a
pointer
to
the
ntp
v5
sketch
that
he
wrote
a
couple
years
ago.
A
It's
a
ditra.
I
think
we
probably
want
to
capture
that
and
stick
it
in
the
minutes
from
the
chat
and
others
who
might
not
have
noticed
it
in
the
chat
should
probably
take
a
quick
look.
A
Okay,
so
so
back
to
scheduling
we
will.
We
will
work
on
a
doodle
poll
for
two
virtual
interims
between
now
and
november.
A
So
with
that,
the
the
last
thing
that
I
I
neglected
to
put
on
the
agenda
was
the
one
remaining
document
from
the
tick
tock
working
group,
which
is
the
enterprise
profile
and
that
has
fallen
off
the
table
yet
again,
but
we
will
put
it
back
on
the
table
and
hopefully
we
will
get
it
done
real
soon
go
ahead.
Doug.
H
Is
there
anything
as
one
of
the
authors
on
that?
Is
there
anything
that
you
need
from
us
on
that,
or
is
it
just
really
in
the
iatf
administrative
court?
At
this
point.
A
At
this
stage
it
I
need
to
write
the
shepherd
right
up.
So
if,
if
anybody
wants
to
help
me
with
that
write-up
that
would
be
great
and
that
that's
where
it
is
right
now
so.
H
B
A
That
sounds
good.
Maybe
we
can
schedule
some
time
over
not
this
week,
but
maybe
in
the
next
couple
weeks
just
to
get
together
and
work
on
that
at
the
same
time,
so
it'll
be
a
little
bit
more
productive
than
asynchronous
all
right.