►
From YouTube: IETF115-SEDATE-20221108-1500
Description
SEDATE meeting session at IETF115
2022/11/08 1500
https://datatracker.ietf.org/meeting/115/proceedings/
A
A
A
That
looks
good,
okay,
the
usual
note.
Well,
it's
a
small
enough
type
that
it'll
be
hard
to
read,
but
it's
something
that
you
probably
are
aware
of
from
every
other
working
group
that
you've
been
to
so
I
won't
spend
a
lot
of
time
on
that.
There's
some
basic
meeting
tips
here.
If
this
is
your
first
time
there
is
in
the
ietf
115
agenda,
there
is
a
link
to
our
working
group
and
it
has,
on
the
right
hand,
side
a
link
to
the
on-site
tool.
A
That's
the
one
you
should
probably
use.
That
also
does
the
job
of
automatically
signing
the
blue
sheets
for
you
and
we
do
have
some
remote
participants
I
see,
so
that's
great,
we'll
make
sure
and
keep
an
eye
on
the
queue
as
we
go
along
in
terms
of
resources
for
this
ietf
meeting
the
agenda
is
on
data
tracker
meet
echo,
of
course,
is
what
you're
using
to
participate.
A
A
In
terms
of
resources,
here
are
the
usual
ones:
Braun
is
going
to
start
putting
notes
in
the
notepad.
That's
great.
The
mailing
list
is
right
there
enough
about
that.
Here's
our
agenda.
This
is
the
simplest
agenda
that
we
could
possibly
have
we're.
Basically
here
to
see
whether
or
not
we've
made
enough
progress
on
the
sedate
draft
and
Karsten
will
take
us
through
that
and
we'll
see
if
there
are
any
remaining
outstanding
issues.
Otherwise
Braun
and
I
be
doing
an
assessment
we're
supposed
to
do
it
tomorrow.
A
As
a
matter
of
fact,
if
we
need
it,
we
can
talk
about
the
liaison
that
we
have
to
tc1454
I'm,
not
sure
we
need
that,
but
we
can
decide
as
we
go
along,
and
so
with
that
we
come
to
the
end
of
my
prepared
remarks
and
we're
going
to
give
the
presentation
to
Kirsten.
A
C
Okay,
thank
you.
So
this
is
a
pretty
illustrious
Community
today,
but
we
will
go
on
YouTube,
so
it's
worth
doing
this,
so
this
is
really
the
only
slide.
I
need
to
show,
because
we
are
pretty
much
done
and
the
document
has
converged.
C
Surprisingly,
we
found
a
problem
with
the
document
that
we
were
supposed
to
build
on.
We
go
into
some
more
details
and
added
a
fix
to
that
through
the
document,
even
though
we
promised
that
we
were
not
going
to
touch
our
best
documents.
So
that's
really
the
interesting
part
today,
and
so
we
also
found
out
that
it
is
really
hard
to
discuss
this
problem
next
slide.
C
So
just
to
remind
everyone
what
RFC
3339
is.
This
is
essentially
described.
C
By
this
data
model
here,
an
RC
5339
date
has
a
UTC
time
and
optionally,
a
local
office.
That's
the
whole
data
content
of
the
thing
and
well
that
was
defined
around
the
year
2000,
essentially
the
profile
of
ISO
8601
that
we
all
love
dearly,
so
they
used
actually
the
1988
version.
For
that
one
could
argue
that
they
didn't
quite
provide
it
right,
but
that's,
maybe
not
that
important.
There
was
a
2000
version
of
8601
and
that's
even
cited
by
239.
So
let's
think
about
that.
C
So
I'm
noticing
that
when
you
look
at
the
characters,
you
don't
necessarily
see
a
UDC
time.
So
when
there
is
a
local
offset,
the
UTC
time
is
encoded
based
on
that
local
offset.
But
the
data
model
view
of
of
this
data
is
that
you
always
have
a
UTC
time
and
you
actually
have
a
local
offset.
C
So
there
are
no
floating
times
or
anything
like
that.
No
calendaring
times
this
is
just
a
time
stamp
on
the
udg
UTC
time
scale,
plus
optionally,
the
local
offset
a
hint,
and
the
reason
why
that
that
is
given
for
using
the
Oracle
offset
is
that
this
is
often
useful
information.
C
C
So
you
can
add.
Additional
hints,
just
like
the
local
offset
hinge
is
a
hinge.
There
are
other
hints
and
in
particular
there
is
a
way
to
indicate
the
time
zone.
So
the
local
offset
only
tells
you
how
many
hours
you
are
west
or
east
of
UTC.
Why
the
time
zone
actually
tells
you
which
political
construct
you
are
referencing
to
to
arrive
at
that
local
offset.
So,
for
instance,
Europe
Berlin
right
now
is
plus
one,
but
in
summer
it's
plus
two.
C
So
the
the
time
zone
information
is
a
hint
that
is
added,
but
it
doesn't
change
the
content,
which
is
still
a
UDC
timestamp.
C
I.
We
don't
have
an
example
for
that
in
in
the
document
right
now,
but
that's
easy
to
see
how
that
would
work.
Okay,
so
this
is
all
really
not
very
complicated.
It's
not
rocket
science
and
our
main
job
was
to
make
sure
that
this
works
well
with
various
existing
and
in
standardization
interfaces
to
timestamp
libraries
that
we
want
to
make
sure
people
can
continue
to
use
next
slide
so
yeah.
C
This
should
be
my
last
slide.
Unfortunately,
next
slide
it's
not
quite
as
simple
next
slide,
so
the
the
problem
is
that
roc-339
defines
the
ISO
8601z
suffix
and
the
plus
zero
zero
colon
zero
zero
as
synonyms
for
a
local
offset
hinge
of
zero
minutes.
So
you
are
on
UTC,
but
you
are
not
only
on
UTC.
This
is
the
you're
telling
the
recipient
that,
for
instance,
the
person
who
generated
this
timestamp
actually
uses
the
local
offset
to
convert
the
UTC
time
into
their
local
thinking
and
to
opt
out
of
giving
that
information.
C
Again,
we
have
minus
zero
zero
colon
zero
zero.
That
means
no
local
offset
a
given
and
this
minus
zero
zero
zero
zero
was
essentially
imported
from
RFC
822
or
actually
to
a22,
which
is
the
first
version
of
the
email
standards
that
actually
documents.
This
so
in
email
date
may
contain
this
minus
zero,
zero
colon,
zero,
zero
and
that
is
actually
in
use.
It's
not
like
30
of
the
mails.
C
So
how
have
that
I
did
a
quick
check
on
a
small
repository
of
emails
million
or
so
I
had
and
I
found,
like
0.3
percent
I?
Don't
remember
the
number,
but
it
was
not
nothing,
but
it
also
wasn't
an
overwhelming
majority
of
emails
using
that,
but
at
least
that's
in
use.
So
it's
good
that
that
email
has
that
so
people
can,
for
instance,
indicate
that
this
email
originated
from
a
place
that
simply
has
no
idea
what
the
the
user,
who
was
ultimately
responsible
for
the
email
being
generated
users
as
their
local
offset.
C
Now
the
RLC
5339
implementations
actually
generally
don't
deal
with
minus
zero
zero
colon
zero
zero.
C
Some
of
them
actually
follow
the
the
words
of
iso
8601
and
don't
allow
that
that
is
actually
rare,
but
most
never
generate
this
because
8601
in
this
2000
version,
not
in
in
its
1988
version
but
in
its
2000
version,
suddenly
started
to
disallow
minus
zero
zero
colon
zero
zero.
So
since
people
who
write
JavaScript,
implementations
or
other
programming,
language
implementations
often
look
at
isil
standards.
In
parallel
to
the
the
profiles
we
generate
here,
they
decided
not
to
write
that
number.
C
C
All
those
implementations
use
Z
as
the
suffix,
because
that's
short
and
other
implementations
that
actually
do
have
the
information
have
tended
to
give
Zed
as
the
indication
that
no
local
offset
has
been
given
and
plus
zero
zero
colon
zero
zero
as
the
local
offset
0..
C
So
we
have
an
interoperability
problem
between
implementations
that
Implement
through
this
resign
and
implementations
that
Implement
what
other
implementations
Implement,
what
the
majority
of
implementations
out
there
Implement.
So
this
is
based
on
a
survey
that
Justin
Grant
did
then,
which
can
we
find
in
one
of
the
issues
of
the
sea
date
Repository?
C
Well,
there
is
a
the
whole
issue
of
handling
conflicts,
for
instance
between
time
zone,
information
and
information
that
is
in
the
the
original
RC
539
I
think
we
have
that
correctly
covered.
So
we
know
how
to
handle
that,
except
for
the
problem
on
the
previous
slide
next
slide
and
the
the
result
that
didn't
take.
Oh,
the
result
is
that
we
essentially
now
have
two
problems.
There
are
two
options
we
can
ignore:
the
problem,
feign,
ignorance
and
just
add
our
our
optional
suffixes
and
act
as
if
nobody.
A
C
Oh,
that's
something
very
good
or
we
can
do
the
right
thing
and
the
the
discussion
on
the
list
went
into
preferably
doing
the.
C
Next
slide,
and
so
the
radical
proposal
is
that
we
actually
start
to
interpret
Z
as
minus
zero,
zero
zero
zero.
So
that
means
no
local
offset
is
implied.
So
if
you
want
to
imply
a
local
offset
of
British
winter
time,
then
you
write
plus
zero
zero
colon
zero
zero.
C
So
this
happens
to
mirror
the
consensus
in
the
implementations,
so
this
would
essentially
just
be
adjusting
the
specification
to
what
the
implementations
do,
but
it
goes
outside
the
charter
of
sedate
because
we
were
not
supposed
to
actually
modify
539,
so
we
thought
maybe
we
need
a
little
bit
of
discussion
beyond
the
sedate
working
group.
Next
slide,
so
I
sent
an
email
about
a
month
ago.
C
C
C
Ntp
is
in
the
process
of
essentially
making
up
their
mind
of
what
should
be
an
ntp
version
5,
and
there
is
actually
some
some
discussion
about
having
a
time
zone
aware
version
of
ntp
and
to
be
normally
isn't
just
about
UTC,
so
they
they
wouldn't
care,
but
that
may
influence
their
discussion.
So
I
thought
it
might
be
good
to
include
them.
D
C
Now
it
turns
out
when
you
bring
up
this
problem
problem,
then
people
start
first
of
all
discussing
whether
we
should
be
referencing,
ISO
8601
at
all,
which
is
not
irrelevant
to
this
working
group,
because
that
was
a
decision
done
by
539.
But
still
there
was
a
lot
of
discussion
in
the
thread
about
whether
we
should
reference
non-free
standards
normative,
okay
irrelevant.
C
C
So
the
only
thing
in
a
floating
time
is,
you
know
it's
1400
afternoon,
but
you
you
don't
know
what
that
means
in
UTC
and
that's
strictly
outside
of
the
scope
of
this
work
group,
because
we
started
with
the
UTC
time:
representation
539,
so
yeah,
it's
an
interesting
discussion,
but
maybe
not
that
relevant.
C
There
also
was
a
discussion
about
sub
manage
time
zone
offset,
so
the
Netherlands
in
1923
had
a
time
zone
offset
from
Germany.
That
was
something
something
plus
23
seconds.
C
Yeah,
that's
certainly
interesting,
but
it's
not
something
that
that
really
impacts
date
and
time,
implementations
that
we
use
today.
So
nobody
has
submitted
time
zone
offered
offsets
in
use
for
things
that
happen
to
to
matter
for
Commerce.
So
we
can
ignore
that
as
well.
Then
people
brought
up
calendaring
issues.
C
What
if
I
do
a
if
I
plan
a
meeting
next
year
in
the
summer
and
say
well,
it's
supposed
to
be
1400
afternoon
and
then
my
government
goes
ahead
and
finally
implements
the
decision
to
get
rid
of
daylight
savings
time
or
summertime
yeah.
Then
what
happens
to
my
meeting
the
UTC
timestamp
I
might
have
computed
for
that
meeting.
It's
no
longer
going
to
be
right,
so
I
will
see
53.90
really
wasn't
the
right
standard
to
represent
that
in
any
case.
C
So
this
is
about
calendaring
times
and
not
about
time,
stamping
information
in
a
way
that
is
unambiguely
referenced
to
UDC
so
again
relevant
and,
of
course,
you
can
then
from
there
go
into
tangents
on
unstable
politicians
and
times
or
definitions.
And
yes
that
has
happened
in
this
thread.
C
So
so
after
reading
the
whole
thread
I'm,
none
the
wiser,
except
maybe
the
fact
that
these
five
things
came
up
and
not
really
criticism
of
making
the
change
or
making
the
change
that
that
we
are
intending
to
make
here
shows
me
that
this
isn't
really
big
problem.
Apparently
so
next
slide.
C
In
this
context,
which,
by
the
way
I
think,
is
a
useful
outcome,
so
aligning
our
documentation
of
how
a
timestamp
implementation
should
work
with
what
we
people
are
actually
doing
out.
There
is
a
useful
thing
to
do
completely
independent
of
our
Charter
of
adding
additional
hints
to
these
timestamps.
C
So
this
is
where
we
are,
and
I
was
hoping
to
actually
use
the
time
here
to
get
at
least
an
in-room
conclusion
of
this
again.
We
have
to
verify
anything
on
the
mailing
lists
that
we
do
in
the
ietf
and
we
have
to
talk
with
the
ad
I.
Don't
think
there
is
an
ID
in
the
room,
there's
an
ID
online,
oh
good.
F
E
Apologies
I
I
had
one
question,
maybe
not
just
for
Carson,
but
for
the
entire
room
when
we
were
starting
out
with
this
work,
sort
of
pre-sedate
chartering
and
everything
there
were
Ambitions
initially
to
sort
of
revamp
three
to
three
nine
right.
There
were
a
few
other
things
like
you
know,
extended
years,
and
so
on
that
that
could
be
done
back.
E
Then
all
of
those
faced
a
lot
of
resistance
and
and
in
the
end
we
decided
to
go
with
this
sort
of
more
conservative
approach
of
leaving
389,
as
is
what
I'm
trying
to
say
here.
Is
that
I,
while
I'm
completely
with
you
that
you
know
the
I'm,
sorry
that
the
charter
sort
of
restricts
us
I
I
do
have
to
remind
that.
There
is
a
reason
why
the
charter
is
explicit
on
this
thing.
E
So
if
we
decide
to
sort
of
you
know
recharge
it
today
and
and
move
ahead
with
with
this
I
hope
that
we
can
reach
a
conclusion
as
a
working
group
that
the
change
we're
talking
about
here
does
warrant
sort
of
that
change
and
and
that
we
wouldn't
receive
further
pushback
yeah
that
that's
all.
A
Okay,
I
think
I
understand
that
Francisco's
in
the
queue
go
ahead.
Francesca.
C
D
Kill
it,
let's
train
again,
sorry
about
that,
as
you
can
hear,
I'm
Not
Alone
I
was
going
to
say
that,
yes,
this,
this
starter
was
crafted
with
a
lot
of
attention
and-
and
it
was
a
very-
it-
was
a
compromise
to
get
to
to
to
this
text.
So
any
modification
to
this
Charter
will
require
a
lot
of
work
to
get
consensus
from
the
community
and,
while
I
understand
that
fixing
things
is.
D
It's
obviously
very
appealing,
but
we
need
to
have
a
community
consensus
that
agreement
on
what
we're
fixing
and
the
scope
and
the
use
case
and
everything.
So
it's
not
as
simple
as
saying:
let's
extend
the
charter
and
and
get
this
done
and
I
we
are
I,
see
17
people
in
the
meeting
today.
D
I
know
that
this
meeting
collided
with
media
man,
media
man
and
so
I
think
that
a
big
part
of
the
the
resistance
that
was
there
during
the
initial
Charter
discussion,
people
were
not
are
not
present
right
now,
so
I'm
just
catching
up
with
the
thread.
D
I,
don't
know
if
this
was
discussed
in
the
mailing
list,
but
I
think
that
we
should
have
a
consensus
to
to
do
any
sort
of
retartering
and
then,
if
there
is
consensus,
of
course,
I
will
support
it
and
bring
it
to
the
history
and
move
forward
with
it.
But
the
first
thing
is,
you
know:
getting
consensus
in
the
community.
C
Yeah
can
I
quickly
reply
to
that,
so
the
the
purpose
of
the
October
4th
mayor
was
to
find
out
whether
there
would
be
such
resistance.
Of
course,
I.
Don't
know
that
everybody
who
would
be
resisting
this
is
on
the
art,
mailing
list
or
actually
reads
this
or
actually
replies
to
what
they
read.
So
this
is
hard
to
assess,
but
I
was
surprised
that
there
were
no.
There
was
no
discussion
that
really
questioned
what
we
were
trying
to
do.
There
were
some
misunderstandings.
A
C
What
we
were
trying
to
do
so
I
think
these
were
corrected,
but
once
they
were
I
think
yeah
people
just
went
off
those
five
targets
that
I
listed.
So
my
assessment
is
that
we
don't
have
a
strong
opposition
against
that,
but
yeah
I'm
not
sure
in
the
pay
grade
to
actually
make
this
assessment.
A
Before
before,
I
call
on
Brian
here,
let
me
use
Chair
say
that
I
think
we
need
to
be
very
clear
that
we're
talking
about
two
things
right.
We
have
an
existing
sedate
document
that
are
the
working
that
the
working
group
has
and
that's
currently
in
last
claw,
and
then
there
is
this
problem
which
certainly
the
working
group
could
document
yeah
right
right
and
use
that
documentation
as
a
mechanism
to
support
the
ad
as
a
background
to
re-chartering
so
I
I
guess
what
I'm
thinking
here
is
that
the
working
group
has
two
tasks.
A
Excuse
me
number
one
decision
about
the
existing
document
and
number
two,
a
revision,
3339
bits
or
whatever.
We
want
to
call
that
so
Brian
go
ahead.
Sorry.
B
To
interrupt
that's
okay,
thank
you.
My
memory
of
the
discussion
to
start
off
with
about
changing
RSC
3339
was
that
people
didn't
want
anything
which
would
make
the
wire
format
backwards
incompatible
in
any
way.
That
was
the
concern.
If
we
did
something
that
meant
that
existing
passes
broke,
the
nice
thing
about
this
change
is
all
we
are
doing
is
saying.
You
must
not
generate
one
particular
form,
so
we're
not
adding
anything
that
will
break
existing
parsers
I.
Think
that's
why
there
hasn't
been
any
pushback.
A
A
B
A
Now
it's
fine
yep.
D
Great
so
yeah,
my
preference
would
also
be
to
finish
the
current
work
and
then
focus
on
possible
retardering,
but
again
I'm
still
catching
up.
So
my
opinion
might
change.
After
looking
into
the
details
of
the
mail
thread
and.
C
Yeah,
so
maybe
I
should
remind
people
that
the
actual
approach
that
is
in
the
current
document
is
not
to
do
a
639
base.
I,
don't
see
a
reason
to
do
that,
but
to
actually
just
provide
an
update
to
a
639,
so
the
RFC
resulting
from
this
process
would
have
a
tag
on
it,
which
says
it
updates
the
three
nine
and
the
metadata
for
339
would
say
this
is
updated
by
the
current
document
and
to
the
the
only
update
here
would
be
juggling
these
three
time
zone.
C
Excuse
me,
local
offset,
hence
Z,
plus
zero
and
minus
zero.
So
I
know
that
we
are.
We
have
an
urgent
problem
in
our
hands
that
in
about
8
000
years,
this
will
no
longer
work,
but
maybe
we
have
a
little
bit
more
time
to
fix
that
part
and
the
the
intention
here
was
to
make
sure
that
we
have
a
common
format
for
libraries
like
temporal
and
the
JavaScript
support
that
is
being
put
in
by
ecmar
tc39
and
so
on.
A
D
C
We
currently
have
informal
contacts
into
that
organization.
That's
really
the
reason
why
we
have
even
detected
this
problem
because
because
we
have
exercised
these
informal
contracts.
F
Yeah
I
mean
the
the
the
iso
committee
is,
is
sort
of
wrapping
up,
I
mean
I
got
into
it
very
late.
They'd
already
almost
finished,
there's
a
couple
of
points
that
I
was
going
to
raise
about
their
last
minute
decisions.
But
if
we
put
together
a
message,
I
can
always
pass
it
across
and
see
what
happens.
C
But
what
we're
fixing
is
our
own
interpretation
of
there
being
a
difference
between
two
representations
that
mean
the
same
thing
in
8601
and
adding
a
third
one
that
is
not
supported
by
8601.
So
from
from
the
point
of
view
of
tc154,
we
are
getting
more
compliance
which
probably
they
should
be
like.
A
Let
me
sum
up
what
I
think
I've
heard
this
is
dangerous.
I.
Think,
first
of
all,
the
existing
sedate
document
is
in
last
call
that
last
call
ends
tomorrow.
I
haven't
heard
at
our
meeting
today
any
objections
to
moving
that
document
forward
and
so
I'm
going
to
just
stop
for
a
moment
and
listen
if
there
are
any
last
minute
objections.
A
Okay,
that
part's
good
second
thing
I've
heard
is
that
perhaps-
and
this
is
my
interpretation
of
what
I've
heard
the
chair
should
work
with
the
ad
the
responsible
ad
to
start
the
discussion
about
a
very
conservative
re-chartering
for
sedate
to
take
care
of
the
problem
in
3339,
emphasizing
what
the
cause
of
the
problem
is.
What
the
solution
to
the
problem
proposed
is
what
the
use
cases
are
and
and
basically
maybe
even
go
to
the
list
with
proposed
Charter
text.
A
So
that's
the
second
thing
I've
heard.
The
third
thing
I've
heard
is
that
if
we
do
that,
we
should
communicate
to
ISO
that
number
one.
We
found
the
problem,
it's
our
Pro,
it's
a
problem,
that's
associated
with
us,
it's
not
our
interpretation
of
of
the
Isis
standard,
and
but
we
should,
in
the
spirit
of
liaising
with
other
standards
organizations
we
should
communicate
that
to
them.
Those
are
the
three
things
I've
heard
have
I
missed
anything
missed
anything.
A
Carson
is
nodding,
his
head,
okay,
I,
feel
like
we
have
consensus
all
right,
so
what
you
can
expect
next
is
the
working
group
working
group
last
call
ends
tomorrow,
and
at
that
point
the
chairs
will
have
a
conversation.
A
A
A
Right,
let
me
let
me
check
with
the
remote
participants
and
the
people
in
the
room.
Is
there
any
other
business
for
sedate
for
today
going
once
going
twice?
Thank
you
and
look
for
us
on
the
mailing
list.
You
should
see
perhaps
still
this
week,
some
correspondents
from
the
chairs
to
the
mailing
list
and
once
again,
thanks
to
all
the
people
who
participated
both
remotely
and
in
the
room.
This
session
is
closed.
B
B
We've
got
the
Prince
of
emails
in
on
Thursday
night.
If
you
want
to
join
a
bunch
of
email
people,
oh.