►
From YouTube: IETF113-SEDATE-20220321-1200
Description
SEDATE meeting session at IETF113
2022/03/21 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
A
Well,
hopefully,
everyone
has
seen
this
already,
as
we
used
to
say
note
it
well,
there's
lots
of
stuff
here
that
controls
how
we
behave
and
and
tells
us
what
to
do
and
and
what
we
need
to
say
along
the
way.
If
you
have
any
questions,
please
ask
all
right:
here's
the
little
tips
thing
in
the
meet
echo
in
the
data
tracker
information
for
this
session,
there's
a
little
online
link
for
the
the
minimum
tool.
Otherwise
you
can
log
in
with
format
echo
either
way.
You
can
then
add
yourself
to
the
queue.
A
A
I
I'll
probably
pop
in
there
and
do
some
things
as
well
as
we
go
and
the
mailing
list
all
the
information's
in
data
tracker,
and
this
is
what
we
have
for
the
agenda
introduction
the
liaison
mark.
Are
you
in
this
session
as
well?
I
can't
yes
excellent
yeah.
If
you
can
can
pop
in
as
well
and
speak
to
the
liaison
and
then
we'll
we'll
get
into
the
the
draft
go
ahead.
Mark.
C
Well,
the
liaison
shouldn't
even
take
me
two
minutes.
The
situation
is
the
iep
could
make
a
selection.
They
did
communicate
that
selection
to
ice
vote.
Iso
has
a
very
formal
process
for
vetting
and
voting
on
its
liaisons
and
that
process
ends
next
week
and
so
on
the
mailing
list.
I
expect
to
have
an
announcement
about
the
iso
liaison
sometime
in
the
middle
of
next
week
and
unless
there
are
questions,
that's
all
I
meant
to
say.
A
A
D
B
B
B
D
A
B
Let's
see
how
yeah
don't
I
get
at
that,
so
I
wanted
to
say,
if
you
think
about
the
status
of
the
current
document,
then
then
maybe
spend
a
couple
of
minutes
confirming
the
recent
directions
we
have
taken.
The
draft
then
focus
on
the
four
issues
that
actually
need
work,
and
if
we
actually
have
time
we
might
want
to
look
at
an
editorial
issue,
but
I
think
we
will
be
way
out
of
time
by
that
in
any
case,
so
right
now,
I
think
there
are
nine
issues
open
on
github.
B
One
is
marked
philosophical,
which
means
oh
well.
The
feedback
is
gone.
Thank
you,
which
means
that
it's
good
to
have
agreement
on
what
we
are
trying
to
achieve
here,
but
there
will
be
no
direct
exchanges.
So
if
you
have
an
opinion
on
on
the
issue
brought
up
in
number
five
and
what
it
could
mean
for
the
current
draft,
please
comment
there.
B
Then
we
have
one
issue
that
is
already
solved,
but
maybe
we
need
to
look
at
this
quickly.
Number
two,
the
editorial
one
and
the
four
that
need
work.
So
the
draft
version
03
was
submitted
at
the
internet
draft
deadline
and
I
think
the
the
main
new
item
was
the
simplification.
We
had
agreed
at
the
last
last
meeting
to
no
longer
try
to
structure
the
registrations
of
extensions
into
namespaces.
B
So
you
can
now
register
extensions,
but
you
cannot
register
namespaces,
so
any
namespaces
that
might
happen
will
happen
due
to
convention
and
gentleman's
agreement.
So
that
was
all
three
and
four
o
four.
We
took
in
one
feature,
requests
which
is
the
support
for
offset
time
zones
which
are
not
your
garden
variety
time
zones,
where
a
politician
makes
rules
on
how
local
time
differs
from
universal
time.
B
Part
as
well,
and
obviously
we
need
to
spend
a
little
bit
more
time,
actually
defining
what
it
means
to
have
two
potentially
two
offsets
in
a
timestamp
one.
The
rfc
3539
offset,
which
is
really
used
to
compute
the
utc
time
from
the
locker
time.
And
this
offset,
which
is
well
could
be
saying,
the
same
thing
could
be
saying
a
different
thing.
They
don't
compete
with
each
other,
but
the
they.
B
The
intent
of
saying
the
time
zone
inside
and
outside
the
brackets
is
different.
And
while
we
are,
we
were
doing
that.
We
got
discussion
about
the
meaning
of
named
ayanna
time
zones
and
I
just
went
ahead
and
wrote
up
what
I
think
the
working
group
so
far
had
been
discussing.
But
you
really
have
to
read
that
text
and
tell
the
editors
what
we
need
to
fix
there.
B
So
it's
kind
of
a
statement
in
the
future.
If
the
politicians
change
what
europe
paris
time
actually
is.
This
is
really
what
we
are
trying
to
say
here
and
of
course
the
intent
may
then
be
in
conflict
with
what
the
actual
offset
in
the
system
design
timestamp
says.
So
we
have
to
have
some
conflicting,
but
we
have
to
have
some
conflict
ending
in
any
case,
because
we,
it
is
possible
to
create
time
extended
time
times
that
are
internally
inconsistent.
B
E
Am
I
audible,
yep
great,
just
a
clarification?
My
understanding
is
that,
in
case
of
mismatch
between
between
whatever
offset
corresponds
to
the
the
yana
time
zone
at
the
moment
versus
the
offset
that
is
included
in
the
time
spam
and
and
without
any
mechanism
to
say
which
one
to
choose
the
default
behavior
would
be
to
trust
the
offset
that
is
within
the
timestamp.
Is
that
correct.
B
Well,
right
now
it
doesn't
say
so
we
would
have
to
write
text
that
actually
provides
the
the
intended
handling
of
this
situation
and
from
the
existing
discussion,
I'm
taking
away
that
this
is
really
highly
application
dependent.
So,
in
the
end,
you
essentially
will
have
to
ask
the
application
what
the
the
supposed
outcome
is
going
to
be.
E
Right,
I
mean
yeah,
I
was
thinking
more
about
the
case
of
the
application,
which
doesn't
have
the
ability
to
to
say
prompt
a
user
to
choose
between
speaking
about
the
case
of
temporal.
Since
it
is
a
programming
api,
we
can
easily
allow
the
programmer
to
to
write
code
in
a
way
that
would
allow
them
to
choose
either
behavior
but
yeah,
so
so
this
is
something
this
is
really
interesting.
Thank
you
carson,
because
this
is
something
that
came
up
many
times
in
within
the
temporals
discussions.
E
Draft
to
to
to
at
least
my
intention
was
that
the
the
offset
that
is
included
in
the
timestamp
is
the
one
that
is
used
to
resolve
the
the
the
instant
and
the
the
time
zone.
Annotation
is
an
additional
bit
of
information
that
could
be
used
for
many
many
things,
but
you
know
also
could
then
be
safely
ignored,
if
not
needed,
but
yeah.
E
So
my
suggestion
is
that,
as
long
as
we
have
agreement
within
this
group
that
trusting
the
offset
when,
when
the
in
case
of
conflicts,
when
there's
no
way
to
to
ask
for
more
clarification,
be
the
default
behavior.
I
think
we
already
have
support
for
this,
and
if
so,
then,
then
we
could
just
proceed
and
add
more
text
to
to
make
that
more
explicit.
E
G
G
D
G
Yeah,
I
I
I
have
a
hard
time
accepting
accepting
that
I
mean
the
the
the
offset,
tells
you
what
you
believe
the
offset
to
be
at
the
time
the
time
step
was
created
and
what
you're
finding
with
with
this
notation
is
that
at
the
point
it's
used,
that
offset
is
no
longer
correct.
So
what
you're
saying
is
you
should
actually
agree?
You
should
actually
use
an
incorrect
offset.
B
B
G
G
You
probably
should
do
at
that
point,
which
is
reschedule
meetings
and
things
I,
but
what
you
actually
do
is
I
mean
what
you
should
do
is
reschedule,
I
guess
so,
yeah,
okay,
maybe
it's
just
a
matter
of
how
of
how
you
see
what
what
you
should
do
when
this
is
discovered?
It's
a
good
thing
to
have
both
in
a
sense
because
it
it
it
allows
you
to
discover
that
the
world's
changed
since
you,
since
you
wrote
down
that
time,
step.
G
A
B
E
A
E
Cool
you
hear
me:
okay,
yeah
did
you
to
respond
to
to
what
michael
said.
I
think
I
disagree
with
with
with
this
statement
that
if
there
is
a
conflict,
then
then
necessarily
the
offset
is
wrong
in
it.
It
could
be
either
way.
So
let's
say
I
I
schedule
an
international
meeting
and
and
somehow
the
the
offset-
and
you
know
the
tz
rules
change
and
now
the
offset
is
out
of
you
know
it
doesn't
work
with
my
timezone
anymore.
E
That
still
means
that
the
meeting
needs
to
happen
at
the
same
instant
in
time
right
so
so
this
is
one
of
those
cases
when
I'd
still
want
the
meeting
to
be
at
the
same
time,
irrespective
at
the
same
offset,
irrespective
of
if
the,
if
the,
if
the
tz
rules
changed
and
then
then
there's
of
course
also
cases
where
I
I
would
not
want
that.
I
would
want
to
to
be
woken
up
at
8
a.m.
E
Every
morning,
irrespective
of
what
my
local
time
zone
is,
so
I
think
either
could
be
could
be
useful
depending
on
on
the
application
is,
as
was
mentioned,
to
respond
to
what
neil
said.
I
I
agree
like
if,
if
the
application
can
make
a
call,
if
the
application
has
enough
context
to
make
a
call,
let's
say
then
then
it
should
be
able
to
do
that.
I
was
specifying
more
about
the
case
when,
when
let's
say
you
have
a
demon
running
on
a
server
somewhere,
which
is
no
context
about
what
what
does
this
person
like?
E
I
Hi
this
is
pete
resnick
and
by
the
way
the
mic
is
working,
the
audio
in
this
room
is
a
little
strange
anyway.
I
actually
disagree
with
ujwal
and
karsten
on
this.
If
you
know
that
you've
scheduled
a
meeting
that
will
always
be
at
an
offset
plus
800,
then
why
would
you
add
a
textual
time
zone
after
that?
If
that
hint
is
providing
nothing
that
is
going
to
be
useful?
If
there's
a
conflict,
then
you
should
leave
out
that
hint.
I
If
the
meeting
will
be
at
plus
oh
800,
then
the
meeting
will
be
at
plus
0
800
and
saying
that
it
should
be.
You
know
in
some
chinese
time
zone
that
might
change
is
not
useful,
and
it
seems
to
me
that
the
right
thing
to
do
is
if
you're,
adding
the
hint
that
this
is
in
a
textual
time
zone.
Then
your
intention
is
that
this
is
a
moving
target
and
the
offset
is
just
what
it
was
when
I
created
the
meeting.
I
If
that
is
not
your
intent,
then
there
needs
to
be
a
way
to
explicitly
mark
that.
That's
not
the
time
zone.
You
want
you're,
giving
the
hint
for
some.
Other
reason,
but
I
I'm
trying
to
figure
out
what
the
use
case
is
of.
I
want
the
interpretation
to
be
at
the
33
39
offset,
but
still
add
this
hint.
I
don't
understand
what
that
use
case
looks
like.
B
A
I
But
this
is
pete
again,
so
if
you
scheduled
it
in
pacific
daylight
time
as
currently
imagined,
what
is
your
intent?
Is
your
intent
to
say
that
if
that
definition
changes,
the
meeting
has
moved
and
you
have
to
reinterpret
or
is
your
intent
that
it
is
at
the
3339
offset?
If
it's
the
latter,
then
why
are
you
telling
me
pacific
daylight
time
because
that's
a
meaningless
piece
of
data.
B
Well,
it's
meaningful
in
the
context
of
an
application
that
actually
shows
appointments,
because
if
I
have
an
appointment
that
is
no
longer
sharply
defined
because
the
the
people
out
in
the
world
think
it's
in
a
different
at
a
different
point
in
time
than
the
people
in
california,
then
I
have
a
problem
and
acting
as
if
I
had,
I
didn't,
have
a
problem.
It's
not
useful!
B
I
A
If
I'm
an
end
user,
not
the
person
hand
constructing
this,
this
artifact
over
the
wire,
my
intent,
is
I'd
like
it
to
be
in
pacific
time.
At
this
time
of
day
and
encoding,
both
those
bits
of
information
in
the
data
format
allows
that
intent
to
be
transferred
to
another
system
in
a
way
that
the
other
system
can
understand.
I
mean
pacific
time,
not
just
-800.
I
D
A
To
say
the
exact
time
stamp,
but
the
the
idea
of
this
is
to
transfer
that
information
between
systems,
including
the
user's
intent,
but
the
the
time
that
they
might
want
to
lock
in
might
be
the
hard
coded
time.
There's
no
easy
way
in
this
format
to
to
say
which
one's
more
important
and
I
did
make
a
proposal
a
while
back,
which
we
decided
was
too
complex
to
have
a
way
to
tag
which
one
matters
I.
I
I
Now
we
you
may
disagree
with
that.
You
may
think
that
no
system
wise.
We
should
design
this
such
that.
If
the
user
says
pacific
time
today
and
it
moves
to
0.700,
then
to
minus
0700,
then
we
should
move
the
meeting
and
ignore
that
it's
labeled
pacific
time,
but
if
that
is
the
system's
default,
the
system
need
not
add
the
pacific
time
to
the
timestamp,
because
someone
on
the
other
end
of
the
world
doesn't
care
that
it
was
labeled
by
the
original
user
as
pacific
time.
A
Yeah,
but
the
user
themself,
when
they
transfer
between
systems
does
care,
and
this
is
this-
is
a
data
interchange
format,
that's
not
just
for
the
use
case,
you're
imagining.
It's
also
for
the
use
case,
where
you
are
storing
your
own
information
and
coming
back
to
it
later
or
where
you're
transferring
it
between
systems
and
having
that
annotation
is
of
value
to
the
user.
Even
if
it's
not
the
primary
intent.
I
B
I
think
the
difference
here
is
that
you
are
assuming
that
the
system
must
automatically
resolve
any
nonsense.
That
politicians
do-
and
I
don't
think,
that's
possible.
So
it's
really
useful
to
have
time
exams
that
say:
hey
I'm
inconsistent.
We
have
planned
something
that
no
longer
works
in
the
real
world.
Please
supply
new
information.
D
Ken
murchison
so
pete
pretty
much
said
everything
that
I
had
come
up
here
to
to
say.
The
the
issue
we
have
here
is
that
we're
we're
extending
three
through
three
nine,
so
we
can't
strip
off
the
numeric
time
zone.
So
there's
an
artifact
that
we're
stuck
with,
even
if
all
we
really
want
is
the
iana
time
zone.
D
Zero
zero,
as
the
offset,
which
is
considered
nonsensical
in
eight
five,
three
six.
That
might
be
a
marker
that
we
could
use
to
say
I'm
here,
just
as
a
placeholder.
I,
what
I
really
want
is
the
iono
time
zone
now,
whether
that
causes
a
conflict
with
three
three
three
nine.
I
have
not
re
researched
that
plus
and
minus
zero
might
be
treated
the
exact
same
way,
in
which
case
my
suggestion
is
useless,
but
something
to
look
into.
G
So
I
yeah-
I
was
just
on
the
point
of
maybe
I
I
let
me
just
hang.
I
think
people
are
saying
what
I
was
going
to
say
anyway.
I
I
I
just.
I
think
I
think
you
should
treat
it
as
a
flag
to
indicate
that
I
think
what
you
said
is
is
that
this
is
what
I
thought
the
offset
was
at
the
time
that
this
is
written
down,
but
now
it's
not
the
same.
A
B
Yeah,
I
think
we
have
had
a
good
discussion
here
and
have
to
take
that
to
the
list
and
yeah
peter's
on
the
chat
again
using
the
word,
trust,
which
is
not
a
meaningful
concept
here.
So
there
is
no
trust.
Somebody
sits
in
front
of
their
computer
and
tries
to
make
something
happen,
and
the
world
is
unfortunately
working
against
that
and
we
have
to
find
a
way
to
yeah
it's
the
intended
offset,
but
other
people
have
agreed
to
that
and
they
have
agreed
to
that
based
on
the
old
meaning
of
the
time
zone.
A
All
right,
the
if
I
could
just
summarize
what
I've
heard
there
was
fairly
strong
indication
from
a
lot
of
people
that
there
needs
to
be
an
explicit
decision
somehow
either
explicitly
it's
always
the
zone
explicitly.
It's
always
the
offset
or
something
added
to
the
format
that
says
explicitly
what
the
intent
of
the
creator
of
this
timestamp
is.
I
don't
know
if
there
was
a
a
which
of
these
are
acceptable
or
unacceptable
people,
but
it
has
to
be
an
explicit
somehow
not
just
a
best
guess.
I
I
What
the
markers
mean?
So,
if
you
want
there
to
be
a
case
where
I'm
giving
you
something,
but
I'm
not
sure
what
it
means
there
needs
to
be
a
default
interpretation
and
I
think
that's.
The
crux
of
the
disagreement
is:
if
the
system
wants
to
express
I've
been
given
an
offset,
a
numeric
offset
and
I've
been
given
a
textual
time
zone
name,
and
I
I
the
system
have
not
been
able
to
assess
the
creator's
intent.
I
A
I
That's
right
and-
and
I
that's
that's-
the
clarification
is,
there's
got
to
be
a
default
interpretation
for
I
don't
know,
but
everyone's
going
to
assume
that
it's
and
it
sounds
like
the
answer-
is
everybody's,
going
to
assume
that
it's
the
numeric
offset
and
then
there's
got
to
be
an
explicit
marker
which
says
no
in
this
case.
I
don't
want
you
to
interpret
that
as
the
numeric
offset.
I
want
you
to
always
the
intent
of
the
user
was.
I
want
you
to
interpret
the
textual
time
zone
name.
B
B
B
B
So
last
time
we
had
these
syntax
proposals,
so,
for
instance,
you
could
say
that
the
the
information
that
a
calendar
on
the
hebrew
system
is
desirable,
that
would
be
a
hint
and
if
you
cannot
do
that,
you
just
ignore
it
or
you
could
say
something
like
the
calendar
is
critical.
So
if
you
cannot
show
it
this
way,
don't
show
it
at
all
reject
the
date
and
there
was
an
alternative
syntax
proposed
with
the
exclamation
mark
at
the
start,
and
that
has
the
advantage
that
can
be
applied
to
the
time
zone
hint
as
well.
B
E
Go
ahead,
I
one
thing
that
I
want
to
say
about
this
proposal
is
that,
while
it
solves
a
lot
of
the
problems
that
we
just
talked
about,
we
one
of
the
goals
that
that
we
had
was
to
was
to
allow
certain
implementations
that
already
follow
part
of
this
standard
as
sort
of
a
de
facto
non-standard
format
would
continue
to
keep
working,
but
including
this
would
make
them
also
non-compliant.
So
they
need
to
actually
change.
Go
back
and
change.
E
B
I
So
in
the
previous
discussion
we
were
talking
about
well,
you
know
you
might
interpret
the
date
to
mean
the
numeric
time
zone.
You
might
interpret
the
date
depending
on
what
markers
or
what
your
defaults
were
to
be
the
textual
time
zone
and
that
the
other
piece
was
the
the
hint.
But
I
mean
if
I'm
running
a
calendar
system
and
I
get
an
event
and
I
support
this
extension
and
I
get
an
event
that
has
a
critical
thing
that
I
don't
understand.
I
I
B
Okay
yeah,
so
I
think
that
that's
another
clear,
let's
take
this
to
the
list,
then
we
have
a
little
problem.
We
don't
really
have
a
good
name
for
the
thing,
and
the
draft
currently
calls
it
the
internet
date
type
for
date,
time
format,
which
is
not
really
very
sharply
defined,
and
also
a
little
bit
overpretentious.
A
A
B
A
B
An
extension
so
that
that's
again
one
thing
we
have
to
define
now,
so
we
keep
this
extension
point
open
for
people
to
define
something
in
there
and
well.
Maybe
we
even
can
do
something
useful
while
we
are
providing
this
at
least
one
extension
with
the
document.
So
if
you
have
other
proposals
what
we
should
define
as
an
extension
tag
this
this
would
be
very
interesting.
A
A
A
I
can
just
do
that
and
then
it'll
go
off
to
you
to
get
approved
anyway,
and
the
other
one
is
submit
the
draft
to
asg
for
publication,
which
is
obviously
not
going
to
happen
in
december
2021
we're
waiting
for
the
iso
liaison
which
should
come
through
next
week.
It
sounds
like
the
one
big
piece
of
debate
we
still
have
is
how
we're
going
to
indicate
the
important
what
is
more
important
out
of
the
offset
or
the
time
zone
name.
B
B
But
of
course
the
the
details
of
conflicting
hints
and
elective
versus
critical
will
probably
take
another
couple
of
months
to
clarify
and
it
helps
if
people
actually
follow
the
github
and
our
meeting
list
discussions
and
and
comment
there.
So
we
we
had
a
little
bit
of
a
break
in
the
discussion
and
have
been
speeding
up
again,
and
I
think
we
don't
really
need
another
break
to
finish.