►
From YouTube: IETF114-SEDATE-20220725-1730
Description
SEDATE meeting session at IETF114
2022/07/25 1730
https://datatracker.ietf.org/meeting/114/proceedings/
A
A
B
A
D
D
All
right
welcome
to
monday
afternoon
today
this
is
our
hour-long
session.
You
should
be
able
to
see
some
slides
that
I'm
presenting
here
we
go
first
of
all,
here's
your
eye
test.
This
is
the
usual
notewell,
I'm
sure
the
veterans
here
have
read
this,
but
everyone
should
be
aware
of
its
contents
in
terms
of
this
particular
meeting
ietf
114.
D
We
have
some
folks
here
who
are
in
person.
We
also
have
a
group
who's
online.
That's
great
for
the
in-person
participants.
Remember
that
there
is
a
local
tool
for
this
meeting.
It's
called
the
on-site
tool
in
the
client
and
if
you
go
to
meet
trip
meet
echo
you'll
see
the
icon.
That
gets
you
the
local
client.
D
We
will
monitor
the
mic
queue
that
won't
be
a
problem
for
us
for
remote
participants.
It's
the
usual
situation,
make
sure
your
audio
and
video
are
off
and
for
the
people
who
are
here
in
person.
Here's
a
reminder,
although
I
look
around
the
room-
and
I
see-
there's
not
a
problem-
is
masks-
are
mandatory
in
ietf
sessions
this
week.
So
thank
you
to
all
the
people
who
are
here
in
person
who
are
masked
up
in
terms
of
resources
for
philadelphia.
D
The
comment
in
the
chat
is
that
zulip
is
the
current
choice.
That's
right!
There's
a
link
at
the
bottom
clients
do
work.
The
agenda
is
posted
online
and
in
the
data
tracker,
it's
also
on
the
sedate
information
website
in
terms
of
meat,
echo
there's
lots
of
material.
There
don't
need
to
really
talk
about
that.
D
So,
in
terms
of
resources
for
our
work,
as
I
said,
zulip
is
the
is
the
choice
here.
We
will
be
keeping
notes,
but
I
want
to
encourage
you
to
add
to
the
notes.
In
fact,
I'm
going
to
rely
on
braun
pretty
much
to
do
most
of
the
note-taking
from
the
chair
and
then,
but
I
would
certainly
welcome
people
who
are
in
person
or
people
who
are
working
remotely
to
add
to
the
notes
as
we
go
along.
That
would
be
very
helpful.
Our
mailing
list
is
on
the
screen.
D
I
won't
say
anything
more
about
that
and
once
again
for
the
people
who
are
here
local,
there
is
the
long
uri
for
the
onsite
tool
in
terms
of
the
agenda.
It's
very
simple.
I
will
open
it
up
for
agenda
bashing,
but
I
would
be
shocked
if
there
was
much
agenda
bashing
here.
We
have
a
very
quick
presentation
on
our
liaison.
D
That
should
not
take
very
long.
The
dominant
item
on
our
agenda
is
to
get
our
draft
going
and
I
will
be
turning
it
over
to
carsten
for
that
and
and
then
we'll
have
a
short
amount
of
time
for
any
other
business.
One
of
the
things
the
chairs
will
ask
the
assembled
group
is
whether
or
not
we
should
consider
an
interim
in
order
to
make
further
progress
on
getting
this
draft
done.
So
let
me
pause
here
and
see
if
there
is
any
concerns
about
the
agenda
or
if
we
can
just
proceed.
D
A
D
Sure,
maybe
what
begging
our
pardon
here,
what
we'll
do
is
we'll
put
mike
mike's
presentation
at
the
end
and
if
we
can't
do
that,
then
I'll
try
to
add
liv.
I
know
a
little
bit
about
what's
going
on
here.
I
wouldn't
do
nearly
as
good
a
job
as
mike.
So
let's
move
on
to
our
main
item
on
the
agenda
and
let
me
bring
that
up
and
karsten.
I
can
run
the
slides
for
you
just
tell
me
when
you
want
the
next
slide.
B
This
works
as
well,
yes,
okay,
so
I'll
be
your
master
of
ceremonies
for
the
next
40
minutes
or
so,
and
I
will
talk
about
where,
where
we
are
with
the
one
deliverable
of
this
working
group
and
since
113,
we
had
a
version
of
four
of
the
document
that
added
the
offset
time
zone
syntax.
So
we
can
have
time
zone
hints
both
with
a
time
zone
name
and
with
a
numeric
time
zone.
This
is
kind
of
a
specialty
and
not
exactly
recommended,
but
it's
needed
to
be
compatible
with.
B
What's
out
there
and
in
a
dash
of
five,
we
added
a
critical
flag.
So
we
have
a
way
to
identify
a
hint
as
something
that's
actually
not
just
a
hint
but
critical,
and
we
added
one
example
for
how
to
extend
the
format,
because
if
you
don't
provide
an
example,
then
people
won't
know
what
to
do
and
they
actually
won't
implement
it.
B
And
finally,
we
had
a
little
bike
shed
here.
The
thing
needed
a
name
and
we
came
up
with
internet
extended
day
type
format
and
yeah.
You
can
argue
whether
that's
a
serious
proposal
or
just
the
the
scare
proposal
we
put
up
so
people
generate
better
proposals
than
that.
But
if
we
don't
have
a
better
proposal,
then
we
can
certainly
live
with
that
name.
B
B
There
may
be
a
little
bit
too
little
detail
about
the
calendar
format
and
we
also
had
a
discussion
on
the
list
about
suffix
key,
limiting
suffix
keys
to
lowercase.
So
these
are
three
things
that
could
be
in
a
dash
or
six
and
that
then
we
would
be
done,
except
for
issue
number
17,
and
I
think
that's
the
the
interesting
one
that
we
need
to
address
during
this
meeting
and
what
is
issue
17?
Well,
it's
the
the
elephant
in
the
room.
B
B
A
B
B
So
if
you
look
into
three
two
three
nine,
it
defines
zed,
which
is
time
time
zone
time,
offset
zero
as
a
synonym
for
plus
zero
zero
zero
zero,
which
makes
sense,
but
the
the
implementations
out
there
often
have
a
problem
in
that
they
are
also
trying
to
be
iso.
8601
compatible
and
iso
8601
doesn't
seem
to
provide
for
-0,
which
is
essentially
the
absence
of
a
time
zone
hint.
B
B
B
B
So
that,
of
course,
increases
the
confusion
because
we
now
know
not
only
have
the
conflicts,
the
potential
conflicts
between
the
time
zone
hint
and
the
59
offset
information,
but
we
also
have
a
deviating
interpretation
of
that
offset
information
and
that
that
is
pretty
much,
not
a
situation
that
that
can
be
rescued.
You
don't
get
interoperability
when,
when
you
do
that
so
again,
if
you
look
into
progress
19
the
discussion,
they
are
provides
a
survey
of
various
platform,
time
data
types
and-
and
those
have
this
interesting
problem.
B
So
what
we
could
say
is
yeah
these.
These
are
all
just
deviating
implementations
and
we
don't
care
about
them,
and
39
really
defines
how
the
world
should
be
and
the
part
of
the
world
does
that
doesn't
implement
this
right.
Well,
it's
it's
their
problem
and
so
on,
but
there
is
also
another
possibility
and
the
radical
proposal.
B
So
that
is
based
on
the
assumption
that
still
needs
to
be
verified
that
this
actually
is
the
consensus
in
the
implementations,
and
we
have
this
nice
survey
from
justin,
but
I
think
we
we
actually
have
to
cast
a
slightly
wider
net
before
we
say
this.
This
is
really
what
people
out
there
are
doing.
Then.
The
second
question
is
is
actually
authorized
to
make
this
change
because,
as
a
working
group,
we
are
certainly
not,
and
so
we
probably
would
have
to
have
a
discussion
outside
the
working
group
and
unfortunately
there's
nobody.
B
So
this
is
really
the
the
question
and
I'm
posing
this
question
as
as
an
editor
here.
I
personally
really
don't
care
about
iso.
8601,
so
I
personally
would
say
well
539
rules
and
no,
we
do
don't
do
any
of
this,
but
I
think
we
also
have
to
think
about
what
what
will
happen
with
this
out
there
in
reality
and
urge
wall
is
in
the
queue.
E
Yeah
carson,
just
about
a
tiny
note
about
the
remark
about
not
caring
about
iso
8601,
that's
understandable.
However,
you
have
to
also
understand
that
implementations
generally
do
not
get
that
choice
and-
and
you
know,
in
order
to
be
maximally
compatible,
they
they
would
have
to
stick
to
behavior.
That
is
permitted
by
both
339
or
you
know,
339
bis
and
8601,
which
means
which
of
course
is
the
reason
they
do.
The
whole
z,
behavior.
B
F
First
of
all,
thanks
for
including
me
just
a
few
notes
on
the
survey
that
I
did.
What
I
did
is.
I
looked
for
other
platform,
libraries,
and
I
think
I
looked
at
maybe
10
or
so,
and
then
took
the
subset
of
those
that
actually
had
a
time
stamp
type
right
where
it,
you
know
the
the
equivalent
to
what
3339
does
or
the
the
full
iso
8601
that
that
records
an
instant
in
time
without
a
time
zone.
And
then
I
look
for
well.
How
are
those?
F
There
is
no
conflict
right
where
the
the
whole
the
whole.
The
only
reason
you
have
a
time
stamp
is
to
record
an
instant
in
time.
If
you,
if
you
don't
know
the
time
zone
information,
it
sort
of
doesn't
matter
that
much
when
you're
serializing
it,
whether
you
use,
z
or
plus,
zero
zero
zero,
or
for
that
matter,
minus
zero,
zero.
It
all
has
the
same
meaning
unless
there's
a
time
zone
involved,
and
so
my
assumption
is,
is
that
the
designers
of
all
these
libraries
again?
This
is
all
water
under
the
bridge.
F
It's
already
been
designed
in
some
cases.
You
know
10,
plus
years
ago,
chose
to
use
the
shorter
and
more
compatible
serialization
of
z,
as
opposed
to
the
minus
zero
zero,
which
would
be
incompatible
or
the
plus
zero
zero
zero,
which
would
be
longer,
and
so
so
again,
it's
hard
to
to
understand
without
really
digging
into
the
details
of
sort
of
how
each
of
these
libraries
was
designed.
F
F
B
Yeah,
so
I
I
copied
the
the
section
4.3
into
the
chat,
and
this
is
what
gives
semantics
to
minus
0,
0
0
0,
and
it's
trying
to
say
that
an
unknown
offset
to
local
time
is
expressed
with
-0
and
a
known
offset.
It
can
be
expressed
with
both
z
and
plus
zero,
and
they
say
both
z
and
plus.
Zero
imply
that
utc
is
the
preferred
reference
point
for
the
specified
time.
B
So
we
we
do
have
a
pretty
clear
statement
from
539,
of
course,
you're
right
that
this
doesn't
prescribe
how
an
implementation
actually
is
supposed
to
use
this
information-
and
maybe
implementations,
actually
did
have
some
leeway
in
in
not
actually
making
use
of
the
information
that
is
encoded
in
the
timestamp
but
yeah.
I
think
we
we
are
at
least
changing
this
section
4.3.
B
E
A
G
G
G
E
G
G
F
Okay,
so
so
the
one
thing
I'd
recommend
is,
I
don't
think
you
should
remove
the
minus
zero
zero
zero
zero
from
three
three
three
nine,
in
other
words,
that's
been
around
for
20
years,
if
anybody's
using
it.
I
I
didn't,
find
anybody
using
it,
but
I'm
sure
there
is
somebody
out
there
who
has
so.
I
would
strongly
recommend
we
not
take
that
out,
but
rather
I
think
it
would
make
sense
to
acknowledge
that
in
the
20
years
since
then,
the
industry
has
essentially
voted
with
their
feet
around
a
particular
implementation
of
z.
F
That
is
also
useful
in
what
we're
doing
here,
which
is
to
include
a
time
zone
hint
along
with
a
time
stamp
right.
So
it's
sort
of,
like
you
know
like
like
evolution
right
in
a
in
a
cave
where
some
sometimes
the
animals
lose
their
eyes,
and
sometimes
they
don't,
but
it
doesn't
matter
because
it's
dark
and
then
some
then
the
animals
get
out
of
the
cave
and
they're
like.
Oh,
I
have
eyes,
and
I
don't
right.
F
I
think
this
is
an
example
of
that
right,
where
it
kind
of
didn't
matter
very
much
until
now,
and
now
it
matters
more,
and
so
I
think
it
would
make
sense
to
acknowledge
the
way
the
industry
is
has
kind
of
voted
so
far,
but
I
wouldn't
break
backwards
compatibility.
Nor
do
I
actually
think
that
this
makes
it
incompatible
as
well.
In
other
words,
as
far
as
I
could
tell,
this
is
undefined
behavior,
in
other
words,
does
the
does
he
require
you
to
to
assert
that
the
local
time
is
a
particular
human
time
zone?
F
I'm
not
convinced
that
that
spec
is
clear.
The
3329
is
even
clear
enough.
Now
that
that's
that's
the
case.
It's
clear
that
the
offset
means
that
the
you
know
it's
relative
to
utc,
but
that's
different
from
from
asserting
that
hey.
This
is
a
real
human
time
zone
that
you
can
pull
out,
for
instance,
the
local
time
in
there
and
display
it
to
an
end
user,
as
if
it
was
the
the
real
time
that
was
was
asserted.
F
G
Myself
off
the
cube,
I'm
trying
to
I'm
fishing
around
in
my
head
for
other
inputs
about
how
to
guide
this
decision.
One
of
the
things
we
say
when
we
move
from
proposed
standard
to
internet
standard
or
the
full
standard,
whichever
the
highest
one
is
you
remove
stuff
that
is
nobody's
implementing
before
you
can
advance
it
to
the
next
level?
You
have
to
do
that,
and
so
that
might
be
a
consideration
here.
G
So
for
the
second
question,
who's
authorized
to
demolish
3339
this
this
working
group
is
chartered
properly
to
to
do
that
sort
of
work.
I
think
that
if
we're
really
worried
about
this
a
little
bit
of
exposition
in
the
document
that
explains
you
know
the
history
that
we've
just
been
talking
about
in
the
last
five
minutes
would
be
not
harmful
to
include
and
then
on
the
first
and
third
bullets
I
mean,
if
you
can
demonstrate
either
be
the
history
of
the
list
or
the
in
more
exposition.
G
D
E
E
The
suffix,
if,
if
any
for
that
and
yeah
editorially
there
there's
already
some
guidance.
I
I
suppose
there's
many
comments
about
including
some
examples
to
make
it
clear
and
so
on.
We
could
also
include
notes,
including
the
survey
we
did
to
drive
the
point
and
yeah
with
that.
I
feel
it
should
be
convincing
enough.
B
B
So
please
don't
rely
on
on
that,
actually
meaning
that.
So
that
would
be
the
the
update
to
33
9,
and
for
for
this
specification
we
would
indicate
that
minus
0,
0,
0
0,
is
often
not
implemented,
so
it
provides
less
interoperability
than
using
the
the
new
semantics
for
z
that
is
defined
in
the
update
for
33
9,
and
then
we
have
a
good
basis
to
actually
complete
the
conflict
text
that
I
think
is
already
quite
good,
but
but
maybe
could
take
another
round
of
editorial
updating.
A
F
So
so
I
I
I
think
the
answer
in
it.
Unfortunately,
I
I
my
mental
arithmetic,
is
not
as
good
as
yours,
but
my
understanding
is.
If
the
zed
is
on
there,
then
the
string,
the
the
the
local
time
shown
before
the
zed
is
not
meant
to
imply
a
real
human
local
time,
but
rather
it's
meant
to
defer
to
the
time
zone
hint
to
determine
what
the
local
time
actually
is.
F
So
the
the
instant
always
stays
the
same
right,
the
the
point
in
universal
time,
regardless
of
the
time
zone,
but
having
the
z
there
implies
that
a
there
can
never
be
a
conflict
right
because
you're
not
making
an
assertion
about
the
local
time,
nor
the
the
offset
when
it
was
was
gathered
and
b
that
you
should
defer
to
the
to
the
time
zone
hint
to
determine
the
the
time.
Does
that
match
what
you
were?
I.
A
A
That's
the
the
whole
question
with
all
of
this
is
how
do
we
disambiguate
this
and
is
the
time
there,
the
local
time
or
not,
or
has
it
had
an
offset
applied
to
it
already
to
convert
it
to
utc,
because
certainly
the
meaning
of
z,
as
as
output
by
these
libraries,
I
have
done
a
conversion
to
what
I
think
is
utc
and
then
I've
slapped
a
z
on
the
end.
It's
not
that
I
took
the
local
time
and
slapped
a
z
on
the
end.
C
Yeah
I
was
going
to
get
up
and
say
something
similar
what
brandon
said.
So
if
I
saw
that
string
that
brown
proposed,
I
there's
a
clear
conflict
that
this
spec
needs
to
have
text
to
resolve,
because
in
my
eye,
zed
still
means
utc
and
that's
how
I
read
8601
and
3339,
and
especially
in
calendaring
and
I
calendar
and
in
vcard,
for
that
matter,
zed
does
mean
utc
it
does
not.
It
does
not
mean
we
didn't
know
we're
just
going
to
slap
it
on
there.
So
I
don't
know
how
we
get
around
this
issue.
E
Wait
I'm
the
next
friend,
okay
yeah.
I
I
don't
think
so.
I
I
think
what
the
confusion
here
is
is
the
possibility
of
something
what
we
have
previously
called
within
the
context
of
this
group
floating
times
we're
not
trying
to
do
floating
times.
Here
I
mean
these
are
still
instants.
Z
still
means
udc.
B
D
So
that's
that's
kind
of
where
I
was
going
to
go,
and
this
is
kind
of
a
question
for
ken.
I
I,
when
I
think
about
these
examples,
I'm
wondering
whether
or
not
it's
case
of
one
of
two
things
number
one-
that
this
document
would
benefit
from
examples
and
interpretive
text.
That
explains
the
conclusion
based
on
on
the
rules
in
the
text
or,
if
you
think
it's
just
incompatible
and
no
interpretive
text
will
actually
provide
an
implementer,
the
guidance
they
need
and
I'm
in
a
deferred
account
here.
Thanks
yeah.
C
I
think
we
need
examples
with
with
text
because
in
in
my
head,
when
I
see
zed
and
america,
new
york
there's
a
clear
conflict.
But
if
the
spec
is
is
written
in
such
that
the
time
zone
id
overrides.
Whatever
is
in
front
of
it,
then
I'm
fine
with
that,
but
I
think
it
needs
to
be
spelled
out
and
not
just
left
for
the
the
reader
to
determine
on
their
own.
F
Yeah,
yes,
I
I
I
actually
agree
strongly
that
that
this
I
think
this
discussion
sort
of
came
out
from
some
some
comments
that
that
I
made
in
in
carson's
latest
pull
request.
Where
I
saw
the
example
using
z-
and
I
was
like
hey
that
doesn't
that
doesn't
match
the
way
we're
using
an
integral.
So
we
should
chat
about
that,
and
so
I
totally
agree
that
that
a
we
should
have
examples
in
the
spec
b
that
there
should
be
clear,
explanatory
text.
F
E
Yeah
real
quick
just
to
comment
on
the
latest
message
by
braun.
That
is
exactly
one
of
the
most
common
use
cases
that
I
think
about.
When
I
think
about
this,
I
think
that
a
lot
of
implementations
would
be
dealing
with
instance
and,
and
then
you
know
separately,
storing
in
in
many
cases
a
time
zone
in
order
like
to
refer
to
the
context
and
not
necessarily
holding
them
together
in
a
single
unified
object,
so
yeah.
E
In
that
case,
it
would
be
good
for
for
them
to
be
able
to
take
like
the
instant
in
in
the
utc
zone
and
then
just
slap
the
time
zone
suffix
after
that
and
yeah
to
at
the
risk
of
leaking
some
tc39
lingo.
Here
I
I
think
we're
all
in
violent
agreement
here
and
I
I
don't
think
anybody's
proposing
the
other
solution.
D
D
The
first
edition
is,
I
I
hear
from
the
group
that
examples
and
interpretive
texts
that
explain
how
the
examples
are
to
work
is
essential
for
the
document,
so
that
would
that
would
get
added
as
well.
I
heard
from
murray
that
I
think
it's
important
to
have
not
a
long
amount
of
text,
but
some
contextual
information
that
explains
the
deviation
between
3339
and
what
implementers
went
ahead
and
did
there's
nothing
wrong
with
that,
and
I
I
think
that
I
I
think
that
a
future
draft
should
just
have
a
paragraph
or
two.
D
D
And
then
carsten
about
five
minutes
ago
noted
that
we
do
need
to
explicitly
say
what
changes
we're
making
to
3339,
and
I
think
that's
true
as
well
that
deserves
highlighting
in
the
document
and
that
I
I
don't
think
and
again
taking
my
tear
hat
off
temporarily.
I
don't
think
that
amounts
to
demolishing
rfc
3339.
G
A
I've
just
been
reading
through
this
again,
I
don't
think
we're
doing
making
any
changes
to
309
at
all
we're
just
saying.
If
you
see
a
zed,
then
you
don't
you're
not
required
to
cross
check
that
the
time
zone
matches
up
we're
still
giving
the
time
zone
hint
separately,
and
so
it's
minus
zero.
Zero
is,
I
don't
know
the
offset
plus
zero,
zero
or
z
is,
I
absolutely
know
the
offset
and
we're
in
this
zone
we're
saying
in
the
context
of
this
document.
A
G
E
B
I
cannot
agree
with
that.
I
I
used
the
word
demolish,
of
course,
that
that
was
a
joke
right,
but
there
is
something
that
the
section
4.3
says
and
after
20
years
of
interoperability
experience.
We
are
saying:
well,
that's
not
exactly
what
happened,
and
we
are
updating
that.
I
think
we
have
to
be
very,
very
straightforward
about
that
and
on
that
basis
we
can
then
do
all
the
other
things
we
want
to
do.
D
So-
and
I
really
I'm
going
to
close
the
queue
here
justin
I
apologize-
I
am
going
to,
I
think
karsten.
My
understanding
of
the
way
forward
here
is
that
if
we
do
provide
that
historic
context
for
and
and
the
information
that
the
working
group
had
justin's
analysis
of
implementations,
we
include
that
that
in
the
draft
that
meets
both
your
needs
and
also
the
future
needs
of
the
iesg,
so
I
think
I
think
we're
in
a
good
place
to
move
forward.
D
I'm
I'm
really
clear
on
that.
Okay,
I
feel
like
we
have
a
relatively
crisp
definition
of
what
is
going
to
happen
next
feel
good
about
that.
I
won't
put
karsten
on
the
spot
to
say
when
we
might
see
the
next
version
of
the
draft,
but
he
should
be
sort
of
prepared
to
answer
that
question
sometime
soon.
D
H
D
H
Great,
if
yeah,
if
you
could
drive
them
for
me,
that
would
be
helpful,
so
yeah
the
the
approval
took
ages,
actually
didn't
it
from,
and
I
did
notice
when
I
was
looking
back
to
see
exactly
when
it
was
actually
april
1st.
They
approved
it.
So
that
was
very,
very
good,
so
I
haven't
really
had
much
dealings
with
the
actual
with
actual
tc154,
but
they
have
had
yeah.
You
can
move
on
to
the
next
slide.
H
I
think
they've
had
five
meetings
since
I,
since
it
was
approved,
but
not
all
of
them
are
to
do
with
the
8601
work
they're,
also
working
on
thirty
four
thousand,
which
is
the
cabin
that
should
be
vocabulary
and
and
terms.
So
a
couple
of
the
meetings
were
more
related
to
that
than
than
the
8601
work
and
by
the
time
I
got
involved
with
with
this.
I
think
a
lot
of
the
work
that
they
intended
doing
has
been
sort
of
done,
but
they
did
raise
a
a
topic.
H
H
H
In
every
other
case,
there's
no
end
of
a
period.
You
talk
about
the
start
of
the
next
period
effectively.
The
end
date
is
really
the
start
of
the
of
the
next
period
and
it's
non-inclusive,
and
that
works
very
nicely.
This
is
this
is
an
outlier
reading
back
I
have
a
feeling
this
is
actually
in
some
of
the
earlier
8601
specs.
H
H
Was
there
another
slide?
Oh
yeah?
I
I
wanted
to
try
and
get
hold
of
the
actual
document
we're
working
on.
I
I've
been
attending
the
meetings
and
and
going
through
them
with
people,
but
the
documents
were
presented
on
the
screen
and
it
hadn't
occurred
to
me
that
when
I
tried
to
get
an
actual
copy
of
the
working
document,
it
would
be
as
difficult
as
it
is.
H
D
A
A
H
I
can
what
I
think
I
can.
That
was
why
I
wanted
to
get
hold
of
a
copy
of
the
of
the
actual
working
document
to
see
what
the
the
the
effect
of
these
changes
they're
making
are,
but
they're
mostly
seen
to
be
fixing
up
errors
and
things
in
the
in
the
general
that
have
turned
up
in
the
document
since
it
was
last
published.
H
D
So
let
me
insert
myself
in
the
queue
here,
although
our
time
has
come
to
an
end
mike.
Let
me
tell
you
that
the
iab
is
well
aware
that
this
problem
exists.
This
is
not
just
for
you,
your
liaison
role,
but
for
many
liaison
roles,
and
so
what
I'll
reach
I'll
do
is
reach
out
to
the
iab's
liaison
coordinator
to
see
if
we
can
solve
this
problem
for
you
and
I'll.
Take
that
as
a
to-do.
H
D
D
D
A
E
Okay,
are
we
allowed
to
make
small
talk?
No,
I
mean
yeah,
I
I
was
overhearing
you
sorry
abroad
for
that,
but
yeah
yeah.
I
do
feel
that
with
this
we
have
at
least
semantic
consensus.
What
I
would
say
is
we
have
a
a
clear
understanding
of
what
each
part
of
the
proposal
should
do
and
there's
some
editorial
work
left,
which
we
could
take
care
of
without
needing
to
to
collect
everyone
in
the
same
room.
A
A
Offline
we're
down
to
eight
seven,
something
like
that,
but
yeah
it's
it
does
feel
like
we're.
Basically
there
we
just
need
iso
to
sign
off
on.
We
can
use
those
characters
in
our
syntax
and
we
need
to
agree
that
if
there's
a
z
there,
then
it
doesn't
need
to
align
with
the
time
zone.
That
doesn't
mean
you
can
only
use
utc
and
I
think
we've
basically
done
apart
from
that.
E
A
E
E
A
A
E
B
E
F
Yeah,
I
was
just
saying
once
first
of
all,
thanks
so
much
for
your
all,
all
your
guys
help
and
braun
for
your
opinions.
It's
it's
been
great.
I
think
now
that
we
seems
like
we
have
tentative
consensus
on
the
overall
idea.
I
think
the
biggest
outstanding
one
will
be
like
well.
What's:
what's
a
must?
What's
a
should
and
what's
a
may
for
for
the
various
options
and
that
I
I
have
some
suggested
spec
text
in
the
in
the
pull
request
that
that
I
can
follow
up
with.