►
From YouTube: IETF98-NTP_TICTOC-20170327-1300
Description
NTP TICTOC meeting session at IETF98
2017/03/27 1300
A
A
B
B
C
D
D
B
D
D
This
is
the
IETF
note.
Well,
you
all
have
seen
it
before.
You
checked
the
box
when
you
registered
that
you
have
read
this,
go
to
the
next
slide,
please.
So
this
is
the
agenda.
For
today
we
have
basically
the
administrative
and
agenda
bashing
portion.
We
have
the
ntp
portion
and
then
we'll
have
the
tick-tock
portion.
D
So,
starting
with
the
ntp
working
group
agenda,
we
have
the
working
group
status,
an
update
on
the
NT
on
the
NTS
work,
and
this
is
where
I
remembered
on
shell
that
I
forgot
to
update
the
slides
because
the
mac
for
ntp
and
the
open
paren
was.
I
need
to
go
back
and
get
your
last
name.
I
remembered
your
first
name
and
I
apparently
forgot
to
do
the
rest
of
the
update
so
anyway
on
child
will
tuck
tuck
tuck
us
about
the
mac
brain
TP,
a
data
minimization
and
we'll
have
a
short
discussion
on
the
ref.
D
It
updates
yang
data
model
are
those
guys
here
yet
don't
know.
Oh
that's
right!
They're
coming
from
deterministic
networking
one
of
the
things
we
did
this
time
was
we
didn't
list
terminus
networking
as
a
conflict,
and
it
really
should
be
and
so
will
will
fix
that
going
forward.
I
think
they've
got
scheduled
on
top
of
each
other,
and
so
there's
a
lot
of
crossover,
so
the
Yankees
will
be
coming
from
there
and
then
any
other
business.
D
So
back
to
the
ntp
working
group
status,
you
all
will
have
seen
a
flurry
of
emails
today
where
we
did
not
issue
calls
for
adoption
that
we
were
supposed
to
have
issued
after
the
last
meeting
and
they
all
got
issued
today
or
one
of
them
that
issued
yesterday
I
think
but
anyway.
In
any
event-
so
I
was
talking
to
brian
today-
he's
not
here
for
this
meeting
the
and
he's
not
available
to
participate
remotely.
Oh
so
Dennis
put
in
the
jabber
room.
What
has
happened
to
the
bcp
and
we're
about
to
cover
that?
D
There
were
two
questions
from
Brian,
so,
first
of
all
a
clarification
on
the
call
for
adoption,
because
I've
seen
some
good
comments
come
in
on
the
emails
that
have
gone
out
so
far
it
one
of
the
things
I
want
to
be
clear
about
is
commenting
on
the
when
you're
come
into
putting
in
comments
for
the
call
for
adoption.
I
still
think
we
need
to
be
clear
that
we're
we're
planning
to
adopt
the
document.
D
D
D
The
security
issues
were
addressed
by
that:
okay,
okay,
so
Harlan
would
rather
respond
to
the
mode
six
step
by
email.
So
that's
the
status
of
that.
The
second
thing
is
the
bcp.
This
has
been
around
for
a
long
time
and
it's
never
going
to
be.
It
should
be
considered
to
a
certain
extent
a
living
document,
because
best
current
practices
will
change
over
time
and
I
think
we're
over
obsessing
over
what
should
be
in
there.
So
we
have
issued
the
working
group
last
call
it's
going
to
close
on
the
seventeenth
of
April.
D
D
Okay,
I'm
going
to
take
silences.
You
have
no
comments,
so
that
brings
us
to
well
actually
will
stop
here
and
do
the
NTS
stuff.
So
you
want
to
bring
up
his
slides
and,
while
he's
bringing
up
Daniel
slides,
Dennis's
comment
in
the
jabber
rim
is
to
tell
people
to
read
it
and
tell
them
what
they
think.
I
think
the
key
for
the
vcp
is.
C
F
D
F
We
also
we
work
to
language,
about
nonpareils
ability
in
the
section
objectives
and
privacy
considerations
and
then
I'll
also
remove
the
option
to
pick
a
peck,
the
key
change
packets
on
the
ntp
on
ntp
packets.
So
that
has
been
the
decisions
from
the
interim
meeting
in
Boston
last
year,
and
this
is
now
finalized
in
the
draft.
F
That
raft
is
using
detail
as
to
for
the
creation
other
as
two
transports:
ntp
packets
as
dtls
payload
modes.
We
inform
packets
are
protected
by
and
authentication
taken
in
an
nth
extension
which
is
transported
over
the
normal
ntp
part.
The
key
changes
done
via
TLS
martex
packets
are
protected
like
mode
1
and
2
packets.
Currently,
a
Harlan
stand
lanced,
oh
awesome
on
tour
to
transport
mode,
6
packet
over
TLS
connection,
so
that
might
be
added
in
the
future.
G
F
D
F
G
D
H
H
We're
going
to
be
supporting
DTLS
from
modes
one
and
two
allowing
a
piggyback
option
is
I,
don't
see
where
there's
any
extra
work
there
and
it's
certainly
easy
enough
to
use
words
like
may,
instead
of
should
or
must,
and
that
gives
implementers
the
option
of
whether
or
not
they
feel
like
adding
that
complexity.
This
is
about
mechanism,
not
about
policy,
so
we
should
give
people
the
mechanism
to
do
things
if
they
want
to,
and
then
it's
local
policy
choice,
whether
or
not
they
do
them.
A
H
H
Know
that
it's
going
to
be
productive,
to
have
a
discussion
about
this
right
now.
My
point
is
that
I
would
rather
see
it's
not
going
to
do
any
good
to
not
specify
these
things
and
leave
it
to
different
implementers
to
decide
to
do
this
in
a
possibly
incompatible
way.
In
my
opinion,
it's
better
to
go
ahead
and
specify
it
as
an
option
that
may
be
implemented,
and
you
specify
how
it's
done
so
that
there's.
D
H
Is
the
obvious
one
also
if
we're
going
to
be
supporting
dtls
for
modes
one
and
two
prohibiting
it?
You
know
if
you
want
to
make
the
assumption
the
people
would
have
to
implement
this
four
modes,
three
and
four
as
a
piggyback
option.
Unless
we're
talking
about
something
different
here
because
of
key
exchange,
I.
D
H
There's
a
difference
between
using
this
out
in
the
evil,
bad
internet,
where
there's
one
set
of
constraints
and
in
an
in
internal
situation
where
you
don't
have
some
of
those
constraints.
So
it's
fine
to
not
to
say
don't
do
this
on
the
big
bad
internet,
it's
something
else
to
say,
because
you
can't
do
this
on
the
big
bag
internet.
We're
not
going
to
look
we're
not
going
to
give
you
a
clear
way
to
implement
this
internally
in
a
more
friendly
environment.
So.
D
H
D
Flexibility
is
not
a
use
case
say:
that's
it's
a
condition.
Okay
characteristic
aspect,
it's,
but
it's
not
a
use
case
and
I.
Think
what
we're
looking
for
here
is
without
a
use
case,
a
reason
why
you
would
want
to
do
this
and
perhaps
we
should
not
specify
it
yet
and
once
a
use
case
becomes
obvious
and
we
understand
the
use
case,
then
we
can
add
the
capability
or
add
the
option.
I.
I
Of
things
that
are
Christian,
like
Eddie
hat
on
I,
think
it's
going
to
be
incredibly
difficult
to
justify
this
like
I
in,
do
this
in
my
friendly
piece,
not
on
the
bad
internet
into
the
iesg.
So
this
is
gonna
like
probably
get
hit
with
like
discusses
from
all
the
security
Eddings
like
that
away
when
it
gets
there.
So
I
don't
want
to
go
there,
but
even
before
that,
like
procedurally
right
Kevin
so
like.
I
If
you
want
to
like
close
this
once
and
for
all
like
do
a
consensus,
call
on
the
list
and
say
like
okay
like
do
you
want
to
keep
this
or
not?
And
if
people
are
agreed
agreed
like
RF
happens,
and
there
are
problems
in
the
rough
right
like
I'm
I.
Think
that's
probably
one
way
to
like
this
part
from
here
inside
the
working
group,
but
I'm
just
telling
you
already
that
it's
going
to
be
difficult
in
the
iesg
to
like
get
this
through
a
security
review.
I
I
have
an
issue
of
a
document
right
now,
where
people
kind
of
said,
like
hey
like
we
have
this
bunch
of
ID's
like
we
can
pass
a
mobile,
IP,
okay
and
they
say
like.
Oh,
this
other
thing
looks
like
really
cool.
We
can
use
this
in
the
future,
and
people
are
saying
why.
So
the
document
is
now
back
in
the
working
group,
I'd
saying
like
okay,
justify
why
you
need
this.
So
I
see
this
having
the
same
path
in
the
iesg.
I
Okay
saying
like
so
I,
don't
see
a
point
Harlan,
but
it's
probably
left
to
a
point
when
it's
needed,
like
Anna's
like
daniel,
said
like
it's,
nothing
preventing,
there's
no,
must
not
use
anything
else,
so
I
I
think
it's
really
open
and
we
can
probably
write
another
draft
which
describes
how
this
works
and
then
take
that
independently
in
the
working
group.
Okay,.
H
G
G
H
G
F
G
G
If,
if,
if
we
want
to
push
this
for
wide
adoption,
because
MVP
pools
or
what
almost
everybody
uses
so
handling
the
handling,
the
the
key
management
temple
in
public
key
infrastructure
for
for
server
servers
that
we
trust
to
participate
in
the
ntp
pool
is
a
non-trivial
problem,
and
I
don't
expect
a
complete
solution
to
that
problem
prior
to
publication
of
this
draft.
But
I
would
like
to
at
least
have
some
discussion
of
what
direction
we're
heading
there
so
that
I
can
have
a
few
relevant
sentences
in
the
security
considerations.
Section.
F
F
F
D
Other
questions
on
the
status
of
the
security
work
so
a
year,
roughly
a
year
ago,
we
put
out
a
consent.
Working
group
lost
calls
on
three
documents.
The
CMS
document
has
been
parked.
The
generic
NTS
document
is,
he
was
just
talking
about
and
we're
going
to
update
that
and
publish
it
as
informational.
Do
we
have
a
time
line
for
that.
F
D
D
G
D
D
K
D
D
D
Guess
the
question
is
Daniel
you
sent
in
some
comments,
but
I
don't
know
if
you
you
sent
some
comments
to
the
mailing
list
about
on
the
word
on
the
call
for
adoption.
I
don't
know
if
they're
out,
if
they're
obe,
because
of
what
I've
done
or
if
or
if
you
think
that
so
my
question
for
you
is
you're
the
one
who's
commented
on
it
did.
Should
we
pursue
a
sec,
debra
byrne
review
now
or
do
you
think
the
document
needs?
Well,
you
actually
just
said
it's
going.
G
To
change
yeah,
I'm
the
the
mac
frantically
draft.
We
talk
about
yeah
so
much
my
compliments.
The
mailing
lists
are
that
or
that
I
support
immediate
adoption
of
draft.
However,
in
the
time
between
adoption
and
when
we
actually
push
it
out,
two
of
the
working
group
I
expect
that
it
that
the
document
will
have
to
undergo
a
substantial
change
of
character
from
being
a
broad
discussion
of
possibilities
and
alternatives
and
trade-offs
to
actually
being
a
specification
for
using
a
yes
CMAC
for
for
legacy.
Mac
and.
D
D
Absolutely
did
and
it's
all
it's
all
my
fault,
because
I
pushed
the
wrong
buttons
and
the
data
tracker,
so
I
was
so.
If
you
just
take
a
quick
look
at
the
the
working
group,
they
already
adopted
working
group
document.
It's
very
short
that
does
an
actual
recommendation.
Oh
I
think
then
you're
right
Suresh.
We
could
get
a
sector
review
of
this.
What.
D
I
D
G
Yeah,
so
all
the
updates
that
I
have
on
this
document
since
the
last
ITF
meeting
or
what
has
transpired
in
the
past
16
hours,
there's
been
a
push
for
we
put
out
the
call
for
adoption
cut.
A
few
people
have
commented
on
it.
I've
responded
to
those
comments
Harlan
so
so
far,
I've
heard
nobody
stating
opposition
to
adoption
arm
as
far
as
the
cut
as
far
as
the
revising
the
content
of
the
document,
Harlan
had
a
few
comments
on
that
he
want.
He
wanted
some
musts
changed.
G
D
H
Written
I
believe
the
doctor.
If
the
purpose
of
this
document
is
to
do
exactly
what
it
says,
then
it
does
exactly
what
it
says:
I
think
it's
over
each
and
that's
why
I
want
those
should
or
shells
change
to
maize,
because
that
behavior
is
inappropriate
in
various
contexts
and
prohibiting
that
behavior
is
counterproductive.
H
Paul
gear
had
a
comment
about
a
wider
use
case
of
why
doing
this
behavior
will
make
it
more
difficult
to
find
operational
problems
in
the
wild.
As
for
the
third
paragraph
of
the
randomization
I'm,
pretty
sure
my
original
comments
say
exactly
what
they're
supposed
to
while
I
remain
polite.
So
again
that
third
paragraph
should
go
because
it's
exactly
for
the
reasons
why
I
mentioned
so.
G
H
D
H
I
Description
so
Harlan,
like
I,
hear
what
he's
saying
and
I
understood
this
like
as
supporting
adoption
right.
So
once
the
document
gets
adopted,
it
goes
under
working
group
change
control.
So
it's
not
like
Daniel
making
the
changes
anymore.
It's
like
the
working
group
making
changes.
So
at
that
point,
once
it's
adopted,
like
you,
are
as
much
as
a
party
to
it
as
like
Daniel
right,
like
any
its
you're
free
to
argue
the
changes
in
the
graph
right.
So
so
that
is
the
process
right.
I
H
D
At
this
point,
I
think
we
can
take
the
discussion
of
whether
the
language
should
be
should
muster
may
to
the
mailing
list,
and
perhaps
we
will
try
to
craft
a
conversation
that
the
interim
to
deal
with
the
second
issue.
I
would
encourage
you
Harlan
to
you
can't
say
something
is
incomplete.
You
need
to
say
what's
missing,
so
we
need
to
be
a
little
bit
more
errors.
G
G
C
H
D
You,
okay,
so
the
next
item
I
have
on
the
list.
We
don't
actually
have
any
updates
on
Harlan.
This
is
the
ref
ID
document
that
you
and
Sharon
did
and
I
didn't
get
a
chance
to
follow
up
with
either
view
on
where
we
are
with
this
and
I.
Don't
know
if
Sharon
I,
don't
think
Sharon's
actually
I
know
she
has
a
issue
I'm.
D
L
Hi
Aunt
Ruth.
This
is
the
first
time
I'm
in
the
NTP
working
group.
I
was
recruited
by
other
authors
to
come
and
like
join
this
effort,
because
I
have
some
yang
models
under
my
belt
and
but
I
have
started.
I
actually
coded
a
bit
of
ntp.
The
auto
key
features
where
I
was
just
an
implementer,
so
kind
of
combining
the
two
experience
and
trying
to
write
and
up.
Basically,
the
yang
model
was
already
there
finding
out
what
are
the
issues
in
the
and
making
sure
that
it
gets
moving.
L
So
this
young
model:
what
does
this?
Do?
It's,
basically,
a
man
away
for
us
to
manage
the
ntp,
both
the
client
side,
as
well
as
the
server
side.
It
has
the
mechanism
to
on
figure
as
well
as
to
get
the
real-time
state.
Most
of
the
features
for
ntp
for
are
covered.
Auto
key
was
something
that
we
recently
added
it's
incomplete.
As
of
now
there
are
still
some
changes
needed
to
be
done
there.
L
L
We
made
sure
that
we
could
change
the
port,
because
this
is
some
feature
that
some
of
the
vendors
have,
where
they
allow
the
ntp
port
to
change,
to
a
non-standard
put
if
needed,
so
that
configuration
is
allowed
earlier
in
the
document,
we
were
having
a
mechanism
for
only
a
single
trusted
key,
so
that
has
changed
to
a
list.
A
container
for
auto
key
has
been
added,
so
we
need
to
make
sure
that
to
keep
enhancing
the
authentication
part,
a
little
bit
of
structure
has
changed.
I
will
I
have
a
slide
on
that.
L
I
will
talk
about
how
we
are
handling
the
association
type
and
the
interface
container,
that
we
have
the
list
of
ntp
interfaces.
How
handling
the
many
cast
kind
of
feature,
those
things
we
are
adding
him.
So
this
is
a
straightforward
thing.
Allow
you
to
configure
the
NTP
port
by
default.
The
ATP
port
is
always
there,
but
you
you
are
allowed
to
change
to
non-standard.
L
L
Okay,
this
way,
so
what's
the
next
change?
The
next
changes
the
earlier.
This
was
just
a
single
container,
but
the
star
would
mean
that
it's
a
list
now,
so
we
have
changes
to
a
trusted
key
and
maintaining
key
ID.
Actually,
there
is
recent
work
in
the
RTG
WG
as
well
about
the
keychain
handling.
So
we
in
the
next
update,
we
will
make
sure
that
we
use
the
RTG
WG
motor
and
keep
it
aligned
a
container
for
auto
key
also
has
been
added
right.
L
Basically,
we
combine
broadcast
multicast
server
together,
rather
than
maintaining
a
separate
as
per
the
ntp
mode.
Five
and
auto
key
and
the
many
cast
client
and
many
cast
server
related
details
have
been
added.
We
still
plan
to
reorganize
this
a
little
bit
based
on
the
some
ideas
from
the
yanks
best
practices,
which
we
are
planning
to
do
it
in
the
next
update.
L
So,
oh,
if
I
remember
during
the
last
ITF
I
think
one
question
what
an
ill
asked
was
that
is
this:
something
that
the
NTP
working
group
wants
to
do.
Coming
from
the
when
decide.
We
think
that
we
are
using
yang
models
for
most
of
our
protocols
and
for
configuring
of
our
devices,
as
well
as
for
the
manageability
things.
L
So
we
feel
that
entity
fits
into
that
definition,
and
this
could
be
one
or
another
way
for
you
to
configure
ntp
and
enhance
the
manageability
part
of
ntp,
and
we
were
hoping
that
this
time
we
could
get
adopted
and
then
work
and
up
keep
updating
the
document
under
the
umbrella
of
the
working
group
rather
than
as
a
private
draft.
Thank
you.
M
H
L
So
we
have
currently,
we
have
a
proprietary
version
of
our
young
and,
as
you
know,
bunch
of
vendors
already
are
using
that
confer
configuring,
MTP
and
other
CL
eyes
and
other
stuff.
So
our
aim
to
coming
to
ITF
and
doing
this
as
a
so
not
using
a
proprietary
young
models
anymore,
coming
to
the
idea
of
standardizing
those
young
models,
and
once
that
work
is
done,
we
will
implement
those
right
now.
L
It's
a
probate
on
a
proprietary
version,
we're
coming
to
the
idea
of
making
changes,
and
once
those
changes
are
standardized,
we
have
to
go
back
to
our
vendors
and
implement
those
young
models.
So
if
you
are
asking
this
model
in
its
in
its
current
form
is
completely
implemented.
No,
but
parts
of
its
are
implemented.
Okay,.
H
L
That's
basically
netconf
andres
con,
so
that's
definitely
already
there.
We
are
just
writing
the
yang
models
and
using
the
existing
protocols.
This
is
going
to
work,
so
there's
no
need
for
extra
functions
at
the
net
conf
in
the
restaurant
place
or
any
other
monitoring
tool
that
can
use
young
models.
Okay,.
I
This
is
Richard
like.
Would
you
like
me
to
take
a
shot
at
this,
because
I
think
I
understand
what
he's
saying
so
I'll
take
a
shot
at
it.
Please,
okay!
So
just
like
ntp
implementations
right,
okay,
so
there
needs
to
be
something
between
like
setting
some
variable
like
using
yang.
You
said
something
using
the
yang
model,
but
something
needs
to
happen
to
make
to
activate
that
in
the
implementation.
I
think
that's
the
question
Harlan's
asking
God.
Is
there
like
open
source
implementation?
I
L
Implication
so
if
I'm
a
device
at
I
am
implementing
this
young
model
I'm
going
to
use
the
protocols
like
net
convent
risk
on
to
receive
the
data
in
form
of
XML
in
case,
if
it
is
a
net
conf
or
if
in
case
of
rest
conf,
it
will
be
in
JSON
format,
so,
based
on
the
yang
format,
I
will
receive
the
data.
I
would
have
a
general,
a
young
parser
which
can
pass
any
xml
data
based
on
a
young
file.
L
L
There
are
tools
like,
for
example,
if
you
look
at
open
daylight,
there
are
yang
tools
that
can
generate
the
parses
automatically,
so
we
usually
use
that
kind
of
auto-generated
to
so
that's
why
this
kind
of
manageability
works
very
easily,
and
if
there
is
an
update
to
a
young
file
or
a
revision
to
an
young
file,
the
glue
code
is
quite
easy
to
update
it's,
not
a
big
problem,
and
usually
this
is
something
that
is
already
defined
in
and
already
working
for
rest
of
the
other
young
models.
It's
not
something
ntp,
young,
specific,
okay,.
H
Two
questions:
first,
I
will
say
that
I'm
not
particularly
I'm
not
very
familiar
with
yangyang
at
all,
are
their
transactions
capabilities
with
this?
Yes,
okay.
Next,
at
some
point,
we've
got
to
find
a
way
to
take
the
yang
data
transmission
so
that
we
know
what
configuration
needs
to
happen
and
that
needs
to
be
translated
into
something
that
queries
or
manages
an
NTP
instance
yeah.
Okay,
Harlin.
J
D
D
B
D
D
H
D
D
D
D
So
the
first
thing
is:
we
actually
have
a
new
RFC
I
know
he's
here,
but
he's
not
he's
over
in
the
deterministic
networking
working
group,
but
tiles
multipath
time
synchronization
has
been
published
as
of
January.
It's
RFC,
80
39.
So
that's
a
big
step
forward
for
that.
The
second
thing
is:
we
actually
have
the
1588
move
in
the
RFC
editor
queue
and
with
deep
thanks
to
suresh
and
the
document
editors
patients.
D
D
It
completed
the
working
group
class
called,
but
there
was
some
updates
that
we
wanted
to
make
based
on
some
changes
that
have
happened
in
1588,
so
the
I
Triple
E
1588
document
has
has
completed
its
first
working
group
ballot
and
so
the
we're
so
we
need
to.
We
need
to
get
an
author
update
on
that
one,
and
so
we'll
do
an
author
update
and
then
we
will
reissue
a
very
short
working.
Your
class
call
it
has
been
around
for
a
while
and
then
the
hoops.
The
last
thing
is
the
1588
over
mpls.
E
Used
to
having
Harlan
in
the
queue
ji,
Kristin
yeah
just
about
the
1588
over
mpls
one
I
think
at
this
point
it
is
the
right
thing
to
do
to
drop
it
since
the
draft,
which
came
afterwards,
which
is
more
generic,
remember
Greg
mere
skis
wrath
actually
passed.
Working
group
last
call
in
the
mpls
working
group.
H
There
so
at
some
point,
I
like
to
discuss
how
we
want
the
documents
to
look
moving
forward.
This
goes
to
things
like
do.
We
want
to
have
separate
proposals
for
like
each
extension
field
things
we
want
to
have
clumps
of
extension
field
proposals,
or
do
we
want
to
do
something
like
have
higher
level?
You
know
have
have
high
level
documents
to
describe
each
thing,
and
then
we
augment
them
as
we
make
changes
for
things.
H
G
H
But
that
was
like
so
now
we
have
the
ref
ID
proposals
that
has
like
two
or
three
ref
ID
proposals
in
it,
but
there's
a
bunch
of
other
extension
field
once
and
then
there's
the
issue
of
how
we've
separated
the
mac
processing
from
something
else
with
extension
fields
and
we've
got
the
hilarity
that
we
have
not
yet
discussed
about
the
the
dock.
The
proposal,
I
hate
and
I
propose
some
changes
to,
and
you
know
the
question
is:
how
do
we
want
to
do
this
moving
forward?
H
D
So
I
think,
there's
probably
a
little
bit
of
homework
and
organization
that
we
need
to
do
to
have
this
conversation
productively
and
I'd
like
to
have
I
know.
Sharon
has
involved
in
some
bit
kind
of
like
to
have
her
there
as
well
and
also
I
know
that
there
is
an
ongoing
disagreement
between
you
and
towel
on
the
the
clarification
to
the
extension
field
that
is
made.
Oh,
please,.
D
Realize
there's
an
ongoing
disagreement.
There
are
several
issues
and
in
order
to
have
a
productive
conversation,
we
need
to
have
the
conversation
a
little
bit
more
organized
and
we
don't
have
all
the
parties
in
the
room
and
we
might
as
well
I,
don't
think
it's
effective,
given
the
amount
of
time.
Oh
yeah,
absolutely
yeah.
We've
gone
in
circles
on
this
I'm,
tired
of
going
in
circles.
I
don't
want
to
have
the
conversation
until
we
get
all
of
the
key
participants
in
the
room
together.
I
was.
H
Expecting
to
my
point
goes
toward
if
we're
going
to
work
toward
an
April
interim
meeting
where
we
discuss
these
things,
it's
going
to
help,
if,
if
it
will
help
if
we
can
get
a
decision
or
about
the
overall
direction,
we
want
to
proceed.
So
are
we
looking
at
you
know
submitting
clumps
of
new
rfcs
to
add
in
different
proposals,
or
we
looking
at
updating
in
existing
RFC,
so
that
you
know
when
a
time
come
to
add
a
new
extension
field.
We
add
a
new
section
to
the
existing
document
under
supported
extension
fields,.
H
H
D
G
I
oppose
any
approach
which
would
treat
the
set
of
extensions
as
closed
the
entire
idea
of
having
the
exhibition
fields
is
that
you
can
simply
but
simply
register
your
extension
and
and
maintain
to
maintain
that
maintain
that
document
separately
from
everything
else
that
we
don't
have
to
read
the
course
back
on
and
leave
open.
The
possibility
of
extensions
in
the
private
use
range
where,
if
you
don't,
if
you
see
this,
and
you
don't
recognize
that
you
ignore
it,
that's.
H
G
G
Well
aside
from
the
iono
registry
which
which
I
think,
which
I
think
is
the
is
the
directory
you're
interested
in
and
when
you
see
a
river
point
of
the
you
can
you
can
either
look
at
that
which
should
point
to
let
us
read
or
you
can
just
watch
the
list
traffic
for
14
when
something
is
updated
on,
but
I
think
I
think,
requiring
us
to
put
everything
into
a
single
document
defeats
the
point
of
extensions
all
together.
Okay,.
D
Guess,
I'm
not
convinced
that
I
can
provide
you
at
this
point
in
time.
The
guidance
on
how
to
do
this
I
think
revving.
The
course
back.
Every
time
is,
is
not
the
way
we
want
to
go
I
think
perhaps
a
single
document
related
to
all
of
the
extension
field,
types
of
issues
and
the
definition
of
new
extension
fields
could
potentially
be
done.
The
other
thing
yet
to
think
about
is
I
think
there
are
other
things.
People
have
suggested
changing
to
the
core
specification
and
we
haven't
opened
that
up
to
do
that.
O
Yeah
I'm
trying
to
track
down
everything
can
be
frustrating,
but
you
just
make
sure
the
RFC
numbers
in
the
registry
and
look
at
one
spot
and
then
it's
a
table
of
contents
toward
where
the,
where
else
I
think
opening
up
the
main
doc
really
bad,
want
something
stable
and
trying
to
collect
all
the
extensions
once
father's,
also
counterintuitive,
to
the
way
everything
else.
Okay,.
D
So
I
think
one
or
a
small
set
of
drafts
is
the
guidance
that
we're
getting
all
right.
I
think,
combining.
I
don't
think
we
needed
a
separate
draft
for
every
extension
field.
Thank
you
where
we
can
coalesce
and
that
would
be
better,
but
I
don't,
as
rich
says,
I
don't
think
we
should
read
the
base
specification,
all
right,
so
I'm
pushing
the
red
button,
Harlan
you're,
going
out
of
the
queue
okay.
D
A
D
D
There
is
an
open
source
module
for
this.
It's
available
on
github,
go
to
the
next
slide.
Here's
the
next
steps,
the
this
work
is
being
so
one
of
the
authors
at
the
top
that
you
noted
was
Rodney,
Cummings
and
Rodney.
Cummings
is
heavily
involved
in
the
actively
1588
work
and
the
current
revision
of
I
triple
e
15.
It
is
looking
at
the
definition
of
datasets
that
would
support
whatever
the
underlying
management
model
would
be
because
in
the
case
of
1588,
you
have
the
SNMP
based
management.
D
N
N
N
Yeah,
so
for
this
elevation,
and
mostly
it's
a
whole
one,
but
we
are
you-
can
skirt
that
the
hora
module
to
simplify
is
structure.
We
we
introduced
several
new
types,
such
as
ions
o'clock,
class,
clock
accuracy,
thousands
and
also
a
solar.
You
types
of
our
Malaysian
just
to
remove
also
an
advantage
in
different
modules.
N
N
Just
rather
in
the
Middle
East,
we
think
we've
been
discussing
sorta,
Libya
and
new
leaf
interface
that
we
are
added,
so
it
will
be
very
convenient
ever
you
need
to
look
into
what
is
the
underlying
physical
port
with
uncle
for
definitely
related
her
logic
or
so
for
the
next
iteration?
We
we
will
add
a
visa.
Your
parents.
D
No
kind
of
so
we
will
wait
for
the
update
from
you
and
then
we
will
issue
the
work
in
your
glass
call,
yeah
and
you're
still
closely
coordinated
with
Ron
Rodney
in
the
1588
community,
okay
and
the
lessons
learned
in
the
1588
mill.
We
will
also
apply
to
this
as
far
as
getting
that
the
proper
and
rot
Rodney.
It
knows
what
those
are,
so
we
will
we'll
take
care
of
that.
We.
D
D
D
D
Do
that
there's
been
a
little
bit
of
discussion
on
the
mailing
list
today
about
a
virtual
interim
I
think
what
we
proved
between
the
last
meeting
in
this
meeting
is
that
this
is
a
working
group
that
is
a
little
bit
more
effective
if
we
do
have
the
occasional
virtual
interim
in
between.
So
we
are
currently
targeting
having
two
virtual
interims
between
now
and
the
next
meeting
and
Prague
we're
looking
at
late
April
for
the
first
one
and
then
late,
May
or
very
early
June.
D
D
We
really
really
really
need
to
do
the
administrative
work
to
combine
these
two
working
groups
into
one
and
recharter
and
I
have
solicited
solicited
the
Haut,
the
help
of
a
former
iesg
member
to
help
get
this
charter
work
done
and
he
has
agreed.
So
look
for
draft
reach
our
during
text
on
the
two
mailing
lists.
The
intention
is
to
combine
the
two
working
groups
into
a
single
one
that
does
a
Time
Protocol
work
in
the
IETF,
because
it
is
a
very
small
community.
All
right
all
right
with
that.