►
From YouTube: IETF-SEDATE-20211209-2000
Description
SEDATE meeting session at IETF
2021/12/09 2000
https://datatracker.ietf.org/meeting//proceedings/
A
B
D
D
A
A
A
A
Okay,
those
should
be
on
the
way
to
you.
Let
me
go
away
and
come
back.
You
should
have
the
slides
in
your
inbox,
I'll,
stop
sharing
them.
Also,
I
will
send
you
a
copy
of
carsten
slides
as
well
and
then
I'll
go
away
and
come
back.
I
was-
and
I
still
am,
I
see
recording
the
session,
so
we
don't
really
need
a
traditional
note
taker,
just
someone
to
sort
of
record
the
big
decisions.
I
think
all
right
so
like
I
said,
let
me
go
away
and
I
will
come
back.
C
C
C
D
So
I
guess
well,
while
we're
what
we're
waiting
around
here,
I
might
as
well
start
with
the
noteworld,
welcome
everybody
I
think,
from
the
list
of
names.
I
see
here
that
everyone
has
been
involved
in
these
meetings
before
or
been
involved
in
ietf
before,
but
just
as
a
reminder,
everything
that
happens
in
this
meeting.
It
is
an
ietf
meeting.
It
is
covered
under
the
ihf's
noteworld,
so
you
have
a
bunch
of
responsibilities.
D
If
you
choose
to
make
any
contributions,
they
are
covered
under
the
the
copyright
and
patents
participation
rules
here
and,
of
course,
there
are
also
the
anti-harassment
code
of
conduct,
so
please
behave
well
and
be
kind
to
each
other
and
all
these
nice
things
moving
along
briefly
to
the
the
rest
of
this.
We've
been
more
aware
recently
about
work
working
well
with
each
other
and
making
sure
your
contributions
progress
the
work
rather
than
than
attack
of
people.
D
So
I
won't
spend
too
long
on
this,
but
let's
be
good,
basically
we're
going
to
start
just
with
a
brief
agenda
bashing
see
if
there's
anything
anyone
wants
to
add
and
then
I'll
hand
over
to
carsten
to
present
from
there.
So
does
anybody
have
anything
you
want
to
add
to
the
agenda
or
any
changes
to
make.
D
D
D
I
I
see
now
there
are
some
tiny
little
icons
if
you,
because
I
went
to
in
data
tracker
to
the
sedate
working
group
meetings
and
then
clicked
on
the
meeting
from
there,
and
there
are
some
tiny
icons
up
the
top
very
small
and
unassuming
with
all
the
other
information
there.
So
there
we
go
all
right,
yep
cool.
I
will
take
notes
into
that.
Then,
with
that
said,
we're
basically
at
the
end
of
the
the
slides.
I
think
here
the
last
one
is
just
a
and
other
business
slides
yeah.
So
let's
switch
over.
A
I
can
do
this
in
less
than
one
minute.
Last
wednesday
the
iep
met
and
picked
a
liaison.
The
liaison's
been
been
selected.
It's
not
me,
I'm
happy
to
say
I
guess,
and
but
the
actual
name
of
the
person
hasn't
been
announced.
I
expect
that
it
should
be
announced
early
next
week
and
as
soon
as
it
is
I'll
send
a
note
to
the
list.
I
think
that
was
less
than
60
seconds.
E
Okay,
so
I
I
slept
together
some
some
really
quick
slides
for
this.
I
was
kind
of
torn
between
waiting
for
the
mailing
list
to
actually
have
have
some
discussion.
I
was
going
to
reference
in
the
slides,
and
so
I
waited
maybe
a
little
bit
too
long
for
for
making
some
yeah
so
next
slide.
Essentially
the
the
current
status
is.
D
D
D
E
D
E
E
E
E
Great,
so,
let's
go
back
to
the
slides,
so
what
I
would
like
to
do,
we
still
have
eight
issues
open
on
github.
I
didn't
change
anything
there.
What
I
would
like
to
do
is
first
look
at
the
two
pull
requests
and
see
whether
these
are
actually
going
in
the
right
direction.
If
they
don't,
then
we
should
focus
on
fixing
these
pull
requests
or
the
these
changes
that
led
up
to
o2,
and
then
we
can
essentially
take
the
open
issues
and
group
them
into
issues
that
are
now
officially
out
of
scope.
E
So
we
can
get
to
them
later,
issues
that
essentially
have
been
answered
by
by
this.
These
changes
and
some
some
four
issues
that
we
actually
need
to
work
on
and,
of
course
there
are
more
issues.
We
haven't
really
started
making
new
issues
now
and
we
had
a
little
bit
of
a
discussion
on
the
mailing
list
on
critical
versus
elective
extensions.
E
But
it's
it's
a
statement
that
this
draft
focuses
on
these
informational
extensions
and
a
future
recharger
might
enable
the
working
group
to
actually
add
extensions
that
change
the
meaning.
So,
for
instance,
we
had
talked
about
calendaring
support
floating
times
and
so
on,
which
would
be
out
of
scope
by
the
current
text.
G
News
that
thanks,
oh
yeah,
I
just
want
to
ask
whether
that
means
the
scope
doesn't
cover
all
the
cases
that
the
temporal
folks
from
that
brought
this
to
us
need,
because
that
was
my
understanding
is
they
have
some
that
would
not
be
covered
by
this,
and
that
was
I
thought.
The
original
purpose
of
this
group.
E
B
Okay,
great
yeah,
I
think
our
main
focus
is
to
get
the
informational
extensions
as
as
are
mentioned
here
in
and
there's
definitely
the
need
to
standardize
the
sub
formats,
but
it's
not
as
urgent
for
us.
So
we're
happy
to
to
to
sort
of
leave
that
out
until
we
can
figure
out
the
best
strategy
for
that.
But
as
long
as
the
the
extension
format
is
standardized,
that's
a
great
start
for
temporal.
B
G
B
E
The
the
other
result
of
the
itf-112
discussion
that
I
tried
to
write
up
was
to
simplify
the
key
and
namespace
handling
and
and
all
that
actually
focuses
on
that
focuses
around
that
registry
that
I
just
talked
about.
So
essentially
we
have
one
iana
registry
that
registers
what
is
called
x
name
on
this
slide
and
again
we
have
to
define
the
the
policy,
so
we
could
define
a
restrictive
policy
for
that.
E
We
could
define
a
more
open
policy
that
that
has
not
yet
been
decided,
and
I
think
that
that's
probably
the
biggest
decision
we
we
have
to
make
for
that.
And
apart
from
that
that
registry
we
have
the
the
syntax
defined,
and
I
think
it's
it's
important-
that
people
look
at
the
syntax.
I
I
didn't
copy
the
abnf
here
on
on
the
slide,
whether
that's
actually
good
enough
as
a
generic
container
mechanism
for
people
to
define
their
extensions
in
yeah
right.
So
so,
if
you
go
into
the.
E
So
basically,
the
the
syntax
is
on
line
3,
24,
new
399,
old
and
date.
Time
extended
is
a
date
time
and
traditional
is
the
33
39
daytime,
followed
by
a
suffix
and
the
suffix
is
a
time
zone
extension
followed
by
zero
or
more
excuse
me,
an
optional
time
zone
extension
followed
by
zero
or
more
suffix
tags.
E
E
D
D
D
B
So
so
that's
I
think,
two
questions
and
one
I
can
try
to
answer
that.
On
the
first
hand,
we
we
chose
this
namespace
format,
because
we
were
inspired
by
the
unicode
bcp-47
stuff,
so
so
that
was
definitely
an
inspiration
regarding
extensions
that
might
conflict
with
each
other.
The
draft
did
mention
that
the
extension
that
came
first
would
take
precedence.
B
C
E
Yeah,
that's
pretty
much
the
the
discussion
how
restrictive
the
registration
policy
should
be
yeah,
so
we
can
go
for
rfc
required,
which
would
mean
that
there
would
be
some
extensive
discussion
and
vetting
of
an
extension
or
we
could
go
for
specification
required
specification
required
means.
Somebody
has
to
write
up
the
specification
and
a
designated
expert
who
is
nominated
by
the
isg
will
check
that
specification
against
a
number
of
items
that
we
would
write
up
in
in
this
document.
E
C
I
mean
the
problem
with
with
I
mean
it's,
it's
really
just
sort
of
reinventing
the
x-dash
problem
is
is
what
I
is.
What
I
see
happening
is
the
the
problem.
There
is
people
in
you
know
you
should
say
in
the
countering
world
decided.
Oh,
we
need
to
have
this
property
to
do
something.
We
can
use
the
x
dash
mechanism
and
we'll
define
it
and
then,
of
course
what
happens
is
it
goes
into
production
like
that
and
would
be
better
off,
not
even
allowing
that
and
saying
why?
E
E
C
E
C
E
G
Okay,
sure,
so
what
I
was
going
to
say
was
this
problem
comes
up
every
single
time,
because
it
is
a
common
problem
tool
that
all
any
kind
of
data
format
from
protocol
and
there's
a
key
difference
of.
Is
it
a
data
format
or
a
protocol,
this
one's
a
data
format
that
makes
it
harder,
because
you
can't
negotiate
with
the
other
side
when
it's
protocol,
you
can
do
a
lot
more
to
make
sure
that
you
know
both
sides
have
to
opt
into
anything
new,
and
that
kind
of
thing.
G
G
Even
if
it's
just
you
know,
registering
proper
name
space
because
as
mike
was
saying
as
soon
as
someone
does
something
useful
and
it
starts
getting
out
in
the
wild,
everyone
else
is
going
to
want
to
implement
it
as
well
for
interoperability
they're
going
to
have
to,
and
so
you
might
as
well
have
made
it
easier
to
standardize
properly.
Rather
than
have
everyone
use
x,
dash
forevermore.
C
F
Sorry,
I
don't
know
if
people
can
hear
me
now
we
this
business
using
two
zooms
at
a
meet
echo
at
the
same
day
is,
is
a
problem
we
this
this
next
business
really
started
with
email
and
our
experience
with
it's
been
terrible.
There
is
actually
an
ietf
normative
document
which
says:
don't
do
that
anymore.
F
I
understand
all
the
arguments
for
it.
I
think
those
of
us
have
been
around
for
a
while,
though
before,
but
this
is
just
not
a
good
way
to
go
to
try
to
put
things
in
there
that
are
half
standard
and
maybe
experimental,
but
maybe
it's
not
an
experiment
anymore,
and
maybe
you
could
do
this,
but
maybe
somebody
else
is
going
to
do
this
in
a
different
way.
F
I
I
I
think
you
have
to
the
register.
Is
richard
register
a
name
indicate
it's
provisional
indicate
when
it's
times
out
it
disappears
if
you're
not
going
to
use
it,
maybe
or
make
it
make
it
permanent,
make
the
definitions
better,
but
but
relying
on
on
a
particular
piece
of
syntax,
like
this
x-dash,
to
convey
too
many
things
that
some
of
which
may
not
be
true
by
the
time
somebody
sees
it
just
is
not
workable
in
the
long
run.
D
E
C
B
Okay
but
yeah-
I
I
think
it's
clarified
at
this
point,
so
I
wanted
to
ask
if
people
are
against
the
x
dash
or
just
name
spacing
in
general
and
and
it
seems
that
people
are
against
name
spacing
in
general,
but
I
just
wanted
to
clarify
that
name.
Spacing
is
not
a
strong
position
on
the
temporal
side,
so
yeah
it's.
E
C
E
D
D
H
I
not
working
previously
yeah,
I
think
the
the
like
ujjwal
had
said
earlier.
The
the
the
idea
of
having
this
mechanism
with
namespaces
is
directly
inspired
by
the
bcp-47
rfc,
and
you
know
if,
if
there's
another
system
that
works
better
than
that,
I
think
we're.
You
know
very
happy
to
entertain
that.
I,
I
think
one
of
the
advantages
of
having
the
name
spaces
is
that
in
bcp-47,
for
instance,
is
that
unicode
could
decide
to
can
decide
to
add
additional
keys
under
its
namespace.
H
You
know
with
with
a
more
lightweight
process-
and
you
know
I
think,
in
the
in
in
this
ca
in
this
in
this
calendar
syntax,
where
we're
discussing
you
know,
I
could
foresee,
for
example,
there
may
need
to
be
in
a
unicode
may
want
to
add
an
additional
field.
I
don't
exactly
know
what
that
would
be
at
this
particular
case,
to
specify
maybe
a
a
a
time
calendar
system,
for
example,
like
maybe
uca,
represents
the
date
calendar,
maybe
there's
also
a
system
for
the
time
calendar.
H
That's
been
something
idea,
that's
been
brought
up
before,
with
with
a
lower
cost
process
to
add
it.
I
I
think
that,
probably
if,
if
like,
if
we
don't
have
name
spacing,
we
should
have
established,
we
should
have
a
way
established
to
add
to
you
know
a
a
low-cost
mechanism
for
you
know
proposing
and
standardizing
these
these
these
keys,
and
I
think
that
if
we
did
have
that
process,
then
I
agree
that
you
know.
I
think
that
the
namespaces
are
probably
not
necessary,
but
I
would
also
you
know.
H
C
E
E
We
can
do
registries
with
a
policy
of
rfc
required,
which
means
we
have
a
lot
of
process
or
we
can
make
registries
with
the
policy
of
specification
required,
which
means
we
have
a
relatively
easy
process,
which
is
run
by
a
designated
expert,
who
gets
a
little
bit
of
a
of
a
sar
position,
but
that
designated
expert
can
be
guided
by
by
statements
from
the
rfc
that
sets
up
the
registry
to
own.
To
only
do
things
that
we
we
consider
useful
here.
C
D
F
People
should
try
to
keep
in
mind
that,
in
general,
the
most
important
criteria
for
doing
any
of
these
things
is
that
you
don't
end
up
in
a
situation
where
two
different
people
or
organizations
are
using
two,
the
same
strength
to
develop
something
different,
that
that's
where
you
get
chaos,
and
that's
that's,
of
course,
the
problem.
The
next
stage
doesn't
solve
how
far
you
want
to
go
into
trying
to
get
specifications
trying
to
encourage
specificity.
F
Trying
to
evaluate
applications
is
is
another
question,
but
with
the
understanding,
if
you
make
it
too
hard,
people
will
ignore
you
do
whatever
they
feel
like
anyway,
but
but
the
main
thing
is
to
make
absolutely
certain
and
provisional
registries,
which
are
very
lightweight,
can
be
a
way
of
doing
it
that
you
don't,
if
you
can
all
avoid
it
end
up
with
two
people
accidentally
using
the
same
strength.
You
know
two
different
things:
everything.
A
D
E
Yeah
this
one,
so
I
think
we
we
just
resolved
to
radically
simplify
this,
getting
rid
of
the
namespaces
having
a
registry
that
allows
provisional
registration,
and
we
have
to
write
up
the
details
of
that.
There
are
lots
of
devils
in
that
detail
and
we
can
look
at
alternative
policies
like
rfc
required
or
specification
required,
and
I
I
can.
I
think
I
understand
what
the
the
work
group
wants.
Well
enough,
that
I
can
make
reasonable
proposals
there.
E
Cool
and
on
john's
chat
comment
pointing
to
the
media
type
registry,
of
course,
that
that
is
a
pretty
good
example
for
for
how
you
actually
can
hurt
the
the
cats
here.
So
I
think
we
can
learn
a
lot
from
that
and
and
we
should
so,
media
types
have
provisional
registrations
and-
and
they
also
have
vendor
trees,
which
we
may
or
may
not
want
to
to
adopt.
Probably
not,
and
I
think
we
can
learn
a
lot
from
that.
So
I
I
second
the
recommendation
of
reading
that
rc.
E
So
there
are
three
open
issues
that
essentially
are
out
of
scope
now,
which
is
adding
time
scales,
adding
flow
floating
time
mechanism
and
adding
away
a
time
zone
name,
can
override
the
time
zone
offset.
So
all
three
are
out
of
scope
with
the
the
sedate
charter,
which
doesn't
mean
that
when
we
actually
come
to
the
the
place,
where
we
actually
define
extensions
like
that,
we
it
doesn't
mean
we
cannot
use
the
syntax
we
defined
in
this
document.
E
We
just
cannot
define
these
specific
extensions
just
yet,
so
my
assumption
would
be
all
three
actually
would
go
into
extensions
and
yeah.
We
have
to
discuss
for
the
floating
time
we
might
want
to
discuss
whether
we
want
to
have
a
way
to
make
sure
this
doesn't
look
like
a
rfc
339
date,
so
maybe
there's
a
little
bit
more
than
an
extension,
but
we
probably
only
can
do
this
properly
once
we
we
are
chartered
to
do
so.
E
E
E
E
E
E
E
I
Yeah,
I
just
have
a
quick
feedback
on
that.
Certainly,
on
the
temporal
side,
we
have
been
assuming
from
the
get-go
that
this
is
for
programs
and
that
there's
sort
of
separate
software
for
for
parsing
of
human,
readable
values,
separate
software
for
displaying
localized
human,
readable
values,
and
so
the
primary
consumers
we've
anticipated
for
this
format
are
our
software
and
then
you
know
obviously
developers
in
the
in
the
prospect
of
debugging
or
logging
or
whatnot.
But
but
it's
not
viewed
as
an
end
user
facing
format.
E
Yeah,
so
I
came
up
with
a
quick
proposal:
how
to
do
elective
versus
critical
extensions
and,
for
instance,
we
could
simply
replace
the
equal
design
by
something
like
a
exclamation
mark
or
an
exclamation
mark,
equal
design
or
whatever
syntax
can
can
come
later.
To
say
that
an
extension
really
needs
to
be
understood.
D
E
G
Yeah,
I
think
changing
the
syntax
within
the
extension
like
that
is
likely
to
cause
issues,
because
it
won't
happen
very
often,
and
so
people
will
not
read
the
spec
code,
something
that
just
presumes:
it's
always
an
equals
and
that
will
just
break
if
it's
different,
even
if
they
actually
supported
it.
I
I
would
prefer
to
keep
things
simpler.
I
think
either
we
don't
need
it
yeah.
It's
just
like
you
say
in
respect.
G
If
this
is
required,
acquired
or
sorry
in
the
registry
and
look
if
apps
don't
understand
it,
they're
going
to
have
problems
regardless
of
what
you
do,
the
other
option
is
you
have
an
extension
that
explicitly
means
all
of
these
extensions
must
be
fully
understood
for
you
to
process
this
like
so
you
know,
miracle
standards,
uca
equals
hebrew
and
then
square
brackets
required
or
status
equals
required
or
something
close
square
brackets.
You
see
what
I
mean.
E
C
F
F
I
I
mean
my
my
concern
with
this.
One
is
that
oftentimes,
the
people
creating
strings
are
different
from
the
people
interpreting
strings
and
that
a
lot
of
times
they
won't
know
ahead
of
time
how
it's
going
to
get
used,
and
so
I
would
it
just
feels
like
there's,
there's
two
ends
that
can
screw
up
and
if
either
one
of
them
screws
up,
then
it
breaks
and
it
breaks
in
unpredictable
ways.
This
feels
like
a
harder
one
and
rather
like
either.
D
F
F
Yeah,
if,
if
you're
going
to
try
to
make
this
distinction-
and-
and
this
is
part
of
my
somewhat
cynical
comment
in
the
email-
that
it
cannot
be
on
a
registration
basis,
it
needs
to
be
global
and
it
needs
to
be
absolutely
clear
in
your
face
rather
than
something
which
depends
on
well.
For
example,
looking
at
the
slide
on
a
single
character,
clue
in
syntax,
because
not
only
will
people
ignore
it
at
the
computers.
D
D
E
I
C
C
I
D
D
D
A
Is
the
signal
have
another
interim
meeting,
so
I
think,
rather
than
make
that
decision
now
the
right
way
to
go
about
that
is
to
see
whether
or
not
we
can
get
a
new
draft
out
the
door
sometime
in
january
and
cf.
Karsten
is
up
for
that
and
also
see
how
the
discussion
on
the
mailing
list
goes
and
then
I
think
braun
and
I
would
be
happy
to
do
the
usual
doodle
poll
and
all
the
administrative
stuff.
I'm
certainly
happy
to
take
care
of
that.
A
F
A
Okay,
fair
enough,
fair
enough,
so
I
think
what
we'll
do
is
we'll
encourage
further
conversations
on
the
list
there.
I
noted
a
couple
issues
that
I
should
probably
talk
to
braun
about
and
then,
if
we
do,
if
we
do
have
a
a
new
draft
under
the
christmas
tree
or
ready
for
a
dramatic
reading
at
somebody's
new
year's
party,
that
would
be
great
and
yeah.
Well,
some
of
us
know
how
to
have
fun.
A
I
think
I
think
then
an
interim
in
january
would
be
great
because
I
would
feel
like-
and
this
is
a
really
naive
point
of
view.
I
would
feel
like
we're,
making
a
pretty
good
progress
here
and
can
start
thinking
about
the
timetable
for
when
this
be
ready
for
finishing
up
and
last
call
and
all
the
administrative
stuff
that
goes
on
at
the
end
and
then
in
january.
A
I
I
I
have
one
quick
question
so
regarding
namespaces
and
will
the
string
format
of
the
of
the
calendar
annotation
change
at
all
as
a
result
of
that
discussion
like?
Is
it
still?
U
dash
ca
equals,
or
should
it
be
something
else
because
that
that
will
actually
affect
us
on
the
temporal
side,
and
if
we,
if
we
are
going
to
change
it,
we'd
love
to
be
able
to
change
it
sooner
rather
than
later.
E
And
one
thing:
we
said
that
we
were
going
to
get
rid
of
the
dash,
but
then
there
were
other
people
who
wanted
to
have
some
structure
in
that
name.
So
maybe
we
are
not
getting
rid
of
the
dash.
If
you
are
saying
that
life
is
easier
for
you,
if
you
have
the
dash,
then
maybe
we
should
just
make
it
into
a
character
you
can
use
like
you
can
use
an
a
or
a
said.
I
B
E
D
I
guess
this
is
me
right:
calex
is
looking
to
recharter.
We
could
definitely
bring
this
under
the
charter
of
cal
ext,
so
the
question
then
is:
do
we
want
to,
or
do
we
want
to
keep
a
separate
group?
Calex's
planned
recharter
is
to
do
maintenance
of
all
the
related
formats,
and
so
adding
this
to
calyx
charter
instead
would
definitely
be
possible.