►
From YouTube: IETF99-NTP_TICTOC-20170718-0930
Description
NTP TICTOC meeting session at IETF99
2017/07/18 0930
https://datatracker.ietf.org/meeting/99/proceedings/
A
A
A
B
A
A
If
you
have
any
questions,
the
only
reason
why
I'm
spending
a
little
bit
more
time
on
this
unusual
is
the
underlying
RFC
has
actually
changed.
So
for
those
of
you
who
everybody
should
care
about,
that,
it's
getting
ready
to
say
for
those
of
you
who
care,
but
everybody
cares
about
this,
and
so
everybody
should
be
aware
that
it
has
changed.
A
Yes,
we
have
looks
we
all
care
about
this
and
it
has
changed
all
right,
any
other.
So
moving
on
we're
all
aware
of
the
note.
Well
so
the
agenda
for
today
administrivia
and
agenda
bashing,
we
have
a
minute
taker.
You
have
a
jabber
scribe,
thanks
to
both
of
you
very
much.
I
do
believe
that
this
is
quite
possibly
a
record
for
the
NTP
working
group.
A
Well,
we
have
not
stood
at
the
front
and
begged
for
both
of
those
positions,
as
the
meeting
is
starting
so
which
is
progress
so
the
agenda
for
today
will
do
NTP
first
and
then
we
will
do
the
tick-tock
stuff
we'll
have
we'll
go
over.
The
working
group
status
talk
about
network
time
security,
all
of
those
lists
of
documents,
so
I
didn't
prepare
a
slide
for
the
NTP
working
group
status.
The
only
thing
I
really
wanted.
Basically
what
I?
A
If,
if
its
current
work
item
or
something
we've
been
discussing
for
a
while,
it
is
not
represented
somehow
on
the
agenda
somewhere
else,
then
I
put
it
here,
and
so
the
only
thing
that's
really
here
is
the
draft
IETF
ntp
mode.
Six
commands
I
know
that
Brian
Haberman,
who
is
the
author
of
that
document,
is
over
in
the
deprived
meeting.
So
he's
not
here.
A
He
incorporated
all
the
comments
that
were
received
from
the
last
set
of
comments
and
it's
his
it's
his
beliefs
that
this
document
is
ready
to
go
to
working
group
last
call
I'm
not
does
anybody
have
any
reason
why
they
don't
believe
that
should
be
the
case
and
as
a
reminder
to
two
folks
that
are
new
to
this.
This
is
actually.
A
A
C
So
I
haven't
bothered
with
slides,
because
the
update
on
this
is
fairly
straightforward.
I
believe
the
documents
is
ready
to
go
to
last
call
at
any
time
outstanding
issues.
As
far
as
I'm
aware
are
a
few
people
have
contacted
me
with
with
with
proofreads
and
identified
some
typos.
They
need
to
go
through
those
and
also
make
sure
they
listen
encrypted.
Your
section
and
I
think
there
was
an
outstanding
question
from
the
interim
about
what
we
want.
The
final
title
of
this
document
to
be
I,
don't
think
these
questions
are
both
fairly
creepy
old.
A
A
A
A
B
There
Dave
Mills
I,
just
sent
this
to
the
chat
area,
has
a
report
and
comments
about
the
follow-on
to
AutoKey.
That
includes
Network
time
security
and
with
respect
to
network
time.
Security
is
particularly
concerned
about
the
lack
of
symmetric
mode
coverage.
Yeah
I've
got
a
copy
of
his
paper,
that's
in
the
queue
to
the
mailing
list,
and
it
should
it
should
address
everything
he's
talking
about.
C
A
B
B
A
B
A
C
C
A
Yes,
we
should
move
the
list
and
that's
I
had
kind
of
hopes
that
this
wouldn't
become
a
discussion
talking.
Yes,
yes,
we
need
to
move
the
mailing
list.
It's
been
sort
of
one
of
these
things
that
when
it's
working
it
doesn't
matter
and
when
it's
not
working,
Harlan
and
I,
don't
I,
don't
think
he's.
Actually
speaking
at
this
point,
I'm
kicking
him
out
of
the
queue
get
back
in
all
right.
So
yes,
at
this
point,
thank
you
very
much
Daniel
and
the
the
folks.
A
D
Yeah
I
don't
have
any
slides,
but
there
are
a
couple
of
updates
to
the
enthalpy
back
draft.
There
were
a
couple
of
questions
raised
during
the
last
discussion.
So
first
was
the
algorithm
agility
and
we
added
so
I
NTP
has
an
inbuilt
algorithm
agility.
You
know
support
for
algorithmic
agility.
There
is
this
file
called
NTP
.
keys
file,
which
allows
for
the
specification
of
the
key
identifier
and
the
associated
key
as
well
as
the
we
can
also
I
mention
the
algorithm
used,
which
we
want
to
use
for
the
symmetric
crypto
for
NTP
packets.
D
Currently,
there
is
only
support
for
md5,
but
since
we
are
proposing
this
new
AES
CMAC
algorithm
I
think
we
can
incorporate
it
in
that
donkeys
for
its
own
ntp.
So
the
point
is
that
there
is.
It
allows
for
the
transition
from
one
algorithm
to
another,
so
that
should
not
be
a
problem.
I've
addressed
that
in
the
draft-
and
the
second
issue
was
to
have
a
test
vectors
section.
Since
we
referred
to
RFC
four
four
nine
three,
four
ACS
D
Simak
implementation.
D
It
contains
the
test
vectors
for
AES
CMAC
itself
and
we
also
checked
our
implementation
using
the
same
vectors.
The
draft
itself
uses
the
vectors
from
NIST
CMAC
document
and
I.
Think
we
don't
need
new
test
vector
so
I
have
added
the
new
test
vectors
referring
to
that
draft
I.
Think
that's
it.
If
anyone
has
any
other
questions.
A
Any
questions,
so
this
is
another
document
at
our
last
interim.
We
talked
about
moving
this
to
working
group
last
call
as
soon
as
we
got
an
update
to
it.
So
this
is
a
really
short
document.
I,
don't
see,
any
reason
why
we
can't
do
the
working
group
last
column
parallel
with
the
NPS
document,
so
I
would
like
to
start
it
this
week
and
based
on
the
discussions
at
the
last
meeting,
I,
don't
see
any
reason
not
to
do
that.
Okay,.
C
So
there
have
been,
there
have
been
no
substantive
changes
or
a
much
or
any
at
all,
since,
since
the
last
interim,
there
is
an
issue
of
a
bit
of
drama.
Some
individuals
who
are
not
present
in
to
not
ordinarily
participate
with
the
ITF
have
been
making
some
some
demands
and
accusations
surrounding
this
draft
and
been
abusive
to
the
point
that
I
believe
I
can
no
longer
treat
these
surrounding
issues
and
partially.
Therefore,
I
have
requested
the
chairs
to
appoint
an
editor
for
this
document.
To
can
make
a
fair
decision
on
those
issues.
A
Right
so
so
we
have
talked
about
this
offline.
I
I
have
solicited
at
least
one
potential
editor,
anybody
else
who,
if
there's
any
volunteers,
who
really
want
to
do
this,
that
would
be
great.
Otherwise
I
will
proceed
with
arm-twisting
to
get
an
editor.
So
yes,
oh
sorry,
you
have
to
go
to
mike.
Oh,
oh
I'm,
sorry,
Harlan,
I
didn't
see
you
again.
Okay,
go
ahead
on
she'll.
D
What
isn't
hi
I'm
Julie
from
Boston
University?
What
does
it
entail
to
have
a
new
RFC
editor
like
it's.
C
A
The
author's
Oh
Lorraine
listed
this
so
there's
currently
there's
two
authors
on
that
document
you
and
and
Daniel.
So
my
intention
would
be
to
to
have
a
third
person.
That
would
be
the
editor
of
the
document
and
then
the
authors
would
say
as
authors
unless
you
asked,
unless
you
specifically
want
to
be
removed
as
an
author
and
moved
to
the
acknowledgement
section,
but
I
think
what
what
you're
looking
for
is
somebody
else
to
arbitrate
the
comments
that
you're
getting
yes.
E
A
E
If,
like
there's
something
you
do
it
and
like
we'll,
take
care
of
it
like
I,
don't
think
you
necessarily
need
to
stand
on,
because
your
your
job
as
editor
is
to
do
whatever
the
working
group
wants
you
to
do
so
and
I
think
like
I'll,
let
the
chairs
decide
like
watch
what's,
okay
right.
So
if
you
want
to
do
it,
like
you
wanna
step
aside,
if
it's
difficult,
I,
don't
know
exactly
what
happened
so
like.
So,
if
you
want
to
share
with
me,
we
can
actually
talk
about
it
and
I.
E
Don't
think
it's
acceptable
that,
like
you
know
this
kind
of
personal
stuff
happens
and
especially
on
right
here
stuff,
so
I
don't
know
like
how
this
happened,
but
it's
if
it's
an
idea
of
activity
I,
don't
like
this
kind
of
things
happening
so
and
I
really
I'm.
Really
fine
with,
like
you
know,
you
guys.
E
B
Dave
had
separate
comments
about
this
that
go
along
the
lines
of.
He
wonders
why
the
document
is
at
all
necessary
because
it
looks
like
the
document
basically
is
a
reimplementation
of
smtp
and
since
everything
data
minimization
does
can
be
done
with
SMTP.
Dave
wonders
why
we
even
need
it
and
as
a
side
issue
I
think
there
may
be
an
error
in
the
minimization
document,
where
it
talks
about
how
the
received
timestamp
for
one
gets
sent
back
and
that's
data
leakage,
but
that
only
gets
done
in
in
symmetric
mode.
That
doesn't
happen
in
client-server
mode.
C
So
I
will
I
will
go
back
through
the
SMTP
spec
carefully
and
see
if
the
only
thing
I've
indicated
it
as
a
must
in
the
document
is
already
covered.
If
that's
the
case,
then
we
can
change
the
status
and
we
can
change
its
intended
status
from
standards.
Attracting
firm,
national
I
think
the
document
the
document
needs
to
be
published,
regardless
just
to
have
a
statement
of
the
of
the
security
and
privacy
considerations
surrounding
these
choices.
Okay,.
D
Yeah
I
also
wonder
to
say
the
same,
because
that
I
think
the
document
is
necessary
because
it
doesn't
state
the
reason
why
we
are
doing
this
thing
like
the
privacy
issues
that
are
involved.
It
does
I,
don't
think
any
documentation
in
an
smtp
states
that
that
he's
thing
behind
why'd.
We
have
that
okay.
A
B
A
A
I
switch
the
order
of
that
actually
I
was
that
should
have
been
moved
down
there,
so
I'm
doing
a
dynamic
agenda
bash,
because
I
thought
I
fixed
this
I'm
going
to
move
the
NTP
ref
ID
discussion
down
with
the
EF
discussion
at
the
bottom
I
wanted
to
cover
all
of
the
things
that
we
had
updates
from
the
last
meeting
first
and
then
we'll
get
to
the
stuff
that
is
still
sort
of
outstanding.
A
F
Okay,
these
are
the
topics
that
are
changed
after
the
last
cool
class.
Call
that
basically
changes
to
the
language
regarding
sin,
a
loaf
pan
sauces
and
the
behavior
of
that
changes
to
the
language
regarding
any
cars,
as
an
auto
key
section
has
been,
we
crafted
and
also
there
is
a
pointer
to
the
new
feature
of
the
NTP,
the
content
or
key
files
of
it
at
states.
F
A
H
H
A
Okay,
so
at
this
point,
I
believe
this
document
is
ready
to
send
to
the
isg
I,
don't
see
any
reason
not
to
do
it,
so
that
is
what
we
plan
to
do
next,
unless
somebody
opposes
it
well,
actually,
I
guess
if
you
opposed
it,
you
should
have
spoken
up
during
the
working.
Your
last
call,
so
this
document
will
be
proceeding
to
the
isg
shortly
yang.
A
A
B
B
I've
spoken
with
them
and
they
aren't
planning
on
it
and
the
only
other
side
bit
I
will
say
there
is
Dennis.
Reilly
and
I
were
chatting
about
things
and
he
commented
on
how
one
of
the
things
he's
noticing
in
the
PTP
meetings
is
they're,
specifying
things
in
the
standard
before
they're
implemented,
and
then
they
get
to
go
back
and
fix
them
when
they
realize
they
don't
work.
And
let's
just
say
we
generally
don't
have
that
problem
because
we
implement
standard
stuff.
After
we're
sure
everything
is
polished
and
running.
A
I
A
A
J
H
So
my
name
is
tal
Mizrahi
I'm
from
Marvel,
and
this
craft
is
joint
work
with
your
team
Intel
and
it's
about
guidelines
for
defining
packet
time
stamp
format,
and
actually
this
was
submitted
to
the
internet
area
working
group,
and
this
is
presented
here
FYI,
because
we
believe
this
community
may
be
interested
in
this.
It
may
have
some
valuable
feedback.
Next,
please.
H
Okay,
so
in
general
time
stamps
are
widely
used
in
the
RFC
series
and
we
distinguish
between
two
types
of
time:
stamp:
text-based
time,
stamps
and
packet
time
stamps.
So
on
the
Left,
we
see
an
example
of
a
text-based
time
stamp,
so
we
see
in
net
con
RPC
and
on
the
right.
We
see
an
example
of
a
packet
time
stamp,
which
this
is
the
NTP
packet
format,
so
text-based
time
stamps
are
intended
to
be
human,
friendly,
user,
friendly
and
packet
time.
H
Stamps
are
intended
to
have
a
fixed
length
because
they
need
to
fit
into
a
packet
header.
So
this
is
the
main
difference
between
the
two
next
slide.
Please
so,
like
I
said
text-based
time,
stamps
are
very
common
in
many
documents,
and
we
see
a
few
examples
here,
not
an
exhaustive
list
of
examples
but
related
to
net
confit
and
various
RFC's
related
to
Jason
and
XML,
and
test
based
time.
Stamps
are
defined
in
RFC
three,
three,
three
nine
packet
time
stamps
are
also
very
common.
H
H
The
problem
that
we're
trying
to
address
here
is
that
there
is
no
common
time
stamp
format
for
packet
time
stamps,
as
opposed
to
text-based
time
stamps
and
furthermore,
in
many
RF
season,
internet
drafts
a
new
packet
time,
stamp
format
is
defined
and
the
way
time
stamps
are
defined
are
not,
and
necessarily
in
a
standard
way
that
is
they're
defined
in
different
way,
not
necessarily
clear
a
lot
of
times.
There's
some
ambiguity
about
the
way
the
format
is
defined
next
slide,
please.
H
So
the
goal
of
this
draft
is
twofold:
actually,
first
of
all
to
define
a
small
set
of
recommended
time
stamp
format,
and
the
second
is
to
specify
guidelines
regarding
how
to
define
a
new
time
stamp
format
next
slide,
please.
So
this
is
the
set
of
recommended
time
stamp
formats
that
are
currently
defined
in
this
draft.
So
we
have
two
formats
which
are
based
on
the
NTP
time
stamp.
We
have
the
64-bit
NTP
time
stamp
and
the
32-bit
time
stamp
and
then
on
the
right.
H
We
see
a
PTP
based
format,
it's
actually
a
concatenated
64
bit
time
stamp.
So
the
idea
is
that,
generally,
if
you're
defining
a
network
protocol
that
will
typically
work
on
a
PC
or
on
a
server,
then
you
will
typically
want
to
integrate
that
with
NTP.
So
we'll
probably
want
to
use
an
NTP
based
time
stamp
format
and
if
you're
defining
a
network
protocol
that
will
typically
work
on
a
hardware
device
which
sometimes
uses
PTP,
then
you
may
want
to
use
the
PTP
based
timestamp
format.
H
So
we
expect
that
in
most
cases,
one
of
these
times
ten
formats
should
fit
your
requirements.
However,
obviously
not
always
so
in
some
cases,
none
of
these
is
going
to
fit
your
requirements
in
terms
of
number
of
bits
or
in
terms
of
granularity.
In
these
cases,
you
want
to
define
a
new
timestamp
format.
So
next
slide,
please.
So
if
you
do
need
to
define
a
new
timestamp
format,
we're
recommending
to
use
this
template.
These
are
basically
the
properties
that
needs
to
be
well
defined
in
order
to
implement
the
timestamp
correctly.
H
So,
first
of
all,
you
need
to
define
the
field
format.
That
is
the
number
of
bits
in
the
units,
and
if
there
are
a
few
subfields,
you
should
define
these
for
each
of
the
subfields
and
you
also
need
to
define
the
epoch.
That
is
the
point
of
reference,
for
example,
the
first
of
January
1970,
any
considerations
related
to
wrap
around
when
the
timestamp
is
going
to
wrap
around
in
2036
or
whatever,
and
also
any
considerations
related
to
synchronization,
whether
we're
requiring
all
the
endpoints
that
are
using
this
timestamp
to
be
synchronized
or
not
next
slide.
H
H
It's
precision
or
resolution
the
epoch,
the
era
and
we're
actually
looking
for
feedback
and
more
ideas
of
what
kind
of
information
you
would
expect
to
see
in
this
control
field.
So
any
feedback
about
this
would
be
next
slide,
please,
okay,
so
this
is
the
first
draft
we've
submitted
it
in
the
last
month
or
so
we're
looking
for
any
feedback
you
may
have,
and
especially
we'd
like
to
collect
requirements
about
the
control
field.
H
Like
I
said
we're
also
looking
for
feedback
about
what
is
the
right
place
to
discuss
this
document
because,
like
I
said,
we
did
submit
this
to
the
internet
area
working
group,
but
obviously
this
draft
may
be
relevant
for
different
working
groups
in
different
areas,
so
any
opinions
you
may
have
about
what
is
the
right
place
to
discuss.
This
draft
are
also
welcome.
H
K
K
B
K
With
them
talking
with
them
and
contributing
might
be
just
to
create
something
that
represents
time,
stamps
NTP
PTP
couple
comments,
so
you
you
refer
to
PTP
1588,
concatenated
format,
right
I,
think
that
more
recent
is
1588,
v2
and
64
bits
is
referred
as
a
truncated,
okay,
and
another
thing
is
that,
yes,
we
see
it
many
protocols
that
try
to
serve
both
purposes,
ntp
and
PTP,
especially
in
a
delay
measurement.
So
they
do
here
identifier,
what
type
of
format.
I
B
K
H
That's
a
good
point,
so
that
was
one
of
the
reasons
we
discussed
the
control
field
here
because,
for
example,
in
RC
63
74
there's
a
dedicated
field
which
specifies
whether
you
use
the
PDP
based
or
the
ntp
based
timestamp.
So
that's
just
you
know
one
subfield
of
the
control
field,
but
we
try
to
generalize
it
and
to
possibly
include
more
information
that
that
may
be
relevant
to
it
right.
C
So
my
my
first
snarky
comment
about
this
is
we
have
17
compatible
standards,
so,
let's
create
one
more
that
will
solve
everything,
but
my
my
more
sincere
input
is
that
I
think
we
actually
do
have
a
valuable
opportunity
here,
which
is
to
fix
something
that
virtually
every
system
since
the
dawn
of
computers
have
got,
has
gotten
wrong,
and
that
is
that
we
we're
doing
binary
UTC
timestamps
improperly,
in
that
we
are
unable
to
unambiguously
represent
the
time
during
live
seconds.
The
way
to
fix
that
is
that
giving
seconds
in
fractions
is
not
sufficient.
G
H
B
E
E
So
if
you
put
this
in
interior,
like
I'm
gonna
come
to
like
NTP
and
tick-tock
forever,
you
anyway,
okay,
so
it
does
not
make
sense
to
take
it
anywhere
else
and
I,
don't
make
sure,
like
everybody
gets
know
about
this
in
all
the
areas
I'd
like
we're
gonna,
do
an
idea
of
last
call
and
I
can
talk
to
my
co,
Eddie's
and
say
like
okay,
guys
like
this
is
new
timestamp
at,
but
I
really
want
that
to
happen
here.
I
mean.
E
In
NTP,
tick-tock
like
wherever,
like
Karen,
wants
to
take
it
off
right
like,
but
I
want
somebody
with
like
time,
knowledge
to
take
a
look
at
this,
like
not
somebody
in
interior,
because
like
outside
here
is
just
users
of
this
right.
Like
so
I
want
somebody
who
has
understanding
of
all
the
stuff
to
actually
review
it.
So
I
really
think
should
be
an
NTP,
a
tick-tock,
okay,.
F
H
M
Fubini,
so
one
of
the
co-authors,
so
basically
exactly.
This
was
one
of
the
reasons
for
including
the
Contra
field,
also
for
application
layer
application.
So
we
have
right
now
in
and
I
Triple
E
protocol
in
the
synchro
phasor
measurement
units
protocol
field
in
the
sea,
37
118
standard
we
have
exactly
so
we
have
synchronization
requirement
of
one
microsecond
and
p.m.
use
are
able
to
include
this
information
how
accurately
they
are
synchronized
to
UTC
into
such
a
control
field
and
something
similar
we
planting
truth
is
also
here.
A
A
Okay,
so
anyway,
yeah
cough
also
question
as
to
whether
anyone
is
going
to
try
to
convert
this
to
local
time
zones,
and
he
also
says
it
may
be
nice
to
have
an
indicator
as
to
the
master
clock.
So
suffice
it
to
say
there
are
lots
of
suggestions,
carlins
back.
B
B
You're
covering
a
bunch
of
stuff
and
going
down
a
road
that
we've
already
gone,
we
as
in
network
time
foundation,
have
already
gone
down
with
this
general
timestamp
API,
so
we're
covering
the
issues
of
pretty
much
everything.
That's
been
brought
up
and
a
bunch
that
people
haven't
thought
of
yet
so
we've
got
stuff
to
start
with
and
work
with,
and
we
we've
been
looking
for
a
place
to
talk
about
this
and
just
haven't
found
anywhere.
It
looks
like
we're
colliding,
and
that
would
be
a
great
thing
to
merge.
A
A
So
the
we
moved
item
number
six,
the
ref
ID
updates
and
the
EF
discussion
down.
I
know
that
we
don't
have
any
updated
drafts
yet.
So
this
is
just
a
discussion
about
where
we
want
ahead
with
those
documents
and
I
didn't
my
apologies.
I
didn't
catch
you
in
advance
to
ask
you
about
it
and
Harlan's
online.
A
So
between
the
two
of
you
I
just
wondered
there
was,
you
know,
talk
to
Harlan,
first,
okay,
oh
absolutely
yeah
that'd
be
perfect,
there's
a
whole
set
of
documents
out
there
and
there's
the
results
of
the
interim
meeting
and
because
we've
been
so
focused
on
the
time
and
the
the
on
the
time
on
the
security
work,
it
just
sort
of
I
think
we
are
trying
to
wrap
up
the
security
stuff
and
then
we'll
get
to
the
other
pieces
all
right
at
that
point.
That
brings
us
to
the
NTP
agenda.
Oh.
A
B
A
A
A
A
So
that
brings
me
to
the
end
of
the
NTP
working
groups.
Portion
of
this
agenda.
Are
there
any
questions,
comments
related
to
that
nope
I
do
think
this
is
pretty
short.
It
was
only
45
minutes,
but
I
think
we've
made
a
lot
of
progress
over
the
last
four
or
five
months.
I
think
we've
got
some
stuff,
that's
really
close
to
going
out
the
door,
which
is
very
exciting,
so
the
tick-tock.
A
Agenda
this
one
will
be
pretty
short:
we
have
the
tick-tock
working
group
status
and
then
we
have
the
yang
model.
If
we
go
to
the
next
slide,
I
did
actually
prep
a
tick-tock
working
group
status
slide
and
part
of
the
reason
why
I
went
ahead
and
put
this
slide
together
was
I
am
very
excited
to
announce
that
we
actually
got
the
PTP
myth
published
huge
thanks
to
suresh,
because
I
basically
wash
my
hands
of
it
and
said.
Please
go
solve
this
and
he
did
so.
A
A
The
1588
group
is
deep
in
into
the
working
on
their
resolution
and
working
group
aleck
comments,
member
that
for
the
first
we
did
a
first
working
group
ballot
for
the
update
to
1588,
and
that
has
you
know,
preparing
answering
the
results
of
that
has
pretty
much
consumed,
that
working
group,
so
I
think
again,
I'm
really
sort
of
interested
in
wrapping
up
some
of
the
time
security
work.
So
I
haven't
pushed
too
hard
on
this
to
give
the
1588
folks
a
bit
of
a
breath.
L
L
L
Since
the
original
information
module
of
the
58,
a
diversion
to
categorize
member
into
three
classes
might
configurable.
The
second
is
the
dynamic,
and
the
last
is
the
static,
since
some
of
the
desire
member
can
also
change
the
status.
For
example,
the
poorest
state
in
the
40s
that
said,
can
be
configurable
or
the
dynamic
that
is
read-only
depending
on
their
scenarios
or
implementations
of
this
device.
L
L
The
current
state
has
in
the
industry
what
a
few
vendors
have
shown:
interest
to
demo
or
implement
their
young
Mario.
More
more
vendors
were,
are
still
waiting
for
the
publication's
that
they
can
be
without
have
any
changes
to
the
devices
so
the
publication
we
are
at
the
momentum
of
of
influence
just
here
in
the
last
month.
L
L
Some
people
have
reached
the
points
at
her.
It's
best
to
be
consistent
with
58
ATM
model,
whoever
an
application
worker
yeah.
So
that's
another
thing
having
written
today
last
ride,
so
this
version
has
been
there
for
quite
some
time,
we'd
like
to
see
more
feedback
if
there
is
any
concerns
or
new
improvements
needed
and,
lastly,
we'd
like
to
hold
whether
it's
ready
for
the
work
group
last
call.
Thank
you.
A
A
A
E
Slightly
different
topic:
I'm
suresh
krisshnan,
so
we
talked
about
this
in
berlin
right
like
to
see
like
what
what's
going
to
end
up
with
this.
Like.
Are
you
gonna
go
with
foreign
arcs
you're?
Not
you
made
a
decision
that
is
gonna
proceed
to
an
RFC
because,
like
we
are
wondering
whether
it
should
say
internet
draft
get
done
and
then
sent
up,
societally
I'd
like
tell
us
one
option,
we
considered
right
so
did
you
make
a
decision
that
will
go
for
RF
seekers.
A
E
A
B
A
Yes,
it
is
that
we
had
quite
a
bit
of
discussion
about
it
and
the
intention
is
to
publish
this
version,
publish
the
version
for
v2.
The
question
is:
what
would
happen
for
the
next
and
I?
To
be
honest,
I
think,
what's
gonna
end
up
happening
is
the
next.
The
next
version
of
the
1588
specification
will
include
a
generic
data
model
itself.
E
I
don't
mind
you
staggering
it
like
staggering.
The
last
calls
and
I
don't
mind
waiting
for
this,
like
whenever
you
see
this
bandit
in
the
book
to
do
it.
Do
it.
Okay,
and
if
this
is
the
last
item
like
I
I,
think,
like
this
couple
of
things,
add
necessary
things
that
we
need
to
do
like.
That's
the
the
combining
the
working
of
charters.
I
want
to
remind
you
like
to
think
about
it
at
some
time
right.
A
A
The
right
so
we've
had
several.
Let
me
viscosity,
we've
had
several
conversations
about
why.
Why
do
we
have
two
working
groups
because
they
consistently
meet
together
and
they're
both
related
to
time
and
to
some
extent,
we
kind
of
hated
to
lose
the
heritage
of
the
ntp
one,
but
we
thought
perhaps
combining
the
two
and
having
a
new
working
group
called
time
where
all
of
the
time
issues
in
the
IHF
would
go,
and
that
would
include
ntp,
PTP
timestamp
formats
stuff,
like
that.
So
we
have
I've
been
threatening
this
for
a
while
and
I.
E
So
so
the
other
related
issue
of
the
meaningless
stuff,
so
I,
if
this
is
gonna
happen
like
I'm,
not
gonna,
like
you
know,
push
on
the
ntp
mailing
is
more
and
then
we
can
just
like
postpone
this
until,
like
you
know,
we
have
like
a
new
charter
and
this
just
don't
new
list,
and
we
done
with
it
right.
Otherwise,
it's
like
you
know.
Let's
try
to
get
that
started
like
so.
I'm,
not
gonna
push
you
to
like
Mozilla
store,
but
at
least
I
can
get
that
stuff
started
like.
E
A
That
would
be
fine.
The
one
thing
is
because
we
will
finish
quite
early
today
if
there's
a
couple,
people
that
want
to
stick
around
and
help
draft
a
charter
that
would
be
would
be
really
fabulous.
E
A
C
G
A
A
All
right,
no,
that
was
Stewart.
A
H
A
Yeah
I'm
sorry
you're
done.
Thank
you.
I
wasn't
all
right,
so
one
slide
for
each
draft
coming
forward.
At
the
end
of
the
last
interim,
I
sent
out
sort
of
a
summary
of
high-level
summary
of
the
actions.
It
wasn't
really
a
set
of
minutes.
I.
Think
I'm
gonna
do
that
again
today,
even
though
we
didn't
actually
quite
meet
all
the
things
we
said
we
were
gonna
do
out
of
the
interim.
A
At
least
it
was
helpful
to
to
go
through
each
of
the
drafts
that
was
discussed
and
summarize
what
the
results
and
next
steps
were
so
with.
So
we
can
look
for
that
going
forward
there.
The
question
for
you
Suresh
is
for
combining
the
working
group
with
all
of
these
existing
drafts.
I
don't
want
to
rename
everything,
that's
mine,
but
that's
it
I,
don't
have
to
do
that.
Okay!
A
N
Great
rain
so
now
us
from
telecom
bretagne.
Yes
in
ace
working
group,
we
will
be
dealing
with
the
problem
of
time
synchronization
and
we
have
to
come
up
with
a
solution
lightweight
and
actually
it's
not.
We
don't
need
a
precision
time.
We
only
need
a
rough
time
with
with
a
server,
so
if
I
don't
know
currently
doesn't
fit
on
this,
neither
on
tik-tok
working
group
or
ntp,
but
in
the
future,
if
you
have
a
more
general
working
group
for
time
related
to
the
issues,
I
think
we
can
make
use
of
your
expertise.