►
From YouTube: IETF-CORE-20230705-1400
Description
CORE meeting session at IETF
2023/07/05 1400
https://datatracker.ietf.org/meeting//proceedings/
A
A
B
A
Shall
we
yeah
all
right,
then,
let's
start
how
come
everyone
to
this
entry
meeting
of
the
co-working
group
last
before
it
f117
I
am
Marco
Michael,
Cesar
and
Jimenez
and
Kirsten
Mormon
and,
as
usual,
the
network
applies
will
be
recorded
and
Reveal
Your
iprs.
If
you
have
any
it's,
not
just
about
that,
it's
awesome,
especially
about
our
code
of
conduct,
so
be
nice
and
professional
to
each
other.
A
We
have
a
pretty
packed
agenda
today,
especially
compared
to
past
entry
meetings
as
recording
for
a
while.
Now
we
have
an
entry
for
corkov
for
the
core
c,
then
comma
document,
then
we
couldn't
make
it
two
weeks
ago.
So
it
comes
today.
A
discussion
on
attacks
on
Co-op
input
from
Christian
and
John
Martino
gave
an
update
prey
itf117
on
the
answer,
Co-op
and
time
allowing
but
I
think
so.
A
We
can
also
have
a
discussion
that
was
also
originally
planned
for
two
weeks
ago
on
non-traditional
responses,
input
monster
from
Carson
and
Christian
and
and
then
let's
try
to
save
a
few
minutes
for
the
end.
Just
for
a
quick
announcement
on
next
core
events
in
the
coming
weeks
and
months,
any
agenda
bashing
or
more
input
for
today.
A
D
B
B
B
So
we
are
still
working
on
revising
20,
which
was
pushed
back
to
the
working
group.
So
we
can
complete
some
work
on
this
and
it
turns
out
this
actually
was
necessary.
We
added
Global
file
status
and
passage
status
to
make
the
Sid
documents
be
more
indicative
of
what
they
actually
are
and
right
now
we
are
trying
to
complete
this
work,
but
we
would
need
a
version
of
pjang
that
actually
can
be
used
for
generating
our
examples,
and
it
turns
out
that's
a
slightly
bigger
construction
site
than
we
thought.
B
The
the
mainline
version
doesn't
actually
generate
the
examples
that
we
are
using,
so
there
apparently
was
some
manual
editing
and,
of
course,
that
that's
not
really
attainable
situation
in
particular,
since
we
don't
really
have
any
validation
mechanism
either.
So
one
way
of
being
sure
that
that
what
you
have
is
structurally
sound
is
to
generate
it,
the
other
one
is
to
validate
it.
But
if
you
don't
have
either
that's
a
problem
and
that
causes
us
to
find
more
and
more
issues
each
time,
so
the
the
one
thing
after
we
have
cleaned
up
Yang.
B
The
one
thing
we
actually
need
to
do
is
make
sure
that
we
have,
since
for
the
remaining
identifiers
that
we
identified
need
to
have
since,
and
that
is
probably
just
this
moment
of
rubbering,
but
the
the
consolidation
in
front
of
it
is
kind
of
dwarfing.
This
effort.
There
are
also
some
small
editorial
items
that
need
to
be
done,
which
I
I
didn't
focus
on
yet
so
yeah
validation
is
the
one
of
the
bigger
open
items
that
maybe
we
can
look
for
some
ideas.
How
to
do
this.
B
So
the
the
set
of
issues
that
that
we
need
to
work
on
one
thing
that
already
is
fixed
is
that
the
RPC
parameter
SIDS
actually
needs
input
and
output
in
the
strings
in
the
identifier
string.
So
that's
actually
fixed.
Now
the
Ping
implementation
doesn't
generate
a
dependency
Vision
section.
This
is
completely
missing,
I,
don't
know
what
needs
to
be
done
to
to
get
this,
or
if
it's
not
really
implemented
at
all,
then
we
have
some
serious
plural.
B
B
B
So
next
step
will
be
to
get
the
laws
patches
in
there
and
then
maybe
the
patches
from
from
his
grad
students
and
yeah.
We
are
obviously
not
going
to
have
this
completed
early
enough
to
to
have
the
discussion
this
week,
so
it
seems
like
we
will
have
to
wait
a
little
bit
a
little
bit
longer
before
we
can
submit
and
do
the
working
plus
call
but
I
hope
we
can
still
do
this
in
such
a
way
that
we
can
discuss
it
at
1
17..
B
So
work
is
remaining.
There
is
a
dependency
slowing
us
down,
but
we
have
control
a
limited
amount
of
control
over
that
dependency.
So
I'm
not
really
worried
here.
It's
just
a
delay.
The
other
document
is
the
comma
document
which
tells
us
how
to
map
a
car
conf
on
on
Co-op.
So
just
like
rest,
conch
was
a
mapping
for
http.
B
Is
doing
that
for
Co-Op
and
doing
it
for
sibo
as
well,
so
it
plays
both
the
role
of
7951
for
Json
and
8044
HTTP
in
in
one
document
minus
the
parts
that
are
already
done
in
9254.,
so
we
went
through
working
with
last
call
a
while
ago.
Then
we
decided
we
want
to
do
it
to
have
some
simplifications
and
we
completed
the
simplification
there
and
Dash
13..
B
But
there
is
one
remaining
issue
that
I
want
to
briefly
talk
about
today,
which
is
the
way
we
use
post
and
that
that's
a
bit
surprising,
because
the
the
simplications
brought
new
focus
on
the
way
to
use
Fetch
and
eye
patch,
but
yeah.
We
apparently
didn't
look
at
post
as
much
in
that
process
and-
and
we
probably
need
to
so.
What
we
need
to
do
apart
from
the
posting,
is
the
media
types
that
we
Define
actually
are
not
silver
media
types.
B
They
are
civil
sequence,
media
types,
so
we
have
to
change
the
media
type
names
that
that
was
easy.
So
it's
already
done
in
the
editors
copy
and
we
have
an
example
India.
That
is
under
headline
RPC
example.
But
it's
actually
not
an
RPC
exam,
but
it's
an
action
example.
So
we
have
to
rename
that
which
is
also
done
in
the
editors
copy
and
add
an
actual
RPC
example.
Probably
because
you
want
to
make
sure
that
people
who
want
to
do
our
rpcs
understand
how
to
do
that.
B
Now,
the
the
question
that
came
up
when,
when
juggling
these
examples
was,
does
that
this
actually
work
and
and
is
it
actually
concise,
and
let
me
show
you
what's
in
the
current
document
in
dash
13.,
so
this
says
we
are
posting
to
the
data
store
resource,
an
example,
name
of
which
would
be
C
and
we
are
posting
a
Yang
instances,
sibo
sequence,
but
in
this
case
it's
actually
just
one
element,
so
it
it's.
Actually.
If
there
were
young
instances
of
Seawall,
this
would
also
qualify.
B
But
when
you
then
actually
look
at
the
example,
we
see
a
sibo
sequence
of
two
items,
the
identifier
and
yang
data
map,
and
that's
definitely
wrong
because
the
we
are
supposed
to
have
young
incenses,
which
are
instance,
identifiers
as
map
Keys,
going
to
a
map.
That
is
a
young
data
object.
So
so
this
is
definitely
wrong,
but
it's
pretty
obvious
how
to
fix
this.
But
when
you
actually
look
at
this,
there's
also
something
quite
striking.
Why
are
we
repeating
this?
B
The
Sid
for
the
actual
rpco
action
that
we
are
talking
to,
and
we
already
have
identified
that,
probably
as
a
mistake
and
have
made
one
slide.
That
summarizes
all
that,
based
on
an
example
from
from
the
rest
conference,
the
8040
we
probably
should
be
using
that
example,
so
so
people
who
know
restaurant
can
can
find
their
way.
B
So
what
what
we
see
here
on
the
left
side
is
the
RPC
request
and,
and
the
second
further
down
an
action
request,
and
essentially
the
the
difference
between
an
IPC
and
an
action
request
is
that
an
action
request
identifies
a
specific
place
in
the
data
tree
that
the
the
RPC
is
applied
to.
So
it's
kind
of
a
method
in
the
invocation,
while
rpcs
are
just
generally
going
to
the
server,
and
we
probably
don't
need
to
to
separate
these.
B
This
is
really
just
do
we
have
any
additional
parameters
like
the
is
null
is
zero,
I'm,
sorry
for
the
interface
ID
and
in
the
action
example.
We
don't
have
that
in
an
RPC,
because
we
are
not
identifying
a
place
in
the
data
tree,
so
we
have
to
give
the
name
of
the
the
rpcl
action
which
we
can
do
with
a
sid.
In
this
case,
the
reboot
sit
for
the
reboot
RPC
and
the
interface
reset
search
for
the
interface
reset
action
and
then
something
weird
happens
in
1840.
B
There
is
a
interstitial
here
which
is
the
Sid
of
the
input
part
of
that
RPC
or
action,
and
it's
not
at
all
clear
why
that
is
needed,
so
the
reboots,
it
would
be.
The
sixty
thousand
two
from
from
the
previous
Slide.
The
input
set
would
be
sixty
thousand
four
or
something
depending
on
what
what
set
it
actually
gets,
and
then,
in
that
we
would
get
the
various
parameters
like
delay,
message,
language
for
the
message
and
so
on.
B
So
looking
at
that,
I'm
essentially
forced
to
propose
getting
rid
of
this
inputs.
It
thing
because
it's
very
clear
request
will
have
an
input,
Sid
and
a
response
will
have
the
outputs.
It
cannot
be
any
different
from
that.
So
why
are
we
sending
this?
This
is
not
at
all
clear
and
the
the
routing
in
the
the
Yang
Sid
space
is
already
done
by
the
operation
Name
by
the
IBC
name,
action
name
like
reboot
and
and
interface
reset.
So
there
really
is
no
point
putting
that's
it
in
there.
B
So
this
is
a
proposal
I'm
making
to
to
further
simplify
rpcs
and
actions,
I'm,
not
sure
that
anybody
actually
has
implemented
these
things.
So
I'm
still
looking
for
an
implementer
that
we
could
talk
to
to
find
out
whether
that
creates
any
problems.
But
in
the
end
this
just
means
there's
one
less
actually
completely.
Redundancy
implementations
have
to
remember
what
it
is
and
have
to
check,
and
we
are
saving
a
couple
of
bytes,
maybe
three
years
old,
okay.
B
B
So
that's
where
we
are
with
these
two
documents
and
then,
of
course,
we
want
to
finish
the
Yang
library
and
get
to
the
item
that
is
frequently
requested,
which
is
not
only
having
a
efficient
encoding
of
this
structure.
Structure
of
a
Ying
data
item,
but
also
to
get
binary
formats
for
things
like
IP
addresses
dates
and
so
on.
That
tend
to
be
very
bloaty
when,
when
all
the
structure
on
that
is
so
concise
with
yang
sibo,
any
questions.
A
A
B
D
E
E
This
really
is
dependent
on
whether
the
server
does
kind
of
a
lifo
or
fifo
kind
of
response.
When
he's
doing
his
lookup,
and
so
the
attacker
can
change
his
method
depending
on
whether
he
detects
the
the
server
is
the
fifo
or
the
lifoot
method
whatever,
but
essentially
What's
Happening
Here
is
that
we
have
the
two
requests
for
initial
bits
of
data
in
concurrent
and
then
there
is
a
request
for
the
next
block
of
data,
but
the
server
has
no
knowledge
of
whether
that
is
against
the
first
request,
T1
or
against
the
second
request.
E
E
E
E
E
So
should
we
be
sending
request
tag
with
every
request
which
is
supported
in
RFC
9175,
or
should
we
be
doing
something
different?
It's
creates
an
unnecessary
overhead.
Yes,
it
can
be
small,
a
few
bytes,
but
if
we're
talking
about
dtls,
it
needs
to
be
larger
to
kind
of
make
it
more
unpredictable
in
terms
of
trying
to
analyze.
E
What's
going
on,
it
is
actually
required
in
the
RFC
9177q,
lock
logic
that
the
request
tag
is
there
with
every
request,
but
the
challenge,
if
we
don't
use
request
tag,
if
multiple
requests
are
active,
the
server
can
use
the
select
the
one
response.
We
have
a
problem
there
so
and
how
to
mitigate
this,
we
could
send
a
request
tag
with
every
request.
E
D
E
To
ask
for
the
subsequent
blocks
of
the
same
block
same
sort
of
payload
of
data,
but
how
can
it
be
done
at
the
moment?
Request
tag
is
not
allowed
to
be
in
the
response.
Should
we
be
allowing
that
in
a
response
overriding
some
of
rsc9175
or
do
we
need
to
be
thinking
about
a
new
block,
2
option
that
has
some
sort
of
embedded
request
tag
as
generated
by
the
server
for
the
client
to
use
to
get
to
these
subsequent
blocks,
and
so
that
sort
of
is
is
is
questions
that
selected
posters?
E
F
B
D
F
Payload
was
a
mistake
and
I.
Actually
I
thought
it
went
differently
and
only
after
John
brought
this
up.
I
found
this
and
consequently,
9175
is
incorrect
here,
because
it
is
built
on
my
wrong
assumption
that
the
request
payload
is
not
sent
that
the
request
payment
is
sent
again
yep
now
that
it
is
not
sent
again.
E
Yeah,
it's
it's
yeah,
it's
difficult
to
try
and
mandate
something
or
encourage
people
to
do
something.
Okay,
yeah,
so
I
always
call
can
help
a
bit
here.
Other
people
want
to
use
dtls
for
various
reasons.
Back
in
my
old
dots
days,
everything
was
DT
less,
but
it's
yeah,
it's
not
straightforward,
but
it
just
is
yeah
the
service,
somehow
signaling
the
needs
to
do
something.
There
is.
F
E
F
F
And
when
users
of
dtls
already
had
to
start
sending
a
bit
more
data
with
the
9175
Mandate
of
not
reusing
tokens,
so
since
and-
and
there
is
not
too
large-
I
mean
there
is
only
this.
This
only
effect
request
where
there
is
both
request,
payload
and
response
payload,
and
then
sending
a
request.
Tag
for
every
such
request.
I
think
is
not
too
much
of
too
much
of
overhead
in
Institute
for
for
ttls
users,
I
mean
they
would
just
they
would
just
be
incrementing
a
number
there,
and
that
would
be
like
two
to
three
bytes.
B
F
F
B
E
F
E
F
A
F
E
D
E
F
E
Fine
I
think
I
also
may
have
partially
confused
you
looking,
but
back
at
an
email
Trail
about
two
years
ago.
I
gave
you
an
answer.
What
I
thought
was
the
right
answer
to
your
question,
but
rereading
your
question,
you
asking
a
slightly
different
question.
So
I
may
have
sewn
the
confusion
there
as
well.
F
F
Okay,
so
I'm
thinking
of
a
case
where
a
client
is
sending
a
fetch
request,
server
is
sending
a
big
say,
one
kilobyte
response
and
then
the
proxy
says:
hey
I'm,
on
a
six
little
paneling,
I'm
gonna
fragment
the
response
and
then
suddenly,
like
I,
think
this
makes
things
more
complicated
than
it's.
But
it's
an
option
to
have
another
look
at,
but
I
think
it's
more
complicated.
F
E
Yeah
yep,
okay,
so
just
comment
on
the
attacks
is
that
without
the
request
tag,
we've
talked
about
that
and
without
the
e-tag,
it's
possible
that
data
can
get
corrupted
from
the
client's
perspective
without
the
e-tag
is
because
the
server
has
gives
you
half
of
a
watch
of
data,
which
is
then
updated.
Mid-Flight
to
something
new
in
the
e-tag
doesn't
change
because
it's
not
been
given
there,
and
this
is
another
comment
and
start
equals.
One
serialization
can
be
broken
by
the
man
in
the
middle
foe,
causing
trouble.
E
It
comes
out
actually
better
in
a
couple
of
slides
as
further
on
okay.
So
token,
manipulation
is
something
else
that
sort
of
came
out
of
the
woodwork
of
this
essentially
here
is
that
the
client
thinks
he's
doing
a
request
to
request
one
with
using
token
one
and
request
to
request
two
using
token
two.
The
foe
changes
the
token
so
that
the
services,
the
request
to
with
token
one
and
so
on
and
request
one
with
token
two
and
responds
accordingly
and
as
far
as
the
client's
concerned,
when
he
matches
up
token
one,
he.
D
E
The
response
to
data
instead
of
the
response,
one
data,
so
this
is
General
manipulation
of
some
guy
sitting
there
in
the
middle
and
the
same
thing
can
be
done
with
con,
but
here
is
that
the
the
foe
in
the
middle
is
getting
a
bit
smarter
and
so
he's
getting
around
the
end
start
equals
one
issues
by
acting
back
the
con
request.
So
as
far
as
the
client
is
concerned,
everything
is
is
not
a
piggyback
response.
At
this
time
he
is
going
to
get
a
subsequent
once
coming
back.
E
He
then
replaces
the
tokens
moving
Upstream,
the
response
comes
back,
which
is
now
act
and
again
the
foe
changes
it.
While
this,
because
it's
a
delayed
response,
we
need
to
send
it
back
as
a
con
and
then
drops
the
responding
act
so
again,
just
even
with
cons.
It's
relatively
easy
for
a
foe.
To
do
token,
lip
relation
and
get
around
the
end
start
equals
one
kind
of
block
which
most
people
will
be
challenged
by.
E
E
So
there's
two
completely
separate
DCS
sessions,
one
back
to
the
client
and
one
up
to
the
server
and
so
again
someone's
commented
earlier
is
mitigation
against
that
kind
of
stuff
is
to
use
OS
core
or,
and
certainly
do
not
use
no
SEC
against
that
type
of
attack.
But
it
is
a
different
type
of
attack.
That's
out
there
I,
don't
think,
there's
much
else.
That
needs
to
be
said
about
that.
But
I
think
that
sort
of
thing
should
be
in
the
co-op
attacks
document.
E
2
request
for
the
next
block
that
you
want
coming
back
so
essentially
is
that
there
is
no
data
that
passes
through
on
these
request
for
the
subsequent
block
coming
back
from
the
server,
and
the
same
is
true
if
observe
is
being
used.
As
far
as
that
is
concerned,
an
observer
Quest
using
block
one
and
then
somewhere.
Subsequently,
the
client
decides
to
deregister
it.
It
has
to
send
the
entire
original
data.
E
Is
my
understanding,
including
all
the
block
ones
as
I
read,
7641
3.6,
but
a
cancellation
May
trigger
a
block,
2
set
of
responses,
and
what
still
is
currently
unclear,
in
my
mind,
is:
should
the
client
wait
for
all
the
or
go
forget
all
the
block,
2
responses
to
complete
the
deregister
process
so
that
the
server
can
completely
do
stuff
or
do
it?
It's
just
the
first
block
coming
back
sufficient
to
acknowledge
that
the
d-register
has
actually
successfully
taken
place
and
I.
Does
anyone
have
an
opinion
on
that.
B
B
E
Sure
it's
it's
it's
kind
of
in
one
sense,
alerting
them
to
them
that
they
can
be.
They
haven't,
or
someone
hasn't
properly
thought
through
the
security
model
and
what
are
the
effects
of
a
malicious
actor
doing
stuff
but
yeah?
It's.
You
know,
token
manipulation.
You
know
someone
couldn't
say
well,
I've
unlocked
my
car,
but
that's
been
manipulated
to
follow
on
with
the
Locking
of
the
car
and
then
reversing
them
around
and
yeah.
You
get
you
get
this
great
potential
there
for
creating
real
fun
and
games,
but.
B
E
F
D
B
E
F
I'd
just
like
to
pick
up
that
point
of
of
having
those
two
or
five
brothers,
two
three
one
responses
to
re-emphasize:
how
I
think
we
should
fix.
We
should
consider
fixing
block
wise
with,
in
this
interaction
case,
to
just
send
request
payload
again,
because
fetch
Works
fetch
could
do
all
this
two
or
five
stateless
server
thing,
but
it
can't
because
the
request
payload
doesn't
get
repeated.
F
D
E
F
Or
no,
no,
no,
no
it
it
would.
It
would
be
fine
if,
if
there
is
block
one,
if
if
there
is
block
one
splitting
and
there
is
and
and
and
the
block,
one
cannot
be
processed
independently,
as
it
can
only
be
done
when
there
is
no
actual
response,
then
yes,
the
server
is
stateful
and
it
won't
get
around
this,
but
many
fetch
requests
will
have
the
fetch
payload
fit
in
a
single
request.
F
E
E
F
A
D
E
F
A
F
E
D
A
A
A
C
B
C
Okay,
then
yeah
I
wanted
to
talk
a
little
bit
about
DNS
over
Co-op
and
our
progress
again
for
those
in
case
someone
doesn't
know
what
I'm
talking
about
again.
We
want
to
encrypt
a
name
resolution
for
iot
devices
against
eavesdropping,
and
for
that
we
want
to
use
Co-op,
namely
DNS
over
Co-op,
so
we
can
use
encrypted
communication
and
the
clockwise
method
and
also
share
system
resources
with
the
co-op
application.
C
Published
and
it
Conex
2023
and
there's
also
a
preprint
available
on
archive.
If
you
want
to
read
into
it
already,
how
does
our
doc
draft
there
was
a
question
by
the
chairs
relate
to
the
dnsc
board
draft.
We
also
currently
discuss
in
the
sibo
working
group
the
draft
of
about
DNS
of
a
Corp.
It
just
introduces
an
application,
DNS
message
format
which
a
Content
format,
which
is
basically
just
mapping
the
media
type
from
HTTP
DNS
over
the
https,
so
it's
a
classic
DNS
wire
format
and
easily
transferable
to
other
DNS
transports.
C
However,
if
we
work
in
the
iot,
sometimes
things
are
not
small
enough,
even
when
we
use
the
classic
name
compression
that
we
have
in
the
DNS
wire
format.
So
we
decided
to
go
for
sibo-based
format,
which
is
application,
DNS
Plus
sibo,
as
discussed
in
the
draft,
which
reduces
the
message
size
even
more,
and
if
that
isn't
even
isn't
enough,
says
optional
support
for
practice,
eboard,
so
that
we
can
even
have
even
smaller
messages.
C
C
We
clarified
that
the
the
DNS
over
Co-op
is
orthogonal
to
DNS
over
HTTP
and
in
what
way
we
recommended
that
the
root
path
should
be
the
DNS
resource
pass.
We
set
an
ID
for
the
application,
DNS
con
message
format,
namely
3535c5.
So
you
know
three,
five,
three,
five
three,
so
we
have
somewhat
that
remembers
you
about
the
dnsport.
C
C
C
B
C
Dtls
there's
also
GitHub
issue
on
that
and
the
co-op
I
there's
already
a
co-op
ID
for
Co-Op
over
TLs,
but
it
was
never
mandated
for
details
and
Ben
also
recommended
to
keep
this
for
TLS
only
and
have
maybe
a
new
ID
for
dtls,
and
there
is
nothing
on
SV
CBS
for
Oscar
ad
hoc.
We
started
some
discussion
on
the
mailing
list,
but
there's
still
some
consensus
on
that
needed
and
even
though
they
are
especially
because
they
are
orthogonal,
there
is
some
translation
needed
between
doc,
o
d
o
h.
C
Maybe
when
we
have
a
co-op
to
HTTP
proxy-
or
we
just
say
hey,
this
is
just
a
DNS
forwarder
and
it
keep
it
treats
DNS
over
a
HTTP
like
any
other
DNS
transport.
But
the
main
question
here
is
to
the
co-working
group
how
to
translate
fetch
to
http
in
general.
Maybe
we
answer
this
in
the
document
or
maybe
we
do
not
Marco.
D
F
C
I
mean,
and
the
other
problem
is
now
that
I
know
what
we're
actually
talking
about
is
for
Doh.
There
are
very
specific
methods,
defined,
get
and
post,
so
I,
don't
think
we
can
use
the
query
or
the
search
methods,
so
they
need
to
be
some
decision
or
some
definition
on
how
to
translate
it.
If
we
want
to
go
that
route
so.
F
C
F
C
Okay,
then
we
just
specify
that
I
guess:
okay,
then,
the
other
thing
that
is
still
open
is
a
GitHub
issue
which,
given
the
discussion
in
the
previous
talk,
I'm,
not
even
sure
if
this
is
applicable
anymore.
So
it's
basically
about
when
we
use
Doc
in
the
unprotected
case.
So
if,
for
whatever
reason,
we
can't
use
crypto
and
but
we
want
to
have
the
feature
set
of
Doc
like
blockwise
transfer,
and
currently
the
draft
says
that
you
should
not
use.
C
B
C
I'm,
sorry,
maybe
I
just
copied
the
title
of
the
issue
and
yeah
okay
yeah,
maybe
some
a
little
bit
more
specific,
would
have
helped
yes
I'm
talking
about
the
DNS
message.
Id!
Thank
you
so
yeah.
The
question
is:
if
we
still
could
maybe
use
mid
0
and
instead
rely
on
the
tour
to
co-op
tokens,
but
a
little
bit
from
the
talk
before
I'm,
not
sure
if
this
helps
or
if
you
can
rely
on
that.
D
C
C
So
the
question
now
remains:
what
do
we
need
from
the
widget
from
the
working
group
to
prove
process,
progress
and
yeah?
Basically,
the
things
we
discussed
here
already
is
the
guidance
on
how
to
translate
fetch
to
https.
We
don't
do
that,
and
also
like
a
statement
or
some
action
item
on
the
service
B
records
above
with
escort
or
Co-op
over
dtls
and,
of
course,
there's
always
more
feedback.
It's
always
appreciated.
G
C
B
G
G
C
G
C
A
A
F
So
basically,
what
I
would
like
to
achieve
today
is
to
get
a
rough
feeling
of
the
working
group
of
whether
this
is
a
direction
the
working
group
is
willing
to
support
background
is
so.
This
document
is
a
an
individual
document
by
Karsten
whom
I've
joined
as
an
author
in
the
in
the
Dasher
one
version,
and
the
original
direction
of
the
document
was
that
it
would
just
describe
Define
a
few
options
for
things
like
triangular
responses
and
responses
that
are
pre-configured
but
see
what
they
are.
F
The
response
for
in
in
dash
one.
This
is
being
generalized
to
not
only
describe
such
options
but
to
Define
what
to
to
to
to
flesh
out
the
general
concept
behind
them,
which
is
not
only
used
in
those
options
but
has
been
in
use
since
the
start
of
of
of
Co-op,
for
example,
in
observations
or
in
in
not
in
response
to
multicast
requests,
but
all
is
seeing
an
increase
in
in
such
options.
F
F
On
the
same
token,
we
are
not
interfering
with
flow
control
or
we
are
interfering
with
flow
control,
but
I
think
the
general
cases
we
are
not
interfering
with
flow
control.
General
crop
flow
control
still
applies
and
and
give
a
set
of
such
rules
that
can
then
be
quote
not
quoted
are
referenced
when
a
new
option
is
introduced
and
I
think
this
is
both
helpful
in
keeping
the
specifications
clean
and
in
keeping
the
implementations
clean,
because
the
implementations
can
then
say
we
have
a
request.
F
The
intention
is
not
to
redefine
observation
and
multicast
and
response
to
multicast
requests
here,
because
that
would
be
updating
a
whole
lot
of
documents
and
would
mean
generally
these
things
already
do
work.
There
is
an
appendix
that
describes
them
in
that
way,
but
this
is
purely
informative
and
if
it
so
happens
that
at
a
later
point
in
time,
one
of
those
documents
does
Abyss,
it
might
be
perfectly
feasible
to
use
new
terminology.
But
that's
not
the
plan
here.
A
A
D
F
F
E
E
C
F
It
is
the
destination
address
of
the
request
that
is
keying
everyone
to
the
fact
that
the
token
will
be
will
be
used
with
multiple
responses
when,
when
a
message
is
set
up
through
as
a
phantom
request
for
multicast
notifications,
that
is
also
a
key
that
that
there's
something
going
on,
but
it
doesn't
need
to
be
in
a
co-op
option.
Okay,.
F
Whereas
then,
whatever
describes,
the
characteristics
of
responses
could
be
safe
to
forward
all
so,
for
example,
if
we
were
to
introduce
a
mechanism
to
the
the
classical
clockwise
responses
that
allows
the
server
to
respond
with
multiple
block
2
options
are
block
2
messages.
Then
we
could
have
a
proxy
unsafe
option.
F
This
is
especially
important
when
looking
at
what
options
are
inner
and
outer
in
the
oscore
sense,
because
the
please
keep
the
gates
open
option
needs
to
be
outer,
because
the
proxy
that
is
not
participating
in
oscore
needs
to
be
aware
that
there
are
multiple
things
coming
in,
but
we
don't
necessarily
want
to
tell
that
proxy.
What
it
is
we're
doing.
Are
we
doing
multicast
here?
Are
we
sending
doing
a
large
block
transfer
in
a
block?
Transfer?
That's
not
supposed
to
be
visible
to
the
block
to
the
proxy.
A
F
F
F
Hearing
that
I
that
that
there
was
positive
feedback
out
of
the
working
group
I
think
it
could
next
step
for
me
would
be
to
to
to
also
gather
that
implementation
experience
and
then
feed
that
back
into
next
iteration,
so
not
planning
to
present
on
on
117
and
I.
Don't
think
I
will
have
an
update
in
time
for
the
cutoff
custom.
B
A
D
B
F
A
Okay,
if
none,
we
are
the
aob
and
we
quickly
touched
on
most
of
this.
Actually.
So
we
are
meeting
in
20
days
from
today
on
Tuesday
25
or
two
hour
session
in
the
morning
of
San
Francisco
mid
late
afternoon
or
late
afternoon,
in
Central
European,
Time
Zone,
and
then
we
have
already
booked
a
time
slot
and
a
physical
room
for
a
side
meeting
of
core.
A
That's
the
last
day
of
the
ITF
meeting,
all
considering
the
main
meeting
agenda
and
room
availability
and
so
on,
but
we
reserved
everything
for
well
the
same
time
slot
basically
the
morning
of
San
Francisco.
In
the
late
afternoon
in
Europe,
we
have
a
link
to
miteko
available
to
use
as
this
it
was
created.
Hopefully
it
works
fine,
otherwise
we'll
use
within
Beauty
as
a
fallback
and
yeah.
The
idea
was
to
mainly
discuss
non-traditional
responses.
A
And
finally,
we
were
thinking
very
ahead
of
the
next
series
of
corinthory
meetings,
post
itf-117
and
we
have
a
very,
very
tentative
calendar,
just
keeping
the
same
cuttings
as
now
on
the
odd
weeks
same
day
same
time,
it's
just
something,
first
of
all
to
confirm
with
the
the
chairs
of
seabor.
To
be
sure
we
keep
interleaving
I,
don't
know
Christian
if
you
can
at
least
confirm
the
intention
to
keep
the
same
Cadence
in
seabor,
otherwise,
we'll
we'll
check
better,
also
made
with
berry.
A
Okay,
we'll
open
a
thread
with
you
I'm
better
than
if
Barry
also
agrees,
then
we'll
raise
this
at
F-117
further
confirm
on
the
list
and
there's
no
big
problem.
We
we
go
for
it,
there's
one
particular
plan
day
where
cars
and
I
are
not
available,
but
as
long
as
time
is
available,
it
should
be
possible
to
have
the
the
meeting
anyway.