►
From YouTube: IETF108-CORE-20200728-1410
Description
CORE meeting session at IETF108
2020/07/28 1410
https://datatracker.ietf.org/meeting/108/proceedings/
B
Yeah,
so
I
think
we
can
start.
I
would
like
the
just
well,
let's
start
so
welcome
to
the
core
working
group.
We
are
doing
the
second
ietf
that
we
we
do
it
remotely,
but
all
of
you
or
most
of
you
have
participated
in
the
interim
meeting.
So
this
is
no
surprise,
I'm
jaime
jimenez
and
there
you
have
also
marco.
We
are
the
chairs
of
the
working
group
and
well,
we
will
be
handling
the
session
today,
I'll
be
passing
the
slides.
B
I
guess
you,
marco,
will
be
checking
on
the
jabber
right,
yeah
and,
and
we
have
the
two
minute
takers.
We
were
niklas
and
evo
evo.
Thank
you
very
much
evil
and
nicholas
the
schedule.
So
well,
let's
start
with.
We
assume
that
people
have
read
the
drafts.
Most
of
them
anyway
have
been
for
quite
a
while.
So
probably
you
are
very
familiar
with
them
yeah.
So
basically,
the
the
ipr
applies
to
this
video
conferencing
too.
The
rfc
8179.
B
We
won't
be
using
blue
sheets
because
it's
automatically
taken
by
miteko.
I
would
like
the
mini
takers
actually,
if
they
could
just
put
the
number
of
total
participants
on
the
at
the
top
that'll
be
great.
It
keeps
changing
so
just
keep
an
eye
on
it,
so
that
we
remember
later
on.
The
note
well
also
applies,
which
kind
of
guide
the
way
the
itf
works,
but
also
kind
of,
like
general
behavior,
between
participants,
which
is
to
be
nice
and
so
on.
B
Yeah
I
mean,
please
have
a
look,
if
you
don't
know
it
already
so,
for
today
we
have
what
seems
like
a
very
packed
session,
but
actually
slots
are
rather
small
and
some
of
the
items
are
very
mature.
Some
of
the
drops
are
very
mature,
so
we
are
going
to
go
through
them
rather
quickly.
B
I
believe-
and
we
have
another
10
minute
slot
that
we
didn't
have
before
due
to
some
rescheduling,
so
we
will
have
flex
time
and
we'll
have
discussion
time,
but
we
will
try
to
keep
an
eye
on
the
time,
as
I
mentioned
before,
the
meet
echo
will
close
anyways
after
five
minutes.
So
it's
not
like
we
can
continue
like
all
the
times.
B
20
minutes
after
the
meeting
has
ended
right
so
well
the
agenda
for
today.
I
guess
you
don't
need
to
to
look
at
it
too
much
in
detail
the
one
on
friday.
Here
you
have
it
as
well,
mostly
qualcomm
and
ad
hoc
related
drafts
group
com.
Cluster
has
quite
a
few
there,
as
you
can
see,
and
we
will
also
have
whatever
spills
over
from
today,
which
I
hope
is
nothing
on
the
next
friday
too.
B
Now
some
time
for
agenda
version.
If
you
want
to
say
something
or
change,
some
of
the.
C
B
Okay,
so
without
further
ado,
I
can
just
go
into
the
intro
for
the
working
group.
So
oh
yeah,
sorry
practicalities.
Yes,
we
will
use
miteco,
no
need
to
to
write
your
name.
The
meeting
is
automatically
recorded
when
we
start
it.
If
you
want
to
say
something,
just
write
make
a
column
on
the
on
the
jabber
and
yeah,
and
and
do
we
really
have
relaying
questions?
If
everything
is
remote,
yeah
anyways,
I
guess
if
you
don't
have
a
microphone.
B
Somebody
can
speak
on
your
behalf,
but
I
guess
we
will
just
work
with
your
own
microphone
and
you
will
say
whatever
you
have
to
say
on
the
microphone
thing.
We
don't
you
do
queueing
today,
as
some
have
requested
that
we
will
just
simply
just
click
on
the
fourth
button
for
the
second
microphone
button
on
the
right
side
and
and
your
voice
will
be
relayed,
no
need
to
queue.
Just
try
not
to
interrupt
during
the
presentation
unless
it's
something
important
so
for
core.
B
B
Good
work
yeah,
I
mean
they
have
been
recently
published
and
I
believe
we
already
are
at
least
for
the
more
units
we
already
have
it
in
oma,
so
I
hope
others
start
adopting
them
too,
for
resource
directory
has
been
recently
sent
to
ise
it's
an
isg
evaluation
for
stateless.
I
believe
there
were
a
few
few
comments
left
from
benjamin
khaduk.
I
believe
and
eric
I
had
some
notes.
Maybe
I
should
check
them
sorry
for
that,
yes
from
eric
klein,
but
hopefully
once
those
are
clear.
The
draft
can
move
forward.
B
The
alpha
I
mean
clouds
will
need
to
send
another
draft
there.
Maybe
you
can
give
an
update
later
on
your
slot
as
well
and
same
thing
for
rd
for
christian
on
pause
working
group
last
call,
so
we
have
the
dev
urn,
which
is
pretty
much
done.
There
was
some
discussion
on
whether
the
draft
should
be
informational
or
standards
track.
B
I
believe
barry
settled
it
and
provided
some
comments.
Also,
so
new
draft
is
needed
and
then
yeah
echo
request.
App
is
one
of
the
write-ups
that
marco
will
have
to
be
doing
same
thing
with
daveyorn.
Actually,
another
shepherd
writer
will
be
required
after
the
new
ide
is
sent
and
the
new
draft
is
sent
and
then
for
oscar
groupcom.
We
also
have
working
on
glass
comments
to
process
from
last
week
and
and
also
very
important.
We
have
the
call
my
cluster
on
working
with
glass
call
which
ends
this
week.
B
Hopefully
we
can
discuss
them
in
the
next
friday
meeting.
So
if
you
have
some
anything
left
on
on
your
on
your
mind
and
if
you
haven't
checked
the
latest
versions
now
it's
really
the
the
best
time
to
do
that.
Please
all
right!
So
that's
the
update.
We
are
still
on
time
and
I
will
switch
to
christian.
Please
go
ahead.
C
Yeah,
thank
you.
I'm
on
echo,
request,
tag
and
token
processing
next
slide,
please
and
actually
two
next,
because
that's
just
the
intro
slide,
so
this
hasn't
been
presented
at
the
full
itf
meeting
for
about
a
year
but
has
gone
through
a
number
of
steps
which
I
would
just
run
through
quickly.
So
this
has
passed
a
working
group
last
call.
C
We
got
a
number
of
feet.
Feedback
points
in
that
and
also
in
the
post
working
group
last
call
reviews
that
we've
received
one
of
them
was
that
the
amplification
mitigation
should
have
been
should
receive
more
more
details,
so
now
a
we're
giving
numbers
for
that
based
on
the
numbers
that
are
that
are
in
quick.
C
That
is
don't
send
more
than
three
times
what
has
been
sent
to
you,
which
in
practice
means
that
you
get
about
150
octets
in
the
request
payload-
and
this
is
now
also
update,
like
the
the
token
processing-
is
also
updating
rc7252,
because
it's
basically
the
most
the
only
practical
way
that
is
currently
known
to
do
amplification
mitigation
in
in
co-op
other
than
sending
tiny
block
sizes.
There
were
two
small
changes
on
the
echo
side.
That
is,
we
now
do
allow
shorter
values,
but
still
recommend
I
mean
previously.
C
Klaus
made
a
very
important
point
about
the
architectural
compatibility
with
rest
holders
in
the
rest
architecture
in
general,
so
now
it
may
be
processed
by
proxies,
as
we
already
allowed
it
for
for
cross
proxies.
So
previously
we
said
that
co-op
products
must
just
forward
it
now
they
may
interpret
it,
but
they
still
can't
deteriorate
the
freshness
properties.
So
they
will
usually
not
want
to
do
this
unless
they
have
anything
to
to
add
there.
C
C
My
previous
assumption
was
that
this
could
be
just
tag
attack
it
on
there
and
things
work
it
doesn't,
but
we
don't
really
want
to
do
all
the
kind
of
all
the
detail
work
of
how
of
when
and
where
it
can
be
applied
in
this
document.
So
it's
now
just
a
pointer
to
this
cancel
particular
some
of
those
problems,
but
not
all
of
them.
C
The
document
got
restricted
a
bit
in
that
it's
now
having
dedicated
introduction
sections
to
the
various
parts,
got
added
privacy
and
security
considerations,
especially
mitigating
the
issue
that
someone
might
abuse
a
request.
An
echo
option
like
cookies
and
now
the
client
may
forget
them
at
any
point
in
time.
So
that's
not
too
much
of
an
issue
anymore,
and
now
we
even
have
concrete
numbers
to
suggest
to
ayana.
C
Then
I'd
like
to
jump
to
the
basically
three
three
slides
back,
which
is
the
update
on
the
resource
directory.
C
So
that
that,
as
well
is,
is
actually
past.
The
working
group
next
slide.
Please,
there
is
one
change
that
looks
much
larger
than
we
have
you
than
we
usually
have
at
this
stage.
That
is
the
section
on
security
policies
previously
that
had
pretty
detailed
guides
on
what
exactly
is
protected
in
the
resource
directory
and
turned
out.
C
We,
my
impression,
is
that
we
let
ourselves
just
be
be
pushed
by
the
by
the
review
process
and
just
added
considerations
there,
rather
than
taking
a
step
back
and
say:
okay,
what
can
be
protected
and
turned
out
this
changes
depending
on
how
you
use
a
resource
directory
so
where
we
previously
had?
How
is
this
protected
now?
It
says
what
can
be
protected
and
rather
than
having
hard
rules
with
details
that
we
might
get
wrong
and
did
have
did
get
wrong.
C
We
could
have
fixed
those
details,
but
the
interims
showed
that
this
is
not
really
the
direction
where
we
want
this
document.
So
this
is
now
generalized
and
as
a
recent
mail
russ,
who
did,
the
jannah
review
seems
to
be
very
happy
with
those
changes
with
minor
details.
C
Also,
during
those
reviews,
it
turns
out
that
there's
a
few
points
where
we
should
really
use
echo
in
there,
for
example,
for
amplification
mitigation
and
to
protect
clients
that
are
not
actually
trying
to
register,
and
those
are
now
in
there
and
depending
on
the
sequence
in
which
those
documents
will
hit.
The
rc
editor
will
be
a
non-normative
forward
reference
or
a
more
formal
reference
to
what
it
already
is
part
of
an
updated
co-op
process.
B
Okay,
so
we
we
have
had
for
those
who
are
not
aware
we
have
a
few
interims
among
when
some
of
them
had
to
do
with
authorization
and
rd
and
the
use
of
rd,
but
we
didn't
really
came
with
anything
that
could
be
applied
to
resource
directory
as
it
is
today.
So
I
guess
we
will
just
continue
with
the
the
current
state
and
address
the
few
isg
comments
left.
If
there
were
any
and
just
get
get
it
done
and
ship
it.
C
Yeah
so
there's
there's
some
ongoing
exploration
on
on
how
authorization
which
authorization
models
make
sense
for
resource
directory,
but
that's
really
out
of
scope
for
the
for
the
original
specification.
So
I
think
this
can
be
done
in
in
things
like
how
to
use
aif
with
resource
directory.
B
B
E
Okay,
so
problem
details,
of
course,
this
is
not
details
of
problems,
but
a
draft
that
is
intended
to
provide
a
payload
format
for
errors
in
core
based
apis
next
slide.
E
We
have
before
this
idf
meeting
submitted
dash,
one
which
is
a
rebuilding
of
the
original
dash
0-0
from
the
ground.
Up
this
time
we
have
focused
on
expressing
these
problem
details
and
error
details
exclusively
using
coral
and
zero
zero.
This
was
just
an
exploration
and
the
appendix
and
based
on
the
feedback
that
us
also
authors
have
received.
E
We
have
now
made
this
the
the
only
on
primary
way
to
express
these
problem
details,
and
there
are
a
few
open
things
that
we
want
to
fix,
but
didn't
have
time
to
do
before
the
itf
meeting.
So
this
zero
one
version
includes
just
the
content
where
we
were
very
sure
how
we
would
do
it,
and
we
have
a
github
repository
with
a
bunch
of
issues
and
those
issues
we
want
to
work
on
in
the
following
draft
revisions
and
that's
not
included
in
in
this
current
zero
one.
E
But
the
idea
is
that
we
have
basically
a
core
functionality
that
allows
people
to
use
this
payload
format
to
describe
the
errors.
And
then
we
have
a
bunch
of
extensions
in
mind
for
different
use.
Cases
that
are
optional
to
use
next
slide.
E
Okay,
I
was
getting
ahead
of
myself,
so,
yes,
we
have
this
base
or
core
set
of
fields.
E
That
includes,
for
example,
an
error,
type
description
and
a
human
readable
error
description,
and
then
we
are
planning
to
have
these
extensions
for
a
number
of
use
cases,
and
that
includes
tracing
forwarding
errors
that
were
received
from
third
parties
and
so
on.
E
As
I
said,
we
have
this
github
repository
with
the
open
issues
and
if
anyone
has
a
new
use
case,
please
feel
free
to
open
a
new
issue
or,
if
you're
interested
in
working
on
one
of
these
existing
use
cases.
Please
chime
in
in
the
github
repository
next
slide.
E
We
have
one
big
topic
that
we
have
been
around
a
bit
and
it
might
be
a
bit
an
elephant
in
the
room,
and
that
is
how
do
we
generate
identifiers
for
our
problem
types
and
for
our
extensions
and
of
course,
coral
has
a
way
to
define
new
vocabulary,
and
that
includes
the
use
of
your
eyes
as
identifiers
as
it's
common
practice
and
the
semantic
web
and
json
led
and
similar
technologies
and,
at
the
same
time,
the
zero
zero
version
of
the
problem.
E
We
want
to
make
these
problem
details
available
to
constraint
devices
and
we
don't
want
to
bloat
the
payload
with
a
large
identifiers,
so
these
uris
are
actually
two
variables
and
we
need
something
more
compact
and
we
also
have
other
requirements
like
low
barrier
to
entry.
People
should
not
be
required
to
register
any
application.
Specific
error
type,
for
example
in
an
ayanna
registry
for
protocol
elements.
It's
perfectly
valid
and
simple
for
for
rfc
writers
to
register
new
interest
in
iana
registries,
but
for
average
application
developers.
E
E
So
we
started
looking
already,
for
example,
last
time
in
singapore
at
the
last
physical
itf
meeting
and
two
approaches,
and
so
we
looked
into,
for
example,
the
sits
of
goreconf
that
have
been
developed
in
the
co-working
group.
But
of
course,
naming
things
in
a
distributed
way
is
one
of
these
two
heart
problems
of
computer
science.
E
So
there
are
tons
of
solutions,
each
designed
for
different
use
cases
ranging
from
centralized
registries
like
ayana
registries
or
bluetooth
registries,
to
hierarchical
schemes
like
isbn
numbers
and
and
so
on,
and
then,
of
course,
we
have
the
huge
ecosystem
of
different
software
packages
like
and
go
or
javascript
and
dotnet,
and
so
on,
where
they
all
had
to
solve
the
problem
of
globally
unique
identifiers
for
applications
and
application
elements.
E
A
So
one
of
the
the
new
ideas
that
is
being
tested
right
now
is
to
couple
iana
registration
with
a
github
repository,
so
you
can
just
do
a
pull
request
to
the
repository
and
you
get
registered.
E
Yeah,
that
is
definitely
something
that
we
have
on
our
radar.
We
are
thinking
that,
maybe
even
that
might
be
too
much
to
ask
if
we
set
errors
and
co-op
apis,
roughly
equal
to
exceptions
in
say
java
or
python,
and
you
would
ask
developers
to
register
every
exception,
type
or
error
type
or
class
in
a
java
program
with
registry,
even
through
github
repository.
C
Question
I
think
there
should
be
some
some
kind
of
hierarchical
part
in
this.
So
what
so?
Maybe
I
think
we
can
ask
developers
of
a
particular
piece
of
software
to
register
something
somewhere
if
it's
as
easy
as
a
pull
request,
but
then
they
should
get
some
kind
of
name
spacing
below
there.
So
just
just
out
of
the
blue.
C
E
F
B
Then
we
move
to
the
next,
which
is
the
link
bill.
Are
you
there.
G
B
H
Yeah,
it
should
be
fine
thanks.
Thank
you
all
right,
hello,
everybody!
So
yeah
we
have
a
very
short
update
on
what's
happening
with
dyn
link.
H
So
then
link
is
right
now
at
version
11.,
could
you
put
it
to
the
next
slide?
Please
right.
So
there
has
been
substantial
changes
in
in
downlink
going
forward
from
the
previous
version,
so
most
of
it
had
to
do
with
restructuring
and
organizing
the
the
the
the
different
aspects
that
indic
was
trying
to
promote
and
from
version
08
to
up
to
version
010
version
10.
H
We
have
actually
restructured
it
so
that
we
introduced
the
observe
attributes
first
and
then
the
dynamic
links
and
then
the
binding
table
implementation.
And
then
we
have
been
able
to
incorporate
all
the
feedback
received
and
and
the
clarifications
for
those
then
next
slide.
Please,
yes,
so
from
version
10
to
version
11,
there
hasn't
been
very
many
changes.
However,
a
small
group
of
people
have
been
meeting
for
the
last
two
times.
Some
of
them
are
here,
there
has
been
carson
has
been
there.
H
The
court
chairs
have
been
there-
klaus,
christian
and
michael
and
as
well
as
ellen
ellen
soloway
from
from
qualcomm,
and
we
have
been
discussing
various
various
things.
So
I
I
kind
of
just
wanted
to
crystallize
a
few
of
these
things
and
and
and
tell
you
what's
happening
in
dangling
moving
forward
and
and
basically
there
are,
there
are
just
three
different
updates.
H
The
first
one,
which
is
an
editorial
change,
that's
gonna
happen,
is
due
to
the
fact
that
in
the
current
draft,
a
lot
of
the
of
a
lot
of
the
observed
notifications,
the
the
language
that
is
being
used
gives
impression
that
we're
reporting
values
and
and
we're
doing
a
lot
of
message,
transfers
and
so
on,
and
there
was
a
feedback
that
we
should
probably
be
looking
at
this
more
in
terms
of
restful
straight
state
transfers,
so
that
that
that
literally
affects
all
the
the
observe.
H
The
observed
attributes
that
that
we
are
defining
and
and
so
the
there's
going
to
be
a
substantial
editorial
change,
just
to
alter
that
language
and-
and
hopefully
that
brings
in
line
with
the
with
the
restful
state
transfers.
H
H
If
we,
if
you're,
considering
a
simple
client
server
interaction
between
a
co-op
server
and
a
client,
that's
not
too
bad,
but
when
you
start
introducing
proxies
in
between,
then
the
behavior
of
pmax
may
not
necessarily
be
reflected
to
what
the
the
client
really
wants,
because
there
might
be
a
chance
that
that,
because
the
values
don't
really
change,
the
the
proxies
do
not
really
give
the
give
the
the
current
value.
H
I
do
not
know
if
you
have
actually
reached
a
consensus
on
how
proceed
forward
with
this.
We
have
had
a
discussion
about
whether
we
can
actually
let
pmax
influence
the
server's
max
age,
so
that
whenever
you
actually
have
the
data
being
expired,
then
then
the
the
origin
server
will
send
a
new,
a
new
notification.
H
And
the
final
thing
that
is
happening
right
now
has
been
a
proposal
from
allen
from
oma
to
support
two
new
attributes
that
are
actually
already
specified
in
the
library
and
2m
specifications
right
now
called
ep
min
and
epmax
and
ome
is
using
these
two
attributes
for
reporting
and
basically
to
do
device
configuration
in
order
to
do
sampling,
so
ep
min,
which
is
minimum
evaluation
period,
is
used
so
that
after
the
expiry
of
ep
epwin,
the
device
may
immediately
perform
an
evaluation
and
then
to
get
to
get
the
value.
H
And
then
epmax
is
the
converse
so
and
if
both
of
them
are
defined,
then
then
ep
min
must
be
less
than
epmax.
So
if
you
want
to
follow
the
discussion
about
whether
this
should
be
inside
dynlink
or
not,
that's
there's
a
link
there
in
the
in
the
in
the
slide.
You
can
just
click
on
it
and
it'll
bring
you
right
there
to
the
dangling
issues.
H
I
don't
know
if
ellen
is
here
or
if
michael
is
here
today.
I
saw
them
earlier
in
the
asdf
meeting,
but
I'm
not
sure
if
they're
here,
but
I
thought
this
would
be
a
good
time
to
solicit
some
feedback
from
anybody.
If
you
actually
have
some
comments
from
the
working
group,
whether
epm
and
evmax
should
be
inside
the
dandling.
H
Yes,
there
actually
are
ipr
disclosures.
I
think
they
have
been
declared
online
link
by
by
qualcomm.
So
that's
that's
one
factor.
Yes,.
H
Let
me
check
quickly,
I
think
I
think
it
was.
I
noticed
it
after
after
ellen
raised
the
issue
on
the
mailing
list,
but
of
course
the
the
current
draft
itself
does
not
contain
ep
mini
max,
so
it
has
not
been
put
into
the
dongle
yet
so
the
ipr
is
is
is
raised
against
the
current
draft,
which
doesn't
have
ep
and
up
max.
A
Right
because
I
think
that
that
having
some
some
ipr
declaration
against
this
document
would
reduce
its
usefulness
considerably.
G
B
Yeah
exactly
I
was
just
going
to
comment
on
that.
Maybe
we
don't
want
to
discuss
ipr
issues
as
such
and
in
fact
I
I
think
the
discussion
on
on
the
functioning
of
pmax
and
then
the
way
it
is
intended
is
actually
more
interesting,
because
it's
about
whether
we
want
co-op
to
be
about
transferring
the
state
or
about
message
passing
and
the
discussion
happened
on
the
other
meetings,
but
it
didn't
happen
in
core,
so
I
was
just
I
mean
I
thought
it
would
be
nice
to
onboard
everybody
else
on
the
topic.
H
Yeah
yeah,
so
I
just
want
to
respond
to
what
jaime
said.
Sorry-
sorry,
sorry
barry
already
so
in.
In
fact,
we
can
actually
see
almost
almost
a
categorization
of
two
different
kinds
of
observer
attributes
right
now,
pmax
ep
min
and
epmx
appear
to
be
attributes
that
are
being
used
to
configure
the
device.
So
I
just
wanted
to
highlight
that
for
reporting.
B
I
So
our
here
solid
comment
that,
given
that
life
with
mlm
is
probably
the
biggest
user
of
the
dynamic
mechanism
that
we
know
of
today,
it
would
be
very
natural
to
have
those
capabilities
like
what
emblem
is
using
as
part
of
this
document.
I
think
that
would
make
a
lot
of
money.
B
J
Okay,
this
is
barry
libo,
the
just
clarification
on
discussing
the
ipr
issue
and
I'm
sure
carsten,
and
you
know
this.
I
want
to
make
sure
everybody
understands
it's
not
appropriate
to
discuss
the
ipr
itself
and
whether
it's
valid
or
applies
or
whatever,
but
it
is
absolutely
reasonable
for
the
working
group
to
discuss
in
any
context
whether
whether
ipr,
on
a
particular
document
affects
the
progress
of
that
document
in
the
working
group.
So
I
just
want
to
make
sure
that
everybody
understands
that.
B
Thank
you
very
that's
a
very
good
clarification,
I
think.
Actually,
for
the
I
mean
as
far
as
discussion
goes,
I
would
like
to
split
the
two
topics,
because
it's
completely
different
the
one
on
the
pmax
and
pimin
from
the
ep
max
and
epimin.
If
we
could
just
maybe
for
for
this
session
right
now,
focus
on
the
p
max
and
p
mean
rather
than
the
other
one.
Would
that
be
okay?
If
people
have
comments
on
this
and
if
they
understand
the
problem
and
the
implications.
C
Just
go
ahead.
Christian
I'd
just
like
to
point
out
that
I
as
a
kind
of
third
issue,
I
do
have
some
concerns
about
the
structure
of
the
binding
site,
which
is
not
something
that
changed
in
the
recent
versions.
That's
still
yet
to
be
addressed,
and
I
think
I.
C
H
Yes,
so
just
to
respond
to
christian.
Yes,
that's
exactly
right,
so
there
is
there's
the
other
part
of
of
diet
link
which
is
basically
outside
the
observer
attributes
which
talks
about
the
binding
table
and
and
the
link
bindings.
Indeed,
yes,.
H
And
one
more
okay,
thanks
yeah,
so
that's
just
just
to
get
back
to
the
track.
H
So
I
can
you
know
we
can
go
to
the
the
discussion
part
so
so
so
right
now
we're
in
drive,
11
and
drop
12
will
will
reflect
those
editorial
changes
to
to
understand
that
we
are
going
to
be
discussing
the
the
notification
via
reflecting
the
state
transfers
and
after
that
we
are
going
to
be
able
to
address
the
other
things
which
has
basically
what
pmax
and
whether
the
ep
mean
and
epm
actually
incorporate
or
not.
H
Also,
we
plan
to
continue
discussions
in
small.
You
know
it
was
kind
of
like
using
jitsi
after
ietf108,
so
we
have
not
been
very
forthcoming
yet
to
to
to
advertise
that.
But
but
please
let
us
know
if
you
would
like
to
receive
an
invitation
and-
and
we
can,
you
can
join
us.
Also
for
that.
B
H
B
Yeah
I
mean
regarding
invitations,
I'm
just
thinking
that,
at
the
end
of
the
day,
the
authors
can
choose
how
they
want
to
work
right
like
they
can
limit
the
audience
or
not.
But
if,
if
it
is
about
having
higher
attendance
or
or
just
inviting
everybody
that
may
want
to
join,
if
there's
no
problem
to
the
progress
of
the
draft,
I
think
we
can
just
send
the
gta
invitations.
Also
on
the
mailing
list,
and
you
know
people
can
choose
to
join
or
not,
and
then
we
will
also
have
after
the
the
summer.
B
Okay,
all
right!
Thank
you.
Thank
you
bill.
Thank
you
very
much.
So
next
is
the
cinema
cluster
just
to
check
quickly.
How
are
we
on
time,
marco
one
minute
behind
all
right,
fair
enough,
so
we
still
have
the
remember.
We
have
the
15
minutes
flex
time.
So,
let's
go
with
this.
I
think
it's
carsten
right
carson
go
ahead.
A
Yeah,
so
I
think
we
we
have
talked
about
cinema
versions
before,
but
just
to
refresh,
I
put
in
six
slides
that
that
we
will
run
through
very
quickly,
so
next
slide
defines
a
version
number
that
is
currently
version,
10
or
1.0.
A
Depending
on
how
you
read
it,
it's
an
integer
and
cinema
doesn't
really
define
how
we
are
going
to
handle
this
version
number
just
says:
if
the
version
number
is
increased,
we
are
doing
an
rfc
updating
the
existing
cinema
rfc
next
slide
and
the
the
objective
of
course,
is
to
get
extensibility.
A
The
the
centimeter
and
a
version
number
is,
is
a
unidirectional
declaration,
so
the
the
originator
of
the
cinema
says
a
particular
set
of
features
is
needed
to
process
this
cinema
pack
and
the
version
numbers
have
a
total
order,
so
usually
a
version
of
n
plus
on
n
plus
one
includes
all
features
of
version
number
in,
except,
of
course,
for
features
that
are
deprecated,
but
once
you
deprecate
features,
you
get
problems
with
integrating
packs
from
from
different
versions
next
slide.
A
So
essentially,
the
the
general
principle
here
is
version.
Numbers
are
not
always
the
best
way
to
to
handle
a
situation.
We
have
had
that
discussion
in
a
lot
of
contexts
now
and
there
are
different
applications
for
version
numbers.
Some
of
them
are
revision
numbers.
Some
of
them
are
actually
rolled
up
features,
and
so
I
don't
want
to
repeat
this
discussion.
A
We
have
a
way
to
declare
individual
features
using
must
understand
fields,
so
that
is
already
there.
So
people
who
don't
want
to
use
version
numbers
can
use
that,
but
on
the
other
hand,
of
course,
when
you
have
to
have
half
a
dozen
of
these
must
understand
fields
at
the
beginning
of
a
pack
that
becomes
less
useful
as
a
compact
representation
of
some
sensor
measurement
next
slide,
please.
A
A
A
Handling
version
numbers
in
in
cinema
now
the
the
feature
code
or
the
version
numbers
in
json
are
limited
to
be
53
bit
integers.
If,
if
we
consider
a
version
number
zero
to
four
excuse
me
feature
between
zero
to
four
taken,
we
would
have
48
bits
remaining
next
slide.
A
Yeah,
so
I
just
said
53.,
I
think
some
of
us
still
remember
that
there's
that
was
an
evil
number,
but
maybe
the
the
53
or
the
48
left
is
really
all
we
need,
because
we
still
have
the
must
understand
for
for
for
stuff.
That
is
not
used
widely.
A
We
can
really
limit
the
way
these
bits
get
allocated.
So
if
we
do
not
allocate
more
than
10
of
the
remaining
set
per
year,
then
we
we
have
quite
some
time
before
we
have
to
think
about
something
a
new.
Maybe
we
don't
even
need
10
of
the
remaining
set
per
year
next
slide.
A
So
this
this
is
the
background
and
0
0
itf
0
0
defines
this
feature.
System
creates
a
registry
under
the
cinema
registry
for
the
features
reserves
a
feature
called
023
and
makes
the
whole
thing
specification
required
with
the
frugality
mender
to
the
designated
expert.
So
it
spells
out
what
the
expert
should
check.
So
we
don't
give
away
all
these
48
code
points
in
the
next
week
and
finally,
it
registers
feature
code
4
for
the
use
of
secondary
units,
so
this
is
now
a
working
group
draft.
It
has
the
adoption
call
behind
it.
A
A
A
So
I
think
this
is
ready
for
when
you
blast
call,
maybe
you
want
to
get
one
or
two
reviews
so
so
we
can
iron
out
some
of
the
nits
there,
and
then
we
should
process
these
reviews
check
if
we
are
done
and
do
a
working
plus
call.
A
A
Okay,
that
that
was
celebrated
versions,
any
other.
B
Comments
on
this,
thank
you
carson.
I
also
I
actually
read
the
draft
and
I
think
it's
quite
mature
and
quite
clear.
I
mean
it's
not
that
complex.
My
only
two
thoughts,
maybe
on
the
deprecation
side,
do
you
do
the
authors
have
an
opinion
on?
How
often
will
it
happen
that
some
features
are
deprecated.
B
True,
all
right,
no
crystal
ball.
There,
then
I'm
just
wondering
like
about
the
implications.
If
start,
if
some
features
are
being
deprecated
but
yeah,
it's
not
a
big
thing.
B
Yep-
and
I
think
the
other
one
I
mean,
we
can
also
check
whether
the
expert
can
actually
do
this
kind
of
allocation
mechanism
like
to
make
sure
that
no
more
than
10
per
year,
I
don't
expect.
To
be
honest,
I
don't
think
a
lot
of
features
will
pop
up
every
year.
B
Who
knows
okay,
so
I'm
totally
fine
with
working
with
glass
call
for
this
document.
I
don't
know
if
others
have
more
comments,
but
of
course
we
yeah.
We
need
few
more
reviews.
We
can
take
it
to
the
list,
if
no
one
volunteers,
of
course
the
chairs
can
also
do
some
other
reviews,
as
working
group
participants
in
order
to
help
move.
B
I
can.
I
can
do
a
review,
no
problem.
I
think
I
might
also
be
the
shepherd
on
this
one.
I
don't
remember
right
now,
but
since
I'm
familiar
with
more
units,
that
would
be
fine
for
me
to
do
good,
so
mini
takers.
Please
take
notes
of
bill
and
me
as
potential
reviewers
for
the
draft
for
for
the
draft
and
that
we
would
like
to
do
working
with
lascal.
After
that
happens,.
A
Aria
is
asleep
okay,
so
I
will
do
it.
Data
video
content
found
indication
next
slide
is
essentially
about
the
the
fact
that
we
can
have
binary
data
in
a
cinema,
a
record,
and
sometimes
it's
not
so
useful-
to
have
binary
data
without
knowing
what
it
means.
So
the
idea
is
to
have
a
content,
format,
indication
or
cg
field
to
indicate
the
content
format
of
the
data
in
the
cinema
record
next
slide.
A
So
the
person
who
sees
the
arrow
on
this
slide
gets
a
beer
from
me,
and
so
we
we
know
how
to
interpret
this
base64
encoded
field
in
in
this
case,
as
sibo
next
slide.
A
So
the
the
last
update,
the
the
dash
r2
version
is
different
from
dasher
one,
in
that
we
essentially
remove
the
city
underscore
version
that
would
have
been
a
must
understand
version
of
the
same
field,
but
it
turns
out
that
we
don't
really
have
good
answers
for
that's
an
old
slide.
Anyway,
we
don't
really
have
good
answers
for
the
integration
in
the
resolution
process
between
two
versions
of
a
field.
One
is
must
understand,
and
the
other
is
not
must
understand,
because
the
base
versions
start
to
fight
against
each
other.
A
A
So
unless
anybody
thinks
this
is
really
important
to
have
a
must
understand
version
of
of
the
quantum
format
field.
The
authors
believe
this
is
now
ready
for
working.
A
C
Somebody
says
something:
sorry,
good
riddance.
Thank
you.
B
So
how
about
reviews
do
we
have
any
any
volunteers?
Do
we
need
them
for
this
draft,
just
like
with
the
versions.
A
B
Okay,
then,
let's
issue
a
working
class
call
already,
and
let's
do
the
usual
couple
of
weeks.
If
that's
okay,
unless
there
is
emergency,
no,
I
guess
all
right.
So
let's
do
that.
B
B
B
So
next
on
the
agenda,
we
have
the
blockwise
for
the
dots
working
group.
This
has
been
ongoing
on
the
interims
and
we
have
been
maybe
postponing
the
adoption
of
this
document
and
hopefully
we
will
get
adopted
on
on
this
idf
and
I
just
for
the
benefit
of
the
group.
I
would
like
the
presentation
to
happen
all
right.
Thank
you,
jim,
for
a
comment
then
so
john.
Whenever
you
want
the
floor,
is
yours.
There
is
no
video,
I
assume
or.
L
L
L
Okay,
so
this
the
the
dots
which
is
distributed
service
open
threat,
signaling,
creates
a
challenge
in
environments
where
there
are
distributed
denial
of
service
attacks,
and
we
need
to
maintain
communications
between
different
components
so
that
we
can
try
and
mitigate
those
ddos
attacks.
So
next
slide,
please.
L
Okay,
so
we're
talking
about
large
body
packets,
large
body
being
transferred
in
multiple
packets,
and
that
gives
us
headaches
in
lossy
environments,
and
so
we've
come
up
with
an
alternative
to
block
one
and
block
two,
which
is
the
block
three
in
block
four
similar
semantics,
but
some
additional
sort
of
changes
in
there.
So
next
slide.
Please.
L
Is
a
sort
of
simple
graphic
of
the
environment?
You
have
some
clients
sitting
in
some
enterprise
somewhere,
you
have
some
mitigation
services
out
in
the
cloud
and
we
need
to
be
able
to
request
mitigation
from
the
enterprise
type
client.
But
the
part
of
the
challenge
is
that
the
pipe
or
the
connection
out
to
the
internet
is
being
overloaded
with
traffic
coming
inbound.
L
So
there
is
packet
loss,
but
once
we
can
get
mitigation
requests
out,
we
then
should
be
able
to
just
control
what's
happening
with
the
pipe,
so
we
can
at
least
get
back
to
some
reasonable
communications
that's
taking
place
and
we
have
an
rfc
out
there
for
dealing
with
the
actual
dots
communication
to
the
dots
protocols.
L
L
We
cannot
rely
on
getting
responses,
so
we
send
a
request
out.
We
cannot
guarantee
that
we're
going
to
get
a
response
back
because
of
the
pipe
overloading
and
at
that
point,
the
request
response
model
just
basically
lock.
L
Stepping
fails
we're
also
interested
in
being
able
to
do
fast
transfers
for
large
bodies
so
that
we
just
don't
hang
around
for
the
round-trip
times,
and
we
also
because
of
that
we're
looking
for
some
packet
interchange
reduction,
design
goal
is
that
we
use
utilize
other
co-op
options
wherever
possible
and
that
we
kind
of
maintain
the
existing
co-op
ethos
of
how
things
are
done.
So
we
don't
want
to
break
the
co-op
model
at
what
at
all,
but
we
just
want
to
be
able
to
streamline
things
that
are
taking
place
next
slide.
L
So
the
solution
is
we
come
up
with
block
3,
which
is
very
similar
to
block
one,
but
some
usage
examples.
Likewise
block
c
block
four
and
there
we
just
got
the
things
hitting
on
there
and
we
expect
it
to
be.
It's
called
classy
in
class.
U
just
to
be
within
the
encrypted
or
without
encrypted.
As
things
stand
there
next
slide.
Please.
L
So
the
block
three,
the
intentional
idea-
is
that
the
block
three
can
send
out
the
packets
without
expecting
a
response
until
we
get
to
the
end
of
the
data.
That's
been
pushed
out.
So
therefore
things
like
the
231
continue.
L
We
no
longer
acquire
and
we're
only
really
looking
for
a
single
response
at
the
end
of
the
transmission
of
the
set
of
blocks
that
make
up
the
body,
use
of
none
is
recommended
because
we're
not
looking
for
the
act
coming
back,
but,
alternatively,
if
people
want
to,
they
can
increase
end
start
so
that
multiple
packets
can
be
in
the
pipeline
of
confirmable
type.
L
We
need
to
make
use
of
the
request
tag,
co-op
options
so
that
we
can
make
sure
that
this
is
this
set
of
block
of
this
body
that's
being
sent
and
if,
for
any
reason,
we
then
move
on
and
send
another
body
of
data
to
the
same
resource.
We
know
this
server
is
able
to
differentiate
between
what's
taking
place.
So
we
need
to
make
use
of
the
request
tag
that
has
been
brought
up
earlier
at
this
meeting.
L
Each
request
payload
has
to
have
a
unique
token
again,
just
maintaining
the
token
type
stuff
for
request
response
and
we've
come
up
with
a
new
missing
payloads
response,
which
indicates
these
particular
packets
have
been
missed,
so
the
server
says
I
have
seen
packets
one
three,
nine,
I'm
missing
the
rest,
that
kind
of
stuff
we're
also
very
concerned
about
creating
our
own
ddos
problems
by
what
we're
doing
here.
So
we
have
congestion
control
in
place.
So
we
said
every
max
payload,
which
is
a
default
of
10..
L
We
just
pause
and
check
that
everything
is
still
working
right
before
we
send
the
next
burst
of
10
packets
in
the
single
direction,
and
each
body
is
subject
to
the
our
7252
probing
rate
again,
just
congestion
control
next
slide,
please
so
the
actual
missing
payloads
cbo
encoded
the
content
format
we're
coming
up
with
a
new
content
format,
and
we
have
the
descriptive
language
down
there
below
which
basically
is
what
is
the
request
tag
and
what
are
the
missing
block
list
next
slide?
L
Please
so
an
example
block
3
example:
here
we
can
just
see
the
first.
Basically,
five
lines
is
a
put
request.
The
four
blocks
go
out
and
then
there's
an
acknowledgement,
saying
yep
I
got
them
or
in
the
failure
case,
all
four
put
out
and
then
there's
a
response
saying.
Well,
I'm
missing
a
couple,
so
those
two
are
retried
and
then
one
still
fails
and
then
we
try
and
then
the
actual
transfer
is
complete.
L
If
you
issue
the
get
or
fetch
with
block
four
and
that
will
trigger
block
four
response,
as
opposed
to
a
block
two,
if
the
size
of
data
being
returned
is
sufficiently
large
and
missing
blocks
indicated
by
gate
with
multiple
block
the
client
realizes
that
he's
seen
a
couple
well,
he
hasn't.
F
L
A
couple
of
blocks:
he
can
then
just
issue
a
gate
request
with
those
multiple
missing
blocks
again
recommended
none,
but
we
could
increase
nstar,
and
here
we
make
use
of
the
existing
etag
option,
unique
body
to
make
sure
that
we're
getting
the
right
data
back
to
the
right
stuff
and.
L
L
Four
we
get
the
four
packets
or
whatever,
how
many
packets
come
back
and
then
somewhere
down
stream
and
the
observer
is
triggered
and
we
get
the
form
packets
coming
back
with
the
appropriate,
observed
tag,
updated
and
using
etag,
etc.
L
So
here
we
have
an
observed,
triggered,
but
we're
missing
several
of
the
packets
coming
back
at
the
client
end,
and
so
the
client
wakes
up
realizes
he
issues
a
request
for
the
missing
blocks.
In
this
case,
we
just
get
one
of
the
two
blocks
back.
He
realizes
still
one
outstanding
he
requested
and
then
everything
is
complete.
L
L
Yeah,
so
this
particular
draft
has
been
discussed
at
two
intimate
meetings
out
of
that
we've
taken
on
board.
A
lot
of
comments
worked
things
through
adjusted
things
slightly
simplified.
Essentially
the
design
that's
taking
place
and
try
to
make
you
know
bring
things
in
line
with
everything.
That's
taking
place
there,
and
so
yes,
final
request
is:
can
we
move
forward
and
adopt
this
as
a
working
group
document?
C
Yeah
first,
first
of
all,
apologies
for
not
having
sent
the
review
that
I've
promised
earlier.
One
thing
that
I'm
primarily
missing
in
about
this
is
a
clarification
on
where
this
wants
to
go
in
terms
of
either
being
a
generic
successor
to
block-wise.
C
That
addresses
the
the
issues
that
that
you
need,
or
whether
it's
supposed
to
be
a
bespoke
solution
to
the
particular
problem
of
block-wise,
not
being
able
to
do
everything
that
you
need
in
in
in
this
particular
situation,
because
there's
a
bunch
of
if,
if
it's
supposed
to
be
the
generic
solution,
there's
a
bunch
of
things
that
would
come
up.
Like
this
hand,
this
doesn't
handle
non-atomic
block-wise
requests
at
all
which
the
original
block-wise
can.
C
So
I
think
some
clarification
on
that
point
would
be
the
would
be
a
start
would
be
a
good
good
starting
thing
for
a
next
step,
and
then
we
can
talk
about
things
like
proxy
reversal,
still
existing
layer,
mix-ups
and
mix
up
some
layering
violations
or
possible
ways
to
to
separate
things
better,
but
I
think
the
the
direction
another
paramount
question.
L
Okay,
the
direction
I
see
it
in
addition
to
the
block
one
and
block
two,
because
there
are
certain,
as
you
point
out,
there
are
certain
qualities
that
they
have,
which
are
not
there
in
block
three
block
floor,
but
it's
an
optional
set
of
options.
L
A
Okay,
so
I
queued
up
to
say
essentially
the
same
things
that
christian
said,
but
let
me
also
add.
I
think
this
is
a
good
solution.
Now,
of
course,
it
still
needs
a
few
knits
being
ironed
out,
but
we
can
do
this
while
it
is
a
working
group
document.
A
So
I
support
doing
the
the
adoption
call
now
and
then
I
support
the
adoption
of
this
document
and
I
think
what
we
need
to
work
on
as
a
as
a
working
group
is
making
sure
that
all
all
the
components
of
of
co-op
are
really
used
correctly.
A
Like
the
whole
token
thing,
and,
and
so
on,
this
draft
doesn't
really
have
to
say
very
much
about
tokens,
but
because
there
are
general
principles
that
guide
this,
but
I
think
it's
good
for
the
implementers
to
to
know
what
those
general
principles
result
in
and
the
other
thing
that
we
need
to
do,
as
christian
said,
is
work,
work
on
an
applicability
statement
and
explain
that
this
is
for
very
specific
environments
where
those
trade-offs
are
are
good
and
it's
not
necessarily
replacing
block
one
block
two
as
the
main
way
to
handle
bodies
that
are
larger
than
the
payload
size.
L
M
Yeah,
actually
yeah
is
that
we
we
do
already
have
a
first
version
of
the
an
applicability
statement
in
the
document
which
basically
say
that
this
is
not
a
generic.
I
would
say
a
solution
and
yeah
that
our
tag
is
in
a
very
specific
problem,
so
yeah.
So
this
is,
we
have
a
start.
There
start
text
if
and
if
the
worker
wants
to
modify
that
to
to
make
it
clear
that
there
is
no
confusion
with
the
mainstream
solution
yeah.
This
is
something
that
you
can
work
on
and
update
as
as
required.
B
Great,
thank
you
christian.
Do
you
have
any
other
comments
on
that
by
the
way?
Just
going
back
to
your
initial
question
not
directly,
I
might
have
missed
that
part
all
right,
so
I
think
for
all
of
all
of
us
who
participated
on
the
on
the
interims,
we
tend
to
support
the
adoption
of
the
document
I
would
really
like,
and
also
for
my
for
myself.
I
would
really
like
to
use
this
humming
tool
that
we
have.
B
B
Oh
sorry,
sorry,
sorry!
So
let's
do
a
quick
hum.
Just
for
those
who
are
not
familiar
is
the
tab
that
you
have
there.
Some
little
bars
next
to
the
comments.
So
next
to
the
discussion
and
you'll
you'll
be
a
humming
which
you
basically
is
in
italian,
so
fortissimo
means
that
you
really
are
humming
very
strongly
and
you
support
it.
Niente
is
that
you're
pretty
quiet
about
it?
So,
let's
just
start
the
hum
right
away.
B
B
Oh
yeah,
sorry
well,
he's
italian
also
he's
using
music,
so
only
sopranos
and
tenor
can
answer
so
all
right.
So
there
is
some
interest,
not
a
strong
hum,
but
still
a
positive
hum
and
I'm
sure
that
electron
drop
yeah.
So,
but
I
think
this
is
enough
to
adopt
it
as
a
working
group
document
with
the
cave
ads
that
mohamed
and
john
have
mentioned.
B
B
All
right,
so
I
think
we
will
do
the
adoption
then,
and
the
authors
will
have
to
send
a
new
version
yon
and
mohammed.
We
usually
work
with
github.
So
is
it
okay
to
work
that
way?
We
we
can
set
up
a
repo
for
you
on
our
core
working
group,
github
repo.
We
do
it
for
every
draft
these
days
and
basically
also
issues
a
track.
There
no
need
to
yeah
no
need
to
to
ask
for
permission,
just
go
ahead
and
talk.
M
Yes,
so
yeah
we
have,
we
have
already,
I
would
say,
a
version
on
the
on
the
github.
So
yes,
if
there
is
a
a
working
group
repository,
we
can
move
that
to
that
recruiter.
That's
for
for
sure,
yeah,
perfect.
B
B
A
B
Of
course
we
will,
I
mean
yes,
as
usual,
we
will
send
to
the
mainly
list
and
we'll
validate
it
there
for
those
who
haven't
participated.
I
also
thank
you,
mohamed
and
young
for
the
patience
I
just
really
wanted
to
have
it
in
the
work
in
the
group
as
well,
because
not
everybody's
attending
the
meetings,
the
interims
and
yeah.
Thank
you.
B
Yep
casting
are
you
sending
your
video
again,
it's
actually
again.
It
stopped
for
some
reason.
If
you
want.
A
There
you
go
okay,
so
af
next
slide
the
authorization
information
format
that
has
a
pretty
weird
draft
name.
It's
called
draft
bomb
and
core
ace
af
because
it
really
was
originally
meant
as
something
that
was
submitted
to
both
core
and
ace
and,
as
you
will
see,
that
has
been
picked
up
by
ace
now,
but
it's
maybe
also
interesting
for
the
co-working
group
what's
going
on
so
let's
quickly
talk
about
that
next
slide.
A
So
basically,
this
is
about
access,
control
or
authorization.
These
two
words
are
synonyms
and
in
information
security
this
is
usually
modeled
by
the
access
control
matrix,
which
was
introduced
by
lamson
in
and
that
is
a
function,
mapping
a
subject
and
an
object
to
a
set
of
permissions.
So
it's
a
nice
little
abstract
tool
that
says
which
permissions
does
a
subject
have
on
a
specific
object,
and
this
is
often
sliced
by
object
into
an
access
control
list.
So
on
the
object,
you
have
the
information
which
subjects
can
actually
do
what
on
this.
A
This
is
a
lot
like,
like
unix
permission,
bits
and
so
on,
but
what
this
draft
does
is
the
other
way
we
slice
by
subject
and
not
by
object.
So
we
have
a
capability
list
or
c
list,
as
it's
traditionally
called
that
maps
objects
to
sets
of
permissions.
A
The
the
formula
itself
doesn't
do
any
security.
It's
not
protecting
this
information,
so
the
protection
has
to
be
done
outside.
There
has
to
be
some
binding
to
a
secure
channel
or
some
subject:
authentication,
verifier
proof
of
procession
talking
and
so
on.
So
this
particular
draft
is
not
concerned
with
that.
This
is
concerned
with
the
actual
authorization
information
in
the
next
slide,
so
we
we
represent
the
c
list
in
the
the
simplest
natural
form,
which
is
an
array
of
pairs.
A
So
this
is
essentially
the
representation
of
a
function
we
could
have
used
a
map,
but
for
various
reasons
this
is
slightly
more
more
easy
to
use.
So,
looking
at
the
cddl
here,
the
generic
af,
depending
on
on
the
type
for
the
object,
identification
and
the
type
for
the
the
permission
set,
is
just
a
sequence
of
zero
or
more
such
pairs
and
this
generic
thing,
which
is
also
used
by
by
other
protocols
like
like
the
mqtt
profile
of
ace.
A
The
generic
thing
is
specialized
to
the
rest
situation
by
saying
the
object.
Identifiers
are
really
paths
uri,
your
eyes
that
are
or
ui
references
is
the
right
term
that
are
relative
to
the
enforcement
point
to
the
server
that
actually
enforces
these
authorizations,
and
the
permissions
is
just
a
number
that
serves
as
as
a
set
of
bits.
A
So
the
the
two
to
the
power
r
is
is
really
what
what
happens
there
and
the
the
actual
permissions
are
structured
by
corp
methods.
So
we
have
a
permission
with
forget
one
for
post
one
for
put
and
so
on
until
eyepatch.
A
That
may
be
a
bit
cause
for
some
applications,
but
in
many
cases
this
is
a
good
basic
way
of
doing
permissions
on
some
resources.
Next
slide.
A
So
one
problem
we
have
is
that
this
is
good
for,
for
describing
the
permissions
on
static
resources
that
were
known
at
the
time
the
authorization
information
format
document
was
created,
but
on
iot
database
devices
we
often
have
actions
that
lead
to
dynamic
action
resources,
so
these
are
essentially
post
results
that
are
pointed
to
by
a
set
of
location
response
options,
and
these,
of
course
happen
dynamically.
So
so
getting
a
permission
for
each
of
them
for
from
an
authorization
manager
would
be
very
tedious.
A
So
the
idea
is
to
derive
these
permissions
from
the
base
resource
the
resource
where
the
post
request
was
made
on
that
led
to
the
action
resource,
and
we
do
this
by
by
just
doubling
the
the
bits.
So
we
have
the
same
widths
we
just
had,
and
these
dynamic
bits
mean
this
is
not
for
the
the
base
resource
itself.
A
It's
not
answering
the
question
who
can
post
to
it
or
who
can
delete
the
base
resource,
which
is
something
that
that
maybe
nobody
can
do,
but
it's
about
the
the
action
resource
and
deleting
an
action
resource,
for
instance,
is
a
convention
for
stopping
an
action
that
that
is
going
on.
So
you
might
not
be
able
to
delete
the
base
resource,
but
you
should
be
able
to
delete
an
action
resource
that
you
actually
created.
A
So
this
requires
the
the
enforcement
point
to
actually
remember
who
created
a
particular
resource
and
then
it
can
just
apply
these
dynamic
bits.
This
is
a
bit
like
the
the
nfsv4
acl
inheritance
scheme,
at
least
that
it
reminds
me
a
little
bit.
So
this
is
not
not
a
completely
new
invention
here,
but
I
think
it
should
essentially
do
another
twenty
percent.
So
so
the
what
I
described
on
the
previous
slides
was
sixty
percent,
and
this
gives
us
another
twenty
percent.
A
This
document
has
been
around
since
2014
that
came
out
of
the
the
decaf
work
and
it
actually
was
listed
as
as
a
formative
contribution
at
the
the
a
spot
at
itf
89
in
london.
So
this
this
has
been
around
for
a
while,
and
people
have
generally
looked
at
it,
nodded
and
and
then
gone
to
the
next
thing
because
they
didn't
need
it
at
that
time.
A
But
in
the
ace
working
group
it
now
looks
like
we
actually
can
use
this
and
the
there
is
a
working
group.
Adoption
call
going
on
right
now
that
actually
ends
today.
So
if
you
like
the
thing
you
can
still
put
in
your
opinion,
and
even
if
you
don't
like
the
fingers,
you
can
put
in
your
opinion
in
the
adoption
call,
one
question
came
from
ben
benjamin
kedark.
A
A
This
is
probably
limited
because
most
web
servers
have
much
more
complicated
authorization
schemes,
so
they
don't
have
a
set
of
of
pretty
much
static.
Resources
like
like
an
iot
device
has
the
ig
device,
has
a
sensor
value
and
then
maybe
a
couple
more
things,
but
you,
you
don't
grow
a
new
sensor
or
something
like
that.
A
So
this
this
makes
a
lot
of
sense
for
sensors
and
actuators.
It
may
not
make
a
lot
of
sense
for
for
a
website
for
wikipedia
or
something
like
that.
A
But
of
course,
yes,
the
question
is
once
we
have
done
it,
it
may
attract
other
users
and
we
should
make
sure
that
we
understand
these
uses
and
don't
do
something
stupid
that
would
hamper
those
users.
So
tomorrow,
in
the
ace
meeting
that
that
starts
at
11
am
real
time.
I
think
we
will
conclude
the
the
result
from
the
adoption
call
and
please
go
there.
If
you
have
a
an
opinion
on
how
af
could
be
used
outside
a
so,
what
else
could
be
used
with
it
or
instead
of
it.
B
Carsten,
if
I
might
hear
her
head
off
so
I
think
if
the
if
pattern
is
very
similar
to
that
using
ipso,
you
know
mma
right
like
when
you
have
the
resources
and
you
have
the
operations
that
you
can
do
on
each
of
them.
We
don't
use
co-op
methods
like
get
get
post,
put
delete
per
resource,
but
we
use
this
abstraction
to
create
operations,
but
as
co-op
is
underlying
protocol,
I
guess
it
can
be
used
in
a
similar
fashion.
But
it's
not
exactly
like
this,
but
it's
related
in
case.
You
want
to
have
another.
A
So
maybe
it's
it's
worth
actually
writing
this
up
and
and
explaining
how
how
a
more
general
crud
level
abstraction
would
map
to
these
bits.
So
you
don't
need
a
new
registration
for
for
permission
bits
just
because
they
are
named
differently.
B
Oh
yeah,
I
mean
for
oma,
I
think
in
the
long
run,
if
they
use
something
like
this,
this
mapping
hat
will
have
to
exist.
Anyways
current
mapping
is
basically
to
the
to
the
existing
co-op
methods.
That
is
the
intention
to
add
other
application
layer
protocols
like
http
and
mqtt.
I
don't
know
the
process
or
the
the
progress
on
on
the
latter,
but
at
the
end
of
the
day
at
least
as
far
as
mma
goes
everything
maps
to
crowd
operations,
everything
is
food
for
thought.
Another
pointer
there.
B
C
Christian
answers:
how
would
you
envision,
I
mean?
Is
there
some
room
still
for
extending
this
in
such
a
way
if
you
say
that
the
dynamic
dynamic
permissions
applied
to
the
to
the
entity
that
created
this
re,
these
dynamic
resources
to
apply
dynamic
permissions
to
entities
that
did
not
create
that
resource?
Is
that
something
that's
kind
of
within
reach
from
here,
or
is
this
something
that
would
need
another
value
for
the
generic
parameters.
C
It
would
not
necessarily
span
that
particular
it
would
not
go
from
inside
that
same
document,
but
it
would
rather
go
state
something
like
dynamic
resources
that
we
are
created
from
here
that
someone
else
created.
That
would
be
a
phrasing,
that's
more
in
line
with
the
split
of
the
of
the
code.
A
Yes,
so
we
we
have
lots
of
bits
we
could
use.
So
if
you
go
to
the
previous
slide
again,
you
see
that
I
actually
started
with
32
for,
for
the
dynamic
get
just
to
be
able
to
simply
accommodate
any
future
co-op
methods
that
is
being
registered
and,
of
course,
we
could
start
at
64
for
for
dynamic
other
get
or
something
like
that
that
that
could
be.
That
could
easily
be
done.
Yes,.
F
A
F
F
A
Yeah,
so
the
the
the
management
of
subject
identities
over
time.
That
is,
of
course,
a
very
interesting
issue
and
that's
probably
something
that
really
should
be
discussing
in
ace.
But
yes,
so
this
token
may
be
time
limited
and
it
goes
away
and
with
that
the
af
information
goes
away
and
then
the
client
gets
a
new
token
and
then
maybe
with
a
new
new
temporary
identity.
A
F
Right
now,
but
I'm
going
to
go
put
it
on
the
agenda.
If
it
isn't
okay
and
do
I
need
slides
too.
B
It's
probably
saying
yes
not
to
the
microphone
okay,
so
thank
you
carson
any
more.
Anybody
else
any
comments,
any
thoughts,
because
if
not,
then
we
have
the
rare
occasion
in
which
we
are
ending
quite
early,
it's
5
35,
so
you
still
have
15
minutes
to
go.
We
can
use
the
flex
time
for
whatever
the
group
wants,
or
we
can
just
cut
it
early.
I
mean
we
actually.
D
Agenda,
yes,
that
is
also
already
uploaded
in
the
data
tracker
and
francesca
can
cover
perfect,
so
francesca
could
be
presenting.
Maybe.
B
K
K
K
Yes,
so,
first
of
all,
this
is
about
reducing
number
of
round
trips,
that
it
takes
to
run
a
dock
and
then
a
no-score
request
and,
of
course,
we're
talking
about
edok
over
co-op.
This
is
why
we
are
we
are-
or
I
am
bringing
this
to
core
and
also
to
answer
a
question
from
jim
that
he
posted
to
the
mailing
list
yeah,
so
lake
is
scoped
to
produce
one
lightweight
egg,
and
since
this
is
about
running
edoc
over
co-op
and
then
oscor,
I
thought
this
is
more
in
scope
of
core.
K
We
can
discuss
about
that
and
also
I
wanted
to
highlight
the
fact
that
this
document
proposed
optimization
on
how
to
run
adobe
and
oscore
minimizing
the
number
of
round
trips,
but
it
is
totally
possible
to
also
run
a
document
score
sequentially.
As
described
in
this
slide,
so
you
can
see
there
is
a
co-op
client
sending
message
one
edit
message:
one
edit
message:
two.
K
Then
there
is
some
add-on
verification,
then
edoc
message
three
sent,
so
I
skipped
the
edit
verification
for
message,
one
and
two,
obviously,
and
then,
and
then
after
the
server
has
verified
addock
message.
Three,
both
client
and
server
can
derive
this
oscar
security
context,
and
all
of
these
is
described
in
the
ad
doc
document
and
then,
after
that,
the
client
can
send
an
oscar
request
and
receive
an
oscar
response.
K
So
this
is
how,
following
the
current
ad
document
and
the
current
oscar
document,
one
can
run
a
dock
and
a
score
over
co-op,
but
we
can,
we
were
wondering:
can
we
optimize
these
three-round
trips
exchange
so
by
moving
the
oscar
security
context,
derivation
after
the
adult
verification
and
and
then
moving
the
other
verification
after
the
first
oscar
request,
we
can
actually
merge
these
three
message.
These
two
messages,
because
both
co-op
client
and
co-op
server
have
all
the
material
they
need.
K
So
basically,
what
would
happen
is
that
a
co-op
client
would
send
out
a
message
to
one
receive
add-on
message
to,
and
then
it
would
verify
it
would
verify
the
the
addock
message
to
and
produce
addock
message
three
and
at
the
same
time,
since
it
has
everything
he
needs,
can
also
do
a
oscar
security
context.
K
Derivation
and
use
these
oscar
security
context
derivation
to
protect
the
request,
and
then
the
co-op
server
receiving
this
combined
message
would
first
have
to
process
the
edoc
message
three
and
then
once
it
has
passed
verification
it
can
derive
the
oscar
security
context
and
then
it
can
finally
process
the
request
and
respond
with
the
response.
So
I
don't
know
if
there
is,
we
can
probably
take
questions
at
the
end
but
yeah,
so
we,
this
document
talks
about
different
options
on
how
to
send
these
two
messages
together.
K
So
there
are
two
options:
one
is
to
send
an
ad
doc
message
inside
a
score
message
and
the
other
one
is
send
an
oscar
message
inside
edoc
message.
So
I
remember
last
time
I
talked
about
this
in
itf
106.
I
did
not
have
slide
and
I
was
asked
if
we
could
have
figures
and
diagrams,
so
I
have
figures
now,
so
I
hope
this
is
better.
K
So
what
does
it
mean
to
have
adoc
inoscore?
So
basically
we
have.
This
is
a
representation
of
a
co-op
message.
We
have
a
header
options,
payload
and
a
oscar
message
is
defined
as
a
co-op
message
that
contains
an
oscar
option.
It
also
has
some
dummy
method
in
the
header,
for
example,
and
deciphered
in
the
payload.
There
is
a
cipher
text.
The
ciphertext
is
the
payload
of
the
club
message.
K
If
there
is
any
comment,
yeah
dummy
placeholder,
yes,
so
then
there
is
the
question:
how
to
signal
how
to
signal
which
one
of
these
it
is
so
it
can
either
be
a
signal
in
a
new
co-op
option
in
both
cases,
which
would
be
in
different
things
in
in
both
cases
or
it
could
be,
for
example,
signal
in
the
oscore
option
in
the
case
where
edoc
is
sent
inside
of
oscore,
or
it
could
be
signaled
based
on
the
number
of
elements
or
even
a
specific
content
format.
K
So
I'm
gonna
go
into
details
about
that.
So,
first
of
all
for
the
add-on
message
inside
of
oscor,
so
we
could
define
a
new
co-op
option
in
this
case
called
edoc
that
is
basically
telling
the
receiving
endpoint
or
in
this
case,
or
actually
the
server.
K
Please
process
addock
before
you
process
oscor
as
you
normally
would
so.
This
option
would
have
to
be
processed
before
the
oscar
option
and
that's
that's
a
hard
requirement
and
then
the
server
would
extract
educ
message
three
and
then
pass
the
the
rest
of
the
co-op
message
to
the
co-op
processing
that
would
go
to
through
oscore
processing,
okay
and
then
the
other
option
is
to
actually
add
something
in
the
oscore
is
called
flagbyte.
So
in
the
oscar
option
itself.
K
That
indicates
that
the
payload
contains
both
the
ciphertext
as
usual,
but
also
message
three.
So
the
difference
would
be
that
an
implementation
would
go
through
oscore
processing
and
would
have
to
recognize
this
bit
in
the
flag,
byte
and
would
have
to
extract
a
dock
and
then
run
the
add-on
processing.
So
the
add-on
processing
would
start
from
the
oscore
processing
instead
of
being
before,
like
in
the
first
option.
K
Okay,
then,
if
we
go
to
the
next,
if
we
have
oscar.
A
K
Oh
yeah,
you
know
yeah,
it's
a
sibor
encoded.
A
N
No,
no,
you
answered
the
question.
Okay,.
K
Okay,
so
then
the
other
option
is
that
yeah
for
for
signaling.
If
we
have
an
ad
doc
message
to
signal
that
the
payload
also
include-
and
he
needs
to
include
those
corruption
and
ciphertext,
then
we
would
either
define
a
new
co-op
option
or
which
is
basically
the
same
as
the
other,
but
the
meaning
is
different,
so
the
meaning
is
the
payload
contains
both
addock
and
oscor
option
and
ciphertext
and
another
option
is
to
we
either
say
the
endpoint,
the
edoc
handler
resource
handler
receiving
this
message
should
recognize
this.
K
This
payload
has
three
elements.
Instead
of
so
this
would
be
a
seabor
array
of
three
elements,
so
it
should
recognize
that
it's
not
only
add-on
message
three,
but
it
also
contains
oscar
option
cipher
text,
so
it
can
recognize.
Okay,
this
is
a
piggybacked
oscar
request
on
the
edoc
and
you
could
also
possibly
register,
or
we
could
also
possibly
register
a
new
content
format
that
would
let's
say
edoc
oscor.
K
That
would
indicate
that
the
payload
is
a
seabor
array
with
these
three
elements,
and
so
these
are
the
options
that
are
described
in
the
document
right
now
and
the
oscore
it's
worth
noting
that
this
option
the
option
number
two
is
the
one
that
would
save
the
most
bytes,
because
you
would
not
have
to
define
a
new
co-op
option
like
in
option
one
and
that,
and
also
because
you're,
not
using
a
specific
uri
path,
as
you
would
have
to
in
in
the
option
three
and
four,
because
it
in
yeah,
because
in
option
three
and
four,
basically,
you
would
have
to
send
a
specific
post
to
a
specific
uri,
and
that
is
all
defined
in
that
doc.
K
Also,
this
uri
path
right
now
is
a
well-known
resource
and
you
we
could
also
talk
about.
This
is
quite
long,
so
it
could
be
shorter.
You
would
have
to
maybe
define
a
resource
type
if
you
don't
want
to
have
it
as
a
well-known
resource,
but
yeah.
This
is
the
the
option.
Two
is
the
smallest
of
the
option,
and
I
I
see
people
yeah
and
did
you
want
to
say.
K
K
Well,
that
that
doesn't
matter
because
the
ciphertext
actually
contains
the
request
method.
The
dummy
method
is
anyway,
dropped.
N
K
It
doesn't
it
doesn't
matter
it's
going
if
it's,
if
it's
oscar,
going
into
a
doc
message,
this
oscar
option
and
cipher
text
would
have
to
be
extracted
and
the
new
co-op
like
a
co-op
message,
would
have
to
be
constructed
from
just
the
option
and
ciphertext
and
the
ciphertext
should
include
also
the
uri
and
the
method.
C
I
I'm
strongly
in
favor
of
one
of
the
first
options
and
jordan's
comment
highlights.
One
of
the
trouble
here
troubles
here.
That
is,
that
the
response
that
comes
would
come
back
from
a
shape.
Three
or
four
would
not
be
a
response
to
that
request
itself,
but
to
the
request,
that's
packed
in
there
and.
F
C
Need
to
be
encapsulated
in
there
and
then
we
are
starting
building
both
the
request
and
the
resp
inside
some
encapsulation,
whereas
in
with
pattern
patterns,
one
or
two,
the
response
is
a
plain
response
to
what
is
in
the
request.
C
C
One
suggestion
that
I'd
like
to
add
just
to
to
the
mix
of
of
one
and
two,
maybe
as
a
1b
or
maybe
that
was
already
considered,
is
to
just
put
the
ad
hoc
message
inside
an
option
inside
that
ad
hoc
option.
You
suggest
in
in
version
one
because
this
is
something
you
would
only
do
if
the
ad
hoc
message
is
short
and
if
that
is
significantly
longer
than
and
every
everything
else.
C
K
Okay,
I
think
we
are
over
time,
but
it
should
not
kick
us
out
before
in
next.
In
four.
B
K
Yeah
so
yeah.
This
is
already
super
helpful
comments
and
feedback,
and
this
was
the
goal
of
the
presentation.
Today
is
to
get
feedback
and
reviews,
and
then
hopefully
we
can
pick
one
option
and
progress
it
and
I
think,
from
from
the
feedback
today,
I
think
we're
all
converging
to
one
of
the
first
two
options.
M
M
B
A
B
K
Just
have
one
slide
left,
and
this
was
about
something
that
is
not
in
the
document
that
jim
brought
up
and
it
was
about
using
multi-part
core
to
to
optionally,
send
all
of
these
payload
together
with
different
content
formats,
and
I
think
this
option
has
the
same
problem
as
christian
brought
up
but
yeah.
I
wanted
to
put
it
in
in
it
and
also
it
adds
some
more
bites
because
you
would
have
to
have
bytes
for
each
different
content
format
for
addock
or
score
option,
oscor,
ciphertex
or
possibly
combined.
K
So
this
is
not
our
favorite
option,
so
yeah
just
wanted
to
mention
that
we
have
considered
that
and
that's
it
for
me.
If
anybody
has
more
comments,
please
also
I'd
like
if
klaus
is
here
also
about
length
of
or
custom,
maybe
you
can
say
something
about
length
of
options.
B
All
right,
so
I
think
this
concludes
the
session.
Thank
you.
Everybody
for
joining
us.
Remember
that
you
have
a
is
tomorrow.
Thank
you
francesca
again.
Sorry,
if
I
didn't
mention
it
before.
Oh
sorry,
christian.
B
All
right
so
again,
thank
you
very
much
for
coming.
We
will
see
you
again
on
friday.
At
the
same
time
and
yep,
we
will
take
all
the
items
we
took
on
the
list
and
I
think
that's
all.
I
can
think
right
now.
Marco,
any
other
comments,
nothing
else,
all
right.