►
From YouTube: IETF96-NTP_TICTOC-20160718-1800
Description
NTP TICTOC meeting session at IETF96
2016/07/18 1800
A
E
C
C
C
Yes,
oh
well,
I'm
sorry,
I'm
reading
jabber.
At
the
same
time,
that's
always
dangerous,
but
anyway,
so
don't
forget
to
get
in
the
queue.
If
you
want
to
be
in
the
queue
in
your
remote
and
if
you
have
allowed
me
dekho
to
have
access
to
your
microphone,
you
can
speak
like
you
would
normally
blue
sheets
going
around.
Everybody
needs
to
sign
that
the
next
thing
I
need
would
be
a
minute
taker
and
a
jabber
scribe.
Jabbers,
pretty
lightweight
for
us.
Does
anybody
mind
doing
that?
C
Tal
you'll?
Do
then?
Okay
do
I
have
any
minute
taker
volunteers
going
once
going
twice
all
right.
My
guess
we'll
have
to
do
it
from
the
recording.
That's
always
fun
all
right!
So
well,
that's
it!
So,
as
you
all
will
have
already
figured
out,
we
have
a
little
bit
of
a
kludgy
schedule
this
week,
because
I
apparently
did
not
hit
the
final
submit
button
and
therefore
we
did
not
have
a
session
requested.
So
what
we
have
done
this
week
is
we've
divided
our
work
into
three
portions.
C
We
had
a
ad
hoc
working
meeting
of
the
ntp
working
group,
primarily
to
discuss
and
NTS
and
vcp
earlier
today.
Let
me
take
me
back
up
for
just
a
second
go
ahead
to
the
next
slide.
The
note
well
I
forgot
the
note.
Well,
this
is
the
ietf
note.
Well,
everybody
is
aware
of
this.
You
click
the
button
when
you
register
for
the
meeting.
If
you
have
any
questions,
be
sure
to
see
me
next
slide.
C
So
our
meeting
this
week
is
divided
into
three
portions.
We
have
the
working
session
we
had
earlier
today,
primarily
on
NTS
and
the
bcp.
We
have
this
meeting,
which
is
going
to
be
a
little
bit
higher
level
discussion
of
all
of
that
and
talk
about
next
steps,
and
then
we
will
get
through
all
of
the
primary
points
today
and
then
on.
Friday
we're
going
to
have
a
meeting,
that's
primarily
going
to
discuss
the
15,
the
tick-tock
work
in
the
1588
mibbe,
the
yang
module
and
the
scalable
synchronization
stuff,
and
the
primary
reason
for
that
is.
G
C
C
Yeah
you're
still
on
the
right
side,
so
I'm
going
to
go
through
these
really
quickly
and
then
I'm
going
to
come
back
to
ditch
or
to
talk
more
about
the
NTS
work.
So
we
have
several
things
on
our
plate
right
now
we
have
the
network
time
security
work.
As
you
all
are
aware,
we
had
a
working
group
last
call
in
the
March
timeframe.
We
just
we
established
after
the
Buenos
Aires
meeting.
We
established
a
design
team,
that's
been
working
on
that
and
they
have
making
some
progress
and
there's
more
progress
yet
to
be
made.
C
A
H
Yes,
I'm
speaking
I'm
here
to
report
on
the
progress
of
me
and
he
has
documents
Karen
already
mentioned.
There
has
been
no
progress
on
the
actual
documents
we've
been
busy
on
the
next
slide.
Please,
with
the
design
team
to
process
the
tons
of
feedback
that
we
actually
received
in
the
last
call
and
yeah.
That
means
they
just
talk
about
what
we
discussed
in
the
design
again
next
slide.
H
Please
please,
okay,
the
main
issue:
there's
there
are
some
items
on
the
agenda
for
the
design
team,
but
the
main
issue
that
needs
to
be
solved
first.
Is
that
the
way
we
wanted
to
do
things
initially
in
the
NTS
drafts
and
I
think
it's
still
in
there
with
a
custom
key
exchange
protocol
that
was
just
wrapped
into
extension.
H
Fields
of
ntp
packets
did
not
work
out
because
we
needed
to
transport
actually
change
of
goods,
which
was
which
was
so
large
that
that
would
cause
IP
fragmentation
and
generally
large
size
of
the
NDP
packet
switches,
which
is
also
generally
a
problem
yeah.
We
would
get
problems
with
NAT
devices
with
the
IP
fragmentation.
We
might
get
the
problem
that
the
resulting
ntp
packet
would
be
rejected
by
a
client
or
server
just
because
of
its
size,
on
even
after
the
fragmentation
had
been
reverted
and
also
IP.
H
Fragmentation
has
some
negative
implications
on
the
protocol
security,
and
so
we
went
ahead.
Considering
alternatives
on
the
first
alternative
would
actually
be
to
just
still
run
the
NTS
custom
key
exchange
protocol
over
extension
fields,
as
originally
planned,
but
with
some
mechanism
to
do
the
fragmentation
so
that
it
doesn't
have
to
be
done
on
an
IP
level.
This
would
be
tons
and
tons
of
work,
and
so
we
yeah
are
strongly
considering
other
alternatives.
H
Something
that
has
also
been
on
the
table
at
times
was
to
just
run
the
custom
key
exchange
protocol,
not
over
extension
fields
of
ntp,
packets,
but
just
externally
over,
for
example,
an
additional
tcp
channel,
which
still
doesn't
solve
the
fact
that
we've
been
advised
that
IP
fragmentation
is
bad
on
a
security
level
and
might
also
not
solve
other
problems
mm-hmm.
What
we
are
leaning
currently
towards
is
doing
at
least
the
key
exchange
for
the
network
time
security
protocol
by
our
dtls
in
some
way
I'm.
H
Despite
either
be
done
by
are
just
on
DTLS
packets
on
some
UDP
channel
that
might
or
might
not
be
on
UDP
port
123.
In
any
case,
we
would
always
secure
by
the
way,
I'm
always
secure
the
actual
time,
synchronization
exchanges
by
just
a
Mac
on
in
an
extension
field
on
regular
ntp,
packets,
and
this
would
be
done
over
UDP
123
and
the
last
alternative
that
I
haven't
described
is
that
we
might
also
do
DTRS
pretty
over
the
channel
that
is
represented
by
extension
fields
of
actual
ntp
packets.
H
So
this
would
go
back
to
a
UDP
123
next
slide.
Please
also
an
issue
that
is
related
to
this
heavily
is
that
we
somehow
might
or
might
not
want
to
deal
with
the
usual
ntp
rate,
bandwidth
or
packet
rate
limitations,
because
on
the
one
hand
there
might
be
on
suppliers
that
just
enforce
these
limitations
on
levels
that
are
not
the
actual
ntp
software.
H
So
out
of
the
control
of
the
ntp
software
and
also
we
have
a
requirement
somewhere
in
the
nds
main
document
that
says
that
NTS,
secure
traffic
must
not
negatively
interfere
with
non-secured
time.
Synchronization
traffic,
in
this
case
ntp
traffic,
and
so
it's
also
debatable
whether
on
whether
or
not
pushing
the
right
limitation
levels
with
key
exchange
packets,
some
might
fall
in
that
category
in
my
tent
enter
that
requirement,
so
the
accountants
are
pretty
much.
H
We
could
run
whatever
it
is
that
we're
going
to
run
over
UDP
123,
and
in
that
case
we
have
to
post
the
question:
do
we
respect
the
usual
rate
limitations?
Or
do
we
not?
If
we
do
not,
then
the
whole
key
exchange
setup,
it
might
be
more,
might
become
very
slow,
which
is
something
to
keep
in
mind,
but
this
would
also
represent
kind
of
maximum
compatibility,
and
then
the
other
big
option
is
to
not
run
over
UDP
123
and
just.
H
Ok
next
slide.
Please!
Here
we
have
Alice
issues
that
need
to
be
decided
pretty
much,
no
matter
what
k
exchange
mechanism
we
go
for
specifically
on
and
the
first
one
is,
and
we've
talked
about
some
of
these
in
the
side
meeting
three
a
few
hours
ago.
The
first
one
of
these
is
what
is
to
be
done
with
unauthenticated
time
stems
that
we
might
get
as
kind
of
a
side
effect
of
key
exchange,
because
we
do
the
key
exchange
mechanism
over
actual
ntp,
packets
and
I.
H
The
same
discussion
pretty
much
on
is
to
be
had
about
authorization,
both
server
and
client
authorization.
Mostly
kind
authorization,
is
just
a.
Is
it
healthy
to
postpone
this
issue
and
have
a
document
out
that
doesn't
deal
with
it
yet
and
we're
kind
of
leaning
towards
yes,
that
is
healthy
for
both
these
things
and
also
the
NTP
broadcast
mode.
H
Okay,
next
slide,
please.
This
is
just
a
list
of
bullet
points
that
are
on
the
agenda
for
the
design
team,
but
there
are
pretty
much
I'm
falling
from
relevance,
because
these
are
only
relevant
if
we
choose
to
go
for
the
NTS
custom,
key
exchange
and
since
we're
leaning
towards
at
least
not
soothing.
Choosing
that
for
the
mandatory
to
implement
key
exchange
algorithm,
these
can
helpfully
be
postponed
or
not
thought
about
for
now.
H
Okay,
next
slide,
please
other
things
that
need
to
be
done
is
first
off
the
handling
of
cipher
suites
as
it
is
in
the
documents
currently
is
not
written
very
well,
and
this
needs
to
be
improved
upon.
We
have
dropped
from
an
charm
that
might
help
with
dealing
with
this
issue
and
something
that
has
already
been
done,
and
this
was
in
the
context
of
the
working
group
last
office,
actually
I.
H
Something
else
that
was
discussed
was
where,
where
to
put,
and
how
much
text
to
put
in
the
documents
about
the
chicken
neck
problem,
which
is
to
say
that
the
security
mechanisms
need
some
sense
of
timing
and
then
the
timing
on
these
security
mechanisms
to
be
reliable
and
the
consensus
that
we
have
hovering
right
now
is
that
we
need
enough
text
to
clearly
specify
what
NTS
needs
a
requirement
on.
But
the
actual
deeper
discussion
on
this
should
not
be
anywhere
in
the
NTS
documents
they
might,
it
might
go
into.
H
H
We
just
feel
that
it
doesn't
really
belong
in
the
NTS
documents,
and
then
we
have
also
one
issue
the
issue
of
symmetry
of
the
message
sizes
in
the
actual
time,
synchronization
exchange
from
where
it
was
discussed,
whether
it's
it
might
be
relevant
that,
on
the
request
and
response
message
are
of
the
same
size.
Just
to
increase
the
symmetry
in
the
communication,
we
do
not
yet
have
any
kind
of
consensus
on
the
site.
It
hasn't
been
discussed
much
as
far
as
I.
Remember
next
slide,
please,
okay!
What's
to
be
done
next.
H
We
then
need
to
figure
out
what
to
do
or
if
to
do
anything
about
the
pier
mode
and
it
to
specify
the
question
about
the
unauthenticated
timing.
Information.
If
the
question
posed
a
pisser
itself
due
to
the
phase
change
mechanism
like
if
we
have
these
unauthenticated
timestamps
flying
around
oh
and
the
course
of
key
exchange,
and
then
we
should
see
that
we
bet
and
how
we
include
the
work
in
the
announcers
draft
into
our
specification
and
use
this
next
slide,
please.
H
So
this
is
pretty
much
poses
the
question
of
how
to
go
about
publication
of
the
these
documents.
We,
the
next
thing
that's
going
to
happen,
is
we
need
to
get
a
new
version
out
for
the
NTS
20p
draft
and
we
need
to
have
another
working
group.
Last
call
don't
still
says
right
after
the
next
face-to-face
meeting
karen
has
hinted
at,
but
she
wants
to
want
it
to
be
sooner.
H
One
issue
that
we
still
have
remaining
is
that,
even
if
we
postpone
stuff
from
the
NTS
front
EP
draft,
we
also
have
the
generic
NTS
draft,
and
this
needs
to
contain
material
about
at
least
the
broadcast
month.
That's
that's
the
issue
specifically
I
feel,
and
so,
even
if
we,
if
we
push
that
out
of
the
NTS
20p
draft,
the
NTS
20p
draft
requires
that
the
anti-aircraft
be
published,
and
so
we
have
to
figure
out
what
to
do
with
it.
H
And
we
feel
that
in
the
course
of
the
working
group
last
call
while
we
got
a
lot
of
feedback,
we
did
not
get
concrete
feedback
about
the
quality
of
the
specification
with
the
broadcast
mode,
and
then
it
might
be
possibly
have
a
third
document.
The
CMS
for
NTS.
This
is
largely
used
for
a
would
largely
be
used
for
the
unaccustomed
key
exchange
protocol.
So
huge
amounts
of
what's
in
there
are
not
relevant
anymore.
H
If
we
don't
use
that
as
the
mandatory
mechanism
and
what
is
the
relevant
could
be
just
taken
into
the
other
documents,
so
it
might
be
possible
to
to
drop
this
or
drop
the
publication
process
for
this
document,
at
least
depending
on
what
we
choose
as
the
key
mechanism.
Okay,
do
we
have
a
next
time?
No,
and
that's
it
and
I'm
open
for
questions
and
discussion.
C
Okay,
so
just
a
couple
points
before
we
open
the
floor
for
general
questions
based
on
the
the
side
meeting
we
had
earlier
today,
we
sort
of
have
a
couple
of
of
next
steps,
and
one
of
them
is
Daniel
is
working
on
a
draft
for
us
and
and
then
we
will
have
I'm,
assuming
you
know,
continuing
calls.
That's
some
interval
figure.
C
And
I'll
talk
about
this
a
little
bit
later
when
we
get
to
a
specific
scheduling.
But
we've
also
talked
about
the
concept
of
having
a
face-to-face
interim,
specifically
in
the
probably
in
the
Boston
area,
in
either
in
september-october.
We're
going
to
put
some
dates
out
on
the
mailing
list
it
to
see
what
what
might
actually
work.
C
So
obviously
we
only
have
a
one
hour
slot
now
and
so
I.
Don't
know
how
much,
how
much
of
the
detailed
questions
that
we
want
want
to
get
into
a
few
very
few,
but
you
get
an
idea
of
the
of
the
the
status
of
the
work.
So
are
there
any
questions
about
status
or
approach
or
anything
like
that?
Any
remote
questions,
nope,
okay,
the
one
other
thing
that
I
did
want
to
point
out
is,
if
you
go
to
the.
C
If
you
go
to
tools,
ITF
torg
go
to
the
NTP
wiki
at
the
top
of
the
wiki
you'll,
see
a
link
for
the
the
NTS
working
group
last
call
design
team
and
we're
doing
a
fairly
decent
job,
or
they
are
doing
a
fairly
decent
job
of
keeping
rough
summaries
of
where
they
are
and
there's
also
a
link
to
a
Google
document
there.
That
has
some
of
these
issues
articulated
a
little
bit
further.
So
any
the
questions
about
that
nope
fabulous.
E
Hi
there,
everybody
so
I,
don't
have
any
slides
to
show
right
now,
but
I'll
just
go
over
the
current
status
of
the
bcp
document.
It's
currently
up
on
the
data
tracker
as
draft
riley
ntp,
ecp
02,
that's
a
bit
of
my
fault,
because
I
didn't
understand
how
items
get
promoted,
so
I
will
be
resubmitting
it
sometime
this
week
as
draft
IETF
ntp
bcp
and
the
draft
has
been
reviewed
by
a
few
people.
Now
it
has
some
good
information
in
it.
More
review
is
always
welcome.
E
So
if
you
have
the
time
to
review
it,
either
in
its
current
form
or
once
it
gets
uploaded
as
an
ietf
document,
if
you
could
send
me
your
input
either
directly
or
on
the
mailing
list,
I
appreciate
it
right
now.
There
are
a
few
areas,
other
than
just
general
editing
and
making
sure
all
the
links
work.
E
There
are
a
few
areas
that
we're
looking
to
improve
before
we
move
it
forward.
One
is
in
the
security
considerations.
The
current
track
has
nothing
there.
It
just
has
a
TBD
I
intend
to
supply
something
this
week,
just
some
general
text
about
how
important
time
is
to
security.
To
again
with,
and
then
also
the
highlighting
the
parts,
the
vcp
that
deal
directly
with
security
so
that
that
will
be
there
in
the
coming
week
or
so
on.
E
The
document
in
its
current
form,
make
the
modifications
to
those
two
sections
that
I
mentioned
clean
up
the
rest
of
the
test
for
text
for
any
stray
links
that
might
be
might
be
there
and
we'll
have
a
target
to
consider
moving
it
forward
on
toward
workgroup
last
call
at
the
next
interim
meeting,
which
would
likely
be
in
about
a
month.
So
you
should
expect
to
see
some
activity
on
that
document
over
the
coming
weeks.
E
C
You,
let's
go
back
to
my
slides,
so
the
next
set
of
documents
are
a
set
that
I'm
going
to
defer
to
the
next
virtual
interim,
but
I
did
want
to
highlight
them
just
a
tiny
bit.
We
have.
We
have
an
ongoing
discussion
about
extension
fields
and
we
have
an
ongoing
discussion
discussion
about
the
ref
ID
documents.
I
I
I
I
Okay,
no,
I
mean
they're
out
there
there's
a
number
of
extension
that
the
extension
field
draft
that
Danny
and
I
are
working
on,
has
to
do
with
exact
goes
to
some
mechanism
around
what
is
a
ref.
What
is
an
extension
field
there?
There
are
also
out
there
drafts
on
some
ref
ID
proposals
and
there's
a
number
of
other
extension
field
proposals
that
are
out
there,
so
they've
been
up
for
a
while
I
haven't
had
much
feedback
on
them.
I
C
C
C
Think
one
of
the
things
that
we
need
to
look
at
is
we
for
the
people
that
are
reviewing
the
extension
field
stuff.
We
need
to
review
the
RFC
that
was
recently
done
in
the
context
of
these.
So
if
you
have
an
interest
in
that
particular
draft,
you
might
want
to
volunteer
to
review
that
draft
those
set
of
drafts-
okay,
I'm
trying
not
to
name
names,
but
so
anyway.
C
To
move
those
forward
and
get
that
that
that
set
of
issues
addressed,
if
not
the
concept
of
doing
a
face-to-face
interim
to
deal
specifically
with
MTX,
will
probably
expand
to
deal
with
NTS
and
this
this
set
of
of
drafts
when
we
get
all
the
key
players
in
the
same
place.
Any
other
questions
or
comments
on
this
topic.
C
C
But
before
so
I
had
asked
Brian
to
do
a
a
draft
on
the
we've
had
for
a
long
time
on
our
list
of
to
do's
documenting
a
piece
that
got
left
out
of
RSC
1305.
When
we
did
the
update
to
ntp
and
it
had
to
do
with
the
mode
six
messages.
We
actually
had
a
conversation
earlier
in
the
in
our
side
meeting
about
whether
it
makes
sense
to
proceed
with
this
or
not,
and
there
was
some
feeling
that
it's
basically
a
management
tool
and
that
by.
C
That
we
don't
really
want
to
be
encouraging
people
to
use
it
any
way.
We
want
it
to
be
encouraging
them
to
use
standard
management
protocols
instead
of
using
something
like
this
and
so
especially
with
Harlan,
remote
and
Brian
sitting.
Here
we
can
bet
we'll
we'll
double-check
this
on
the
mailing
list,
but
sort
of
the
consensus
was:
maybe
we
don't
need
this
after
all,
and
maybe
we
would.
C
C
I
K
Hollander
this
is
haiku
I
I.
Basically,
my
opinion
with
this
is
that
we
don't
have
to
drop
it
entirely,
but
I
don't
see
a
requirement
for
creating
an
RFC
for
this.
Basically,
because
we
are
trying
to
standardize
a
management
protocol
for
this
one
single
specific,
let's
say
application
space
for
MTP
and
it's
in
my
view.
If
we
want
to
standardize
the
management,
monitoring
and
configuration
possibilities
of
an
NTP
service
instance,
we
should,
if
we
really
want
to
do
that,
we
should
do
that
with
one
of
the
existing
standard
protocols.
K
I
I,
don't
want
to
depreciate
mode
six,
packets
or
anything,
but
I.
Don't
I.
Just
don't
think
that
it's
a
lot
of
it's
a
very
high
priority
to
standardize
this
way
of
managing
ntp
server.
It's
it's
probably
the
reference
implementation
is
the
only
implementation
using
it
and
that's
fine
and
there
will
always
be
a
inclement,
ation,
specific
ways
of
monitoring
and
management.
K
I
If
I
may,
if
you
want
an
implementation
specific
way
to
do
that,
we
have
it
it's
called
mode
7
mode.
6
is
an
implementation
independent
way
to
perform
ntp
monitoring.
That
requires
no
additional
mechanism
so
again
until
there's
a
working
alternative,
I'm
opposed
to
getting
rid
of
the
contents
of
mud.
Six.
J
L
Okay,
so
Brian
Hammerman.
So
first
in
response
to
what
Harlan
said
it
wasn't
an
oversight.
We
actually
made
a
conscious
decision
to
leave
him
out.
I
can't
remember
the
reasons
for
it,
but
there
are
probably
good
ones,
but
I
actually
want
to
respond.
Probably
somewhat
to
the
question
the
towel
just
read,
relayed,
but
also
what
heiko
just
said.
L
So
people
don't
know
where
to
find
about
six
commands
because
5905
actually
obsoletes
1305,
which,
which
is
where
they
were
defined.
So
people
don't
think
to
go
back
and
look
so
there's
a
couple
of
options,
one
which
is
what
you
just
said,
and
just
let
people
try
and
find
him
if
they
really
really
want
them
which
I
you
know.
L
If
the
work
group
wants
to
do
that,
then
why
we
could
go
the
router
just
publishing
an
informational
RFC
that
says
here's
what
the
reference
deployment
ation
does
and
we're
done,
or
if
you
really
want
to
be
correct
in
the
status
of
this.
In
order
to
have
to
represent
what
what
you
just
said,
we
publish
the
RFC,
but
we
publish
it
immediately
as
historic.
L
K
I
mean
I
I,
don't
think
that
documenting
a
certain
specific,
let's
say
feature
or
functionality,
often,
implementation
is
subject
to
an
RFC
I
mean
I
would
see
that
an
RFC
is
basically
trying
to
standardize.
Oh
the
way,
how
other
implementations
and
all
implementations,
basically,
who
are,
who
claim
to
be
our
c
compliant,
should
deal
with
that,
and
my
point
is
that,
as
you
say,
this
is
a
historic
thing,
so
so
I
I'm,
probably
in
favor,
of
either
publishing
it
as
an
informational
RFC
as
an
historic
RFC.
K
L
In
general,
I
agree
with
your
initial
premise
that
you
know:
there's
really
no
reason
to
publish
something.
That's
implementation-specific,
however,
because
1305
does
document
ntp
and
includes
the
mode
six
people
are
going
to
look
for
it
in
some
some
fashion,
so
yeah
it.
From
my
perspective.
It
doesn't
matter,
I
mean
if
the
working
group
wants
to
do
one
way
or
the
other
I'm
perfectly
fine
with
it,
because
it's
no
skin
off
of
my
back
I.
I
Will
point
out,
if
I
may,
that
one
of
the
reasons
they
have
mode
6
is
to
allow
monitoring
of
ntp
and
by
built
keeping
it
as
part
of
the
protocol?
It's
a
very
lightweight
mechanism
that
can
be
very
useful
while
the
system
is
coming
up
or
in
the
face
of
other
issues,
if
you're
going
to
say
we're
not
going
to
give
you
this
mechanism,
unless
you
know,
in
order
to
provide
monitoring
of
ntp,
you're
going
to
uses
other
mechanism
you're,
adding
complexity
to
the
system
even
during
times
of
startup
and
I,
think
that
is
short-sighted.
G
Suresh
krisshnan,
so
I
I
kind
of
disagree
with
like
huggers
characterization
of
this,
like
I,
think
it's
okay
to
publish
something
is
historic,
right
leg,
even
if
so,
if
it's
just
one
implementation,
probably
not,
but
if
it's
more
than
one
like
it
probably
makes
sense.
Just
document
like
what's
in
there
and
like
Brian,
said
it's
like
something
that
was
taken
off
right
and
if
it
causes
confusion
like
for
somebody.
G
Looking
like
it's
same
thing
happened
in
v6
right
like
we
took
out
em
and
like
obits
from
the
specification,
and
it
kept
coming
up
for
like
ten
years.
People
say
like
what
do
they
mean?
What
do
they
mean
and
we
still
haven't
put
it
back,
but
people
just
say
like:
oh
the
previous
version
had
it.
This
version
doesn't
so,
and
so,
if
that
question
goes
away,
if
people
are
actually
asking
the
question,
then
it
makes
sense
to
publish
like
even
ss-sorry
so.
J
M
Just
to
add,
from
the
security
point
of
view,
I
would
recommend
documenting
all
these
mod
six
information,
because
we
find
out
that
there
are
several
probably
firewalls
who
are
dropping
some
of
the
mod
six
mode.
7
queries
from
security
point
of
perspective,
but
since
all
the
mood
6
queries
are
not
documented,
they
don't
really
know
which
ones
exist
and
we
have
actually
found
a
file
found
out
so
many
mode,
six
queries
which
make
your
clients
vulnerable
to
Billy,
unnecessary
information,
and
then
that
could
be
exploited.
M
C
M
C
N
Maggie
deep
dive
networking
just
after
a
quick
sidebar,
it
does
seem
like
with
the
consensus
of
making
the
recommendation
that
we
don't
suggest
you
use
it
for
all
those
reasons
that
that
would
fit
nicely
and
bcp
if
we're
going
to
make
best
a
best
practices
document
we're
recommending
in
best
practice.
So
maybe
we
could
move
that
to
there
and
then
make
the
decision
about
whether
we
documented
as
historic
or
not
for
the
just
that
subject,
but
it
should
maybe
be
added
to
be
CP
because
it
certainly
as
a
recommendation.
C
C
O
L
C
O
C
That
was
at
least
a
minute
ago,
so
so
Brian
I
like
then
it
sounds
to
me,
like
there's,
there's
rough
consensus
to
move
forward
with
this
document.
As
we've
discussed,
can
you
so
first
of
all,
I
need
the
Harlin's,
since
you
are
one
of
the
strong
proponents
of
having
this
documented
I'd
like
to
be
sure
that
the
NT
f
folks
definitely
review
what's
there
and
make
sure
that
it's
just
a
good
document.
C
I
will-
and
I
will
send
a
question
about
adopting
the
document
as
a
working,
your
document
to
the
mailing
list
and
then
Brian
will
submit
it
with
the
right
name.
Okay
with
that
yep.
Thank
you,
Brian,
okay,
so
back
to
the
so
I
think
the
okay
so
on
to
the
next
slide,
and
so
we're
going
to
move
quickly
through
this.
C
So,
as
I
said,
we're
talking
about
doing
some
sort
of
an
ntp
face-to-face
interim
in
the
Boston
area,
primarily
focused
on
NTS,
but
also
looking
to
resolve
some
of
the
other
issues
and
I
have
some
some
some
rough
schedule
stuff
going
forward.
I'm
going
to
leave
Christoph
to
continue
to
you
can
figure
out
the
schedule
for
the
NTS
working
group
last
call
design
team
meetings
going
forward.
So
so
that's
we're
not
going
to
discuss
that
here.
We
will
have
probably
three
interims
between
now
and
soul.
C
C
You
know
rough
weeks
there
I'll
send
that
out
on
the
mailing
list
to
get
some
feedback
and
then
I'm
looking
at
turning
one
of
those
virtuals
into
a
potential
full
day
face-to-face
in
the
Boston
area,
either
the
September
set
or
the
October
set
and
we'll
work
on
the
details
of
how
to
do
that
later
then.
Obviously,
I
HAF
97
is
the
week
of
november
14th.
I
think
if
we
make
some
basic
choices,
I
think
with
Daniel's.
C
C
C
J
C
C
Actually
go
to
the
next
slide
and
I'll
come
back
to
this
and
I'm
not
sure
why
I
put
them
in
this
order.
So
to
talk
about
some
of
the
specific
working
group
items
in
Tik
Tok,
the
myth
has
completed
IETF
last
call.
We
were
just
talking
about
that.
We
are
expecting
a
final
update
from
the
authors
dealing
with
a
few
remaining
issues,
and
then
we
have
the
resolution
of
the
I
Triple
E
copyright
question.
That's
on
the
table.
C
Then,
if
you
move
back
a
slide,
so
that
brings
us
to
the
other
two
items
that
are
on
the
plate
right
now
for
tick-tock
and
one
is
the
yang
data
model,
and
that
is
also
a
question
that
that
one,
we
also
need
a
little
bit
of
feedback
from
the
I
Triple
E
I
ATF
Coordination
Committee.
It's
a
slightly
different
issue
in
a
sense
that
we're
trying
to
get.
C
We
want
to
make
sure
that
we
can
transfer
the
yang
module
from
IHF
ty
Tripoli
at
the
right
time,
and
so
it's
about
getting
all
of
the
I's
dotted
and
t's
crossed
so
that
we
know
before
we
proceed
with
publishing
it
here
that
we
will
be
able
to
transfer
it
there.
Part
of
the
issue
here
is
that
I
Triple,
E,
802
and
I
hf
have
long
figured
out
how
to
mostly
collaborate
with
each
other
productively,
but
I
1588
is
not
I,
triply
802,
and
so
sometimes
that
makes
just
a
tiny
bit
more
complicated.
C
So
that
item
is
on
the
table
and
then
the
last
thing
that's
on
the
table
that
we
really
haven't
done
much
with
is
the
scalable
synchronization
networks
and
I.
Don't
see
those
oh
there
they
are
so
there
is
still
a
question
about
what
we
want
to
do
with
the
scalable
synchronization
work.
We
did
spin
up
a
separate
mailing
list
for
that
there
hasn't
been
a
lot
of
activity,
and
so
we
need
to
figure
out
what
we
wanted.
C
What
we
want
to
do
with
those
drafts
eventually,
so
that
brings
me
I
believe,
go
down
a
slide
and
then
down
another
slide.
So
I've
already
really
talked
about
next
steps,
which
are
the
interim
meetings
that
we're
going
to
have
going
forward.
So
this
brings
me
to
the
end
of
all
of
our
business
for
the
ntp
and
tik-tok
working
groups.
C
The
so
we
will
have
a
short
meeting
on
Friday
based
on
I,
mean
check,
check
your
email
to
make
sure
it
doesn't
actually
get
cancelled
because
the
primary
work
out
of
that
will
be.
What
do
we
do?
Based
on
the
feedback
we
got
from
the
I
Triple
E
IETF
coordination
committee.
So
any
questions
or
comments
at
the
end
of
this.
C
I
I
must
have
cut
that
part
out
when
I
wasn't
paying
attention
there.
There
is
still
a
plan
to
merge
the
two
working
groups
at
one
point,
I
thought.
Perhaps
the
tick-tock
work
was
dying
down
and
we
would
just
close
it
and
use
ntp
only,
but
further
conversation
has
led
us
to
believe
that.
Maybe
we
there's
still
enough
that
we
want
to
keep
a
working
group
for
time
related
items
in
the
ITF.
So
I
think
that
the
path
we're
going
to
do
is
the
time
related
items
and
a
time,
a
timeline
for
that.
Just.