►
From YouTube: IETF115-CORE-20221107-1300
Description
CORE meeting session at IETF115
2022/11/07 1300
https://datatracker.ietf.org/meeting/115/proceedings/
A
Thank
you,
okay,
so
we
are
one
past
the
hour.
We
can
start
a
meeting
and
welcome
everyone.
This
is
the
itf-150
meeting
for
the
co-working
group,
I'm
Marco,
my
coaches
are
I'm
a
humanity
and
Carson
Borman
before
starting
the
actual
meeting.
I
quickly
share
an
external
slide.
If
I
can
share
my
screen.
A
That's
just
to
convey
some
good
news
that
most
of
you
probably
already
had
huge
congratulations
to
Francesca
and
Christian
for
newborns,
and
indeed
thanks
a
lot
also
for
providing
likely
future
working
group
chairs
and
ads
and
or.
A
Right
as
usual,
we
assume
people
here
especially
contributing
to
discussions
to
have
read
the
documents
in
the
agenda
for
today.
Let's
try
to
make
good
use
of
our
time
within
discussion
and
as
it
comes
in
the
next
slide,
not
well
applies,
please
even
on-site
sign
in
with
the
meet
Echo
app
to
be
sure
you
are
taking
the
blue
sheet.
The
chairs
will
keep
an
eye
on
the
chat
and
we
have
two
volunteers
for
Undertakers,
Bill
and
Rickard.
Thank
you
very
much.
A
Anyone
else
is
more
than
welcome
to
further
out
yes
and
as
an
official
ITF
meeting,
the
note
will
apply.
So
nothing
well
be
familiar
with
that.
If
you're,
not
it's
not
just
about
IPR
patterns
and
so
on,
it's
also
in
the
special
about
our
color
conduct,
so
be
nice
and
professional
to
each
other.
A
Yeah,
a
few
practicalities,
if
you're
not
used
to
that
already.
It
doesn't
really
change
much
from
the
recent
past
for
online
attendees,
but
for
people
on
site
again
be
sure
to
sign
in
the
session
with
the
mythical
tool,
and
if
you
want
to
go
to
the
mic,
please
be
sure
to
First,
join
the
queue
and
then
go
to
the
mic
and
then
leave
the
queue
as
well.
You
may
also
have
to
relay
a
question
if
it's
better,
for
you
just
type
it
on
the
chat
with
Mike
prefixed.
A
This
is
the
agenda
for
today
we'll
continue
this
chair
slot.
With
the
document
status
update.
Then
we
have
updates
about
the
href
document
conditional
attributes
and
a
new
document
on
a
potential
Target
attribute
registry.
A
Then
we
enter
into
a
series
of
security,
Works
group
of
score,
the
profiling
availability,
establishment
for
cop
underscore
and
key
update
for
Oscar,
meaning
Kudos,
and
we
conclude
with
two
slots
covered
by
a
single
presentation
about
the
DNS
of
aircraft
document
in
core
and
the
companion
document
about
encoding
DNS
messages
in
seabor.
A
Heard
in
Reading
none,
then
we
can
go
on
with
document
status
and
we
had
the
problem
details
document
now
published
as
RFC
in
9220.
That
was
indeed
a
big
achievement,
also
done
in
a
pretty
much
record
time
and
I
believe
Carson
can
provide
a
little
bit
more
context,
also
on
related
work,
also
happening
in
httpbs.
B
Yeah,
just
a
quick
piece
of
information.
This
draft
problem
details
actually
is
a
knock
off
from
RFC
7807,
which
is
solving
the
same
problem
for
HTTP
and
Json.
So
this
is
the
co-op
c-bar
and
energy.
We
didn't
copy
it
wholesale
because
it
constrained
systems
are
a
bit
different,
so
there
were
some
changes
and
we
would
have
loved
to
use
the
new
version
of
7807,
but
that
is
only
completing
now.
So
this
is
pretty
interesting,
so
well,
the
ipf
last
call
just
finished,
but
I
still
think.
B
If
you
find
something
broken
in
there,
they
still
want
to
know
that.
So,
if
you
want
to
have
a
look
at
this,
this
was
would
be
useful
and
well.
One
interesting
thing
is
that
to
register
these
problem
types,
you
need
identifiers,
and
the
question
is:
where
do
these
identifiers
come
from
and
we
have
decided
they
come
from
ayenna.
B
So
if
you
want
to
get
an
edifier,
you
go
to
Ayana
and
register
it
there,
and
this
should
be
sufficiently
low
overhead
that
you
can
do
it
and
in
this
draft
the
ideas
that
you
essentially
can
forge
your
own
Ayana
your
eyes
as
the
referenceable
identifiers.
So
we
have
integers
the
original
or
the
updated.
Original
draft
now
has
INR
Uris,
and
this
is
starting
an
interesting
discussion.
It's
probably
more
more
an
aerial
General
thing
about
the
reference
it
will
identifiers
going
into
the
Ayana
Registries,
but
yeah.
B
Yeah,
the
the
one
thing
that
that
I'm
not
going
to
detail
is
that
this
RFC
contains
three
pieces
of
Hebrew
text
which
took
us
about
two
months
to
actually
publish
an
energy.
A
Yeah
moving
on,
we
have
when
documenting
isg
processing
course,
C9
version
19
and
it's
4980
follow-up.
There
is
plan
to
have
further
discussion
already
during
the
ITF
week
with
other
people
involved
in
coreconf
and
and
it
covered
also
the
later
intermediate
plan
for
for
December,
but
I
believe
this
document
can
be
wrapped
up
pretty
soon
to
take
the
next
step,
publication.
A
We
have
a
number
of
documents
that
are
after
The
Working
of
last
call.
Library
are
also
part
of
the
corecomm
cluster.
They
were
put
on
ice
and
waiting
for
the
other
two
core
of
documents
to
be
completed
first,
so
these
are
also
supposed
to
be
taken
up
soon
too.
A
A
As
to
other
documents,
we
have
two
currently
in
working
request,
call
conditional
attributes
that
got
updated.
We
have
in
today's
agenda
and
group
on
this
that
is
waiting
for
a
second
wave
of
comments
or
confirmation
to
come
following
the
first
one.
We
have
also
adopted
DNS
over
cop
after
summer.
It's
also
in
the
agenda
for
today
and
there's
a
document
group
comproxy
appending
a
working
group.
Adoption
call.
A
And
a
number
of
other
individual
documents
were
also
resubmitted
before
the
cutoff,
not
in
the
agenda.
For
today.
Please
have
a
look
at
those
provide
comments
on
the
list
and
we
had
also
a
brand
new
individual
document
that
was
already
resubmitted
during
the
academic.
Basically-
and
it's
on
today's
agenda
proposing
you
a
new
registry
for
Target
attributes,.
A
Yeah,
so
we
can
start
with
the
first
item
as
a
recommendation.
Of
course,
please
be
sure
to
wear
your
masks.
Possible
exception
is
up
to
you
is
if
you
are
at
the
mic
actively
speaking
and
presenting.
Thank
you.
B
I'll
demonstrate
the
right
way
to
use
the
microphone
with
a
mask,
hold
it
very
close
and
unless
you
have
singers
training,
you
cannot
do
this
with
a
stand
just
so
you
always
have
to
take
them
microphone
so
Sia
eyes.
The
document
is
called
draft.
Iit
iatf
called
href
because
we
couldn't
decide
on
how
to
call
them,
but
they
are
not
called
Cris.
B
B
So
the
interesting
thing
is
when
you
take
something
that
has
such
a
long
history
as
a
UI
and
try
to
come
up
with
a
structured
representation
of
that,
you
essentially
have
to
build
a
data
model
for
what
information
is
in
a
UI
and
that's
a
bit
more
complicated
than
maybe
meets
the
eye
immediately
and
there
are
some
dark
corners
and
we
don't
really
care
that
much
about
those
dark
corners,
but
we
need
to
cover
them
to
really
make
Cris
faster
citizens.
So
we
started
to
make
sure
we
can
do
co-op
and
Co-op
s.
B
Now
that's
easy,
but
yeah
there's
some
some
weird
stuff
and
there
are
some
features
in
particular
the
percent
encoding
mechanism.
That
really
is
at
three
levels
at
the
same
time:
lexical,
syntax
and
semantics.
B
So
Cris
are
the
standard
structure
are
intended
as
a
standard
structure
for
past
UI.
So
you
don't
need
a
UI
browser
anymore
and
of
course
every
one
of
us
has
written
a
URI
parser
that
was
about
20,
correct
and
yeah.
This
is
supposed
to
be
done
for
you
before
the
CRI
hits
your
constraint
device
and,
of
course
the
other
attempt
is
to
be
concise,
use
less
bytes
than
a
URI.
In
many
cases.
Next
slide.
B
B
B
The
problem
is,
if
you
provide
a
text
encoding
for
something
that
can
also
be
encoded
as
an
integer,
and
that
integer
comes
in
later,
implementations
need
to
choose
whether
they
use
the
text
encoding
or
the
integer
encoding,
and
they
will,
of
course,
look
at
the
deployment
situation
out
there
and
say
only
99.73
actually
Implement
that
yet
and
I
don't
want
to
lose
the
the
other
0.37.
B
So
I'm
going
to
use
the
text
encoding
so
essentially
adding
something
to
a
registry
after
the
fact
will
have
no
effect
in
in
many
environments,
so
that
that's
a
problem
with
just
saying:
oh,
we
drop
in
a
registry
here
and,
and
that
provides
the
extensibility.
We
need
next
slide.
B
So
the
idea
is
that
we
limit
or
restrict
the
point
in
time
when
these
registrations
can
happen
to
a
the
initial
prefill
of
the
registry.
That
happens
when
we
publish
this
this
drop
and
B
to
the
point
in
time,
when
a
new
URL
scheme
that
we
we
couldn't
know
about
at
the
time
the
draft
was
was
published
as
an
RC
when
a
new
UI
scheme
is
registered.
B
So
that's
relatively
safe
I
mean
the
the
UI
schemes.
The
new
UI
scheme
is
going
to
be
and
use
in
testing
and
so
on,
but
yeah
it
kind
of
only
gets
official
when
the
URL
scheme
is
registered
and
we
have
early
allocation
and
so
on,
so
that
that
should
happen
early
enough.
B
So
we
have
a
Wiki
where
we
try
to
connect,
collect
data
for
an
initial
preview
and
actually
the
dash
o1
version
of
this
internet
draft
has
a
significantly
expanded
set
of
of
items
to
prefill
so
yeah.
At
some
point,
we
will
declare
Victory
on
this
Gathering
activity,
but
really
the
question
is
whether
this
is
the
right
way
to
do.
How
do
we
get
people
who
register
a
UI
scheme
to
actually
think
about
whether
they
should
be
registering
a
number
for
Cris
as
well?
I
mean
it's
not
not
disaster.
B
If
they
don't,
would
it's
just
less
efficient,
so
next
slide
during
the
hackathon,
an
idea
came
up
and
the
reason
the
idea
came
up
is
that
the
URI
scheme
registry
already
had
a
column
added
to
it
in
the
past.
So
when,
when
on
your
eyes
needed
to
needed
an
indication
on
the
UI
scheme,
whether
that
your
ice
cream
has
when,
on
your
eyes
or
not
a
column,
was
added
to
the
your
ice
cream
register,
which
is
defined
in
7595.
B
That
provides
the
information,
essentially
a
Boolean
Value
Plus,
a
reference
to
the
RFC
in
which
this
is
described.
So
why
don't?
We
just
add
another
column
with
this
number,
so
people
who
want
to
add
something
to
the
UI
registry
and
look
in
there
and
and
want
to
emulate,
match
the
existing
entries
they
get
kind
of
they
they
get
LED
nudged
to
actually
register
a
number.
B
If
that
is
Meaningful,
I
mean
registering
a
number
too
many
is
using
up
our
space,
but
we,
we
are
talking
about
100
permanent
UI
scheme
registrations
at
this
point
in
time.
So
before
we
even
leave
the
first
bite,
a
lot
of
additional
registrations
will
have
to
be
done,
so
we
don't
have
a
problem
with
that.
B
So
that's
really
something
that
we
as
a
working
group,
try
to
prevent
impinging
on
somebody
else's
space
and
meddling
with
that.
We
don't
do
that,
but
in
this
case
it
may
be
worth
it
and
it's
they're
pretty
innocuous
thing
so
that
that's
what
we
are
currently
thinking
about
and
I
would
like
love
to
get
some
feedback
for.
A
B
But
yeah
I
mean
why
have
two
tables
when
the
information
can
go
into
one
so
that
that's
the
database
person
and
we're
speaking
yeah,
but
we
have
to
discuss
what
what
what's
the
best
way
to
do
this.
But
the
important
thing
is
that
the
the
registry,
the
Ayana
page
for
the
registry,
contains
the
information
that
there
is
the
opportunity
to
get
a
number
with
the
registration
of
the
scheme,
Market
so
yeah.
B
But
please
look
at
the
Wiki
page
that
was
mentioned
on
the
previous
slide
and
to
see
whether
your
favorite
iot
UI
scheme
actually
is
discovered
so
that
that's
the
big
one.
Well,
it's
not
big,
but
the
largest
one
next
slide,
and
we
have
a
few
more
issues
open
that
essentially
all
have
a
resolution
already
in
the
GitHub
issue
discussion.
But
the
resolution
needs
to
be
written
up.
B
We
plan
to
have
this
done
before
this
IDF,
but
it
didn't
happen
so
the
the
ideas
that
we
will
do
this
now
and
use
the
next
core
interim
on
November
23rd.
To
finish
this
up
and
of
course,
they're
pretty
important
issue
here
is
having
test
vectors.
B
So
how
do
people
know
that
their
CRI
implementation
is
approximately
correct
and
of
course
we
don't
want
to
fill
this
draft
with
with
fill
the
specification
with
test
vectors,
but
where
test
vectors
actually
are
illustrating
the
way
Cris
work,
we
want
them
in
an
appendix,
so
we
will
make
one
more
round
on
the
test
vectors
and
then
select
a
few
to
add
to
the
appendix
next
slide
so
yeah.
B
A
B
C
Okay,
I'm
left-handed,
so
I'm
going
to
hold
the
mic
the
other
way.
Hopefully
this
works
hello,
everybody.
So
this
is
the
presentation
for
a
working
group
document
conditional
attributes
for
constrained
restful
environments.
So
it's
a
pretty
much
of
a
mouthful,
but
anyway
it's
conditional
observed
pretty
much
now,
there's
not
very
many
slides
here,
the
if
you
can
move
it
to
the
next
page,
so
the
current
status
has
been
that
the
document
has
been
in
working
group
last
call
for
a
while.
We
received
one
review,
Thanks
Marco
for
it.
C
If
you're
interested
in
the
review,
you
can
click
on
the
URL
and
then
you'd
see
how
extensive
it
was.
Myself
is
the
editor
I
I
opened
up
issues
for
every
every
little
part
that
Marco
Marco
remarked
upon.
So
in
total
we
had
about
20
issues
that
were
open
on
GitHub.
C
19Th
are
closed.
One
is
still
open
next
slide,
so
the
full.
The
full
list
of
the
working
group
last
call
review
comments
are
at
that
URL.
You
can
see
them
all.
Like
I
said
20
issues
19
Clause
wants
to
open.
C
C
One
close
issue
was
just
referring
to
RFC,
7252
and
RFC
7641
for
the
focal
weapon
and
observe
to
be
normative
references
and
instead
of
informative
and
then
one
other
closed
issue
was
just
about
a
clarification
to
avoid
the
draft
talking
about
value
changes
and
and
transmitting
values,
and
instead
considering
state
state
representations
and
state
changes.
C
So
so
that
was
done.
There's
one
open
issue
still
left.
It
requires
a
minor
code
review,
I,
hope
that
can
be
done
by
this
week.
So
that
should
be
closed
very
soon
as
well.
C
Next
slide,
so
that's
it.
Basically,
we
want
to
complete
the
remaining
issue.
More
reviews
are
always
welcome.
We've
only
got
one
so
far.
We
had
some
some
others
before
before
we
went
to
a
working
group
last
call,
but
obviously
more
reviews
are
always
welcome.
C
Now,
a
question
that
came
up
was
when
I
was
discussing
a
little
bit
more
about
getting
more
review,
as
was
whether
we
should
request
an
early
review
from
the
iot
directorate.
So
I'll
leave
that
to
the
working
group
to
decide
in
the
working
group
chess.
C
If
that's
a
good
idea
or
not,
and
that's
the
only
thing
I
have
the
next
slide
would
say
thank
you,
but
it
might
be
premature.
Yet
if
any
questions
would
you
like
to
take
them.
A
Yeah
thanks
Bill
I
heard
of
it
personally
volunteering
to
review
already
and
then
I
think
it's
a
good
idea
anyway,
to
request
an
early
review
to
the
IIT
directorate,
but
I
think
we
should
go
ahead.
D
C
D
Okay,
yes,
that
would
be
nice
to
have
it
at
the
iot
directorate,
so
you
basically
can
click
into
the
button
review
request,
and
then
we
take
it.
No
problem
with
that.
I
I
can't
review
it
as
well.
B
2000
12.,
we
invented
this
link
format
thing
with
which
became
RFC
66
90.,
and
this
link
format
has
so-called
Target
attributes
and
yeah.
Now
this
is
coming
up
again
so
about
10
years
in
the
making
this
draft,
it's
already
a
dash
or
one
because
yeah
again
it
has
an
initial
initial
set
of
registrations
and
then,
of
course,
is
growing
all
the
time
next
slide.
B
So
the
the
link
from
a
Target
attributes
are
really
meant
to
to
tell
you
with
a
link
that
may
be
in
the
resource
directory
or
in
the
way
known
call
information
what
kind
of
Link
this
is.
Well,
that's
what
the
relation
says,
but
also
what
you
can
expect
to
find
at
the
destination
of
the
link
and
what
that's
why
these
things
are
called
Target
attributes.
B
So
we
don't.
We
didn't
invent
this,
but
took
this
from
the
web
linking
RFC
59.88,
and
that
has
things
like
media
type,
so,
for
instance,
for
a
link
you,
you
can
get
a
hint
what
you're
likely
to
find
what
kind
of
media
type
you
are
likely
to
find
at
the
other
end.
B
So
you
can
decide
not
to
use
the
link
if
you
don't
support
the
media
type
and
for
us
in
particular
the
the
two
target
attributes
RT
and,
if
were
very
important
and
that's
why
we
put
Registries
for
the
values
of
RT
and
if
into
6690..
B
So
5988
is
is
10
years
old
and
or
a
bit
more
than
10
years
old
and,
of
course,
has
seen
a
revision
and
that
revision
is
82.
Ath
actually
now
says
those
creating
and
maintaining
serializations
of
web,
linking
and
being
format,
obviously,
as
a
serialization
of
web,
linking
should
coordinate
their
target
attributes
to
avoid
conflicts
in
semantics,
Authentics
and
may
Define
their
own
Registries,
because
we
don't
really
have
a
very
good
way
of
doing
coordination,
except
in
a
registry
that
this
is
kind
of
an
obvious
thing
to
do
now.
B
So
yeah
this,
we
should
have
done
this
right
at
the
time
of
8288
came
out
for
some
reason.
This
didn't
happen,
but
we
already
had
a
couple
of
close
calls
for
people
registering
attributes
or
not
registering
using
attributes
describing
attributes
in
an
RFC
or
other
document
that
had
the
same
name
and
we
we
want
to
make
this
less
likely.
So
let's
do
this
now,
so
the
idea
is
to
add
a
new
sub-registry
for
Target
attributes
in
the
core
parameters
registry.
B
So
in
in
the
INR
document,
you
always
have
a
web
page,
which
is
the
registry,
and
then
in
this
web
page
you
have
several
Registries,
which
are
then
called
sub
Registries.
The
terminology
is
totally
confusing
but
anyway,
so
the
policy
for
this
sub-registry
would
be
expert
review.
B
So
I
the
idea
was
well
if
somebody
registered
type
or
something
you
would
look
whether
this
was
something
that
is
very
specific
to
one
ecosystem,
one
corner
of
an
ecosystem
or
whether
it's
widely
used.
So
this
is
the
frugal
thing
and
the
other
thing
is
what
RFC
8126
does
not
have
is
specification
desired.
They
have
a
specification
required
policy
which
says:
hey,
you
have
to
put
a
specification
in
there
and
they
have
expert
review
which
doesn't
say
anything
about
that
and
this
is
kind
of
in
the
middle.
B
So
we
we
really
expect
people
to
do
a
specification
unless
there
are
good
arguments
not
to
do
that,
and
there
is
somebody
in
the
queue
let's
go.
You
want
to
go
now
or
yeah
I'm
almost
done
yeah.
The
the
other
instruction
is
to
use
a
lowercase
letter,
followed
by
lowercase
letters,
digits
and
minus
signs,
because
they
they,
the
the
ancestry
of
these
web.
Linking
things
really
are
email
headers,
which
were
defined
in
the
late
1970s.
B
They
are
case
insensitive.
Of
course,
no
no
same
person
would
design
something
be
in
case
insensitive
at
this
point,
but
because
of
this,
this
45-year
ancestry,
they
are,
they
need
to
be
case
insensitive,
and
we
are
just
saying
you
always
register
the
lower
case
form,
so
people
get
nudged
to
using
that
and
reducing
for
fees
next
slide.
B
B
Rtif
size
are
in
the
link
format.
Document
content
format
is
in
the
co-op
document.
Ops
is
in
the
observed
document,
JCT
JCP,
http
HTT,
it's
in
the
HTTP
mapping
document
Oscar
has
a
Target
attribute.
Okay,
that's
the
the
published
out
of
season.
Obviously
we
put
the
pre-fill
in
in
this
document,
because
the
rfcs
cannot
be
better
actively
changed
to
do
the
registration
and
then
we
have
several
drafts
that
are
in
flight,
and
this
has
two
examples
for
for
drafts.
B
B
Decides
where
the
registration
will
be
made
and
draft
you
look,
it's
called
Discovery
has
another
set
of
Target
issues,
pretty
many
actually
and
yeah
they
they,
since
that
document
is
not
in
a
really
in
a
race
to
completion.
With
this
specification,
they
probably
will
be
registered
there,
because
the
target
attributes
vertices
should
be
in
place
by
the
time
that
happens.
So
we
have
to
manage
this
preview,
but
it's
really
historical
work
to
make
sure
we
have
all
of
them.
B
B
B
Yeah,
we
always
have
that
problem,
but
it's
really
really
funny.
So
a
b
and
F,
for
instance,
doesn't
allow
underscores
in
identifiers
and
each
time
you're
reviewing
someone
who's
coming
in
someone,
it's
ABN
F
who's
coming
in
you,
they
use,
underscores
and
the
identifiers,
because
they're
programming
languages
forced
them
to
do
that.
But
a
b
and
F
was
written
by
people
who
were
programming
in
list
where
minus
signs
are
normally
identified.
As.
A
A
E
F
Very
good
yeah,
so
first
of
all,
I
support
this
draft
and
adoption
because
it's
I
think
we
have
hit
hit
this
issue
a
couple
of
times
in
the
past,
so
that
that
sounds
good
to
have
this
also
pre-filled
and
yeah
make
it
also
available
to
other
standards,
bodies
that
want
to
submit
their
elements
with
maybe
a
pointer
to
their
specifications.
F
One
thing
I
was
just
looking
at
you
mentioned.
Expert
review
and
I
did
see
that
we
have
currently
the
process
of
expert
reviewing.
Someone
sends
a
request.
I
recall
the
last
request
was
in
August
and
there
was
no
reply
yet
to
it.
So
it's
not
particular
quick
process.
As
far
as
I
can
see.
Maybe
we
did
do
something,
but
at
least
it
was
not
visible
on
the
core
parameters.
F
F
F
G
Does
this
document
shoot
this
document,
or
did
you
plan
to
address
the
topic
of
whether
the
semantics
of
that
attribute
pertain
to
the
link
itself
or
to
the
link
Target,
because
all
the
examples
that
I've
seen
here,
except
for
title,
as
defined
in
a288,
are
about
the
target
independently
of
the
link,
whereas
other
attributes
could
be
about
the
target
when
used
through
that
link
or
even
the
link
itself,
as
it
was
in
some
iterations
of
dining
link?
G
Go
ahead,
it
wouldn't
do
anything
about
8288,
it
would
just
be
about
which
attributes
can
be
registered,
but.
G
The
terminology
is
a
bit
confusing:
they
are
called
Target
attributes,
but
they
describe
a
property
of
quote
the
linked
the
link
or
its
Target.
B
Okay,
but
that's
just
then
my
my
mistake
of
putting
title
in
the
second
line
on
the
of
this
slide
instead
of
the
first
line,
but
are
people
supposed
to
put
in
more
information
that
really
is
about
the
link
and
not
the
target?
I
I?
Don't
I
didn't
read
8288
that
way
and
that's
maybe
worth
examining,
but.
G
The
type
the
title
is
an
example.
The
title
is
an
example
of
that
and
the
authors
generally
and
I've
I've
made
back
and
forth
with
with
them,
assume
that
it
could
also
be
just
only
about
this
particular
way
of
accessing
that
resource
or
possibly
even
the
the
the
link
on
its
own.
B
Okay,
I
think
that
that's
really
interesting,
I
I
hope
this
doesn't
sort
of
fall
into
getting
this
document
out
quickly,
because
I
think
that
that's
a
pretty
fundamental
question
about
web,
linking
that
we
would
have
to
discuss
with
the
HTTP
people
as
well,
because
we
we
just
have
copied
that
part
and
simplify
that
a
little
bit.
G
And
and
either
way,
just
one
more
comment
on
the
document
registered
for
that
under
the
registry
as
a
whole,
Coral
will
very
much
want
to
add
a
column
there.
That
says,
and
by
the
way
the
mapping
is
defined
like
this
and
that
independently
of
what
the
answer
to
my
first
question,
is
it's
just
if
the
answer
to
the
first
question
is
yeah,
it
could
be
any
of
those
that
second
column
will
be
a
lot
more
complex.
B
Yeah,
maybe
we
should
get
used
to
the
idea
of
adding
adding
columns
and
Registries
and
in
a
later
document,
so
that,
because
the
we
probably
know
what
how
the
race
between
the
target
attribute
registry
and
coral
is
going
to
go,
and
so
we
can't
really
have
a
column
in
there
for
a
document
that
that
isn't
done
yet
yeah.
But
let's
discuss
this
good
yeah
last
slide,
so
this
is
still
an
individual
draft.
B
We
have
discussed
it
I,
don't
know
how,
often
in
the
last
10
years,
but
somebody
had
to
sit
down
and
actually
write
the
thing
that
has
now
happened
and
the
next
step
would
be
to
make
this
a
working
group
document
I
think
it's
pretty
clear
that
this
is
within
our
Charter,
because
it's
essentially
just
to
maintenance
housekeeping
activity.
B
But
of
course
it's
always
nice
to
get
some
confirmation
from
from
the
80s
about
that,
and
then
do
some
working
group
work
like
answer
questions,
do
a
working,
glass
call
and
finally
profit.
E
H
A
Thanks
yeah
very
well:
okay,
hi
everyone.
This
is
Marco.
This
is
an
update
on
the
group
Oscar
document
next
slide.
Please
yeah.
Before
the
cutoff
we
submitted
version,
16,
essentially
merging
a
single
Consolidated,
PR
98
and
covering
fundamentally
four
things.
Number
one
is
the
major
one
and
it
was
about
improving
the
handling
of
some
particular
responses
that
can
happen
during
the
group
of
score
communication
that
we
noticed
was
not
completely
handled.
A
Number
two
was
also
a
little
trick
to
do
to
downgrade
the
must
to
should
to
not
lock
down
possible
cases.
Well,
three
and
four
were
well
extended
editorials.
If
you
want
improving
the
the
presentation
of
the
security
properties
of
group
of
score
to
be
more
aligned
with
those
of
Oscar
and
the
way
those
are
presented
and
improving
the
presentation
of
the
the
properties
of
the
features
that
the
pairwise
mode
has
and
inherits
actually
from
the
group
mode.
A
We've
had
another
discussion
about
this
PR
with
a
crystals
document
Shepard
that
encouraged
us
to
not
wait
for
his
Shepherd
review
and
write
up
before
going
on
with
this
PR,
and
this
merging
still,
of
course,
will
appreciate.
Follow
the
comments
from
him
and
others,
and
he
actually
realized
that
especially
point
one-
had
a
more
General
applicability
in
the
context
of
non-traditional
responses,
for
which
an
issue
on
the
corresponding
GitHub
wrapper
was
also
opened.
Eric,
also,
before
emerging
very
carefully
reviewed
that
VR
we're
very
thankful
for
that
So.
A
Eventually,
we
merged
that
and
I'm
mostly
going
to
go
through
well.
Basically,
the
content
of
the
pr
that
was
merged
in
version
16
and
and
for
the
end
I
have
a
little
open
point
that
came
up
post
cut
off,
which
is
also
related
to
the
Target
attribute
registry
discussed
in
the
previous
presentation
by
carsten.
A
So
next
slide,
please
yeah
and
I
actually
start
with
with
easy
one
number.
Two
we
downgraded
a
must
to
shoot
about
the
use
of
the
group
mode
for
protecting
a
group
request
intended
to
multiple
recipients.
We
actually
had
already
an
exception
under
our
nose
for
a
while.
There
may
be
probably
more
that
we're
not
even
imagining
now,
but
that
was
enough
anyway,
to
to
switch
to
a
should
next
slide.
Please
right
on
the
main
thing
handling
of
multiple
responses.
A
I
need
to
bring
up
some.
Some
context
here
why
we
had
to
to
make
some
fix.
This
is
text
quoted
from
the
group
comb
base
document,
and
this
text
has
been
around
for
a
couple
of
years
now
after
changes
in
this
direction
that
were
discussed,
agreed
and
even
confirmed
later
on
at
ITF
110.
A
Lastly,
and
since
then
the
text
never
changed,
basically,
a
cop
client
sending
a
group
request
to
multiple
recipients,
because
of
that
preserves
the
token
beyond
the
reception
of
a
first
response
and
taking
advantage
of
that
in
principle,
a
same
server
can
send
back
multiple
responses,
not
necessarily
as
of
certifications,
and
the
idea
was
to
leave
the
final
decision
about
what
to
do
in
that
situation
to
the
application
at
the
client
and
not
the
stock
at
the
client,
since
the
application
of
the
client
can
have
more
context
to
take
a
better
decision
for
that
particular
application,
like
considering
only
the
very
last
response
from
that
server
or
produce
some
kind
of
aggregation
of
those
whatever.
A
So
this
is
the
context
we
we
had
and
we
consistently
built
on
in
group
or
score
next
slide,
please
yeah
and
considering
that
context.
Well,
we
had
a
problem.
Most
was
okay
already
and
basically
the
handling
of
a
single
response
to
a
center
request
or
multiple
responses.
If
they
were
observed
notifications,
the
problem
was,
if
a
same
server
sent
multiple
non-modification
responses
to
the
same
group
request,
and
then
there
were
two
issues
due
to
under
specification
on
the
server
side.
A
That
was
no
text
mandating
the
server
to
include
its
own
sender
sequence
number
as
partial
ID
in
the
responses
following
the
first
one,
so
that
of
course
opened
for
80,
nouns
reuse
and
on
the
client
side.
On
the
other
end,
there
was
nothing
really
mandating
the
client
to
do
any
form
of
response
ordering
enforcement
or
replay
check,
and
anyway,
there
were
no
means
to
do
that,
because
there
was
not
necessarily
a
partial
ID
in
those
responses.
A
So
those
were
the
issues
next
slide.
Please
yeah.
We
think
we
fixed
that,
basically
relying
on
the
same
rational
and
approach
used
for
handling
exactly
the
same
kind
of
problems
for
Observer
notifications
only
separately,
because
we
still
want
observe
to
be
a
separate
feature
optional
to
support
that
may
not
be
around
or
used
only
by
some
servers
in
the
group
and
not
all
of
them
so
separately.
We
Define
the
handling
of
non-modification
responses
to
group
requests
again
using
the
same
rational,
useful
Observer
notification.
A
We
had
to
introduce
a
new
term
already
in
the
terminology
section
we
called
it.
A
Non-Notification
group
exchange
I
stress
the
word
exchange
because
it's
intended
to
be
an
environment
like
an
observation
is
so
something
tied
to
the
group
request
that
the
client
send
and
the
non-notification
responses
that
the
server
sent
to
that
group
request
in
such
a
context,
we'll
have
well
on
the
server
side,
including
the
sender
sequence
number
is
partially
V
in
the
responses
with
the
possible,
let's
say
exception,
of
the
first
one,
which
is
good
and
on
the
client
side
the
client
will
expect
responses
to
comply
with
that,
and
just
like
a
client
that
sends
specifically
an
observed
request,
considers
the
partial
idea
of
notifications
as
a
notification
number
well.
A
The
client
will
consider
the
partial
review
of
non-notification
responses
as
a
response
number
trivially
and
based
on
that
we'll
perform
Ripley
checks
and
ordering
of
the
responses
like
it
happens.
For
notifications
and
like
it
happens
for
notifications
at
most,
one
response
from
the
same
server
is
allowed
to
not
have
the
partial
EV
and
that
has
to
be
considered
the
oldest
one
next
slide.
Please,
and
those
are
the
main
points
related
to
the
actual
message
processing.
A
There's
a
number
of
side
things
that,
as
a
side
effect,
had
to
be
said,
but
they
are
exactly
like
for
the
case
of
notification.
So
if
a
client
and
server
would
like
to
have
this
kind
of
exchange,
continuing
Beyond
a
group
of
King,
they
have
to
preserve
the
caddy
context,
meaning
the
group
ID
originally
used
for
the
original
request
and
use
it
for
the
external
AED
to
bind
all
responses
across
for
Kings
to
the
same
request
just
like
we
do
for
observe.
A
And
similarly,
if
they
want
to
have
this
exchange
surviving
beyond
the
change
of
clients
and
their
ID,
they
need
to
store
a
use
for
the
future
external
idea
of
responses.
The
original
kid
meaning
the
original
Center
ID
of
the
client
that
was
used
for
the
group
request
in
question,
I
managed
on
the
extended
editorial
revisions
in
the
presentation
of
the
security
properties
of
Grupo
score.
A
G
Oh
yeah
I
didn't
quite
get
why
notifications
would
need
separate
handling
from
other
requests
with
multiple
responses,
so
at
least
in
in
the
correspondence
document
which
I'm
working
on
they
could
be
unified.
So
why
can't
they
be
unified
here
with
the
with
the
multiple
responses?
Just
being
a
generalization
of
notifications,
people.
A
G
But
this,
but
this
this
feature
is
not
something
that
is
ever
negotiated
or
or
kind
of
being
technically
exchanged.
It's
just
a
matter
of
phrasing
right,
so
you're
keeping
the
phrasing
of
the
document
so
that
people
can
follow
the
one
line
of
phrasing
for
for
the
notifications
under
different
line
of
phrasing
for
everything
else,
but
then
it
effectively
duplicates
text.
Doesn't
it.
A
Partly
yes,
it
uses
a
slightly
different
terminology
to
emphasize
what
is
about
non-notification
responses,
so
it
does
draw
a
line
indeed,
and
bottom
line
to
stress
that
observe
is
a
separate
service
optional
to
support.
So
one
may
not
even
read
anything
about
observing,
if
not
interested
in
it.
C
A
Okay,
do
you
have
in
mind
the
proposal
request.
A
F
So
yeah
I
was
just
wondering
you
mentioned
the
possibility
that
the
server
basically
sends
multiple
responses,
in
this
case
I
think
in
in
group
comb
this
we
have
written
that
that
can
happen
because
of
somewhat
of
a
faulty
server
implementation
or
something
or
medicine
bug
or
a
malicious
server
that
tries
to
yeah
do
something
to
disrupt
whatever
is
ongoing,
but
but
are
you
considering
that
the
server
could
just
yeah
send
two
responses,
basically
to
request
just
because
she
thinks
oh
I
have
some
yeah
updates
to
send?
Why?
Why
not
do
that?
F
Yeah
yeah
I
think
the
intention
was
not
not
to
support
necessarily
that
okay
said
that
the
server
start
sending
multiple
responses.
It's
more
like
saying,
okay,
it
could
happen,
for
example,
due
to
yeah
this,
this
datagram
getting
duplicated,
so
the
server
could
just
send
back
two
responses,
but
maybe
it's
different
if
you
consider
the
the
score
security
on
top
of
that
I
mean
I,
don't
know
the
details
of
that,
but
yeah.
F
It
seems
to
me
that
should
not
be
a
case
that
the
server
would
willfully
send
multiple
responses,
because
it's
supposed
to
send
only
one
right.
F
F
Yeah,
but
you
could
have
a
client
that
implements
group
or
score
that
already
decides
I'm
only
going
to
accept
the
first
response
that
comes
in
and
then
that
client
doesn't
want
any
code
for,
for
example,
for
handling
future
or
future
responses
with
the
same
token,
so
that
that
means
that
maybe
part
of
what
you're
proposing
is
not
relevant
for
that
type
of
client
right.
A
F
A
So
if
the
application
had
not
tolerance
well,
okay,
then
group
of
square
can
be
aligned
accordingly,
but
if
the
application
is
tolerance,
group
of
scores
should
enforce
the
best
security
possible,
meaning
being
ready
to
to
have
replaced,
coming
and
and
being
able
to
detect
them
to
stop
them.
For
example,.
F
Yeah,
okay,
at
least
deal
with
duplicates
I
agree
with
that,
but
I
don't
know
if
it
should
be
kind
of
designed
for
having
a
server
that
that
necessarily
decides
to
send
an
updated
response
later
on,
because
hey
they're
still
timing
and
can
send
an
update.
That
seems
to
be
going
a
bit
out
of
the
co-op
specification
that
they
have
buttercream
yeah
I'll.
Think
about
that
thanks.
Thank.
A
You
and
and
Christian
back
also
to
your
comment.
Probably
we
are
already
on
the
site
on
the
right
track
for
that
on
the
server
side,
because
it
is
phrased
and
Nigeria
in
a
general
way
to
say
must
include
a
partial
V
in
any
response
following
the
first
one,
regardless
of
being
a
notification
or
not.
So
probably
that's
generally
enough.
The
big
thing
is
on
the
client
side.
Then.
G
Briefly,
I
can
just
repeat
it
quite
quick.
Quite
briefly:
yes,
I
agree
that
if
a
client
doesn't
solicit
multiple
responses,
then
it
can
just
take
a
simple
processing
with
for
one
response
and
that's
either
valid
or
not,
but
there
can
be
multiple
ways
in
which
a
client
would
solicit.
Multiple
responses,
observe
being
one
group
proxy
might
be
another
and
whatever
that
is,
if
it
solicits,
then
then
it
there
is
a
way
of
processing
them.
So
that's
that's
opposed
to
to
the
earlier
discussion
and
to
esco's
question.
G
I'll
bring
that
in
as
part
of
my
room.
Yes,.
A
Thanks
a
lot:
okay,
next
slide,
please,
and
it's
a
final
one
in
fact
yeah
about
Target
attributes
when
working
on
that
PR.
We.
You
know
that
as
cars
I
mentioned
before
the
Oscar
RFC
defines
an
Ask
Target
attribute
to
to
signal
that
resource
is
accessible
using
those
score
and
should
be
accessed
using
those
score.
Of
course,
it
didn't
mention
group
of
score.
A
That's
something
that
likes
like
missing,
so
we
would
propose
to
Define
in
a
group
of
score
document,
a
new
similar
Target
attribute
G
osk
to
indicate
that
the
resource
is
accessible,
using
Oscar
and
or
Grupo
score,
so
very
similar.
Of
course,
we
need
to
to
be
supportive
of
all
the
implementations
that
may
retrieve
a
link
to
such
a
resource,
but
they
don't
support
a
specifically
group
of
score
and
the
target
geosc.
A
So
we
could
think
of
these
rules
of
use
so
that
if
the
link
specifies
geosc,
it
must
specify,
also
ask
and
well
an
all
device.
Not
understanding
group
of
square
geosc
would
ignore
geosc
because
it
doesn't
understand
it
after
all,
and
it's
not
interested
in
Google
score.
A
But
if
it
does
understand
group
of
score
ngos,
it
will
focus
on
it
and
ignore
ask
because
it's
practically
overshadowed
by
the
statement
from
from
geosc
any
comment
or
objection
on
defining
a
Target
attribute
like
this.
This
way.
A
And
it
can
be
also
one
more
addition
for
the
pre-filling
of
the
registry
in
Carson's
draft.
A
Okay,
and
the
next
slide
should
be
really
the
the
wrap
up.
We
can
Surah
submit
of
version
17
anyway,
adding
the
new
Target
attribute,
and
then
we
wait
for
more
input
and
review
from
Christians
Christian
for
the
shepherding.
A
I
E
I
I
However,
normally,
when
you
run
edoc,
it
will
take
you
two
round
trips
and
before
you
can
start
using
oscore.
So
what
this
document
proposes,
and
the
main
contribution
of
this
document
is
an
optimization
to
this
procedure,
where,
when
you
send
your
ad
book
message
3,
you
actually
combine
that
with
an
also
protected
application
request,
and
you
can
do
that
because
at
that
point
you
already
have
a
valid.com
context
to
use.
I
There
are
other
supports
also
in
this
document
specifying
some
other
details
like
oscar-specific
processing
of
messages,
consistent
extension
of
the
educ
application
profile.
You
know
web
linking
and
some
performance
considerations
on
the
Block
wise
and
when
what
updates
have
been
done
since
itf14,
when
version
zero,
five
has
been
submitted
and
there
will
be
no
big
changes
to
the
fundamental
mechanics
of
this
optimized
workflow
and
we
did
make
some
modifications,
Diana
considerations
regarding
shortening
the
text
and
only
like
narrowing
it
down
to
option
number
21.
Previously,
we
consider
other
numbers
too.
I
And
as
far
as
these
performance
considerations
on
blockwise
I
mentioned,
basically
restructured
it
a
bit,
so
we
moved
some
of
that
down
to
an
appendix
in
appendix
a
it's
now,
still
the
same
content
as
used
to
be
in
section
six
and
to
kind
of
summarize
our
conclusions
from
that
is
basically
that,
if
you
have
to
use
block
wise
specifically
because
you're
using
this
optimized
workflow,
meaning
this
combined
request
becomes
so
big,
you
have
to
use
clockwise,
then
this
optimization
has
no
performance
benefit
and
you
might
as
well
use
the
original
normal
edoc
workflow,
because
it's
less
complex
and
since
the
optimization
doesn't
give
you
any
benefit
in
that
case,
just
use
the
normal
Network.
I
So
basically,
there
are
some
considerations
now
about
like
access
control,
because
you
have
to
consider
that
you
may
have
access
control
also
involved,
and
the
fact
that
is
like
just
because
you
completed
with
another
pair
that
doesn't
mean
you'll
get
any
specific
resource
access
and
that
still
has
to
rely
on
the
normal
Access
Control
procedures
that
you're
using
otherwise.
I
We
have
some
information
now
about
that.
Like
let's
say
you
have
access
control,
information,
how
and
what
information
may
need
to
be
provided
before
the
end
of
execution,
yeah.
Basically,
no
considerations
on
this
watch
about
access
control.
I
Now
what
happened
after
the
cutoff?
Well,
we
actually
defined
in
section
six,
some
Target
attributes
for
added
resources,
and
basically
so
now
these
attributes
can
be
registered
in
this
upcoming.
I
The
text
is
removed:
okay,
yeah,
sorry
that
was
opposite
yeah,
the
one
that
the
one
that
yeah
anyway
so
well
regardless.
We
may
want
to
also
revise
the
names
of
the
attributes
like
starting
with
some
kind
of
prefix.
That
shows
that
these
are
specifically
related
to
our
document
and
yeah
and,
of
course,
any
thoughts
or
objections
or
comments
on
this
plan
is
very
welcome.
I
And
yeah
I
go
to
the
next
one,
so
we
had
a
proposal
from
David
Navarro,
so
this
is
also
being
tracked
in
a
pull
request
at
in
the
GitHub
repository,
and
basically
he
noted
that
in
one
of
the
figures
we
have,
we
do
not
include
a
response
to
the
edit
message
tree
and
then
here
the
answer
yesterday.
Okay,
why
don't
you
add
that
documents
before
in
that
figure
just
to
make
it
clear
that
the
message
before
can
in
fact
be
used,
but
basically
the
way?
I
The
reason
we
don't
have
another
message
further
currently
is
that
in
the
text
of
that
doc
draft
it
says
that
if
add,
that
message
was
used
or
if
there's
an
error,
then
edit
message
for
then
the
response
will
be
sent
from
the
server
as
a
as
a
response
to
message
D,
but
basically
like
this,
that
you
may
actually
it's
not
mandatory
to
have
another
message
for,
and
you
can
in
fact
omit
that
okay,
so
well
anyway.
The
proposal
is,
we
merge
this
PR
and
we
add
a
note
to
say
that.
I
Yeah
just
to
summarize
Next
Step,
so
the
document
is
quite
stable.
It's
aligned
also
with
the
latest
static
version,
which
is
version
17.,
and
we
have
agreed
to
keep
in
sync
and
keep
discussions
and,
depending
on
the
state
of
the
actual
ad
book
document,
just
include
a
working
group.
Let's
go
of
that
which
has
actually
concluded
now
on
the
4th
of
November
and
yeah.
Our
proposal
basically
would
be
at
this
point
to
start
the
working
world-classical
for
this
document.
Also
thank
you
yeah,
and
that
was
the
last
slide.
I
I
And
yeah
again,
just
to
recap,
I
mean.
Basically,
this
document
has
multiple
subsections,
one
of
the
main
sections
and
where
the
document
gets,
its
title
is
the
Kudos
procedure,
which
is
a
key
update
procedure
for
all
score
and
the
whole
goal
of
that
of
that
is
to
renew
your
master
secret
and
master
salt,
and
you
also
wish
derive
when
you
send
the
recipient
keys,
because
you
change
the
methods
you
get
master
result.
That
is
the
end
result.
I
Benefits
is
that
you
do
not
change
your
ID
context,
which
is
like
an
internal
identifier
of
telescope
context,
and
you
also
achieve
perfect
forward
secrecy
with
this
procedure.
It's
Loosely
inspired
by
the
appendix
B2
procedure
that
also
defines
for
performing
the
update,
but
with
a
number
of
benefits
over
that
one.
The
other
main
part
is
this
thought
about
aad
key
usage
limits
for
all
score,
because
it
was
discovered
and
is
also
defined
in
other
documents,
like
the
c4d
draft.
I
You
see
on
the
bottom
right
that
if
you
have
excessive
usage
of
the
same
key,
that
may
enable
breaking
some
security
properties
of
aad
algorithms.
So
what
we
want
to
do
in
this
document
is
to
Define
appropriate
limits
when
using
all
score
and
the
limits
are
really
tied
to
what
particular
algorithm
you're
using.
I
We
also
want
to
Define
concrete
processing
steps
for
messages
like
what
counters
and
keys
should
you
use
and
what
you
do
when
you
reach
the
limits,
and
the
final
part
is
basically
a
section
about
updating,
Osco
and
sending
recipient
IDs.
I
Yep
next
slide,
so
this
is
normal
of
the
keying
procedure.
It's
pretty
basic,
it's
a
metrics
exchange
to
exchange,
nonsense,
N1
and
N2,
and
these
are
placed
in
a
new
field
in
those
called
Co-op
option.
Then
we
feed
this
into
this
update,
CTX
function
that
builds
a
new
score
security
context
for
the
players
and-
and
we
also
see
a
picture
there.
The
way
we
extend
the
Oscar
option
with
new
fields
to
hold
the
nuns
and
the
X
byte
and
the
X
byte
holds
the
length
of
the
actual
nouns
and
some
flag
bits.
I
Yeah
and
to
go
into
a
bit
more
detail
on
these
flag
bits
and
updates.
We
did
so.
We
updated
the
registrations
regarding
this
bit
15
as
before.
In
the
case,
this
is
a
Kudos
message
and
you
have
the
presence
of
the
nuns
and
the
X
byte.
We
also
defined
now
that
bit
0
instead
of
it,
one
should
Define
that
you
have
a
second
flag
byte
in
those
core
option,
and
it
say
I
really
didn't
have
any
concrete
use
case.
I
We
simplify
the
method
for
updating
context.
We
used
to
have
two
internal
code
paths,
one
relying
on
the
Adobe
update
one,
relying
on
an
extract
and
expand,
and
we
discussed
this
at
the
Korean
stream
and
we
said:
okay,
some
feedback
was
was
why
don't
you
just
have
met.2
based
on
the
extract
and
expand,
because
there's
no
additional
benefits
from
that
docky
update,
so
we'll
simplify
this
now.
So
we
no
longer
have
two
separate
code
paths.
We
only
go
for
the
extra
expand
method.
Basically
you
see
in
the
green
box
there.
I
That's
a
new
style,
simplifies
implementations
simplifies
for
building
external
values,
they're
no
need
for
any
fallback,
because
previously
it
may
have
been
the
case
that
the
Edo
key
update
was
unavailable
because
the
endoc
session
wasn't
valid
anymore.
I
So
there's
no
need
to
signal
that
or
kind
of
negotiate
on
that
you
don't
even
have
to
support
that
dog
or
be
worried
or
think
about
if
the
original
keys
were
established
using
a
doc.
So
this
was
a
simplification
without
them
loss
of
security
properties.
Here
we
also
updated
the
update
CTX
function
to
not
only
rely
on
an
hkdf,
and
previously
we
specifically
defined
it
to
use
the
hqdf
expand.
I
Yeah
another
part
that
we
did
was
the
find
ways
that
you
can
use
end
hook
to
actually
signal
Kudos
support.
So
let's
say
that
you
actually
do
support
and
you
have
to
be
implemented
between
the
pairs.
Then,
when
the
pairs
run
a
block,
they
can
use
this
EAD,
which
is
basically
optional
data
that
can
be
exchanged
during
a
network
execution
and
we're
defined
EAD
items
for
pairs
to
signal
each
other,
whether
they
support
Kudos
or
not,
and
in
which
mode
so
basically
register
an
ID
label
and
four
possible
values
of
this.
I
I
It's
full
meaning
me
as
the
sending
pair
supports
Kudos,
both
in
the
forward
secrecy
mode
and
the
Note
4
secrets
mode,
or
let's
call
it
the
stateless
and
stateful
modes,
and
you
can
also
indicate
Port,
which
means
you
only
support
Kudos
in
the
nor
forward,
secrecy
mode
and
yeah
I
see
Jordan
is
in
the
queue
there
also,
but
you
can
also
see,
on
the
left
hand,
side
there's
a
small
example.
I
Basically,
when
you
indicate
ask
from
the
initiator
well
in
edit
message
too,
they
responder
with
an
indicate
full
meaning,
I,
fully
support,
Kudos
and
that's
saying
fully
message
to.
You
also
is
an
indication
to
the
initiator
to
indicate
what
it
supports,
so
it
will
in
turn,
respond
with
full.
So
after
he
said,
the
execution
both
pairs
know
that
each
other
supports
Kudos
in
both
fs
and
no
FS
modes.
I
I
It
would
I
mean
it's
I
would
say
that,
like
even
if
you
didn't
have
this
signaling,
you
could
always
do
like
a
trial
and
error
approach.
So
you
try
to
run
Kudos
with
other
player
and
see
if
it
works,
so
you
would
eventually
learn
you
could
try
and
see
if
it
fails
or
you
could
try
in
the
fs
mode
and
then
the
other
pyramid
indicate
no
I,
don't
support
FS
mode,
please
retry
in
the
no
FS
mode.
So
it's
not
something
that
Kudos
fundamentally
relies
on
this
functionality.
I
It's
like
an
extra
nice
feature
that
you
may
have
this
pre-established,
pin
knowledge
after
running
a
doc,
so
you
don't
have
to
go
for
the
trial
and
error
approach,
but
it's
not
a
critical
and
coolest
doesn't
rely
on
this.
Basically.
E
I
Yeah
I
think
that's
a
text
for
input,
yeah
I
mean
definitely
if
this
can
be,
then
there's
a
trade-off.
Like
you
said,
is
it
worth
the
add
complexity?
I
mean
this
is
again
it's
if
you
use
if
you
have
Network
supported
and
even
if
you
have
support
with
red
doc.
This
is
not
mandatory
that
you
use,
but
yeah.
Thank
you
for
them
for
input.
I
We
also
indicate
clearly
that
in
the
client
initiated
version
of
Kudos
and
the
server
must
include
a
partial
AV
in
its
Kudos
response
message
and
I'll
come
back
to
that
later.
But
basically,
this
prevents
are
using
the
same
pair
of
a
denouncing
key
in
certain
situations
and
there's
a
little
open
point
on
how
to
analyze
this
first
score.
Overall
and
we
clarified,
we
have
this
concept
of
a
capable
and
non-capable
device.
So
a
capable
device
is
more
like
a
non-constrained
device,
yeah
capabilism
non-constraining
device
and
non-capable.
I
It's
a
constrained
device
and
we're
not
defined
clearly
what
mode
of
Kudos
they
must
support.
So,
if
you're
capable
device,
you
must
support
forward
secrecy
mode
and
you
should
support
the
no
FS
mode,
but
yeah
you
can
see
in
the
draft
these.
These
concepts
are
basically
related
to
if
the
device
can
write
to
persistent
memory
or
not.
I
I
So,
basically,
if
you
look
on
the
figure
to
the
right
there
and
the
blue
arrow,
you
see
that
in
that
response
one
there's
a
partial
ABCO
and
we'll
conclude
that
the
server
must
in
fact
include
that
partial
living
in
response
one
and
the
otherwise
it's
not
secure
behavior,
and-
and
why
do
you
need
to
do
this?
Well,
it's
because
you
don't
want
to
reuse
the
same
adenons
and
key
pair.
I
So
if
you
look
at
the
table,
you
see
that
these
are
the
request,
one
and
response
one
and
request
two
request:
two
from
the
client
and
server
point
of
view,
and
you
see
that
okay,
let's
say
the
user
nouns
placeholder
value
a
it.
Just
stands
for
a
particular
nouns.
But
the
point
here
is
that
request,
1
and
response
one.
I
Basically,
the
client
will
use
a
certain
amounts
and
the
typical
behavior
is
that
the
server
mirrors
and
reuses
the
nouns
from
the
request.
So
let's
say
it
does
that
then,
following
that
the
client
sends
a
request
2
using
the
same
nouns,
and
you
may
I
mean
the
thing.
Is
that,
like
the
cloud
from
the
client's
point
of
view,
the
client
switches
context
from
Context
one
to
context
new
right?
So,
from
the
client's
point
of
view,
it's
sending
two
messages
with
the
same
numbers,
but
it
has
different
key
right.
I
So
it's
completely
fine,
however,
on
the
server
side,
server
will
send
response
1
with
CTX
new
and
the
mirrored
nouns
from
the
client,
and
it
will
also
send
response
to
with
C
takes
new
and
the
nearest
nodes
from
the
client
and
okay.
You
may
say
why
is
the
most
the
same,
because
the
ctx1
has
become
CTX
new
for
the
client,
and
then
you
reset
your
partial,
ID
and
so
fundamentally
announced
would
become
the
same
so
essentially
to
avoid
this
red
line.
We
will
see
that
the
same
key
and
the
same
nonce
is
used.
I
You
need
the
server
in
response,
one
to
actually
include
a
partial
ID
and
now
okay,
the
way
we
fix
this
now
is
just
an
adult
fix
for
Kudos,
but
we
want
to
define
a
more
generalized
fix
to
say
that.
Well,
this.
This
can
also
be
a
general
fixed
first
score
itself,
because
anytime,
you
transition
between
contexts
like
this.
I
You
will
want
to
include
your
partial
area,
so
we
have
a
proposal
for
text
there
saying
that
if
an
OS
corresponds
is
protected
with
a
different
security
context,
then
the
corresponding
response,
the
corresponding
request,
was
unprotected
with
the
server
must
include
its
sequence.
Numbers
partial
AV
as
a
Christian
in
the
queue
also
and
an
exception
is
appendix
B2,
because
that
is
constructed
in
a
way
where
it
also
avoids
this
problem.
Yeah
Christian.
I
Yeah
I
think
yeah
yeah
I
think
it
makes
sense.
It's
an
easy
way
to
solve
this
problem,
but
yeah.
The
problem
is
really
like.
The
the
you
will
transition
between
the
between
contexts
in
the
middle
of
a
message.
Processing
right,
so
you
unprotect
request
one
with
one
context
and
you
protect
the
response,
one
with
a
different
context,
and
you
may
run
into
this
problem,
but
including
the
partial
release
and
easy
fix
and
now
I
come
to
another
question.
So
we
discussed
this
in
multiple
earlier
meetings
about
the
future
structure
of
this
document.
I
So,
as
I
mentioned,
we
have
kind
of
multiple
ports,
now
incense
three
parts,
the
Kudos
procedure,
the
limits
and
then
those
scores
and
their
ID
recipient
ID
update
section.
So
the
question
we'd
like
to
bring
up
here
is:
should
this
be
split
out
into
a
separate
working
group
document,
meaning
the
content
about
the
limits.
So
we
kind
of
try
to
summarize
the
feeling
from
the
last
coin
dream
where
it
was.
I
People
expressed
a
strong
preference
to
split
this
out
and
the
name
of
it
there
is
that
the
limits
document
relies
also
on
the
document
in
c4d,
and
if
we
split
this
out,
it
can
be
updated
independently,
based
on
what
can
happen
in
the
cfrd
documents
and
such,
and
so
we
got
that
impression
that
for
image,
poetry
was
a
stronger
consensus
to
split
it
out.
I
Then
a
similar
question
comes
for
the
method
for
updating
this
under
recipient
ID,
and
this
send
me
recipient
ID
procedure.
It
can
run
either
Standalone
or
embedded
in
a
cureless
execution.
So
the
question
is:
should
we
also
split
this
out
into
a
separate
working
group
document?
The
consensus
from
the
internet
was
well
more
mild
preference
or
people
having
no
opinion
regarding
this.
I
We
still
need
a
bit
to
work
on
this
section
on
preserving
observations
mainly
so.
Our
proposal
here
is
to
keep
the
part
about
the
center
and
zip
into
the
update
in
the
current
document,
and
when
we
have
that
section
more
finalized,
we
come
back
to
this,
but
on
the
limits
I
would
say
we
have
a.
Our
stance
is
that
you
can
actually
be
split
out
today
as
a
working
group
document,
and
the
benefit
of
doing
this
split
is
basically
like.
I
Yeah,
that's
quickly
the
main
next
steps.
We
want
to
address
token
points
that
we
discussed
about
this
restructuring
and
also
about
the
partiality
inclusion,
more
General
text
on
that
and
yeah.
We've
got
some
good
feedback
from
ralpha
Marine
Lopez
on
soft
versus
hard
limits,
with
kind
of
references
to
ipsec
and
how
they
have
soft
limits
there.
I
We
want
to
expand
the
example
about
those
score,
ID
updates
to
provide
textual
description
of
the
examples
and
yeah
any
comments
or
reviews
are
very
welcome
and
also
feedback
on
this
question
about
the
future
structure
of
the
document
and
if
we
should
split
out
and
let's
say
the
limit
spot
for
now,
yeah.
Thank
you.
That
was
the
full
presentation.
A
A
E
I
Yeah
I
think
that
makes
sense
for
now,
like
the
limits
can
more
and
more
freedom
to
update
your
Customs
coming
up.
Also
yeah.
I
I
think
that's
a
very
good
point,
because
if
someone
comes
to
this
document
only
interested
in
the
limits
or
all
interesting
kudos,
then
they
may
be
misled
to
think
that
this
is
longer
and
more
complex
than
it
is
just
because
it
has
multiple
independent
Parts.
Basically,
so
if
we
could
split
out
the
limits,
it
would
make
the
document
simpler
and
make
the
new
ad
limits
document
also
simpler.
Definitely
so,
thanks
for
the
feedback,
yeah.
J
So
yeah
for
my
talk,
yeah
I
will
talk
about
DNS
of
a
co-op
in
the
first
part
and
then
about
the
DNS
message:
format
using
sibo.
These
are
two
drafts.
One
is
the
working
group
draft
for
the
doc
and
the
other
one
is
currently
a
person
on
draft
yeah.
First,
of
course,
I
spoke
to
speak
about
Dennis
over
Co-op.
J
The
motivation
behind
that,
for
those
who
still
don't
know,
is
that
we
want
to
have
an
iot
device
that
requests
a
name
and
we
want
to
protect
against
potential
eavesdrivers
and
a
typical
countermeasure.
There
is
to
encrypt
the
name
resolution
and
oh
and
yeah
with
DNS
over
Co-op.
We
would
have
such
encryption
and
additionally,
we
would
also
benefit
from
blockwise
message
transfer
and
the
shared
research
systems
system
resources
of
the
co-op
application.
J
So
we
can
use
the
same
sockets
and
buffers
and
reuse
also
The
Cooperative
transmission
mechanism
and
yeah
since
the
last
ITF.
Not
that
much
has
happened
except
for,
of
course,
the
working
group
adaption,
but
we
added
some
security
considerations
on
how
ID
0
will
should
be
used
in
an
encrypted
or
how
the
idea
in
general
should
be
used
when
an
unencrypted
use.
J
Then
we
replace
the
layer
violation
where
we
stated
something
about
con
with
a
statement
of
facts
that
well,
if
you
use
con
you
have
you,
can
you
don't
need
a
re-transmission
mechanism
and
we
removed
the
doc
server
considerations,
which
were
basically
moved
to
its
own
draft,
which
a
little
bit
I
will
discuss
a
little
bit
in
the
next
steps.
Also,
then,
there
is
some
open
discussion
still
on
Doc.
We
got
some
feedback
from
DNS
up
thanks
for
that
by
the
way.
J
So
the
first
question
was
basically
why
there
why
it
isn't
just
Doh
via
Co-op
Gateway,
that
the
draft
should
explain
that
at
least
then
we
use
the
different
TTL
rewriting
proposal
that
is
different
from
the
one
in
Doh.
That
should
also
be
probably
explained
a
little
bit
more
in
depth.
Depth.
J
Was
a
question
if
doc
lives
on
a
URI
path?
Of
course
it
does
and
if
there
is
a
default
path
that
we
can
use
as
a
common
practice
in
Co-op,
so
maybe
something
that
some
more
Co-op
Pros
can
answer,
and
then
that
is
also
something
that
was
brought
up
by
Carson
in
the
GitHub
that
we
need
some
recommendation:
how
to
bootstrap
doc
with
a
service
B
record,
where
we
probably
need
to
allocate
some
almp
n
ID
for
Co-Op
or
the
end
or
dtls.
J
Are
there
any
comments
already
on
that?
Maybe
before
I
proceed?
Okay,
then
I
continue
so
for
the
next
step.
Of
course,
addressing
the
feedback
is
one
big
step.
Then
we
still
need
to
pick
an
ID
for
the
application.
Dns
message
for
Content
format,
I
guess
I
will
just
propose
one
and
yeah
for
the
other
draft,
where
that
was
split
out.
So
basically
of
that,
where
this
you
can
have
a
look
at
that,
but
there
was
already
some
comments
that
it
might
not
be
that
much
of
a
edit
value.
J
So
maybe
we
can
just
leave
it
by
the
wayside,
so
yeah
we'll
have
to
see
about
that.
So,
thank
you.
That
was
basically
the
first
talk.
Are
there
any
questions
or
comments.
G
Just
a
brief
comment
on
the
default
path:
while
we
don't
usually
do
default
paths,
I
would
recommend
that
a
server
that
is
just
a
DNS
server
just
place
the
lookup
lookup
server
resource
at
the
slash
resource.
It's
like
saving
at
least
two
bytes
compared
to
every
other
message,
and
if
it's
this
piece
of
software
using
doing
just
that-
and
it
can
easily
do
that,
there
is
nothing
special
about
the
slash
resource
that's
available
and
why
not
use
that.
J
Yeah
I
I
think
I
agree
on
that.
So
yeah
bench
watch.
L
Hi,
so
I
think
that
that
is
a
perfectly
reasonable
recommendation,
but
the
the
question
here
is:
is
it
possible
to
bootstrap
a
DNS
over
co-app
connection
without
explicitly
conveying
a
path,
because
if
it
is
necessary
to
it's
always
necessary
to
pay
a
path,
then
that
places
additional
requirements
on
the
bootstrap
mechanism
that
that
is
used
so,
for
example,
in
the
context
of
something
like
service
bindings,
you
need
a
service
bindings
parameter
that
conveys
the
path
and
that
parameter
always
has
to
be
present.
You
know
the
client.
K
L
Probe
for
the
presence
of
of
a
DNS
server,
co-ops
nerver
on
a
or
supported
for
DNS
over
co-op
on
a
co-op
server,
because
it
doesn't
know
what
path
to
look
at.
L
B
Yeah
I
think
if
we
can
emulate
the
HTTP
here,
then
that's
fine
I
think
it's
important
to
keep
in
mind
that
in
in
the
constrained
environment,
the
discovery
will
not
necessarily
run
over
DNS
that
will
often
be
in
the
resource
directory
and
there.
Of
course
we
can
indicate
the
path,
because
that's
just
part
of
the
link
that
the
resource
directory
provides
so
one
possible
outcome.
I,
don't
know
whether
that's
necessary,
but
one
possible
outcome
would
be
to
say
for
servers
that
use
resource
directory
discovery.
B
They
can
use
any
path
for
servers
that
use
a
more
limited
form
of
Discovery.
They
are
stuck
with
the
mg
path
yeah.
So.
E
F
See
who's
next
yeah.
It's
me
no
I
I
was
thinking
about.
We
could
also
reserve
one
of
the
well-known
something
resources
for
that
and
I've
seen
this
also
in
other
working
groups
that
sometimes
that's
useful.
If
you
have
a
known
resource
path
because
then
in
that
case
you
can
skip
Discovery
processes
and
in
constrained
networks.
It's
often
yeah
takes
time
takes
network
resources
to
do
this
whole
round
trip
of
this
cover
and
then
get
a
response
back.
F
So
if
you
can
typical
situations
skip
all
of
that
and
just
make
your
message
a
little
bit
longer:
it's
not
not
that
many
bites.
So
it's
also
useful
to
have
one
of
these
well-known
piles,
because
I'm
not
sure
if
we
can
assume
that
the
server
will,
if
you
get
an
IP
address
and
port,
for
example,
through
some
some
way,
and
if
you
don't
get
a
resource
I,
don't
think
you
can
always
assume
that
it's
always
at
the
slash
root
resource
or
yeah.
Maybe
we
can
actually
there's
a
similar
case.
F
We
are
working
on
right
now
in
the
animal
working
group,
where
we
also
want
to
play
something
at
the
slash
resource
and
there
the
ideas,
what
you
discover
is
basically
in
IP
address
and
a
port
and-
and
you
also
know
the
purpose
of
that,
so
it's
kind
of
a
relay
Co-op
relay
function.
And
then
you
also
know
by
that
said:
oh,
the
default
resource
is
slash
so
that
yeah.
J
Like
the
content
format,
where
we
can
basically
say
tell
the
server,
hey
I
actually
want
this
DNS
resource,
but
maybe
that's
not
a
good
idea
in
our
evaluations
we
use
DNS,
but
then
again
we
use
four
bytes
in
the
header,
so
yeah
I,
guess
that
we
we
need
to
put
some
thought
into
that
more.
This
is
the
conclusion.
F
Yeah
but
at
least
consider
like
one
of
those
well-known
Parts,
because
a
server
can
easily
support
multiple
assets
could
support
the
well-known
one
plus
discovered
one
which.
L
F
Be
the
slash
resource,
so
so
it's
fine
to
have
multiple,
and
if
you
have
something
to
fall
back
to
then,
if
you
already
have
an
IP
address
and
ports
where
to
go
to
or
maybe
it's
a
default
port,
then
you
can
just
go
and
do
the
DNS
request
without
needing
to
discover
anything.
First,
that's
the
idea.
J
Okay,
then,
let's
continue
with
the
second
talk,
which
is
about
concise,
binary
object,
representation
of
DNS
messages
or
sibo
in
of
this
DNS
messages.
J
So
the
the
motivation
is
basically
that
we
have
a
huge
drawback
of
DNS
and
constraint,
messages
that
if
we
look
at
the
diagrams
here
we're
on
the
x-axis,
we
see
for
each
name
length
a
pair
of
queries
and
quad
a
responses
and
on
the
y-axis,
the
size
of
the
packet
with
the
fragmentation
borders
marked
at
as
a
dashed
line.
We
see
that
we
quickly,
even
for
very
short
names,
can
exceed
the
fragmentation
limit.
So
we
need
some
way
to
compress
our
DNS
messages
and
yeah.
J
That's
basically,
the
proposal
we
wrote
application
DNS
placebo.
J
J
And
then
we
also
provide
address
and
name
compression
using
packed
Sable
as
a
seabor
as
an
optional
measure
for
the
DNS
responses
for
DNS
queries,
you
can
see
the
definition
of
them
in
in
cddl
on
the
left
side.
For
those
who
don't
know
that
much
cddl
there's
also
an
explanation
on
the
right
side.
So,
basically,
a
DNS
query
is
a
sibo
array
which
at
minimum
contains
the
text
string
of
the
domain
name
and
it
also
optionally
provides
an
ID
and
a
record
tab
specification.
The
ID
defaults
to
zero.
J
If
they
are
not
present,
the
DNS
resource
record,
which
is
then
part
of
the
response,
is
defined
to
also
be
a
sibo
array
which
at
minimum
contains
a
TT,
a
TTL
and
a
resource
data,
and
it
optionally
can
also
contain
the
name
and
the
record
type
and
if
both
are
not
present,
then
they
basically
defer
to
the
question
value
and
the
DNS
response
is
an
array
of
arrays
which
at
minimum
contains
the
answer
section,
which
again
is
an
array
of
DNS
resource
records.
J
But
this
basically
generally
assumes
that
the
transport
can
map
the
query
to
the
response,
which,
for
example,
for
DOA,
C
or
Doh
is
the
case,
but
we
can
also
provide
the
original
question
and
the
ID,
if
that
is
not
the
case,
yeah
yeah,
for
a
simple
example.
If
we
want
to
query
the
IPv6
address
of
example.org,
we
have
this
basically
in
sibo
diagnostic
format
represented
here.
J
This
is
then
certain
bytes
compared
to
the
52
bytes
of
wire
format,
which
is
a
compression
rate
of
400
percent
and
the
correspondent
corresponding
response.
You
can
also
see
on
the
slide,
which
is
only
24
bytes,
compared
to
the
68
bytes
of
the
wire
format,
compression
of
the
wire
format,
which
provides
us
with
a
compression
rate
of
284
percent
or
three
percent
yeah
for
a
more
complex
example.
J
If
we,
for
example,
want
to
request
the
annual
record
of
a
example.org
domain
like
we
would
do
for
dnssd,
then
we
get
a
good
compression
for
the
wire
format
still,
but
for
the
response
not
so
much,
we
have
then
200
bytes
of
the
sibo
format
compared
to
the
195
price
of
the
wire
format.
J
So
we
need
some
address
and
name
compression
which,
with
a
little
bit
of
past
and
help
we
provided
so
yeah
for
our
proposal.
We
provide
an
optional
cboard
support
for
the
response,
which
is
negotiated
by
a
content,
type,
no
media
type
negotiation
via
this
packed
parameter
for
the
media
type.
In
as
a
note,
in
version
one
of
the
drafts.
J
This
is
still
its
own
media
type,
but
in
the
next
version
it
will
be
a
parameter
yeah
and
then
we
make
a
shared
value
and
argument
table
one
list
instead
of
compared
to
the
sibo
pack
draft
and
then
basically,
we,
the
response
becomes
another
area
of
two
arrays
which
the
first
parameter
is
the
packing
table,
which
is
basically
a
complete,
combined,
shared
value
and
argument
table,
and
the
second
element
is
a
compressed
DNS
response.
J
The
problem
is
there
that
we
basically
have
this
this
chick.
We
have
this
assumed
Network
structure
and
somehow
the
rules
for
compression
are
exchanged
between
the
device
and
the
shake
compressor
decompressor,
and
so
that
the
rule
ID
can
be
used
for
the
identification
of
how
this
was
compressed,
and
that
basically
means
there
must
be
an
established
connection
between
the
device
and
the
compressor
and
decompressor
which
usually
we
don't
have
when
we
just
select
the
DNS
server
with
a
DNS
client.
J
We
can
basically
just
select
any
DNS
server
there,
so
we
don't
have
any
agreed
upon
rules
between
the
server
and
the
client,
except
maybe
for
a
few
Global
compression
contracts
that
we
have
in
DNS,
for
example
the
tlds.
So
that
is
why
we
decided
for
the
pack
format
and
to
give
you
an
example.
J
How
this
then
would
compress
down
is
that
we
have
this
table
on
the
in
the
first
array
here,
which
is
then
referenced
in
the
response
itself,
and
even
though,
in
diagnostic
format,
it
looks
much
bigger
than
the
original.
If
you
compile
that
to
actual
cboard,
it's
actually
only
119
bytes,
so
we
have
a
compression
rate
of
164,
bytes
percent.
Sorry,
yeah
there's
also
maybe
a
way
to
how
we
can
even
more
optimize
it.
J
Then
if
we
use
these
Global
compression
contexts,
I
mentioned
before,
like
the
tlds
to
even
Elite
more
stuff,
but
maybe
that's
not
that
much
worse
of
an
effort
yeah,
but
for
the
next
steps
here
we
need
to
Define
some
more
details
using
packed
sibo's.
For
example,
we
didn't
Define
yet
how
the
packing
table
is
constructured,
constructed
and
yeah
again.
The
global
compression
context
might
also
be
a
venue
that
needs
to
be
discussed
and
thought
upon.
L
So
there
have
been
a
few
attempts
to
re-express
DNS
over
the
past
few
years
and
in
general,
I
would
say:
dnsop
has
not
been
very
friendly
to
these
kinds
of
proposals,
so
I
would
I
would
say
you
should
start
by
by
going
to
DNS
knob
and
seeing
what
the
DNS
Community
makes
of
it.
L
If
it
doesn't
meet
that
bar,
then
it
is
ossifying.
It's
creating
devices
that
appear
to
do
DNS,
but
actually
only
support
a
subset.
You
know
creating
problems
for
the
evolution
of
DNS
in
the
future,
so
that
that
has
been
a
a
concern.
It's
definitely
something
to
think
about.
In
general,
I
I
have
trouble
seeing
the
value
here,
because
DNS
messages
are
almost
always
a
tiny
fraction
of
the
total
bandwidth
they're
a
bootstrap
mechanism
for
something
else,
so
saving
even
50
percent
off
of
the
size
of
your
DNS
messages
doesn't
save
you
very
much.
J
I
I
tend
to
disagree
with
that
that
it's
not
that
little
of
traffic
but
yeah
we
we
actually.
Of
course
we
want
to
go
with
DNS
up
into
that
so
yeah,
but
first
I
guess
we
need
to
have
the
general
format
done
before
we
go
further
into
that.
Let's
go
yeah.
F
Yeah
I
was
just
considering
that
the
the
normal
DNS
format
has
basically
the
packing
already
integrated
there,
so
you
can
use
it
or
cannot
use
it,
but
it's
all
the
same
format
and
I
think
that's
General
easier
to
to
handle
that.
So
you
don't
need
to
consider
oh
wait.
F
There's
two
formats
or
I
need
to
negotiate,
so
somehow
I
think
it
would
be
easy
if
you
just
one
format
where
you
can,
with
a
clients
or
basically
sender,
of
the
message,
can
actually
compress
on
things
or
decide
to
not
compress
things
and
the
receiver
side
will
always
be
able
to
construct
yeah
back
to
the
uncompressed
message
so
that.
J
J
Year
behind
that
is
that
the
client
might
not
support
Co-op.
So
that's
the
way.
The
negotiation
part
is
basically
a
way
for
the
client
to
say:
hey
I,
support
that
and
if
you're
yeah,
the
response
is
quite
large,
then
please
send
it
back
to
me.
Okay,.
F
Yeah,
you
just
want
to
be
sure
that
that
you
can
have
clients
that
that
cannot
do
the
decompression,
okay,
yeah
and
then
one
other.
Just
random
remark
is
I:
have
a
system
on
my
laptop
running
simulated,
Wireless
nodes
that
can
talk,
DNS,
SD,
so
register
services
and
query
things
like
that.
So
just
just
to
be
aware
of
okay.
B
Just
just
a
quick
answer
to
Ben:
if
you
look
at
the
the
percentage
of
the
DNS
traffic
to
other
traffic,
then
of
course
the
the
total
gain
of
a
concise
representation
is
pretty
limited,
but
I
think
as
Martine
had
in
in
her
first
slides.
The
the
environments
that
have
limited
pdu
sizes
actually
have
a
cost
for
for
using
larger
packets.
That
is
going
Beyond
just
a
few
bytes.
B
So
the
the
problem
really
is
that
you
you're
using
DNS
when,
when
you
when
you're
resetting,
when,
when
you
are
recovering
from
from
a
network,
failure
or
something
like
that,
and
that's
exactly
when
when
everybody
else
does
it
and
your
network
will
be
impaired
a
little
bit
and
if
then,
you
actually
have
to
do
application
data
fragmentation.
So
this
is
not
IP
fragmentation,
but
but
the
adaptation
layer.
J
B
J
And
I
mean
what
you
can
see
also
in
on
the
slide
is
that
larger
packages
also
create
more
overhead,
because
they
also
include
the
link
and
six
Loop
and
headers,
and
and
so
we
try
to
want
to
try
to
avoid
this,
there's
yep
and
again,
okay,.
E
L
So
if
you're
trying
to
stay
under
this
limit,
deterministically,
then
I
don't
think
a
a
concise
representation
is
sufficient
right.
So
like
the
the
path
that
seems
more
appealing
to
me
is
to
say
we're
not
providing
a
general
purpose:
representation
of
DNS,
that's
more
compact,
which
is
very
difficult,
because
the
base
representation,
which
is
already
very
compact,
what
we're
doing
is,
is
defining
a
very
simple
service.
L
Like
a
name
to
IP
service,
you
only
get
one
IP
Mac,
you
know
very
simplified
that
could
then
sort
of
this
use
case
without
claiming
to
be
a
general
purpose,
replacement
for
DNS.
J
No
because
we
of
course
also
want
to
support
stuff
like
DNS
service
Discovery,
where
we
don't
just
want
to
resolve
names
to
addresses,
but
also
maybe
other
records,
so
I,
don't
think
a
name
to
address
service
would
just
suffice
for
that.
L
I,
don't
worry
over
time,
even
in
that
case,
I
would
suggest
seeing
if
you
could
specify
an
API
specifically
for
service
Discovery
and
think
of
it
as
a
service
Discovery
system,
not
a
DNS.
H
I
really
don't
understand
your
argument.
Why
are
you
arguing
against
the
compression
of
the
DNS
messages?
I
mean
that
the
DNS
is
a
rather
tiny
part
also
over
a
traffic?
Okay,
fine,
but
it's
not
an
argument
to
not
standardize.
I
mean
work
on
the
compassion
of
the
messages.
L
L
Should
only
take
the
create
all
of
this
documentation
and
complexity,
if
there's
a
significant
payoff
that
actually
benefits
users
in
a
meaningful
way,
but
but
specifically,
in
this
case,
I
think
that,
as
I
mentioned,
there
are
also
some
systemic
concerns
about
alternative
representations
of
DNS.
So,
for
example,
there's
been
a
lot
of
effort
to
to
try
to
Define
Json
representations
of
DNS.
That's
and
there
are
apis
out
there.
L
K
L
Including
things
like
edns
options
that
have
yet
to
be
defined
so
that
that
raises
the
bar
considerably
I
do
think
that
it's
possible
to
to
define
a
representation
of
DNS
messages.
That
is
a
little
bit
smaller
on
average
than
than
the
current
messages,
and
certainly
you
can
save
a
lot
of
space
if
you're
willing
to
discard
some
of
the
information,
but
discarding
DNS
information
is
a
very
sticky
area.
K
B
Just
want
to
say,
we
already
have
a
resource
Discovery
service,
so
we
don't
need
a
new
one.
This
really
is
about
enabling
DNS
usage,
as
as
it
is
being
used
in
other
environments
in
in
the
constrained
environments
as
well.
Yeah.
K
F
John
yeah
I,
just
another
comment
on
on
this
show
what
I
work
with
is
actually
a
constrained
Network
implementation.
So
it's
a
threat,
wireless
mesh
network
based
on
six
low
band,
but
it's
not
the
most
constrained,
so
it
still
has
the
2.4
gigahertz
operation.
So
it
can
have
a
relatively
large
usage
of
the
Bands,
so
no
duty
cycle
limits
so
so
I
know
there
are
even
far
more
constraints,
types
of
networks,
I
think
than
than
threats,
not
for
threats.
F
What
we
use
is
just
the
normal
DNS
so
for
doing
server,
lookups,
but
also
DNS
SD,
so
Service
registration
querying
for
services.
So
that's
all
done
with
yeah.
Let's
say
on
my
meta
devices
with
with
the
regular
DNS
format.
So
in
that
sense
I
understand
the
argument
a
bit
yeah.
Why
would
that
yeah?
Why
do
things
differently?
Are
we,
of
course,
we
already
have
the
DNS
formats
and
it
offers
some
form
of
compression,
maybe
not
the
best,
but
yeah
it's
it's
in
terms
of
traffic.
F
It's
not
you
know
not
the
main
source
of
traffic.
You
can
say
for
the
obligations,
so
I
can
understand
that
argument.
So
maybe
it's
good
to
think
about
well,
maybe
they're
more
construct,
even
more
constraint,
implementations
here,
where
you
have
to
be
like
in
the
single
radio
frame
for
for
common
queries
like
looking
up
a
name
to
an
RP
address
yeah,
which
is
the
most
common
example
I'm,
not
sure
if
those
type
of
systems
would
actually
go
into
service
discovery.
F
Things
like
that
I,
don't
know,
but
yeah.
It's
good
good
to
think
about
something
that
might
be
very
compact
for
for
the
the
bulk
of
the
queries,
which
is
like
okay,
give
me
the
IP
address
of
this
server,
and
maybe
they
are
slightly
more
bulkier
for
for
complex
things
here
like
if
you
have
a
DNS
SD,
maybe
that
that
just
uses
the
existing
encoding
I
can
also
imagine
that
so
yeah.
In
that
case,
there
is
no
there's,
no
problem
that
that
you
hit
a
limit,
that
your
new
format
cannot
do
everything
that's
at
Classic.
F
J
J
A
So
there's
going
to
be
an
interview
on
November
23
already
scheduled,
and
it's
going
to
cover
most
vhrefs
and
Target
attributes.
We
can
also
continue
this
discussion
on
dnsc
board.
K
Thank
you
just
one
thing:
I
want
to
do
a
Terrace
and
the
working
group.
It's
Francesca
I
have
been
going
through
the
list
of
erratas
and
there
are
currently
10
reports
of
the
router
and
I
will
post
the
remaining
list
I'm
looking
for
agreement
that
this
is
the
right
way
to
mark
them,
so
I
will
send
an
email
shortly.