►
From YouTube: IETF113-CORE-20220325-0900
Description
CORE meeting session at IETF113
2022/03/25 0900
https://datatracker.ietf.org/meeting/113/proceedings/
A
And
now
we
are
on
top
of
the
hour,
so
I
think
we
can
start
welcome
everyone
to
this
co-working
group
meeting
at
ietf,
113
hybrid
after
two
years,
or
so
it's
nice
to
be
here
and
I've
seen
you
again
on
site.
I
am
marco
tyroca.
My
co-chairs
are
jaime
jimenez
and
president
boardman
you
can
find
in
this
cover
slide.
Also
a
new
resource
for
the
working
group,
the
zulip
stream.
A
So,
of
course,
as
usual,
you
assume
people
to
have
read
the
documents
to
be
discussed
today
in
the
agenda.
Please
do
your
best
to
use
the
allocated
time
in
the
best
possible
way
to
discuss
issues
that
benefit
from
face-to-face
discussion.
The
not
well
applies
and
slide
comes
later.
The
blue
sheets
is
collected
automatically
through
meteco.
A
A
A
Right
we
are
on
friday,
so
probably
you
have
seen
this
many
times
and
you
are
masters
of
this
already,
but
the
meeting
is
recording
and
it
works
in
a
particular
way
for
in-person
attendees.
You
have
to
be
signing
me
taeko
to
be
able
to
build
a
single
queue
for
the
church,
to
manage
and
to
be
counted
in
the
blue
sheets
and
so
on.
You
can
do
that
using
the
light
version
from
the
agenda
and
the
data
tracker.
A
A
All
right,
this
is
the
agenda
for
today
it's
pretty
packed,
so
please
try
to
stay
on
time
and
shares
will
be
sure
that
happens.
A
We
start
with
a
bunch
of
working
group
documents
in
the
first
half
of
the
meeting,
meaning
href
conditional
attributes,
group
communication
for
co-op
or
group
combis,
and
then
the
group
of
score
document
and
the
key
update
for
oscor
on
kudos
document,
and
then
we
continue
with
three
non-working
group
documents:
transport
indication
on
traditional
responses
and
dns
over
co-op.
A
In
the
recent
weeks
we
have
two
documents
published
as
rfc
9175,
that
used
to
be
a
echo
request
tag.
Thank
you
very
much.
As
usual
to
the
authors
and
the
working
group
for
this
and
a
few
days
ago,
only
also
9177
was
published
and
used
to
be
a
new
block.
Thank
you
very
much
for
this
too
awesome.
Yes,.
A
A
And
we
have
two
documents
in
isg
processing,
young
cyborg
and
sid,
so
young
zebra
is
really
almost
there.
There
is
one
more
comment
to
be
addressed
and
all
should
be
concluded
next
week
and
for
c
there
has
been
a
lot
of
discussion
also
in
a
side
meeting
yesterday
between
authors
and
the
id
on
a
final
discuss
ballot
to
be
addressed,
and
this
requires
some
more
text
to
be
added,
but
that
should
happen
also
very
soon.
A
All
right
and
then
a
bunch
of
documents,
post
working
group
plus
call
meaning
the
other
two
documents
of
the
quarkon
clusters
that
just
waiting
for
the
first
two
ones
I've
just
mentioned
before
they
can
actually
go
under
shepherd
write
up,
and
then
we
have
the
group
of
score
document
that
has
passed.
The
second
working
group
call
and
should
be
ready
to
move
on,
but
we
have
a
presentation
about
it
later
today.
A
A
A
B
Ugly,
okay
yeah
just
tell
me
when
I'm
no
longer
intelligible,
so
the
idea
is
that
your
eyes
and
your
references,
which
we
love
so
much
actually
have
an
underlying
data
model
that
just
has
to
be
discovered
and
we
can
provide
a
concise
representation
format
for
that.
So
that's
the
point
of
this
draft.
B
This
has
been
originally
started
by
klaus,
harker
and
right
now
we
are
just
trying
to
finish
that,
and
there
have
been
a
few
updates
since
the
last
itf
dasher
8
was
the
iit
f112
version
where
we
had
added
percent
encoded
text
and
there
have
been
a
few
tricks
to
that
in
dash
online.
B
We
also
did
an
editorial
step
by
by
moving
all
the
yeah
weird
stuff
into
an
appendix
the
small
print
appendix
that
you
probably
only
have
to
read
if
you're
actually
implementing
this
and
in
dash
10.
We
finally
added
the
last
ui
component
that
we
so
far
hadn't
supported
the
user
info
structure.
This
is
the
thing
that
comes
in
an.
B
So
that
that
feature
is
not
part
of
dash
10,
but
the
user
info
itself
is
occasionally
being
used.
So
this
is
now
also
possible
to
represent
and
a
few
more
editorial
inferior
changes,
and
we
also
have
a
separate
cdda
rule
for
both
cri
and
ci
reference.
C
B
Reference
production:
what
I'm
doing
right
now
is
implementation
work.
So
there
are
four
implementations
that
I'm
aware
of
in
four
different
languages
and
well,
if
you
implement
something,
you
uncover
little
issues.
So
this
is
exactly
what's
happening
right
now
and
in
the
process.
We
are
also
expanding
our
collection
of
test
vectors,
so
there
will
be
a
connection
that
all
these
implementations
support
and
that
new
implementers
can
use
that
as
a
reference
to
test
their
implementations,
but
really
the
implementation.
B
What
ci
originally
was
developed
for,
but
also
in
the
context
of
various
data
formats,
that
use
queries,
and
we
need
to
make
sure
that
these
work
well
with
the
eyes,
which
is
not
too
easy,
because
curries
are
really
just
a
synthetic
on
your
eyes.
So
they
do
not
map
to
the
data
model.
B
B
B
My
personal
estimate
would
be
that
we
probably
need
about
six
more
weeks
to
do
this
implementation
work
and
then
maybe
one
more
interim
before
we
actually
can
get
all
these
little
issues
laid
down
as
well.
So
look
into
the
issues.
C
B
On
github
to
see
what
these
nuclear
issues
are
yeah,
we
are
no
longer
having
really
big
questions,
but
the
the
small
ones
need
to
be
answered
as
well.
So
that's.
A
C
C
C
Good,
so
everything
is
good
to
go
all
right
so
again,
good
morning,
everybody,
it's
a
very
small
presentation
that
I
have
so
this
is
about
the
conditional
attributes
draft
for
core
and-
and
this
is
just
delta-
from
what
had
happened
from
the
last
interim
meeting,
so
the
last
interior
meeting.
We
actually
resolved
a
lot
of
issues
at
the
moment
there
are
no
more
github
issues
and
there
was
some
resolution
made
on
the
value
of
the
band
attribute.
C
We
included
some
text
about
the
proxy
considerations
inside
the
implementation
considerations.
Part
there
is
security
considerations
done,
but
then,
during
the
last
interim
we
actually
had
a
small
chat
about
what
more
could
be
done
in
this
draft
before
it
goes
for
working
through
glasgow.
So
this
is
what
I'm
here
for.
C
C
The
introduction
of
the
the
draft
so
that
I
try
to
clarify
what
conditional
attributes
are,
so
the
old
specification
define
contribute
conditional
attributes
as
just
providing
fine-grained
control
of
notification
and
synchronization
with
core
observe,
and
there
was
some
artifact
about
resource
interfaces,
blah
blah
blah,
and
then
there
was
saying
that
a
resource
marked
as
observable
in
its
link
description
should
support
this
control
attribute.
C
So
I
I
recrafted
that
text
and
initially
I
essentially,
I
basically
put
that
this
is
this
is
for
use
with
call
observe,
but
also
it's
how?
How
do
you
actually
convey
the
the
conditional
attributes
so
so
using
the
query
component
of
a
quad
uri
and
it
can
be
either
a
name
value,
query,
parameter
or
then
just
a
name
without
a
value
and
and
we
we
are
able
to
essentially
describe
the
resource
using
multiple
conditional
attributes.
C
Please
let
me
know
if
that
is
not
okay,
I
hope
it's
okay
and-
and
this
is
already
in
the
in
the
current
working
group-
no
sorry
the
current
editor's
draft.
It
hasn't
gone
into
the
into
the
newest
version,
and
once
everything
is
done
once
you
have
good
this,
then
I
will
resubmit
the
new
version.
Hopefully
that
will
be
the
last
one
before
working
group
last
call.
So
this
is
this
is
basically
the
the
let's
say,
the
editorial.
The
last
editorial
which
I'd
like
to
do.
C
One
more
thing
that
came
up
in
the
interim
meeting
was
the
the
fact
of
whether
we
need
a
registry
and
what
kind
of
registry
does
does
this
draft
require?
So
in
the
inner
construction
section,
I
had
originally
included
in
the
last
version
of
the
draft
conditional
attributes
registry
to
uniquely
map
these
names
to
what
they
really
are.
But
then
the
discussions
came
about
whether
this
is
necessary
and
what
kind
of
registry
we
should
have.
There
was
some
discussion
on
about
whether
there's
a
you
know
what
the
pros
and
cons.
C
So
obviously
it
would
be
nice
to
have
registry
to
to
remove
the
integrity
of
how
this
can
be
defined
and
that
the
direct,
let's
say
implication
of
this
is
that
some
of
these
names
are
used
in
in
different
contexts
in
in
different
places.
So,
for
example,
lte
is
used
in
the
conditional
attributes
draft
to
mean
less
than
but
then
lt
is
used
in
the
query
parameters.
C
I
think
in
in
the
resource
directory
to
mean
lifetime
so
and
resource
directory
actually
already
defines
the
sub
registry
for
rd
parameters
to
to
describe
lt's
lifetime.
So
that's
that's
one
thing
that
I
I'd
like
to
resolve
today.
C
Obviously
I
don't
really
mind
going
forward
that
the
draft
never
actually
had
a
registry
before,
but
it
would
be
great
to
to
to
get
some
resolution
on
this,
and
also
the
discussion
was
whether
it
makes
sense
to
have
a
more
general
attributes
registry,
but
the
one
let's
say
the
one
caveat
to
this
is
I'd
like
to
just
call
it
rfc,
80,
20,
88
20,
so
to
describe
why
we
should
not
be
doing
that
because
it
it.
C
We
don't
want
to
use
up
the
the
use
of
these
attributes
in
in
other
kinds
of
client
other
clients
that
may
not
necessarily
be
using
this
so
and
then
specifying
more
elaborate
structures
to
avoid
these
collisions
is
not
really
an
acceptable
solution,
so
you
know
it's
it's.
C
If
we
can
go,
if
we
go
generic,
then
I
I
I
feel
that
perhaps
it
will
really
complicate
matters,
but
on
the
other
hand,
I
I
know
that
there
are
experts
in
our
group
who
probably
will
know
how
to
deal
with
this
better
than
I
do
so.
This
is
why
I'd
like
to
put
this
to
the
floor
today,
have
a
discussion
about
that
and
then
take
this
forward
and
hopefully
resolve
it
so
quickly
that
we
can
go
to
the
last
call.
C
E
Yep-
I
just
thought
about
this,
especially
this
example
of
lt
yeah.
I
think
if
it's
used
in
a
particular
context
like
resource
directory,
it
should
be
no
problem
that
it's
reused
for
something
else
right
in
another
context,
so
you
cannot
rule
that
out.
It
will
happen
in
this
way.
E
So
that
seemed
seems
to
be
fine,
although
it's
of
course
better
to
look
at
what
others
use
and
then
try
to
yeah
try
to
use
more
inconvenience
where
possible.
F
C
C
In
my
opinion,
I
I,
my
personal
preference,
will
be
to
to
introduce
a
new
sub
registry
for
conditional
attributes
specifically
for
this
purpose,
without
impinging
on
the
use
of
the
same
attribute.
Space
in
in
our
career
parameter
names
in
other
applications.
C
G
Yeah
because
then
I'm
just
I'd
like
just
like
kind
of
I
don't
have
a
particular
opinion
on
whether
a
registry
structure
makes
sense,
but
I
would
like
to
point
out
that,
just
because
the
one
thing
is
used
for
observations
and
one
is
the
resource
directory
doesn't
mean
that
they
might
not
overlap
because,
especially
as
it
is
phrased
now,
with
everything
that
is
observable
should
support
the
attributes.
G
A
lot
of
things
in
the
resource
directory
are
observable,
not
partic,
not
particularly
used
with
the
less
than
and
lifetime,
but
in
general
you
can
find
things
in
the
resource
directory
and
then
look
it
up.
So
these
things
might
easily
need
to
be
combined.
C
G
I've
I
have
I
I
don't.
I
don't
know
whether
whether
it
comes
up,
if,
if
you
go
for
regis
for
actually
registered
things,
then
probably
doing
this
across
applications
makes
sense.
But
that
might
also
be
a
point.
Why
not
doing
a
registry
in
the
first
place
would
be
a
thing
to
consider.
But
then
these
things
would
be
combined
like
by
the
particular
buyer
server,
and
then
the
server
could
just
not
combine
this
and
that
ext
component,
just
because
they
have
overlap
conflicting
requirements.
G
So
maybe
that
a
registry
would
also
not
be
something
that
is
completely
normative
in
the
sense
that
as
soon
as
one
of
these
elements
shows
up,
these
semantics
are
implied,
but
more
something
for
coordination
between
components
where
they,
where
each
component
would
still
where
the
the
particular
arguments
would
still
that
the
semantics
would
be
opted
in
by
the
extension,
for
example,
resource
directory
of
or
conditional
attributes,
but
just
seeing
which
names
are
in
used
allows.
G
Our
news
allows
the
authors
of
these
extensions
to
make
a
more
informed
decision
on
which
names
may
not
make
sense
to
use
here,
because
they
might
get
into
conflict
with
something
else.
So
it's
it's
not
a
red,
it's
another
registry
that
has
where,
as
soon
as
you
see
the
name,
it
has
a
meaning
but
more.
E
Yeah,
I
just
want
to
react
on
that
so
yeah.
I
think
the
example
that
christian
mentioned
shows
that
there
is
a
kind
of
real
risk
of
clashing
of
these
attributes,
especially
yeah.
If
the
draft
now
says
that
any
observable
resource
should
support
these
attributes,
maybe
the
resource
is
already
supporting
other
attributes
and
there
could
well
be
a
clash,
of
course,
in
the
names
of
those.
E
So
that's
something
to
to
consider.
I
think
if
it's,
if
it's
a
resource
like
something
like
a
temperature
value
that
doesn't
support
any
other
attributes,
then
it's
fine
to
apply
those
conditional
attributes.
But
if
it's
something
like
indeed
a
resource
directory
resource,
that's
already
using
attributes
with
same
names,
maybe
for
something
yeah,
something
else.
Then
yeah.
You
immediately
have
a
problem.
E
If
you
want
to
combine
those
things
and-
and
I
don't
think
you
can
actually
apply
all
the
conditional
attributes
in
that
case,
so
maybe
yeah
require
some
thought
if
there's
a
way
to
resolve
that-
or
maybe
it's
possible
to
yeah,
while
discovering
resources
to
to
see
if
a
resource
supports
the
conditional
attributes
or
not.
That
would
also
be
great,
but
I'm
not
sure
if
that's
already
defined.
E
C
Rises,
usually,
I
think
for
for
for
observe
it's
usually
best
effort.
You,
you
don't
necessarily
need
to
know
that
I
mean
it's
just
like
just
like,
for
example,
if
you,
if
you
try
to
set
pmin
or
pmax
it's
it's
kind
of
like
a
request
to
the
server,
so
the
server
can
choose
to
ignore
that
we
don't
necessarily
need
to
enforce
it.
Yeah.
E
F
E
In
the
fallback
situation,
yeah.
F
C
E
E
To
do
that,
so
I
think
core
discovery
has
some
various
ways
to
mark
like
an
interface
you
can
mark
for
the
resource,
so
it
supports
this
particular
interface,
for
example.
That
could
be
a
way.
H
B
Carson,
so
of
course,
there
is
also
the
problem
of
forward
capability
compatibility
here.
So
if
an
application
already
uses
foo
and
then
we
register,
for
we
have
a
problem,
so
one
way
to
reduce
that
likelihood
would
be
to
define
a
namespace
for
conditional
attributes.
So
anything
that
starts
ca,
dot
or
ca
is
something
that
that
sensor
application
wouldn't
use
because
it
might
be
used
for
a
conditional
attribute.
C
Yeah
yeah,
so
actually
that's
the
reason
why
I
put
that
that
sub
bullet
point
that
this
namespace
issue
was
not
was
discouraged
quite
strongly
in
the
rfc
as
well,
so
that
did
occur
to
my
to
my
mind
as
well.
That
would
would
that
be
a
possibility,
but
but
then
I
don't
know
if
we
really
want
to
go
down
that
path.
Yet.
C
G
G
The
practice
of
ignoring
query
parameters
has,
in
my
understanding,
come
from
php
just
php
applications
just
usually
not
doing
this
and
a
few
other
implementations
of
web
servers,
but
that
doesn't
mean
that
a
client
can
just
make
up
the
same.
The
uri
and
add
a
query
parameter
and
then
just
hope
that
it
means
the
same
unless
the
server
says
otherwise.
C
Okay,
so
so
thank
you.
We
will
take
that
on
board
and
then
prepare
the
next
version
and
we'll
take
this
the
mailing
list,
perhaps
the
next
interim
as
well.
C
A
C
The
the
queues
open,
I
think
I'll
put
in
the
next
one.
So
this
is
now
I
think
zero
three
will
be
will
be
perhaps
latest
at
the
before
the
next
interview
meeting.
Hopefully
I
can,
I
can
come
then
present
the
next
one.
E
So
hi
marco
good
to
see
you
and
and
everyone
else
in
the
audience
yeah,
I
hope
to
be
yeah
at
the
future.
My
itf
meeting
at
least
one
more
one,
more
time
or
multiple
times,
but
we'll
see.
So
this
is
their
presentation
about
communication
for
co-op.
The
group
called
this
draft.
E
So
I
assume
that
everyone
is
roughly
familiar
with
the
topic
of
the
draft,
so
it's
basically
a
normative
draft
that
specified
how
to
do
group
communication
in
co-op
and
adding
basically
adding
more
content
to
what
was
described
in
the
original
code.
Rfc
also,
particularly,
security,
is
also
added
using
group
oscar.
E
There
were
also
two
open
github
issues
for
that,
so
the
examples
we
added
are
for
basically
how
to
encode
an
application
group
name
within
the
co-op
request
to
make
that
more
clear
and
also
for
the
discovery.
There
were
some
clarities
about
that,
so
how
to
discover
co-op
groups
and
application
groups
directly
on
the
co-op
service.
So
if
you
don't
have
a
resource
directory
available,
but
you
just
want
to
do
it
using
co-op
discovery,
how
would
you
go
about
that?
So
that's
kind
of
illustrated
with
examples.
E
Basically,
a
lot
of
this
is
application
specific,
but
it's
good
to
have
examples
for
that,
but
you
know
yeah
approximately
what
what
what
you
can
expect
there
also
new
appendix
was
added.
So
these
are
message:
exchanges
for
group
communication,
just
showing
typical
yeah
group
communication
flows
like
a
basic
one,
one
with
observe
and
one
with
block
wise
transfer.
E
Second
bullet
is
here
a
particular
change.
We
made
was
of
removing
the
uri
host
option
to
encode
a
group
name,
so
we
initially
added
it
because
of
a
comment
in
an
earlier
itef
meeting
but
yeah.
This
gave
some
confusion
and
yeah.
If
you
want
to
resolve
that
it
becomes
very
complex,
so
we
decided
to
just
remove
it.
It
was
a
kind
of
yeah
creative
use
of
an
existing
option
to
do
something
else,
so
that
we
thought
well,
let's
not
encourage
that
particular
usage.
So
it's
better
to
just
remove
it
here.
E
So
next
is
to
show
some
examples
from
the
new
version,
six
draft,
so
what
we
have
now
so
this
is
example
for
section
two
to
one.
So
that's
about
name
encoding
of
application
groups-
and
here
you
see
a
yellow
mark,
this
application
group
name
and
how
it
is
encoded
in
yeah
co-op
request
in
the
uri
and
in
the
actual
co-op
message,
options
and
yeah.
The
second
box
is
a
second
example
of
the
same
thing:
a
little
bit
more
compact
carbon
pressed
in
this
case.
E
E
And
the
idea
here
is
in
this
example
that
you
have
as
input
co-op
group.
That's
a
known
entity
also
marked
in
red
and
a
client
now
wants
to
discover
what
are
the
associated
application
groups
to
this
and
what
servers
are
in
it
yeah,
basically,
and
also
discover
the
resources
that
belong
to
that
group.
E
E
All
right
then,
moving
to
the
next
example,
so
it
was
the
appendix
that
was
added
about
message
exchange.
This
shows
a
basic
example,
so
a
client
sends
a
multicast
co-op
request
to
a
b
and
c
and
all
of
those
respond
with
the
unicast
response.
One
of
them
is
lost
and
there's
kind
of
a
special
twist
in
here.
In
this
example,
you
can
see
that
client
c
is
responding
from
a
different
port.
That
is
just
to
illustrate
that
yeah.
This
is
kind
of
allowed
behavior
that's
specified
by
co-op.
E
Okay
and
there's
more
examples
so
I'll
show
one
more
that's
with
a
more
advanced
example
much
longer.
So
this
is
the
blockwise
option.
You
can
see
that
in
yellow,
so
there
is
a
block
option
in
the
request
and
also
in
the
responses.
So
you
can
see
the
servers
all
supported
and
we'll
send
back
the
first
block
of
the
resource,
that's
being
requested
in
this
case
it's
a
log
resource,
so
you
can
expect
that
it
can
be
rather
big.
E
E
This
is
all
content
coming
from
a
and
then
the
example
continues
we'll
go
to
the
next
next
slide
and
it's
the
same
for
b,
so
from
b.
Also,
the
content
is
fetched
so
for
details.
You
can
also
look
look
in
the
draft
and
this
basically
concludes
what
I
wanted
to
show
here.
E
One
more
thing:
that's
the
next
step,
so
we
don't
have
any
current
updates
planned
all
the
issues
are
closed,
and
so
that's
why
we
think
it's
now
ready
for
the
working
group
last
call
to
be
done
at
some
point
for
this
version:
zero
six.
But
if
there
are
any
more
issues,
found
of
course
before
that,
we're
happy
to
to
work
on
that
as
well.
C
E
E
So
the
the
argument
for
for
including
an
application
group
was
that
basically,
you
do
not
include
it
in
the
group
uri,
but
after
the
parsing,
you,
you
add
in
the
uri
host
you
added
additionally,
so
it's
not
included
in
group
uri
and
that's.
E
G
E
Yeah,
that's
still
allowed
yeah,
but
then
it's
also
because
it's
in
the
authority
component,
it
becomes
the
co-op
group
also.
So
that
means,
in
that
case
the
application
group
and
the
co-op
group
are
one
of
the
same
and
they
are
identified
by
the
same
information
item.
Basically,
so
that's
that's
the
point
and
we
wanted
to
to
basically
encode
a
different
application
group
name
in
the
uri
host
option.
So
that's
what
makes
it
confusing
actually
yeah.
E
E
Any
reaction
from
the
chair,
so
what
do
we
do.
B
A
Okay,
next
presentation
is
group
of
score,
and
it's
on
me
so
carson.
If
you
can
drive
the
slides
that'd
be
good.
At
least
I
moved
to
the
presenter
mic.
A
B
A
Thank
you,
okay.
This
is
marco.
This
is
an
update
on
the
latest
version
of
the
drupal
score
document.
Next
slide.
Please.
A
Right
the
document
underwent
a
second
working
row,
plus
call
and
based
on
that,
we
submitted
version,
14
wait
for
the
cutoff,
and
this
was
based
on
two
reviews.
We
got
during
the
last
call
from
esko
and
rickard.
Thank
you
very
much
indeed,
for
that
there
were
very
good
comments
and
escos
came
first
in
two
parts.
The
the
main
actual
comments
followed
by
a
separate
mail
with
editorial
needs,
so
we
worked
on
those
first
and
we're
also
objective
discussion
at
an
interim
and
rica
reviews.
A
A
So
this
is
a
summary
of
the
main
comments
from
esko's
review
that
we
addressed
in
through
different
incremental
steps.
So
there
was
first
a
proposal
of
overall
direction
to
take
on
those
on
the
list.
The
most
controversial
delicate
points
were
discussed
at
the
cone
interim
and
it's
basically
those
listed
here.
A
So
we
enforce
the
clear-cut
distinction
between
authentication,
credential
and
public
key
in
terms
of
terminology
and
phrasing
around
those,
and
then
it
was
also
a
point
about
clarifying
the
trade-off
between
storage
over
and
convenience
for
for
storing
whole
authentication
credentials.
A
One
very
delicate
point
was
about
making
optional
the
feature
at
the
group
manager
to
recycle
group
ideas
so
that
a
group
can
live
forever
in
principle
still
in
a
safe
way,
and
there
was
especially
important
to
well
confined
this
optional
feature
in
in
a
very
self-contained
section,
so
that
it
was
clear
to
be
something
optional
for
the
group
manager
to
support.
A
So
that's
all
the
case
now
and
exactly
about
these
point.
There
was
a
further
confirmation
on
the
list
and,
finally,
a
number
of
points
related
to
what
was
mandatory
to
implement,
support
and
whatnot
rearrangement
of
references
to
be
appropriately
normative
or
informative.
A
As
the
text
citing
those
and
the
yak
option
used
for
synchronization
of
sequence,
number
three
challenge
response
moved
up
to
the
document
body.
You
find
more
pointers
in
in
the
slide
next
slide.
Please.
A
Yeah-
and
this
is
actually
it-
we
believe
that
the
latest
version
of
the
data
tracker
well
addresses
the
working
classical
reviews,
and
we
had
actually
confirmations
about
that
on
the
list.
A
We
are
not
aware
of
any
other
open
point
or
or
issue
specifically
on
github,
so
we
think
the
work
on
this
document
is
actually
done
for
a
working
group
and
that
it
can
proceed
with
the
next
step,
meaning
the
shepherd
write
up
in
after
some
discussion.
We
we
found
out
that
christian
amsas
is
available
to
act
as
shepherd
for
this
document
that
we
really
appreciate.
B
So
one
quick
question:
what
is
the
web
of
normative
references?
You
are
enchanted
in.
A
It
is
group
combis
and
the
cozy
documents
that
hopefully
will
be
yeah
published
anytime
soon.
They
are
not
48
for
a
while
now,
but
except
those.
If
I
remember
correctly,
it's
only
grouped
on
this
and
well.
Those
documents
have
to
proceed
in
parallel
anyway,
because
they
are
mutually
referring
each
other.
I
I
Thank
you
right,
so
I
will
be
presenting
this
draft
today.
Key
update
for
overscore
kudos
and
yes,
my
name
is
riker
herglund.
I
The
first
part
is
about
the
aad
key
usage
limits
in
os
core,
where
we
define
appropriate
limits,
frost
core
for
a
variety
of
algorithms,
and
this
basically
means
that
when
these
limits
are
reached,
you
have
to
rekey
the
keys
that
you're
using,
and
we
also
define
like
how
can
you
practically
have
a
counter
for
the
key
usage?
How
do
you
change
the
message
processing
compared
to
vanilla
score
and
what
steps
then,
should
you
take
when
the
limits
are
reached?
I
And
the
recent
update
here
was
that
we
recommended
a
new
set
of
values
for
the
qv
and
l
for
the
as128
ccm8,
because
that
has
to
be
handled
separately
from
the
other
algorithms,
since
there,
the
limits
has
to
be
lower,
basically
to
get
acceptable
probabilities
for
security,
but
today
the
main
focus
will
really
be
about
the
key
update
for
our
score
procedure,
and
this
is
a
procedure.
That's
loosely
inspired
by
the
appendix
p2
of
os
core,
and
the
goal
is
basically
that.
I
So
now
we
have
defined
this
bit
d
and
when
that
bit
is
set,
there
is
an
id
detail
field
added
to
those
corruption.
So
you
have
the
id
detail
and
you
have
x,
which
is
the
length
of
the
id
detail.
But
the
purpose
of
the
id
detail
is
essentially
to
carry
these
nonsense
back
and
forth,
and
you
can
see
that
also,
to
the
right
hand,
side
that
the
idea
holds
the
nonsense.
I
F
I
And
if
you
are
capable
of
writing
to
persistent
memory,
you
should
use
the
forward
secrecy
mode,
so
it
the
the
knob
for
a
secret
mode,
should
really
only
be
used
by
devices
that
have
to
use
it,
because
they
cannot
write
to
persistent
memory.
I
Yeah,
so
if
the
b
bit
is
set
to
one,
then
that
is
an
indication
you
want
to
run
kudos
in
the
no
forward
secrecy
mode
and
we
defined
some
concepts
related
to
this.
So
you
have
like
two
sets
of
key
material.
Basically,
like
you,
have
the
latest
master
secret
and
latest
master
salt-
and
this
is
the
information
from
your
last
most
recently
derived
score
security
context,
and
this
you
should
store
on
disk.
I
Right
and
if
you
want
to
run
kudos
in
the
no
forward
secrecy
mode,
basically
what
the
difference
between
the
current
definition
of
kudos
that
we
have
is
you
do
this
modification
that
the
security
context
uses
input
to
derive
your
new
security
context?
You
simply
replace
the
master
secret
and
master
salt
in
that
with
the
bootstrap
master
secret
and
bootstrap
master
salt.
I
So
your
starting
point
is
always
this
bootstrap
information,
and
because
of
that,
you
sacrifice
for
a
secrecy,
but
you
still
have
all
the
other
properties
for
kudos
remaining
and
now
there
is
a
way
like,
for
instance,
if
one
device
supports
writing
to
disk
and
the
other
device
does
not
support
writing
to
disk.
Well,
the
device
that
takes
initiative.
If
it
can
write
to
disk
it
will
try
to
run
kudos
in
the
forward
secrecy
mode
right.
I
So
it
couldn't
be
the
case
that
the
initiator
tries
to
run
it
in
for
a
secrecy
mode,
but
the
responder
is
unable
to
continue
because
it
cannot
practically
write
to
disk.
So
it
cannot
remember
and
store
the
latest
key
material.
But
in
this
case
we
have
this
agreed
downgrading
of
mode.
So,
basically,
if
the
responder
is
a
server,
you
return
a
protected
503
error
message
with
p
set
to
one
to
indicate
yeah.
I
I
want
to
run
it
in
the
no
forward
secrecy
mode
and
if
the
client
is
responder,
you
can
send
the
protected
request
to
with
p
set
to
one.
But
basically,
if
you
attempt
to
run
kudos
and
the
other
party
responds
with
the
p
bit
set,
one
saying
I
want
to
run
it
in
the
no
forward
secrecy
mode-
you
can
simply
try
yourself
with
the
p
bit
set
to
one.
So
at
least
you
can
run
it
in
common,
so
you
basically
have
to
downgrade
to
the
device
that
has
the
least
capability
and
yeah.
I
H
H
You
could
have
I
mean
if
you
could
use
this,
not
only
for
things
that
are
masteries
manufacturers,
that
it
could
be
things
like
afternoon.
Printing,
you
could
fill
this
bootstrap
master
secret
with
with
the
result,
or
it
could
be
the
result
after
and
provisioning
through
the
ace
oauth
framework
and
it
could
be
used
in
in
the
reset
button
settings.
H
So
you
could
I
mean,
even
if
you
have
both
both
the
bootstrap
master
secret
and
the
the
latest
master
secret
fields,
you
could
have
a
reset
a
button,
for
example,
which
means
that
you
pick
from
the
bootstrap
master
secret
register.
If
I
understand
right
and
and
that
I
think
it
would
be
really
useful.
So
this
gives
a
lot
of
options.
H
There's
some
security
considerations
here.
You
obviously
need
to
integrity,
protect
the
field,
but
you
have
you're
coming
to
that
in
the
latest
line
and
and
also
to
to
handle
the
situations.
When
you
have,
I
mean
there
are
a
number
of
cases
now
p
equals
one
and
zero
and
existence
of
these.
Whether
you
support
the
boost,
trap,
master
secret
or
not,
but
I
think
that's
not
not
overly
complex
and
that's
this
looks
good.
B
I
I
B
I
B
I
H
And
carson,
I
think,
and
the
authors,
I
think
this
is
not
a
big
problem.
I
mean
in
the
sense
that
I
mean
assume
that
you
have
a
good
entropy
of
of
the
bootstrap
master
secret
and
what
what
happens
at
the
key
update
is
just
that
you're,
adding
nonsense
so
yeah.
So
so
you
shouldn't,
I
mean
you
shouldn't
really
have
a
problem
as
long
as
the
original
entropy
of
the
of
the
bms
is
large
enough.
It
should
so
that
that
I
mean
it
bought
it.
What
you
say
boils
down
it.
B
Just
interested
in
this,
because
if,
if
it's
a
limited
number
of
times
you
can
use
it,
then
of
course
it
becomes
an
attack
vector
for
the
u.s
attack.
So
you
have
to
be
aware
of
that
vector.
I
Okay,
thanks
a
lot
for
the
discussion.
I
think
I
will
proceed
to
the
next
section.
Then
I
don't
know
how
many
so
now.
I
Another
addition
we
did-
and
this
is
also
in
fact
added
to
an
appendix
in
the
draft-
is
how
can
we
keep
observations
around,
and
this
has
been
something
we
discussed
in
earlier
meetings
also,
so,
basically,
there
is
a
problem
that
we
identified
and
that
problem
is
if
the
client
starts
an
observation,
let's
call
it
ops,
one
by
sending
a
request
direct
one
with
the
request
pivx
and
then
now
after
that,
the
two
pairs
run,
the
kudos
procedure
and
reset
the
sender
sequence
numbers
back
to
zero
and
later
on.
I
I
So
the
problem
here
is
that
now
a
notification
sent
by
the
server
for
the
observation
one
or
a
response
to
request
two-
would
both
cryptographically
match
against
the
request,
one
and
request
two,
and
essentially
because
they're
using
them
they're
using
the
same
request
pov
in
this
case
right.
So
we
needed
a
way
to
avoid
this
accidental
use
of
the
request
piv
for
open
observations.
I
So
what
we
do
now
in
appendix
is
we
define
a
method
where
you
do
this
jumping.
We
call
it
long,
jumping
beyond
the
partial
levees
that
are
already
in
use
for
observations
and
more
information
on.
This
is
also
on
the
next
slide,
and
we
also
now
propose
to
have
a
new
bit
b
that
you
can
actually
use
to
signal
interest.
If
you
wish
to
keep
observations
or
not,
and
of
course,
if
both
parties
do
not
wish
to
keep
the
observations.
I
I
It's
basically
that
when
you
want
to
send
the
first
request
after
you
did
the
key
update,
kudos
execution,
the
client
should
determine
the
partial
av
which
has
the
highest
partial
me
iv,
among
all
ongoing
observations,
and
the
point
is
that
you
wish
to
now
set
your
sender
sequence
number
to
that
value.
Plus
one,
so
you
jump
beyond
this,
so
there's
absolutely
no
risk
that
you
will
be
reducing
that
partially.
I
That's
already
occupied
for
an
ongoing
observation,
but
then
we
identified
after
some
discussion
like
a
sub
issue
or
related
issue
to
this,
which
is
that
to
remove
ongoing
observations.
The
client
needs
an
explicit
confirmation
from
the
server,
because
otherwise
the
server
may
still
consider
observation
to
be
open.
I
So
what
you
do
if
this
client
cannot
get
the
confirmation
the
worst
case,
these
observations
would
be
around
forever
and
you
would
always
have
to
jump
to
a
very
high
sender,
sequence,
number
or
partially.
However,
we
now
define
this
epoch
counter.
So
for
each
ongoing
observation,
you
have
an
epoch
and
when
this
apple
counter
reaches
the
max
epoch,
you
can
both
parties
delete
the
observation,
and
this
counter
would
be
incremented
every
time
you
do
the
key
update
right.
I
This
is
like
to
reduce
the
risk
that
you
have
observations
staying
around
forever
and
always
forcing
you
to
jump
for
a
head
in
the
piv
space.
So
in
this
case
it
would
be
a
guarantee
that,
let's
say
the
max
epoch
is
three
then
after
three
kudos.
Three
year,
keying
executions,
you
would
guaranteed
to
have
deleted
that
observation,
and
both
sides
do
that
so
now.
I
The
question
here
is
like,
for
instance,
what
is
a
recommended,
a
good
value
for
the
max
epoch
and
we're
also
yeah
any
kind
of
commentary
input
on
this,
and
one
thing
we
were
thinking
about
it
if
it
can
make
sense,
also
to
have
like
a
negotiation
within
kudos
where
you
can
mutually
agree
on
the
max
epoch.
H
Yeah,
thank
you
yeah.
I
I
I'm
a
little
bit
critical
to
this.
I
now
have
read
it
a
little
bit
more
in
detail,
so
I'm
I'm
not
really
sure
we
should
do
this
at
all,
but
I'll
provide
since
we're
running
out
of
time
here
I
did
not
ask
those
questions
now,
but
yeah.
I
think
this
is
maybe
a
little
bit
engineering
too
much
something
that
we
should
first
understand.
If
we
need
to
do
so
I'll
get
back
on
that.
I
Thank
you
I
yes,
so
I'll
go
through
it,
a
bit
quicker
and
so
one
other
thing
we
added
was
the
ability
to
renew
the
sender
and
cpid
recipient
ids
on
the
pairs.
I
So
we
have
this
now
in
appendix
d
and
it's
basically
a
procedure
where
you
say
as
a
pair
okay,
I
wish
to
use
this
recipient
id
and
the
other
party
says
which
new
recipient
id
it
wishes
to
use,
and
when
you
have,
then
you
basically
you
generate
new
contacts
based
on
those
new
recipient
ids
and
you
can
continue
the
communication
with
new
recipient
ids
on
both
parties
and
this
procedure
can
also
be
embedded
in
a
kudos
execution
or
run
standalone.
I
So
we
defined
a
new
option
for
this.
It's
just
the
recipient
of
the
option.
Again,
the
idea
is
pretty
basic
in
there
you
put
what
recipient
id
you
wish
to
use
in
the
future,
and
the
other
party
does
the
same
and
here's
the
message
flow.
So,
basically,
what
you
can
see
here
is
the
client
starts
with
a
recipient
id
of
zero.
Now,
in
request
one,
it
includes
the
recipient
id
option
indicating
42
in
the
response.
H
Yeah
again
just
a
brief,
I
think
this,
I
don't
see
any
problem
with
this,
but
I'm
I
haven't
seen
the
compelling
use
case.
That's
one
one
comment,
and
the
other
comment
is
that
this
must
only
used
when
it's
protected
with
the
previously
established
security
context.
So
it's
not
enough
that
austria
is
being
used.
It
has
to
be
previously
established
security
context,
but.
I
I
On
safe
ways
to
use
this,
which
I
think
we
also
cover
in
the
text-
yeah
yeah,.
H
I
Okay
and
then
I
had
this
final
part,
which
is
about
so
throughout
this
draft
now
we
basically
defined
three
new
bits.
One
is
the
id
detail
bit
itself
to
signal
the
inclusion
of
the
id
detail
in
those
corruption.
I
Then
we
have
the
no
forward
secrecy
bit
p
to
signal
the
use
of
the
node
forward
secrecy
mode,
and
then
we
have
the
observation,
speed
b,
so
we
now
first
of
all
the
id
detail
bit
that
is
placed
in
those
corruption,
as
you
can
see
there
to
the
right.
But
then
the
question
comes
okay:
where
do
we
put
the
bits
b
and
p
to
also
provide
integrity
protection
of
these
bits?
So
our
idea
and
proposal
now
is
to
put
this.
I
I
I
Bits
yeah
and
then
just
a
quick
summary
and
next
step.
So
what
did
we
do
in
this
version?
We
suggest
now
a
way
to
do
a
key
update
without
forward
secrecy
defined
in
appendix
e.
We
suggest
a
method
for
preserving
observations
across
key
updates,
suggesting
appendix
c,
and
we
all
started
yesterday
procedure
to
update
the
overscore
sender,
recipient
ids
defined
in
appendix
d.
I
We
propose
an
alternative
placement
for
the
signaling
bits.
Then
we
did
some
general
improvements
in
the
massive
processing
and
also
nothing
I
didn't
really
cover.
We
have
a
document,
an
optimized
way
of
count,
storing
the
count
q
variable,
which
is
basically
related
to
the
limits
that
you
have
to
count
the
amount
of
times
you
use
a
particular
key
and
that's
in
appendix
b
and
yeah.
Our
plan
is
basically
to
address
open
points
and
issues
we
have
a
number
of
issues
on
github
and
feedback
is
very
welcome
and
we
also
want
to
move
the
suggestion.
I
A
G
G
Yeah,
okay
protocol
indication:
that's
the
right
one!
Okay!
What
I'd
like
to
do
here
right
today
is
give
you
a
brief
summary
on
the
on
the
topic,
because
we've
talked
a
lot
of
in
during
interims
and
gone
into
details
there.
But
I
think
what
will
help
be
helpful
for
today
is
to
talk
about
what
this
is,
and
what
that
why?
Why
why
this
needs
to
be
done
and
what
other
challenges
and
solutions
conveniently
the
secretariat
has
been
providing
these
small
badges
and
this
roughly
sums
up
what
this
draft
is
about.
G
That
is
everything
before
the
before
the
authority
in
the
component
of
the
co-op
uri
might
have
different
values.
So
the
typical
examples
that
we
see
are
co-op
over
udp
and
code
over
tcp,
but
really
this
applies
just
as
well
to
couple
web
sockets
and
any
of
those
transports
that
have
been
around
in
draft,
be
it
corp
over
serial
sms
bluetooth,
and
there
are
a
few
ideas
around
of
people
who
want
to
do
it
over
quick
and
that
might
be
done
through
taps.
G
So
maybe
keep
a
look,
keep
an
eye
open
for
that
I'll
be
talking
about
udp
and
tcp,
primarily
as
placeholders.
Here.
The
thing
is
the
way.
If
you,
if
you
look
at
a
device
that
is
concretely
implemented,
what
you
usually
see
is
that
it
has
a
few
resources
in
there,
so
an
led
and
the
firmware
and
provides
different
transports.
But
what
on
the
uri
level,
it
actually
is,
is
the
one
comes
in
through
co-op
over
tcp,
that's
called
plus
tcp
column,
slash,
slash
authority
component
and.
G
Apologies
and
I'll
just
point
to
the
right
half
of
things
right.
G
G
This
does
not
follow,
so
we
might
need
to
indicate
what
actually,
what
the
situation
is
and
whether
a
client
may,
just
when
it
is
doing
cover
or
udp
switch
over
to
tcp
and
continue
on
the
same
resource
now.
Something
we
could
do
is
to
define
that
just
for
a
particular
set
of
servers
just
to
define
that
for
particular
protocols.
These
are
the
same
thing.
G
G
G
So
the
current
proposal
is
to
not
is
to
to
not
unify
these,
but
rather
to
provide
access
to
the
resources
on
one
side
of
the
of
on
on
one
protocol
through
the
other
protocol,
and
conveniently
corp
always
really
gives
us
all
the
tools
we
need
for
that.
Because
there
is,
there
is
the
proxy
scheme
option
and
if
a
device
is
accessed
with
a
query
with
a
request
that
includes
that
option,
the
uri
host
option
still
has
the
same
default
value
that
it
has
already.
G
I
mean
we
have
to
add
proxy
functionality,
but
really
what
it
is
is
the
device
must
be
prepared
to
ignore
that
option
as
long
as
it
implements
the
same
resources
on
both
on
both
protocols.
G
So
reads
like
a
lot,
but
really
what
it
is
is
simple
to
implement
and
just
adding
a
few
bytes
on
the
wire.
G
Then
you
may
follow
that
additional
link
to
find
a
proxy
and
use
that
proxy
now
proxy
is
a
co-op
service
and
basically
mapped
to
a
socket
somewhere,
whereas
all
the
things
we
can
talk
about
in
in
web.
Linking
are
your
eyes
so
and
we
don't
have
a
particular
uri
scheme
that
identifies
a
service
running
on
a
particular
port.
G
But
the
predicate
used
there
says
that
this
is
pointing
to
a
uri
and
what
it
actually
means
is
put
the
put
the
transport
and
the
and
the
protocol
out
of
that
and
use
that.
G
So
so
far,
this
address
is
the
the
first
two
goals.
That
is,
we
introduce
a
mechanism
that
allows
discovery
and
the
other
is
that
we
don't
add
uri
aliasing
to
a
world
in
which
it
was
not
taken
for
granted.
So
far
by
the
way,
if
you
have
questions,
I
think
now
would
be
a
good
yeah.
Okay,
now
might
be
a
good
time,
because
I
can
take
a
okay.
I
can't
go
back
here,
because
this
is
like
the
basic
groundwork.
G
Otherwise,
I'll
just
continue
on
with
to
the
next
part
here
that
is.
E
G
This
is
so
far
not
precisely
described.
My
roth
expectation
would
be
that
it
is
that
it
is
done
whenever
there
is
something
that
looks
like
initial
discovery,
but
might
warrant
a
few
more
words,
so,
especially
with
servers
that
provide
a
lot
of
different
transports.
It
can
well
make
sense
to
narrow
this
down
I'll.
Take
that
as
an
input
for
for
for
an
updated
version
to
say
something
about
which
proxy
statements
make
sense
to
send
unprompted
and
whether
and
how
a
client
might
express
interest
in
them
there
is
providing.
G
So
there
is.
There
are
a
few
words
on
how
a
client
can
ask
for
them
explicitly,
but
especially
with
the
lookup
defined
in
6690
and
used
also
a
resource
directory.
That
is
really
an
extra
query.
Step
with
corel
things
might
be
a
bit
easier,
but
then
again
we
don't
have
the
coral
query
format
specified
yet
so
that
might
be
selling
things
that
we
haven't
even
really
hunted
yet.
E
Okay,
yeah
thanks.
I
see
also
use
case
here
for
clients
that
do
co-op
discovery
and
and
get
a
big
list
of
co-op
s
resources
back.
So
if
you
use
this
statement
and
the
client
understands
it
at
least
then,
then
you
can
make
the
list
shorter
overall
by
removing
yes
of
yeah
overhead,
but
that's
only
in
link
format.
I
think
yeah,
probably
nothing.
G
G
There
is,
of
course,
a
bit
more
to
it,
but
I
think
that's
just
you
should
take
so
if
a
proxy
is
advertised
this
way,
the
general
expectation
of
the
client
should
be
that
the
proxy
can
still
provide
credentials
for
whatever
the
original
service
was,
so
there
would
be
no
downgrade
of
security.
G
There
are
of
cour
kind
of
this
works
really
well
and
transparently.
If
oscor
is
used.
This
also
works
for
tls
based
connections
as
long
as
that
proxy
is,
as
I've
been
describing
it
so
far,
really
on
the
same
device.
So
if
the
same
device
just
opens
the
tls
port,
in
addition
to
a
dtls
board,
it
would
just
provide
the
same
certificates
there.
G
Such
a
proxy
could
still
be
advertised
to
make
the
client
send
its
data
up
around
another
services,
so
that
service
does
an
up
around
through
up
through
attack,
so
the
attacker
at
least
sees
the
traffic
pattern.
G
The
latest
version
now
has
a
few
words
on
that,
among
other
things,
saying
that
yeah,
if
you
want
to
protect
against
that,
you
better
also
use
dns
sec
and
look
at
what
routing
advertisements
you
take,
because
if
you
don't
watch
for
that,
you
might
wind
up
in
the
same
situation,
but
basically
it's
up
to
the
application
which
requirements
to
place
on
the
statement,
because
the
fundamental
security
properties
are
already
upheld
by
the
requirement
that
the
serve
the
proxy
still
needs
to
provide
good
credentials.
G
Maybe
we
just
want
to
look
into
a
few
more
things
that
the
document
also
provides
in
particular
that
someone
else
might
provide
that
proxy
service,
for
example,
a
resource
directory
that
allows
cross-proximing
between
coop
and
core
plus
tcp
connections,
and
also
we
still
send
a
few
bytes
more
so
on
the
on
the
pro
on
the
proxy
side.
This
is
rather
straightforward
because,
generally
this
statement
can
be
produced
by
any
other
party,
in
particular
those
that
are
in
the
discovery
path
and
the
rest
is
really
up
to
the
security
requirements
of
the
application.
G
The
line
on
proxy
usability,
I
won't
talk,
say
much
more
other
than
yeah.
Of
course,
if
there
are
clients
or
if
there
are
proxies
already
in
the
same
in
this
whole
game,
things
will
still
keep
working
on
the
topic
of
optimizing
away,
those
additional
bytes
that
we
might
have
on
the
wire.
There
is
a
specialization
of
that
option.
That
says
that
this
that
the
host
is
generally
not
doing
any
name
and
protocol
protocol-based
virtual
hosting.
G
I
prefer
to
think
of
it
as
an
agreed
on
compression,
basically
similar
to
schick,
because
we
establish
a
context,
although
not
all
not
statically
but
dynamically,
and
that
context
then
says
there
is
an
implication
that
your
ihos,
that
you
arrive,
sorry
that
proxy
scheme
and
your
eye
host
are
already
always
that,
but
the
security
implications
are
a
bit
harder
to
manage
and
there's
still
ongoing
exploration
on
that.
G
So,
to
summarize,
I
think
it's
not
too
hard
to
get
all
of
this
going,
especially
because
most
of
the
options
that
we
need
are
already
there.
We
can
do
this
without
breaking
the
general
rules
of
the
web.
That
is,
do
not
just
introduce
url,
aliasing
yep
and
I
think
it
can
and
should
be
done.
The
question
is:
what
am
I
missing
and
is
this
something
that
should
go
through
this
working
group.
E
Yeah,
okay,
sorry
yeah!
I
was
just
thinking
doing
it
in
this
working
group
sounds
good
and
it
might
require
indeed
yeah
a
document
to
clarify
that
use
of
the
proxy
option.
E
So
yeah,
it
sounds
sounds
useful
at
least
to
do
it
in
this
way.
A
Thank
you
cheretov,
yes,
and
yes
from
my
side
too
anyway.
Okay,
I'd
just
like
to
have
a
first
feeling
from
the
room
and
ask
a
usual
question:
we
can
use
the
very
sense
tool.
B
A
A
Okay,
having
eaten
five
minutes
from
flex
time,
we
are
still
good
on
time.
I
think,
and
you
can
move
on
with
the
next
presentation.
Christian
yep.
G
So
this
next
slot
is
about
non-traditional
responses
where
I've
recently
joined
the
now
who's
author
team.
I
recently
joined
and
again
I'd
like
to
start
with
kind
of
setting
out
the
problem
space
here.
That
is,
that,
without
defining
what
it
is,
we've
had
a
few
variations
on
how
responses
come
in
to
coop
requests.
G
So
the
simple
thing
that
happens
in
in
at
least
in
my
application,
like
99
of
requests,
is
that
there
is
a
single
request
and
there's
one
response,
and
if
that
response
is
retransmitted
that
the
retransmitted
version
might
be
slightly
different,
but
the
client
still
processes
only
one
response
now
multicast
has
been
around
from
the
start,
which
means
that
there
are
different
responses
coming
in
from
different
source
addresses
observation
was
part
of
co-op,
almost
from
the
beginning,
indicate
which
allows
the
server
to
send
more
than
one
response
over
time,
and
then
a
few
documents
explored
how
else
responses
could
come
in
so,
for
example,
co-op
over
sms
was,
to
my
knowledge,
the
first
document
that
described
that
there
could
be
something
like
a
triangular
request,
where
you
send
a
request
from
the
client
to
the
server
over
sms,
but
also
indicate
that
you
would
pretty.
G
G
And
that
was
taken
up
later
in
in
core
responses:
the
endpoint
id
draft
that
was
around,
I
think
around
2017
had
options
for
observations
that
changed
the
server's
address.
So
then,
again,
a
later
response
would
come
in
from
my
next
address
that
the
client
wasn't
originally
expecting
it
from
and
more
recently
the
the
multiblocks
rfc
and
the
mo
and
the
proxy
for
group
communication
draft.
G
G
G
All
responses
are
non-traditional,
but
there
might
be
one
that
is,
that
is
standing
out,
not
necessarily
by
anything
the
transport
provides,
because
any
additional
response
just
looks
like
the
others,
but
quite
possibly
only
one
response
matches
the
request
in
some
sense,
because
there
are
the
others
might
have
say,
options
that
clearly
deviate
from
what
is
okay
to
respond
with.
G
So
there's
an
additional
definition
and
looking
at
it
now,
I
might
want
to
flip
terminology
to
not
have
too
many
negations
in
there,
but
a
matching
response
is
one
that
works
well
for
the
original
request
and
has
no
options
that
make
it
incompatible.
So,
for
example,
if
and
that
is
what's
been
using
in
the
block,
wise
request,
clockwise
rfc
and
new
blocks,
sorry
9177
is
that
a
request
is
sent
for
a
particular
block
and
one
of
the
many
responses
that
come
back.
G
So
the
document
as
it
is
now
does
a
few
things
that
could
all
be
useful
on
their
own
and
anticipating
the
next
slide.
This
is
what
we'll
need
a
bit
of
guidance
for
one
thing:
is
it
provides
terminology
so
right
now,
every
document
that
somehow
introduces
non-traditional
responses
has
to
reiterate
on
the
topics
of
tokens
has
to
say
again
that
and
by
the
way
flow
control
of
this
is
all
still
as
in
rfc
7252,
or
any
extensions
to
flow
control
and
cons
and
nons
work,
as
they
always
have.
G
So
this
document
could
provide
terminology
for
this,
and
there
are
two
concrete
drafts
where
I
think
it
would
be
very
useful
to
pivot
over
to
this,
provided.
This
is
something
that
we
can.
This
is
a
direction
we
continue
going
in
same
goes
for
implementations,
so
I've
seen
implementations
of
observation
of
various
quality,
varying
quality
in
different
in
different
implementations,
and
these
often
don't
work
well
together
with,
for
example,
multicast,
and
if
there
is
a
general
concept
of
non-traditional
responses
and
how
these
work.
G
I
think
that
this
can
also
go
into
implementations,
and
they
would
then
just
say
that
we
are
expecting
several
responses.
G
G
The
current
draft
also
defines
a
few
a
few
options,
for
example,
one
by
which
your
client
can
generally
request
several
more
responses
over
a
particular
over
some
time.
So
that's
the
okay,
that's
the
fourth
bullet
here.
These
options
could
be
by
applications,
and
the
draft
also
describes
that
there
could
be
pre-configured
pre-configured
requests,
which
means
that
there
isn't.
There
are
no
added
options.
G
Okay,
so
the
questions
that
we'd
like
to
ask
is
a
are
non-traditional
responses,
something
that
this
working
group
is
interested
in
working
in
general
and
then
b.
If
it
is,
is
this
document
the
right
taking
the
right
approach
so
do
we
do
we
provide
con
concepts
that
are
useful?
Do
we
provide
options
that
are
useful?
Do
you
want
to
keep
all
of
that
in
apart
from
the
interest
interest
topic?
G
There's
also
the
question
of:
do
we
conflict
with
anything
so
so
far,
I've
compared
this
against
everything
I
found
that
did
multiple
responses
and
I
think
it's
matching
pretty
well,
but
we
might
have
overlooked
something,
and
so
this
is
something
that
I
would
like
to
have
checked
and
then
the
remaining
question
is
basically
aof
any
other
feedback.
E
Yeah,
I
think
these
are
good
questions.
I
find
them
difficult
to
answer
at
this
moment,
but
but
I
wanted
to
ask
one
question
from
the
implementer
perspective,
so
you
propose
that
by
introducing
this
concept
of
non-traditional
response,
that
it
would
improve
also
the
software
quality
in
that
way,
but
because
the
the
stack
would
have
a
sort
of
catch-all
function
or
callback
or
whatever
for
the
non-traditional
response
case
yeah,
it
doesn't
know
how
to
handle
it.
Otherwise,
yeah.
G
So
the
the
stack
would
still
need
to
be
so
what
right
now
happens
is
the
stack
needs
to
be
aware
of
the
full
semantics
of
all
the
non-traditional
response
options,
so
it
needs
to
handle
the
proxy.
The
the
multicast
proxy
option
needs
to
handle
observation,
and
with
that
terminology
the
stack
could
just
have
a
list
of
options
with
their
respective
rules
of
how
long,
how
many
responses
or
how
long
responses
come
in,
without
necessarily
having
to
implement
all
the
nitty-gritty
details
and
can
leave
some
of
that
to
the
application.
F
A
Marco
cherhatov
I've
read
the
the
last
two
versions
of
the
draft
and
I
plan
to
give
out
review
anyway.
I
couldn't
see
any
conflict
really
with
other
documents
and
actually
I
think,
it's
good
to
have
a
single
framework
as
reference
point
for
terminology,
taxonomy
and
concepts
that
are
already
used
here
and
there
any
way,
and
otherwise
we
risk
dialects
of
this
concept
to
develop
and
so
on
and
just
create
confusion.
G
B
B
C
A
F
Okay,
yeah,
I'm
talking
about
dns
queries
over
corp,
together
with
and
also
representing
my
other
co-authors,
which
are
on
this
slide
right
now,
yeah.
I
first
want
to
talk,
of
course,
a
little
bit
about
the
concept
and
then
update
you
on
what
we
did
since
the
last
time
we
spoke
in
this
working
group,
which
was
the
an
interim
last
year
then
show
some
of
our
preliminary
evaluation.
We
did
on
the
various
dns
transports
we
could
use
and
then
go
over
into
the
discussion
where
I
want
to
discuss
a
new
content
format.
F
Caching,
options
if
we
need
to
account
for
observe
or
so-called
server
push
if
we
take
https
lingo
and
the
question
of
how
abstract
the
draft
should
be
or
how
concrete
yeah
for
the
motivation.
Basically,
we
basically
just
want
to
protect
against
eave
dropping
when
doing
dns
requests
in
with
iot.
C
F
And,
of
course,
the
usual
way
to
do
it
is
to
encrypt
the
name
resolution
and
basically
there
are
already
some
solutions
for
that,
of
course,
which
is
dns
over
https
dns
over
tls,
then
newly
added
the
sdns
over
quick
and
dns
over
dtls.
But
all
of
these
have
problems
when
it
comes
to
the
iot.
The
first
two,
of
course,
use
tcp,
which
conflicts
with
some
of
our
resource
constraints
we
face
in
the
in
the
constraint.
F
Iot
dns
over
quilt
has
similar
problems
when
it
comes
to
that
and
dns
over
dtls
has
a
so-called
path
and
deal
problem
which
is
even
amplified
when
it
comes
to
constraint,
link
layer,
videos
with
like
the
ones
we
face
in
802154
or
lower
one.
F
So
our
proposal
is
to
do
dns
over
co-op.
We
can
then
base
your
user
encrypted
communication
based
on
ddls
or
oscore,
use
the
block-wise
message
transfer
to
overcome
the
plasm
due
problem
and
also
share
the
system
resources
with
co-op
applications.
So
we
can
basically
save
some
memory
by
using
the
same
buffers
and
sockets,
and
also
you
reuse,
the
corporate
transmission
mechanism,
and
we
basically
just
do
that
by
putting
the
dns
query
in
a
co-op
request,
fetch
and
that
is
then
issued
to
a
doc
server.
F
F
We
put
a
little
bit
of
thought
into
how
caching
and
cache
validation
is
done
with
the
e-tags.
We
also
added
doq
as
another
consideration
and
why
it
constant
conflicts
with
constrained
iot
scenarios.
We
clarified
how
our
content
format
is
and
accept.
This
handled
and
yeah
also
did
a
lot
of
to
be
done
by
mostly
just
saying
that
they're
out
of
band,
for
example,
the
service
relate
selection,
but
also
put
some
consideration
on
how
messages
that
are
too
big.
F
Basically,
dns
messages
that
are
too
big
should
be
handled
by
a
doc,
server
and
yeah,
and
also
added
some
considerations
on
how
to
use
dns
over
corp
with
a
why
to
use
dns
over
coop
with
an
unencrypted
connection
and
why
it
might
be
also
beneficial
for
evaluation.
F
We
basically
first
looked
into
what
is
there
on
dns
traffic
in
the
iot
and
basically
made
an
empirical
data
set
of
that
to
get
some
idea,
what
name
properties
and
resource
records
are
there?
We
then
did
that
and
used
that
information
to
experiment
do
some
experiments
in
a
testbed
with
two
clients
which
requests
a
name
from
a
resolver
via
forwarder
and
a
border
router
the
clients,
basically
just
query
50a
or
aaa
the
quad
a
records,
often
for
a
name
of
length
24..
F
F
Of
course,
this
completely
ignores
the
end
start
requirement,
which
is
outlined
in
7252,
but
we
wanted
to
see
the
network
basically
in
a
constrained
manner,
so
we
get
some
interesting
data
and
yeah
we
did.
F
Is
this
group
three,
and
the
question
of
course
is:
where
do
these
performance
groups
come
from?
And
when
we
look
at
the
packet
sizes,
we
get
basically
our
answer,
because
the
group
one
is
basically
where
no
message
fragmentation
is
happening.
Group
two
is
where
the
query
is
unfragmented
and
the
response
is
fragmented
and
the
group
3
is
basically
where
both
query
and
response
are
fragmented.
F
So
our
conclusion
of
that
is
that
when
it
comes
to
performance,
basically,
the
fragmentation
has
a
far
larger
impact
compared
to
transport
or
co-op
methods.
And
I
guess
this
is
not
a
big
surprise
for
most
of
you
but
yeah.
But
our
conclusion
from
that
is
basically
that
we
need
a
new
new
content
format
other
than
the
normal
wire
format
for
dns
over
co-op
which,
because
even
with
the
most
realistic
query
and
response
sizes,
we
see
fragmentation.
F
Even
when
we
just
take
our
minimal
name
length
of
two,
the
response
for
a
quad,
a
record
already
gets
fragmented
and
so
yeah.
Basically,
we
want
to
have
some
kind
of
compression
basically
to
get
below
that
number
and
some
ideas
we
put
forward
for
that
not
yet
in
our
draft,
but
to
discuss
here,
is
to
basically
omit
the
authority
and
additional
sections
of
the
dns
response.
F
Omit
the
qd
field,
because
acute
count
fields,
because
the
question
section
is
always
of
length.
Irons,
most
resolvers,
even
just
throw
away
any
query
that
has
more
than
one
qr
question
in.
It
then
make
the
class
and
type
optional
and
basically
imply
the
most
requested
ones,
which
are
hopefully
soon
in
in
quad,
a
apparently
it's
more
in
and
a
but
yeah.
We
hope
that
will
change
in
the
future.
F
F
But
in
general
this
probably
should
be
discussed
in
a
separate
draft.
F
F
I
have
a
slide
in
my
backup,
slides,
which
I
don't
want
to
scroll
forward
to,
because
this
meet
equals
thing
is
a
little
bit.
Okay,
I'll!
Look
it
up
there.
I.
F
Yeah,
okay,
yeah,
then.
The
other
discussion
we
want
to
basically
open
is
that
we
have
basically
currently
two
proposals
for
how
to
handle
caching
and
the
max
age
option
and
dns
ttls,
which
all
use
relative
values,
and
so
we
they
might
get
out
of
sync
at
caching,
proxies
indeed
in
the
doh
rvc.
Basically,
there's
a
proposal
just
use
the
minimum
ttls
as
a
freshness
which
would
equate
and
go
up
to
the
max
age
option,
and
then
the
clients
basically
need
to
figure
out
how
to
do
the
ttl
to
the
dtls.
F
And
basically
this
would
mean
that
you
basically
look
for
the
smallest
ttl
and
if
that
is
not
the
same
as
a
max
h,
just
subtract
them
and
calculate
the
detail
from
that.
That,
of
course,
and
the
other
option
would
be
to
do
it
also
like
doh,
but
then
adapt
the
ttls
already
at
the
server.
So
basically
the
minimum
ttl
is
zero
and
everything
else
is
just
the
difference
from
that,
and
then
the
client
basically
just
needs
to
re-adapt
this
based
on
the
max
age.
F
If
we
do
this,
it
looks
at
this
in
detail.
So
basically
we
get
our
response
at
the
dock,
server
see
the
ttls
get
the
minimum
ttl
off
the
dns
response
and
put
it
into
our
core
header.
That
then,
is
sent
via
a
cache
that
which
does
stores
the
response,
and
we
wait
some
time
then,
when
we
query
the
the
next
time
we
basically
find
it
on
our
cache
and
of
course
the
max
h
now
has
decreased
and
differs
from
the
minimum
ttl.
F
F
We
basically
are
already
done,
so
we
put
mostly
the
workout
on
load
on
the
server
which,
in
this
scenario,
is
assumed
to
be
the
more
powerful
node
and
also
we
have
less
cash
invalidation,
because
even
if
the
ttls
change
in
the
responses
we
get
from
some
upstream
dns
server,
assuming
they
are
off
always
the
same
time
amount
of
time
apart.
We
don't
change
the
content
of
the
response.
So
if
the
content,
if
the
e-tec
is,
for
example,
based
on
hashing
the
content,
then
we
basically
don't
invalidate
our
cache.
F
We
can
just
get
a
valid
response
from
the
dlc
server
from
the
core
proxy
okay
and
then
the
second
to
last
thing
to
maybe
to
discuss,
is
the
section
five
three
which
talks
about,
observe
and
server
push
in
http
2,
which
basically
based
on
this
doh
section,
which
is
about
to
how
that
maybe
the
the
response
to
the
potentially
next
request
could
be
delivered
to
a
client
and
then
cached
by
them
with
core.
F
Someone
could
think,
maybe
that
the
name
could
be
of
the
of
the
core
rd
could
be
requested
and
then
basically
also
deliver
the
well-known
core
of
the
core
id.
But
all
in
all,
this
would
require
the
corp
put
somehow
the
request,
information
in
the
notification,
or
so
we
get
back
to
this
non-traditional
dns
responses
thing
so
that
the
client
basically
knows
where
to
cache
and
for
what
to
cache.
This
response
that
it
got
just
out
of
the
blue
and
another
use
case
of
observe,
specifically,
was
that
there
is
dna
state
for
operations.
F
But
there
is
also
the
question
if
this
is
even
needed
by
just
some
step,
resolver
or
doc.
Client
yeah,
and
the
last
thing
basically
is
how
to
how
abstract
the
draft
should
be.
Klaus
harker
there
put
an
issue
in
our
issue
tracker,
and
he
basically
proposes
that
to
that
that
we
just
specify
a
rest
api
that
the
server
then
serves
how
to
retrieve
the
dns
information
and
leave
all
the
protocol
details
to
the
implementation
so
yeah.
F
F
Then
yeah
so
basically
here
I
resolved
all
the
layers
by
by
all
the
packets
by
layer
and
you
see
for
the
minimal
mim
format.
There
is,
I
mean,
there's
basically
these
four
bytes,
but
they
are
part
of
a
bigger
dns
response
because
of
course
also
the
quad.
A
record
itself
is
in
it
like
the
ip
address,
but
maybe
we
can
also
compress
that
somehow,
if
it's
a
known
prefix
or
something
like
that,.
F
C
D
F
At
the
moment,
we
are
focusing
on
quad
a
because
that,
in
was
what
we
saw
in
our
data
set,
was
the
most
requested
stuff.
Actually,
if
you
don't
account
for
mdns,
it's
basically
the
only
record
we
saw
or
b
or
the
a
records
in
to
be
honest,
but
we
of
course
want
to
also
support
other
kind
of
records.
Okay,.
E
E
Yeah,
so
that
seems
very
suitable
to
just
apply
observe
to
it,
and
I
guess
you
already
consider
that.
E
Yeah,
it's
eight
eight,
seven,
six,
five.
It's
also
notifications
and
then
that's,
for
example,
used
also
by
embedded
devices
I'm
working
on
on
those
kind
of
solutions
where
actually
they
will
query
for
services
so
using
yeah,
dns,
sd
type
of
queries
and
getting
responses,
and
those
are
also
updated
whenever
there's
a
change.
So
whenever
a
new
device
comes
online,
the
device
can
be
notified.
E
F
F
Maybe
we
put
an
option
in
there
and
say
it's
for
dns
push,
or
maybe
we
don't
yeah
that
also,
I
guess,
depends
a
little
bit
on
the
direction
the
approach
will
take
in
the
future.
E
A
So
it
looks
like
you
know
what
to
do.
I
could
count
kind
of
four
main
topics
or
tracks
to
be
more
explored.
If
it's
useful,
you
can
even
start
one
thread
each
on
the
mailing
list
to
get
more
specific
feedback
yeah
on
those,
otherwise
definite
material
for
discussions.
Editorial
meetings.
F
Yeah
yeah
exactly.
B
So
yeah
and
please,
if
you
are
interested
in
reviewing
versions
of
this
draft,
please
send
a
message
to
the
chat.
So
we
can
gauge
the
interest
in
that.
A
Thomas
says
he
is
interested
to
review
and
by
the
way
he
was
thanking
you
and
cultures
for
the
nice
work.
Okay,.