►
From YouTube: IETF115-NTP-20221111-1200
Description
NTP meeting session at IETF115
2022/11/11 1200
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
B
B
A
A
We'll
get
started
in
a
moment
or
two
I'm
waiting
for
Eric
who's
going
to
help
me
co-chair
this.
C
A
The
other
thing,
while
we're
getting
started,
is
there
anybody
ordinarily
ditch
or
helps
take
notes,
but
Dieter
is
not
well
today.
So
I
was
wondering
if
anybody
else
would
be
willing
to
help
take
notes.
Anyone
excuse
me.
A
A
A
A
A
A
This
is
the
ntp
working
group
welcome
to
the
last
session
of
the
week
for
ietf
115.,
and
thank
you
for
everybody
who
is
still
here
at
the
end
of
the
week.
This
is
the
note
well
which
you've
seen
all
week.
You
agree
to
this
when
you
register
for
the
IHF.
It's
the
set
of
rules
and
processes
that
govern
the
the
way
the
ITF
operates.
So
please
make
sure
you
are
familiar
with
it.
You
have
agreed
to
abide
by
it
and
if
you
have
any
questions,
feel
free
to
see
diatri
or
Eric
r.
A
A
d
also
I'd
like
to
remind
everybody
that
we
want
to
trying
to.
We
want
to
abide
by
the
code
of
conduct
and
basically
be
nice
to
everybody,
so
our
agenda
for
today
this
is
this-
is
the
agenda
for
today
it's
up
on
the
notes
pad.
A
If
somebody
a
little
bit
faster
on
the
link,
wants
to
stick
the
link
into
the
you
should
be
able
to
find
it
from
the
agenda
page
on
the
ietf.
You'll
see
which
one
is
the
notepad
or
somebody
could
stick
it
into
chat
for
folks
that
are
unfamiliar
with
that
particular
thing
feel
free
to
add
to
the
notes
as
we
go
that
will
be
turned
into
the
minutes
at
the
end.
So
with
that
are
there
any?
Is
there
any
agenda
bashing
any
comments
or
questions
nope?
A
Okay?
So
the
first
thing
is:
we
have
our
document
status
review,
update
page,
reminding
us
of
the
things
that
we
are
working
on.
The
first
thing
is
we
do
a
second
thing:
I
did
forget
I'm
sure
by
Friday.
Everybody
knows
this,
please
be
sure
to
scan
the
QR
code.
That's
what
we'll
use
to
manage
the
queue,
and
it
also
does
the
attendance
or
the
virtual
blue
sheets.
So
don't
forget
to
do
that.
A
We
do
have
a
new
RFC
RFC
9327,
which
is
the
control
messages
protocol
for
the
use
with
ntp
V4.
This
has
been
published
as
a
historic
RFC
in
the
category,
historic,
as
opposed
to
experimental,
informational
or
any
of
those
things.
So
a
special
thank
you
to
Brian
Haberman
and
to
Eric
for
a
great
deal
of
patience
in
getting
this
through
the
process.
We
have
three
more
documents
that
have
sort
of
passed,
the
working
group
and
into
at
fdiesg
in
various
stages.
A
The
first
one
is
the
interleave
modes,
which
we
believe
we're
basically
going
to
defer
to
V5,
but
we
wanted
to
discuss.
Did
you
want
to
talk
about
that
works
words?
Words
are
always
good.
D
Yes,
so
Eric
client,
the
interleave
modes,
we
brought
it
to
the
telechat,
it
got
One
Security
ad
abstained
and
some
other
people
were
very
operational.
People
were
very
concerned
about
the
safety.
My
proposal
was
that
if
we
wanted
to
continue
with
the
document,
we
should
I
think
the
why
this
is
safe.
Stuff
is,
is
spread
out
through
each
different
possible
mode
description,
and
it
might
be
worth
reiterating
all
of
that
in
a
one
common
section
before
that
that
says
look.
D
This
is
really
not
scary,
and
not
only
is
it
not
scary,
it's
actually
running
now
and
and
things
haven't
blown
up,
but
if
we
you
know,
we
could
do
that
and
then
I
can
bring
it
back
to
telechat
if
we
want
or
we
could
not
pursue
interleaved
modes
for
V4
anymore
and
just
leave
that
as
a
feature
to
be
baked
in
from
the
beginning
for
V5.
That's
whatever
the
the
authors
and
the
working
group
wants
to
do.
I
don't
know
so,
but
Lars
is
pinging
me
saying
hey:
why?
D
What
are
you
going
to
do
with
this?
So
it's
currently
in
some
limbo
State,
basically
between
maybe
we'll
do
something
with
it
and
maybe
we'll
abandon
it.
But
if
we
get
to
know
what
the
working
group
wants
to
do,
one
way
or
the
other.
A
Right
so
I
think
we
we,
we
basically
have
have
two
options.
One
would
be
to
send
it
back
to
the
working
group
and
then
to
update
it
with
the
additional
safety
information
in
a
more
concise
manner
like
you're
talking
about,
or
we
declared
a
dead
document
and
then
just
plan
to
work
on
it.
As
far
as
data
tracker
statuses
go,
those
are
our
two
options
right.
D
Well,
for
the
first
one,
bringing
you
back
to
the
working
group
is
an
option.
It
could
also
just
be
handled
by
the
author.
You
know
I
mean
it
depends
on
on
how
significant
we
think
it
is
if
it's
a
restating
of
text
that
already
exists
and
has
consensus,
then
we're
just
like
copying
that
and
putting
it
out
into
one
place
for
clarity.
I,
don't
think
that
has
to
come
back
to
the
working
group,
because
we
haven't
changed
anything
okay.
D
If
we
do
decide
to
dramatically
alter
something,
the
meaning
of
something
or
whatever
then
yeah,
we
would
probably
read
back
to
the
working
group,
but
I
think
it
can
be
treated
as
editorial.
Oh.
A
D
And
it
could
just
be
handled
by
the
author
and
just
reply
to
the
people
who
have
the
feedback.
At
this
point,
the
document
has
changed.
Telechat
has
changed
iesgs,
so
the
objections
were
from
some
previous
members
who
are
no
longer
on
the
ESG,
so
I
would
have
to
bring
it
back
to
telechat,
but
Miroslav
could
just
take
some
edits
and
we
could
bring
it
back.
Okay,.
A
E
Oh
hi,
yeah
I
think
at
that
time
this
was
discussed
last
time.
I
think
there
was
a
suggestion
to
try
to
change
it
to
an
informational
document
and
that
would
be
more
likely
to
be
accepted
by
isg.
D
I
I
think
some
I
mean
possibly
I,
don't
know
what
would
change
the
minds
of
of
everybody
who
still
holds
concerns.
I.
Think
the
main
concern
from
the
Ops
ads
was
that
they
they
did
not
believe
it
was
safe
to
do.
They
were
not
convinced
that
it
was
that
that
widespread
problems
would
would
not
happen
so
I
think
they
just
needed
some.
My
impression
or
my
recollection
is
that
they
just
needed
some
convincing.
They
needed
some
reassurance,
so
I
don't
know
that
changing
the
informational
is
required.
D
D
E
D
Okay,
that's
on
me,
then
I
will
take.
I
will
take
the
action
item
to
go,
review
the
diff
and
and
then
chase
down
people's
additional
re-reviews.
A
E
D
I
can
I
can
take
the
action
item
too
catch
up
on
all
the
threads
and
make
sure
that
everybody
has
seen
all
the
new
proposed
texts,
whether
it's
in
email
or
in
document
form
I'll.
Do
that.
D
Well,
take
another
run
at
it
and
and
see
what
happens
if.
D
A
So
that's
where
we
are
with
interleave
modes:
updating
the
ntp
Registries
has
been
submitted
and
is
in
the
process
of
being
reviewed
and
the
Enterprise
profile
has
been
submitted.
But
it's
still
lacking
a
Shepherd
right
up.
So.
D
I
think
the
tick
tock
doc
I
I,
reviewed
and
I
gave
some
comments
and
I'm
waiting
for
a
new
version
to
be
uploaded
which
possibly
I
missed
in
my
inbox,
but
yeah
yeah.
A
A
Soon,
as
we
get
a
new
version
on
it-
okay
great
so
this
one
so
updating
ntp,
Registries
is
waiting
on
Eric
to
double
check
and
Enterprise
profile
is
waiting
on
the
authors
to
submit
an
updated
draft.
A
So
that's
where
we
are
with
all
of
those.
The
next.
A
Set
of
topics-
these
are
all
things
that
we've
had
some
at
least
a
little
bit
of
discussion
on
since
the
last
meeting
for
Kronos
Netta
is
on
the
call.
This
has
a
past
working
group
last
call
and
all
of
the
comments
have
been
addressed,
and
the
latest
draft
address
is
the
last
of
the
typos
that
were
found.
Is
that
that's
correct,
right,
Neda.
B
Sorry,
yeah
I
I
fixed
the
type
of
that
Denmark
was
found
and
I
also
went
over.
A
I
think,
and
and
looking
at
the
slides
here,
I
realized
that
I
forgot
to
change
the
C
to
a
k.
A
So
for
those
who
who
are
who
are
following
this
work
at
a
distance,
the
name
got
changed
from
Kronos,
with
a
c
to
Kronos,
with
a
K
because
of
some
conflict
issues,
we're
not
going
to
change
the
file
name
itself,
but
it
will
be
changed
in
the
documents
and
in
the
title
with
that
Dieter
and
I
talked
earlier
this
week,
and
this
is
ready
to
go
to
the
isg
and
he
is
going
to
manage
the
shepherd
right
up
for
that.
A
F
A
Okay,
so
the
next
thing
we're
going
to
talk
about
is
ntpv5
on
a
number
of
topics.
The
first
thing
we're
going
to
talk
about
is
our.
We
did
have
a
small
hackathon
team
here
on
the
weekend
and
David's
going
to
talk
about
what
they
did.
B
Okay,
hello,
I'm
David
during
the
hackathon,
we
spend
a
bunch
of
time
on
entity,
particularly
next
slide.
Please
focusing
around
the
the
main
problem
questions
of.
B
Can
we
build
experimental,
interoperable
implementations
for
this
and
are
there
any
major
technical
gaps
in
the
draft
as
it
currently
stands?
B
The
results
we
have
next
slide.
Please
for
that,
are
there
is
now
two
experimental
implementations.
One
of
these
existed
already
before
the
weekend
continuous
labs
and
the
other
one
came
about
mostly
this
weekend,
we
verified
that
they
are
indeed
talking
happily
to
each
other.
They
seem
to
be
synchronizing
all
the
loop
detection,
algorithms,
which
is
the
main
part
of
what
we're
now
focusing
on
where
what
the
current
draft,
mostly
focused
on
initially
seems
to
be
functioning
correctly,
seems
to
be
reasonably
easy
to
implement
across
implementations.
B
So
we've
identified
a
few
minor
issues
in
the
ntpdrs
implementation.
These
have
since
been
fixed
and
a
few
more
have
been
found
since
the
hackathon
and
have
also
been
fixed.
So
if
you
were
using
it
for
whatever
reason,
there
are
updates
available
now
again
and
we've
also
had
We've
identified
a
few
minor
things
as
well.
B
Next
slide,
please
so
the
main
takeaways
we've
had
is
that
time
scale
offsets,
especially
for
ut1,
with
as
they
currently
stand
in
the
draft,
won't
fully
work
particularly
should
in
the
future.
It
ever
get
decided
that
UTC
moves
away
from
having
leap
seconds,
as
at
that
point
the
ut1
offset
would
be
larger
than
one
second
in
the
current
draft.
Just
assumes
it's
below
a
second
and
we've
identified
that
there
is
a
need
still
for
a
case
of
that
type
mechanism.
B
That
was
an
ntp
before
it
also
have
like
an
1955
and
that
we
need
to
start
adding
that
to
the
current
draft.
These
were
the
main
takeaways
next
slide
please.
So
these
were
the
people
who
were
involved
in
the
hackathon
and
a
short
list
of
links
for
all
of
the
main
things
that
were
touched
during
the
hackathon
for
those
interested.
Are
there
any
questions
about
anything
I've
said
so
far.
A
A
Okay,
I,
don't
I,
don't
see
James
in
the
meeting.
There
has
not
been
an
update
to
the
use
cases
and
requirements
document.
There
has
been
some
discussion
about
needing
some
more
detail
and
and
the
feeling
that
we're
not
quite
hitting
the
hard
issues
yet
and.
A
We
would
like
to
wrap
this
up.
I
was
sort
of
hoping
to
wrap
it
up
by
the
end
of
the
year.
I
think
we
probably
ought
to
Target
the
next
meeting
that
the
next
physical
meeting,
so
maybe
the
Yokohama
ietf.
If
we
could
Target
having
that
at
least
sent
to
the
iesg,
that
would
be
really
helpful.
Does
anybody
have
any
comments
on
the
use
cases
and
requirements?
Has
anybody
reviewed
it
recently.
B
Hi
David
again
there
there's
one
thing:
I
think
we
should
still
work
on
getting
a
little
bit
tighter
on
what
our
priorities
are
going
to
be
around
synchronization
performance
versus
security
in
the
in
the
protocol
in
the
requirements
document,
because
I
think
we're
going
to
at
some
point
have
to
make
trade-offs
in
in
that,
and
it
would
I
think
we
need
to
think
about
those
beforehand
before
we
start
getting
down
into
the
weeds.
But
are
there
any
thoughts
on
that
from
commercial?
In
particular,.
E
E
If
we
need
to
authenticate
everything
or
if
it's
acceptable
for
the
correction
field,
because
that
would
be
difficult
for
Implant
to
implement
in
the
networking
devices
too
re-authenticate
10
DB
message
if
it
was
modified.
So
there
is
a
question
if,
if
it's
acceptable
to
make
some
fields
outside
of
the
authenticated,
payload.
E
In
my
opinion,
I
think,
that's
okay,
because
the
impact
that
an
attacker,
a
man
in
the
middle
attacker
could
have
by
modifying
the
data
in
the
unauthenticated
part
of
the
message,
is
still
smaller
than
the
impact
that,
for
example,
the
delay
attack
has
basically
delaying
the
message
as
a
bigger
impact
on
the
measurement
of
the
client,
then
would
have
the
the
modification
in
the
unauthenticated
part
in
the
correction
field,
as
long
as
the
client
verifies
that
the
correction
is
not
larger
than
the
measured
delay
so
yeah.
B
Yeah
to
respond
to
that,
that
is
one
aspect.
I
think
we
should
consider,
but
also
in
general,
when
we
start
introducing
mandatory
signing,
which
is
one
of
the
things
the
the
requirements
now
pretty
much
hints
I
thought
we
should
do
you're
going
going
to
add
crypto
crypto
to
the
response.
B
The
request
response
path
at
the
server,
which
is
gonna,
inevitably
add
additional
resonance
time
on
the
server
side,
which
will
impact
some
of
the
uncertainty
in
these
algorithms
for
synchronizing,
everything
and
I.
Think
we
should
we
should.
We
should
be
thinking
about
what
what
Traders
are
we
willing
to
make
there
they're
there
as
well
as
in
do
do
we
find
that
an
acceptable
trade-off
and
and
how?
How
are
we
going
to
be
looking
at
that
moving
forward.
C
Foreign
open,
Fortress
I'm
very
happy
that
as
if,
if
the
cryptos
actually
made
very
strong
and
because
many
cryptographic
algorithms
base
they
really
heavily
on
time-
and
this
has
been
very
very
long-
been
a
problem
that
we
looked
away
from
it,
because
that
was
nothing
that
really
allowed
us
to
synchronize
with
cryptographical
strength.
It's
an
important
thing
to
have
proper
timing
and
to
be
sure
about
it.
So
please
don't
make
any
trade-offs
in
that
respect,
and
especially,
if
you
can
just
measure
the
signing
time
and
take
that
make
the
part
of
your
calculation.
A
Any
anything
else
on
this
topic
I
think,
given
the
I
think
what
we're
going
to
need
to
do
that
this
document
is
fairly
solid,
I'll
check
with
James
and
see
we
might
need
to
do
a
working
group
last
call
to
see
if
we
can
get
people
to
review
it
for
the
last
time
in
the
meantime
feel
free,
please
to
review
it
on
the
mailing
list.
That
would
be
great
all
right.
The
next
topic
is
the
ntp
V5
specification.
A
This
has
been
stable
for
quite
a
while,
and
we
now
have
two
interoperable
implementations.
It's
been
out
for
a
call
for
adoption.
I've
heard
no
opposition
to
the
fact
that
we
plan
to
adopt
this
document.
So
with
that
we
will
be
adopting
it
as
a
working
group
document.
Is
there
any
comments
or
questions
on
that.
A
A
The
next
item
was
a
discussion
of
time
scales
as
as
David
hinted,
there
was
some
discussion
of
this
at
the
hackathon,
so
I
think
it's
top
of
mind.
Go
ahead.
B
Ali
yeah,
so
after
having
a
couple
of
discussions
with
a
number
of
people,
I
started
to
realize
that
the
requirements
document
is
not
as
clear
as
the
opinion
some
individuals
might
have
as
to
which
approach
we're
going
to
take
for
time
skills.
Essentially
there's
from
from
what
I've
been
able
to
tell,
and
please
correct
me
if
I'm
wrong
on
this
mayor,
swath,
there's
there's
roughly
two
approaches
we
can
take
here.
We
can
say
that
all-time
stamps
included
in
in
ntp
exchanges
are
always
time
stamped
according
to
whatever
best
approximation.
B
A
server
has
of
one
specific
time-
skill,
for
example,
Thai
or,
for
example,
UTC,
and
then
we
provide
sufficient
information
in
addition
to
those
timestamps
to
be
able
to
get
to
whatever
time
scale
an
end
user
might
want
to
use
depending
on
what
asks
for
or
there's
the
approach.
And
this
is
the
approach,
that's
as
I
understand
it
is
currently
in
the
draft.
Is
we
leave
these
timestamps
essentially
leave
it
open,
which
time
scale
that
is
on
the
protocol
packet
of
course
specifies
this.
B
But
there's
not
all
ntp5
package
used
this
time
scale
for
their
for
the
timestamps
and
then
optionally.
On
top
of
that,
provide
the
mechanism
for
exchange
of
information
on
how
to
translate
between
these
different
time
skills,
I
I
think
we
should
have
the
discussion
which
of
these
we
prefer.
Perhaps
that
is
a
discussion
for
the
mailing
list
I'm,
but
I
I
think
we
need
to
explore
what
the
advantages
and
disadvantages
of
each
of
these
approaches
are
because
I
don't
have
a
full
feeling
for
which
option
we
should
choose.
A
E
Add
that
my
focus
was
on
to
allowing
the
server
to
have
a
preferred
time
scale,
because
you
know
in
the
basic
mode.
The
time
critical
part
is
between
capturing
the
timestamp
from
the
clock
that
the
server
is
using
and
putting
that
in
to
the
message.
So
the
idea
was
that
the
server
could
have
a
preferred
time
scale
which
could
use
for
the
transmit
timestamp
and
for
the
other
timestamps,
because
it's
simpler
to
specify
it
and
implement
it.
A
Any
thoughts
on
this
topic
from
anybody
else,
anybody
else
online
I
know
1588,
has
done
a
fair
amount
of
work.
Looking
at
Alternatives
time
time
scales
as
well,
so
we
should
probably
make
it
take
a
look
at
what
they're
doing
to
make
sure
that
anything
we
do
would
at
least
be
aligned
somewhat
with
what
they're
doing,
because
a
lot
of
ntp
and
PTP
systems
need
to
coexist.
A
Okay,
so
that
brings
us
to
the
end
of
our
ntpv5
list
of
topics.
The
next
agenda
item
is
rough
time.
The
last
update
of
the
I
just
lost
my
data,
try
others.
The
last
update
of
the
rough
time
document
was
at
the
end
of
September
I
know:
Marcus
had
planned
to
have
a
during
the
hackathon.
He
had
planned
to
have
a
virtual
hackathon
effort.
A
There
were
a
number
of
parties
that
had
indicated
interest,
but
they
were
all
going
to
be
remote
participants
and
at
the
end
of
it
we
actually
ended
up
with
none
of
them,
except
for
Marcus,
coming
Christopher
from
net
node
was
here
and
was
working
on
it
a
little
bit
as
well,
but
he
ended
up
focusing
primarily
on
ntpb5,
so
we
didn't
have
much
activity
during
the
hackathon
on
rough
time
and
the
authors
of
the
document
are
not
here
so
I
think
about
the
only
thing
that
we
can
do
is
ask
for
some
additional
comments
and
review
on
the
list.
A
A
The
other
thing
was.
Is
that
the
just
as
a
comment,
the
rough
time
ecosystem
document
has
expired?
So
is
there
anybody
here
who
wishes
to
speak
to
rough
time.
F
Hi
there
yeah
we're
quite
interested
in
rough
time
at
Google
and
actually
we've
we've
just
been
going
over
the
draft.
There's
a
there's,
a
group
of
us
who
are
planning
to
do
some
work
on
it.
We've
gone
over
the
draft.
F
We
got
pilot
comments
which
we
will
a
small
pile
of
comments
which
we'll
post
to
the
mailing
list
next
week
sometime
and
we
are
planning
to
do
an
implementation
of
some
future
ID
when
it's
in
the
shape,
we're
happy
with
we're
planning
to
use
it
as
part
of
our
work
on
supply
chain
security
stuff
in
general.
A
Oh
thank
you
good
to
know
so
with
that.
We'll
look
forward
to
the
Google
comments
coming
on
the
mailing
list
and
if
anybody
else
could
please
review
the
document
and
put
some
comments
on
the
mailing
list.
That
would
be
very
helpful
anything
else.
On
rough
time.
A
A
A
A
And
the
oh,
that's
funny,
there's
an
edit
a
a
copy
and
paste
error
on
my
slide,
so
ignore
everything
after
NTS
over
PTP
they
might
look
suspiciously
familiar
as
the
items
that
were
under
the
document
update
slide
three
slides
ago,
so
the
NTS
over
PTP
effort.
There
is
still
interest
in
doing
it.
The
primary
author
was
doing
some
collaboration
with
an
industry
partner
and
they
have
not
gotten
that
update
done
yet.
A
A
Okay,
so
we
have
any
other
business
and
Way
Forward
at
this
stage,
the
any
other
business
does
anybody
have
any
other
business
that
they'd
like
to
bring.
C
D
Yeah,
sorry,
if
this
is
like
an
aob
moment,
I
just
wanted
to
say
two
thank
yous
one,
thank
you
to
everybody
who
helped
me
close
out
all
of
the
open
erata.
That
was
super
helpful
and
very
much
appreciated,
and
to
thank
you
to
everyone
who
did
some
very
nice
hackathon
work
that
will
be
good
to
show
in
the
shepherd
write-up
that
there
are
interoperable
implementations.
A
Okay,
as
I
mentioned
earlier,
the
attorney
I
met
earlier
this
week
and
and
we're
discussing
ways
to
keep
us
moving
forward
on
a
more
steady,
Pace,
I
think
for
the
ntp
working
group
in
particular.
Sometimes
the
virtual
interims
are
a
little
bit
more
effective
just
because
of
the
the
they're
more
effective
in
keeping
us
moving.
So
we
do
plan
to
have
some
virtual
interims
we're
currently
planning
three
between
now
and
the
next
ietf.
A
Those
are
our
tentative
dates.
This
will
be
in
the
minutes.
If
anybody
has
any
strong
objections
to
any
of
these
dates,
so
please
feel
free
to
speak
up.
It's
it's
roughly
a
month,
or
every
month
or
five
weeks
between
now
and
the
March
ietf
meeting
the
March
ietf
meeting
is
in
Yokohama.
A
We
will
be
thinking
about
what
we
can
do
in
the
context
of
a
hackathon
I.
Think
the
lesson
we
learned
with
NTS
and
that
we
are
relearning
with
ntpv5.
Is
it
really
helps
to
focus
the
work
and
move
it
forward
if
we
can
have
a
little
bit
of
hackathon
activity
on
the
pro
protocol
as
we're
moving
forward
so
we'll
be
needing
to
figure
out
who,
from
the
ntp
community
might
actually
be
able
to
participate
in
Yokohama
or
be
willing
to
participate
remotely
on
hackathon
activity
during
Yokohama
working
hours?
A
So
keep
an
eye
out
for
that?
The
other
thing
that
we
have
talked
about
doing
is
I
think
we
have.
You
know
we're
a
little
bit.
A
You
know
a
couple
years
into
the
deployment
of
NTS
and
we're
beginning
to
see
some
deployment
reports
and
experimental
results
that
we
would
like
to
talk
about
and
see
how
that's
going
and
what
lessons
it
might
teach
us
going
forward,
and
so
we
are
planning
to
have
a
discussion
specifically
focused
on
the
deployment
status
of
NTS
to
see
if
we
can
get
some
idea
of
who
who's
using
it
and
how
they're
using
it,
what
kinds
of
results
they're
looking
at
and
so
I
I.
A
Think,
since
this
is
such
a
new
protocol,
it
would
be
really
helpful
to
get
some
perspectives
on
that
and
with
that
is
there
any
other
anything
else.
People
want
to
bring
to
the
floor.
A
So,
with
that
I'm
going
to
close
the
ntp
working
group
meeting
for
ietf
115.,
everybody
have
a
safe
trip
home
and
hopefully
we
will
see
you
virtually
and
in
person
in
the
future.
A
B
B
The
first
one
that's
reasonable
post
for
me
so
that
one's
definitely
doable.