►
From YouTube: IETF112-SEDATE-20211109-1430
Description
SEDATE meeting session at IETF112
2021/11/09 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
B
B
Braun
is
the
handsome
one
in
the
video
and
and
what
my
goal
here
is
is
to
get
the
preliminaries
out
of
the
way
so
that
we
can
have
a
good
discussion
so
good
morning,
good
afternoon
and
good
evening,
to
all
of
you,
let's
see
here.
If
I
can
do
this,
here's
the
here's,
the
note
well,
the
the
chairs
are
advised
to
stress
the
note
well
this
time
and
it's
it's
good
for
you
to
remind
yourself
of
what's
in
here.
B
One
of
the
things
that
I
want
to
take
just
a
moment
to
do
is
to
remind
you
of
the
fact
that
the
I
the
work
in
the
ietf
is
human
collaboration
and
as
a
result,
that
collaboration
works
best
when
people
are
respectful
to
each
other
understand
the
fact
that
they
have
different
backgrounds,
and
so
one
of
the
things
to
know
is
that
we
have
guidelines
for
conduct.
We
have
an
anti-harassment
policy
and
we
also
have
a
group
of
people
who
are
both
trained
up
and
willing
to
help
address
any
harassment
issues.
B
So
I
put
this
slide
in
the
slide
deck.
Just
as
a
reminder
to
all
of
us.
I
don't
think
there's
a
problem
in
sedate.
In
fact,
I
know
there's
not
a
problem
in
sedate,
but
if
you
experience
this
either
in
sedate
or
in
any
other
working
group,
you
have
resources
to
use
and
as
a
code
of
conduct
for
the
rest
of
us,
I
think
this
is
particularly
important.
B
The
agenda
here
I'll
I'll,
do
a
little
bit
of
agenda
bashing,
but
not
much,
because
I
really
want
to
focus
entirely
on
the
document
that
we
have
and
I'm
going
to
basically
turn
it
over
to
carsten.
To
do
that,
I
have
already
talked
about
the
note.
Well,
as
I
said,
we
have
a
the
working
group
has
a
single
document.
That's
the
one
we're
going
to
talk
about.
Let
me
just
talk
a
few
minutes
about
a
liaison.
Here's
some
potentially
useful
information.
B
Our
charter
talks
about
a
liaison
and
the
chairs
have
had
a
conversation
back
in
august
with
the
iab
to
request
a
liaison
to
tc-39
the
iab
agreed
in
the
beginning
of
october
to
go
ahead
and
do
a
liaison.
That
process
is
a
formal,
iab
process
that
basically
got
kicked
off.
On
october
5th,
the
ieb
asked
for
candidates
and
on
october
22nd
the
iab
had
a
list
of
candidates
volunteers
and
has
started
interviewing
those
volunteers.
B
B
Okay,
well,
I'm
pleased
to
say
that
the
meat
of
the
agenda
is
to
be
turned
over
to
the
discussion
of
our
one
document.
This
was,
as
you
know,
adopted
as
a
working
group
item.
The
last
time
we
got
together,
there's
a
new
version
available.
Dasha1
carson
sent
out
carsten
has
actually
done
a
lot
of
work
and
I'm
not
going
to
steal
his
fire
here,
steal
his
thunder,
I'm
gonna.
Just
let
him
talk
in
a
second.
B
You
can
see
the
mailing
list
for
the
outline
of
issues
and
in
the
last
five
days
there
has
been
a
really
healthy
and,
I
think,
really
positive
discussion
on
the
mailing
list
and
lots
of
good
proposals,
and
so
without
any
further
ado.
Let
me
turn
it
over
to
carson
to
he
has
some
slides
and
I
just
would
like
carsten
to
manage
the
discussion.
C
C
C
So
the
the
charter
tells
us
that
we
are
extending
rfc,
33,
39
time
stamps
and
where
we
could
do
this
to
provide
additional
information
and
that's
actually
what
the
charter
talks
about,
or
we
could
also
do
this
to
to
actually
change
the
semantics.
So
the
the
timestamp
on
its
own
means
something
different
than
the
timestamp,
with
the
extensions
that
that
we
have
added
so
just
to
remind
people
what
3339
does
for
us.
It
gives
us
a
utc
timestamp
and
it
gives
us
the
ability
to
add
an
annotation,
which
is
a
time
zone.
C
Offset
and
numeric
offset
that
allows
you
to
understand
which
time
zone
this
particular
time
was
meant
to
be
in,
but
not
in
the
sense
of
a
human
readable
time
zone,
but
just
in
the
sense
of
time
zone
offset
and
yeah.
It's
a
matter
of
syntax
that
when
you
do
that,
the
time
that
you
actually
look
at
no
longer
is
utc,
but
is
in
that
offset.
But
that's
just
just
that's
not
a
semantic
thing.
It's
just
the
way.
The
way
this
is
represented,
so
I
try
to
summarize
what
happened
on
the
the
mailing
list.
C
C
We
certainly
have
the
the
proposal
to
add
a
human
readable
time
zone.
So
I
can
say
that
sometime
actually
is
in
the
your
berlin
time
zone
and
not
just
that
it's
a
plus,
0100
or
plus
0,
depending
on
the
time
of
the
year,
and
of
course
there
are
also
other
annotations
display,
hints
and
so
on.
That
can
go
there.
C
This
is
a
kind
of
time
stamp
that
is
a
little
bit
wobbling
around
based
on
on
politic
politicians
decisions,
but
after
a
while
it
actually
converges
to
to
an
actual
timestamp,
it's
just
a
little
bit
more
difficult
to
interpret
it
because
you
have
to
have
access
to
a
current
time
zone
information
database
so
that
that's
something
different
from
from
the
annotation
thing.
That's
why
I
called
it
modification
thing
and
then,
of
course
there
are
other
modifications
one
can
think
about,
for
instance,
time
scales.
C
C
And
finally,
there
have
been
new
semantics
which
are
not
covered
by
by
the
concept
of
a
33
39
timestamp
at
all,
so
not
not
a
fixed
point
in
time,
or
at
least
the
time
where
we
can
converge
to
a
fixed
point
after
a
while
so,
for
instance,
a
floating
time,
which
is
a
time
stamp.
That
only
becomes
one
when
you
add
local
context.
So
it's
not
interpretable.
C
Without
that
context,
of
course,
the
data
structure
that
this
timestamp
is
integrated
in
that
might
provide
the
context,
so
you
can
still
have
full
interoperability
on
these
time
steps,
but
the
the
timestamp
by
itself
is
is
quite
different
from
what
the
3339
timestamp
would
be.
Even
if
it
synthetically
looks
very
similar.
C
The
question
really
is:
should
we
be
doing
modifications
and
completely
new
semantics
so
that
the
points
b
and
c
on
the
previous
slides
in
this
working
group,
or
not-
I'm
not
talking
about
what
the
charter
says
about
that?
I
can
read
the
charter,
but
should
we
do
that?
So?
Is
that
something
that
that
is
better
done
in
the
context
with
the
other
extensions
that
are
covered
by
a
and,
of
course,
once
we
do
this?
C
So
the
argument
for
my
argument
I
would
use
for
for
doing
one
and
two
is
that
we
could
make
sure
that
these
modified
or
new
semantics
could
actually
mesh
very
well
with
what
we
already
chartered
to
do,
which
is
a
and
yeah
just
to
to
to
remind
people.
You
all
have
the
charters
on
your
laptops,
but
just
in
case
we
need
this
for
the
discussion
that
sure
will
start
now.
A
A
It
could
shift
depending
on
context
and
once
you
once
you
say
it
could
shift,
then
we
should
do
all
the
good
shifts,
but
I'd
be
happy
to
also
to
find
something
that
doesn't
allow
the
timezone
name
to
override
the
time
point.
If
that's
what
we
want
to
do,
but
yeah
that
one
one
or
the
other,
I
think
not
half
and
half.
D
I
just
wanted
to
say
yeah.
The
the
thing
is
that
some
of
these
things
are
just
not
time
stamps
they're
just
date
times,
but
that's
fine,
there's
a
lot
of
applications
on
the
web
that
need
date
times
with
the
time
zone
or
date
times.
That's
wall,
clock
time
that
does
have
doesn't
have
any
time
zone
associated
at
all
and
defining
a
standard
way
of
serializing.
D
Those
is
good
for
interoperability
and
that's
what
I
thought
the
temporal
group
looking
for
when
they
first
came
to
the
itf
with
this
proposal,
so
I
would
say
it's
fine
for
it.
You
know
to
to
not
be
the
same
as
3339.
We
just
don't
say
it's
an
extension
that
we
say
it's
a
separate
thing:
it's
just
adding
more
standard
serializations
for
common
things
on
the
internet,
just
like
3339
did.
E
So
if
you
have
a
past
time,
let's
say
in
europe,
berlin,
just
as
an
example,
the
the
offset
for
that
time
is
known
and
it's
not
going
to
shift,
although
future
times
this
whole
question
about
how
do
you
know
what
time
it
will
be
in
the
future
where
you
don't,
but
that's
not
not,
really
a
concern.
That's
that's
more
calendaring
things.
C
Yeah,
I
think
the
the
observation
about
b,
b
or
b1
is
that
the
time
zone
info
database
content
is
going
to
change
over
time.
So
the
interpretation
of
that
date
time
timestamp
whatever
is
going
to
change
but,
as
you
say,
it's
very
unlikely
to
change
retroactively
now,
so
the
interpretation
is
going
to
converge
into
something
at
least
well
a
small
time
after
the
timestamp
actually
happened.
E
I
just
want
to
say
the
the
semantics
are
entirely
different.
If
I
am
living
in
berlin
and
I
write
down
that
it
is
1pm
berlin
time,
then
it
is
1
pm
berlin
time
and
whether
or
not
the
off
you
know.
20
years
later,
people
are
confused
about
what
the
offset
was.
The
time
I
wrote
down
is
the
same
so
saying
that
you
know
you
can't
have
the
two.
E
F
A
A
D
F
The
time
you
know
exactly
the
same
way,
it
would
just
you
know,
have
have
difficulty
with
other
operations,
and
I
think
that
promise
is
somewhat
broken
if
you,
if
you
allow
b
but
yeah
b1
sort
of,
doesn't
have
that
so
so
it
ties
back
into
the
point
carsten
made
about
yeah.
Do
we
want
them
to
even
be
interoperable
with
339?
Maybe
it's
you
know
it's!
It's
not
good!
If
they,
if
you
want
something
else,
maybe
it
should
look
different
so
that
there's
there's
no
way
that
there's
a
mismatch
or
something
like
that.
G
G
More
than
people
think
I
believe,
and
when
you
track
time
zone
in
certain
areas,
the
the
world
time
zone,
specifications
change
quite
a
bit
and
at
the
last
minute,
so
I
don't
know
you
can
guarantee
that
any
offset
you've
put
in
there
is
going
to
be
valid
when,
when
you
actually
come
to
the
actual
point
in
time,
it
may
be
more
true
that
they
don't
change
in
retrospect.
But
that's
I
don't
think
we're
dealing
with
that.
All
the
time.
E
Watson
again,
I
think
it's
important
to
understand
what
people
mean
when
they
specify
future
times.
If
I
say
I'm
going
to
meet
you
at
12
p.m
or
grand
central,
I
mean
when
the
hand
of
the
talk
in
grand
central
station,
both
of
them
are
pointing
straight
up
and
whether
or
not
that
is
a
certain
offset
from
utc,
isn't
really
the
problem,
and
so
a
few
you
know
now
what
the
issue
is.
G
G
You
you
each
want
your
time
to
be
your
time
zone.
What
you
agree
on
what
the
contract
you
make
is
to
meet
at
the
same
instant
in
time,
which
can
be
ultimately
expressed
as
utc
there's
a
correct,
there's
a
thing
you
said,
which
is
absolutely
correct:
what
matters
to
people
more
than
anything
else.
What
is
the
invariant
to
people
is
their
local
time,
not
utc.
G
C
G
G
G
E
Is
aware,
I
I
think
I
think,
there's
I
don't
think
saying
that
you're
going
to
have
local.
I
think
that
prom
is
inherently
insoluble.
You
don't
know
whether
next
year,
you
know,
let's
say
it's
a
meeting
between,
say
someone
in
arizona
and
or
in
someone
in
california.
You
don't
know
whether
next
year,
one
of
them
changes
time
zones
and
or
it
changes
the
data
which
the
thing
happens.
So
something
has
to
shift.
G
C
Yeah,
I
think
we
really
have
determined
that
this
use
case
exists.
Let
me
just
put
out
the
other
use
case,
so
so
why?
Maybe
you
understand
why
this
is
not
quite
as
simple.
The
other
use
case
is
that
I
have
a
certificate.
I
want
to
be
able
to
say
when
that
certificate
runs
out
and
there
it's
usually
not
useful
to
factor
in
decisions
of
politicians,
but
you
want
to
have
an
absolute
time
when
that
goes
away.
C
C
Rfc
3339
is
kind
of
leaning
towards
the
the
let's
have
an
actual
point
in
time,
so
that
that's
the
problem
itself
today
and
what
we
are
trying
to
to
find
out
here
is
what
are
the
the
additions
we
can
make
and
where
do
we
make
them,
and
what
we
probably
don't
need
to
discuss
is
whether
the
problem
exists.
I
think
we
are
all
the
way
out
there.
F
I
think
most
of
what
I
wanted
to
say
is
is
is
redundant
with
what
you
just
mentioned,
but
yeah.
I
just
wanted
to
point
out
that
we
already
have
agreement
that
both
use
cases
are
legitimate
for
different
applications.
It's
just
that
we
already
have
a
way
to
to
represent
a
instant
in
time.
If
we
know
exactly,
you
know
when
the
certificate
expires,
we
can
already
represent
that
in
a
format
right,
but
we,
but
we
have
no
way
to
represent.
F
A
Yeah,
so
I
think
we've
we've
gone
around
in
circles
enough
on
this
to
say
that
we
should,
I
guess,
decide
whether
we
want
to
work
on
it
or
not.
That's
really.
The
question
ahead
of
us
is
should
should
we
do
that
this
question
one
here:
should
we
do
a
time
that
is
not
an
exact
point
in
time
format
in
this
working
group-
and
I
don't
know
if
we
need
to
do
a
poll
for
that
to
decide
our
charter
doesn't
specifically
allow
us
to
do
it
though
we
could.
A
We
could
do
it
by
not
by
basically
doing
the
options
that
I
proposed,
which
are
and
not
making
any
changes
to
rfc
339
bit,
but
having
things
that
could
add
an
additional
offset
to
it.
Basically,
that
gets
calculated
by
the
time
zone,
rules
changing
or
by
whatever,
by
floating,
which
says
resolve
it
in
your
current
context,
whatever
that
happens
to
be.
A
C
Would
be,
although
I
think
the
important
point
is
that
if
we
want
to
do
one
two,
we
need
to
initiate
a
recharge
process
quickly
and
we
need
to
be
very
certain
what
the
scope,
what
extent
of
that
recharge
ring
is
going
to
be?
Do
we
actually
include
c,
for
instance,
or
is
a
c
out
of
scope,
and
we
only
do
b?
C
I
think
that's
something
that
we
should
be
deciding
pretty
soon.
All
of
this
doesn't
have
to
stop
us
from
doing
a
and
actually
even
maybe
finishing
and
publishing
an
rfc
that
does
a,
but
I
think
people
are
so
interested
in
this
other
use
case
that
we
need
to
develop
a
position
on
it.
Even
though
it's
not
in
our
chart.
B
So
I
think
scoping
would
be
extremely
important
if
we
rechartered,
especially
in
in
it'd,
be
very
important
to
make
sure
that
we
are
explicit
about
what
is
out
of
scope.
That's
just
one
person's
opinion
and
that's
without
my
chair
add-on.
I
think
the
scoping
conversation
while
you
say
would
need
to
happen
very
quickly,
and
I
agree
with
that.
I
think
what
will
be
very
important
is
how
how
the
scope
is
limited
right.
A
F
Was
actually
just
asking
carsten
how
how
much
this
would
delay
us?
I
I,
as
you
pointed
out,
we're
we've
been
working
on
temple
and
we
would
like
to
be
shipping
out
soon
and
I
I
think
it
would
be
really
sad
if
we,
if
we
have
to
ship
something,
that's
not
standardized,
I
would
not
prefer
that
at
all,
so
we
we
should
try
at
least
as
much
as
we
can
to
to
to
take
the
fastest
route.
F
C
H
C
D
H
So
so,
from
a
purely
process,
point
of
view
a
rechartering
should
take
around.
I
believe
something
like
six
weeks
if
everything
is
already
in
place
and
this
six
weeks
should
start
in
the
beginning
of
december,
at
least
so
that's
at
least
two
and
a
half
three
months,
and
that's
and
that's
assuming
that
you
know
everybody
can
agree
on
on
recharging
text
and
and
scope
and
motivation
and
evaluation
yeah.
That
is
also
mentioned
in
the
current
charter.
So
that's
important
to
to
do.
Yeah.
C
So
I
would
expect
us
to
take
about
the
same
time
to
to
fix
up
the
documents.
Of
course,
we
couldn't
make
one
document
a
working
group
document
before
the
recharger
is
at
least
in
a
definitive
stage
again.
The
the
the
other
thing
we
could
do-
or
maybe
we
can
do
both
at
the
same
time-
is
write
up
the
case
a
here
and
make
sure
all
the
mechanics
for
actually
defining
extensions
are
already
in
there.
B
I
do
think
having
an
interim
might
be
a
way
of
pushing
the
work
forward
a
little
more
quickly
and
that's
something
I'll
bring
up
at
the
end
of
the
session,
but
I
can
actually
see
three
parallel
tracks.
There
right
is
continuing
work
on
the
existing
document
and
putting
putting
a
into
it
working
in
a
track
where
we
recharter
and
then
have
an
individual
submission
to
actually
deal
with,
for
instance,
b1,
so
that
we
were
making.
We
were
making
forward
progress
in
parallel
with
rechartering.
B
F
I
I
guess
I
could
speak
to
that.
The
the
idea
is
that
temporal
does
have
those
semantics,
but
then
because
temporal
is,
is
in
a
special
situation
where
it
is
a
programming
language
api.
So
there's
more
ways
to
represent
that.
So
so,
in
this
case
we
we
of
course
do
not
allow
the
you
know
this
information
of
saying.
Okay,
the
the
time
zone
overrides
the
offset
be
represented
in
the
interchange
format.
But
then
you
know
the
programmer
can
specify
that
on
their
end.
C
F
B
So,
with
my
chair
hat
back
on
I'm
hearing
gradual
consensus
there,
I
I
want
to
make
sure
that
the
mic
is
open
for
other
points
of
view,
but
there
is
this
emerging
consensus
that
we
continue
to
work
on
the
existing
document
and
move
it
forward
as
quickly
as
we
can
in
parallel
with
a
a
rechartering
pro
process.
That
is,
has
a
very
brisk
scoping
and
then
also
the
beginnings
of
a
beginnings
of
the
new
document
for,
like
I
said,
b
and
b,
one
here,
b
or
b
one.
B
B
I
will
say:
editorially:
what's
nice
about,
that
is
that
continues
continues
to
get
us
towards
a
work
product
relatively
quickly.
It
really
addresses
the
issues
that
have
come
up
in
the
last
five
days.
I,
like
that,
a
lot
and
and
I'm
not
afraid
of
the
rechartering
process.
I
think
that
work
can
be
done
after
ietf112
to
move
move
reasonably
quickly
on
that,
although
everything
that
francesca
says
about
the
recharging
process
is
true,
all
the
process
that
it
has
to
go
through.
B
C
Yeah,
I
think
we
have
lots
in
place
that
can
make
us
generate
a
document
for
a,
and
we
should
simply
do
that,
and
this
allows
us
to
get,
for
instance,
the
syntax
issues.
Out
of
the
way
before
we
actually
go
into
the
semantics
issues
that
may
make
b
or
c
a
little
bit
more
complicated
than
it
seems
at
the
moment.
F
That
I
I
wanted
to
sort
of
ask
about
from
the
chat
is
that,
if
the,
if
publishing
this
document
that
we
have
right
now
is
not
blocked
on
rechartering
or
you
know
the
second
document
do
we
have
a
pressing
reason
to
to
do
anything
very
quickly,
because
I
I
think
temple
can
ship
after
we.
We
have
this
one
published
right
so.
B
B
I
and
the
reason
that
I
keep
stressing
parallel
development
here
is
because
I
am
sensitive
to
temporals
timelines
and
I'm
also
sensitive
to
the
fact
that
when
we
were
chartered
as
a
working
group,
we
were
chartered
as
a
short-lived
working
group.
We
don't
want
to.
I
I
and
I
don't
want
to
put
words
in
francesca's
mouth,
but
we
don't
want
to
be
in
a
situation
where
we're
sort
of
like
barnacles
on
the
side
of
a
boat
sort
of
adding
to
the
charter
over
time
right.
We
want
a
clear
and
fairly
succinct
scope.
I
Mark
I
just
wanted
to
make
a
quick
procedural
observation
about
something
you
said,
which
is
that
especially
given
some
of
the
people
who
are
not
participating
in
this
session,
possibly
because
of
conflicts
with
other
working
groups.
We
don't
have
consensus
on
anything
that
was
confirmed
on
the
mailing
list.
B
B
Yeah,
let
me
let
me
be
very
clear
about
my
intention
and
the
reason
that
I
was
hoping
that
braun
was
making
a
note.
There
is
that
if
we
have
a
clear
and
succinct
understanding
of
what
the
proposed
pathway
forward
is
that
I
would
take
the
responsibility
of
getting
that
out
to
the
mailing
list
in
short
order
and
asking
for
discussion
and
potentially
consensus
around
that
path
forward.
C
Yeah,
I
think
the
the
the
interim
is
really
needed,
so
the
the
my
hope
would
be
that
we
actually
can
get
the
the
document
in
a
state
where,
where
it
actually
shows
that
this
working
group
can
get
things
done
at
the
time,
the
the
final
decision
about
reset
the
recharge
ring
needs
to
be
done.
So
this
is
an
incentive.
Another
incentive
to
do
this
quickly.
C
C
You
don't
understand
so,
if
all
extensions
are
annotations
that
actually
simple
once
they
actually
modify
the
the
meaning
that
becomes
a
little
bit
more
complicated,
an
annotation
may
be
something
that
you
really
want
the
recipient
to
understand
before
using
the
time
so
yeah
in
many
other
protocols.
We
have
something
like
must
understand
flags,
or
something
like
that.
C
C
Okay,
yeah
the
time
zone.
Extension,
I
think
is,
is
pretty
clear
what
what
that
is
in
particular,
if
it's
just
an
annotation,
then
I
think
we
we
understand
that
so
so
issue
number
three
is
is
already
answered
by
the
discussion
we
already
had
and
may
we
have
to
spend
a
little
bit
of
time
thinking
about
forward
compatibility
issues
here.
So
what
what
do
you
do
with
the
time
zone
names
that
actually
are
deleted
from
the
database
and
so
on?
C
C
C
So
I
think
we
have
to
think
about
how
we
run
these
registries
a
little
bit
more,
but
my
proposal
would
be
to
get
rid
of
the
whole
delegation
thing,
because
that
leads
to
a
complicated
mechanism
of
making
another
organization
act
in
a
way
that
this
document
describes,
and
I
think
we
can
just
skip
all
that
and
and
create
a
single
registry
and
make
it
reasonably
easy
to
actually
register
something
there
or
maybe
reasonably
hard
if
we
want
to.
But
we
have
to
decide
on
what's
the
threshold
we
want
to
put
in
there.
C
C
F
C
I
I'm
going
to
respectfully
disagree.
Diana
has
had
problems
with
that
kind
of
thing,
since
pastel
handed
over
control
to
a
committee
and
and
they
resist
things
where
they're
forced
to
make
those
kinds
of
decisions
and
designated
experts
do
not
work
with
this
country,
where
the
serious
controversy
is
distinct
from
trying
to
make
things
consistent
with
the
setting
norms
about
how
they're
described
and
this
meeting
conflicting
with
the
media
type.
One
is
a
real
disaster
in
stanford
heaviest
discussion.
I
I
I.
I
would
expect
that
if,
if
you
said
designated
experts
going
to
make
these
kinds
of
decisions
among
competing
entities
who
are
interested
in
registering
names
that
that
you
would
get
resistance
miami
and
you
would
probably,
if
they're
on
their
12th,
get
resistance
to
isg
this
this.
This
is
a
tough
problem.
Now
I
agree,
the
designated
expert
ought
to
be
able
to
project
nonsense.
I
B
This
is
not
a
candidate
for
comfort
serve.
No,
it's
not
absolutely
yeah.
Let
me
see
here
I
want
I
do.
I
know
we
have
four
minutes
left
and
I
do
want
to
reserve
a
couple
minutes
to
talk
about
future
actions
here
and
I
I
understand
john's
point
and
respectfully
disagree
in
some
cases
here.
Other.
Let
me
just
leave
the
queue
open
one
last
time
for
any
further
comments
about
carsten's.
Last
five
slides
here.
B
Okay,
what
I'd
like
to
do,
then,
is
chair
is
summarize
what
I've
heard
and
just
get
a
thumbs
up
from
braun
that
this
is
the
way
forward.
So
what
we're
going
to
do
is
take
to
the
mailing
list.
Commitment
to
move
continue
to
move
forward
on
the
existing
working
group
document
and
try
to
do
that
at
pace.
B
C
A
B
That
was
going
to
be
exactly
my
my
contribution
if
we
make
it
february
of
next
year.
One
of
the
things
a
working
group
could
decide
to
do
is
have
an
interim
in
january
to
sort
of
clean
up
and
and
truly
finish,
the
document
prior
to
working
group
last
call,
and
so
I
like
the
idea
of
february
of
next
year.
Let
me
see,
if
there's
anyone
that
wants
to
get
in
the
queue
to
talk
about
that
change,.
B
C
B
B
Well,
let
me
do
this.
Let
me
talk
to
braun
offline,
about
the
timing
of
that
and
if,
if
he
and
I
can
make
it
work,
we'll
try
to
have
one
in
december,
what
I
would
propose
is
that
if
we
do
one
in
december
then
and
that
at
that
december
meeting
we
would
decide
whether
or
not
we
need
another
one
in
january
rather
than
scheduling
both
of
them.
I
think
it
should
be
on
an
as
needed
basis.