►
From YouTube: IETF-CORE-20220119-1500
Description
CORE meeting session at IETF
2022/01/19 1500
https://datatracker.ietf.org/meeting//proceedings/
A
A
Okay,
so
let's
get
started
and
welcome
everyone
to
this
interim
meeting
of
the
co-working
group.
I
am
marco
tiloka.
My
co-chair
is
jaime
jimenez
and
this
is
an
official
itf
meeting,
so
we've
been
recorded
already.
The
not
well
displayed
here
applies,
if
you
are
not
familiar
already
with
it,
become
familiar
with
it.
It's
not
only
about
ipr,
it's
also
and
special
about
our
code
of
conduct.
So
please
be
nice
and
professional
with
each
other.
A
That
said
as
to
the
agenda,
for
today,
we
start
with
a
status
update
on
the
two
korkov
documents
under
an
isg
review,
so
young
seabor
and
seed
we've
had
progress
on
both
also
an
update
on
recent
progress
in
href,
especially
and
discussion
points
on
coral.
We
have
had
recently
resubmitted
an
href
version,
and
then
we
enter
into
group
communication
territory.
We
have
updates
both
on
the
group
combis
document,
with
an
open
pr
and
the
grupo
score
document
to
discuss
a
few
selected
points
on
a
review
received
recently
from
esco.
A
B
So
let's
talk
about
car
conf,
just
as
a
reminder
there.
There
are
four
documents
on
the
plate
of
the
working
group.
Two
are
in
the
isg.
Two
are
in
working
place
called
past
stage,
but
yeah.
Essentially
it
seems
that
there
will
be
some
some
fallout
from
the
processing
of
the
first
two
documents,
so
we
we
may
need
to
rev
these
one
or
more
one
or
two
times
to
actually
submit
them
to
isg.
B
So
I
I
talked
about
the
first
two
and
the
the
plan
with
the
isg
processing
was
to
do
the
discuss
clearing
first
and
the
plan
was
to
be
done
by
this
time,
but
we
aren't
done
yet
and
I'll
explain
why,
so
that
the
yang
ziba
document
has
cleared
the
discusses
and,
as
usual,
there
is
a
weird
status
in
the
data
tracker
yeah
anyway.
So
this
really
should
be
revised.
B
I
do
need
it
because
we
still
have
to
process
the
the
comments
on
this
document
and
that's
going
to
be
next
after
we
have
cleared
the
corset
discuss
and
on
corset
we
had
several
discusses.
One
is
remaining
and
of
this
signal
discussed
by
rob.
Wilton.
Only
one
item
is
remaining,
so
we
are
pretty
far
advanced,
but
that
item
turns
out
to
be
rather
interesting
and
it's
not
one
where
I
thought,
as
a
document
also
a
really
document
finisher.
B
B
So
it's
a
bit
easier
to
understand,
and
so
essentially
the
the
question
is:
how
does
the
mapping
between
sids
and
names
evolve
for
a
module
that
is
evolving,
so
young
modules
have
a
name
and
a
prefix,
and
these
modules
can
evolve.
They
can
make
non-backwards
compatible
changes
and,
of
course
the
question
is:
how
do
we
actually
evolve?
B
The
sids
that
are
attached
to
the
the
items
in
the
the
schema
and
the
current
document
takes
the
position
that
the
sid
should
be
attached
to
the
semantics
of
the
item
and
actually
one
one
interesting
criteria
here
is:
does
the
sewer
encoding
of
the
item
change
then?
Apparently,
it's
structure
changed
and
its
semantic
semantics
must
have
changed.
B
It's
not
so
clear
what
exactly
that
means,
but
that
might
be
an
operable
definition
we
have
in
in
the
document
right
now.
So
that's
what
we
thought
we
would
be
going
with,
but
the
the
alternative
would
be
to
to
take
a
much
more
bureaucratic
approach
and
just
say:
sids
map
to
item
names
and
well.
If,
if
you
change
the
name
of
of
the
schema
item,
there
must
have
been
a
reason
for
that.
B
This
is
about
the
time
when
the
module
actually
has
been
published.
So
there
is
some
promise
of
stability
with
that
module.
It's
pretty
clear
during
internet
draft
time.
We
are
throwing
things
around
and
changing
names,
and
so
on.
So
this
this
happens
all
the
time,
and
I
would
expect
that
when
we
just
have
a
plane,
name
change,
we
actually
keep
the
sit,
but
this
is
about
the
situation
when
the
module
actually
has
been
published.
B
So
this
this
threshold
may
or
may
not
coincide
with
the
time
when
the
document
is
published
as
an
rfc.
I
think
we
have
some
some
very
different
religious
views
on
this
and
I'm
more
on
this
side.
Once
you
have
promised
promised
the
thing
to
be
stable,
then
you
have
to
operate
on
the
stable
side
and
it's
not
that
important,
whether
it's
an
rfc
already
or
not
anyway.
B
So
if
the
name
is
disney,
then
there
might
be
a
reason
to
change
a
name
to
avoid
the
trademark
conflict,
but
yeah
we
usually
don't
publish
modules
that
have
trademark
conflicts
in
them.
So
it's
not
so
clear
that
this
is
a
lot
of
a
benefit,
but
on
the
other
hand,
this
also
means
that
if
the
semantics
changes
behind
a
name,
then
we
can
allocate
a
new
sit
and
isolate
implementations
from
that
semantic
change
or
actually
make
it
more
aware
more
obvious
that
a
semantic
exchange
has
has
occurred.
B
So
andy
says
that
sid
to
name
mapping
he
says
sit
to
pass
mapping,
but
that's
the
same
thing
here
does
depend
on
module
revision
date,
tuples
used
in
the
sid
file.
So
when
you
have
a
new
revision
date,
your
path,
mapping,
changes
and
further.
If
the
module
uses
groupings
with
which
is
a
way
to
bundle
things
for
export
groupings
from
other
modules,
then
those
revision
dates
also
matter.
B
So
you
essentially
have
to
have
a
pretty
good
map
of
the
landscape
of
revision
dates
before
you
actually
can
choose
the
right,
sid
or-
and
he
says,
if
we
can
accept
that
yang
files
can
change
in
backward
compatible
ways.
Then
the
same
has
to
be
accepted
for
sid
files,
and
that's
probably
true,
but
but
rob
has
had
some
comments
on
that.
B
So,
let's
go
to
the
the
alternative
when
we
attach
to
the
sid
to
the
name,
we
avoid
a
number
of
problems
that
that
rob
wilton
notes
in
his
discuss
comment,
which
unfortunately,
only
went
to
the
author's
chairs
and
and
isg.
So
I
think
that
that's
a
little
bit
of
a
problem
with
transparency
here,
so
sorry
for
for
unveiling
this
12
days.
B
B
Distinguish
two
different
sid
values,
so
I
consider
this
manageable,
but
it
is
a
burden
that
that
we
have
to
keep
in
mind,
so
the
alternative
would
be
to
put
more
logic
into
the
client,
I'm
not
quite
sure
whether
rob
really
means
clients
here
or
servers
here,
but
yeah
somebody
has
to
carry
the
owners
of
the
changed
sid
value
and
it
can
be
the
client
or
it
can
be
the
server.
But
somebody
gets
gets
the
the
short
straw
here.
B
That
sid
is
a
binding
to
a
namespace,
a
name
and
a
set
of
module
revisions
where
this
sid
actually
applies.
And,
of
course,
this
set
will
probably
expand
in
the
future.
So
you
cannot
know
the
entire
set.
You
can
only
know
a
snapshot
shot
of
the
set
up
to
which
your
your
knowledge
of
the
registrations
actually
goes,
and
he
sees
a
number
of
problems
with
that.
B
So
one
question
would
be:
when
do
we
actually
allocate
new
sids
yeah?
Then
we
need
a
set.
We
could
also
allocate
new
sits
each
time
we
change
the
module,
so
we
get
completely
new
sits,
but
then,
of
course,
we
use
a
lot
of
sit
numbers
and
that's
actually
absolutely
the
the
inverse
of
what
we
are
trying
to
do
here.
B
B
B
For
other
reasons,
the
the
rest
conf,
the
young
json
mapping-
is
not
a
schema
free
mapping,
so
you
have
to
know
a
little
bit
about
the
the
schema
to
actually
write
that
that
proxy,
but
I
still
can
imagine
doing
a
successful
proxy
without
schema
revision
information
with
with
the
occasional
creaking
at
the
joints
and
yeah.
I
wouldn't
want
to
actually
kill
that
kind
of
product
so
yeah
can
can
we
can
we
actually
reap
the
benefits
of
this
more
or
less
static,
sid
to
name
mapping
that
that
rob
is
advocating
here?
C
B
B
That's
really
hard
to
decide
these
things.
If,
when
you
don't
have
20
implementations
out
there
with
implementers
shouting
at
you,
but
we
we
have
to
yeah
forecast
a
little
bit.
What
people
actually
will
be
doing-
and
I
think
this
this
idea
of
translating
proxy
is
rather
useful
in
a
mixed
rest.
Conf
call
conf
world
and
we
should
do
everything
we
can
to
to
keep
that
possible.
D
Go
yeah,
can
you
hear
me
yes
and
you
think
so,
I'm
just
wondering:
is
there
also
a
problem
with
different
versions
of
the
modules
so
that
you
also
give
the
complete
yeah
module?
I
think
a
sip
number
and
so
what
what?
If
then
another
version
of
that
module
pops
up?
So
is
that
actually
an
issue
that
it
needs
another
ship
number
or?
B
D
Yeah
at
least
the
way
I've
used
it.
There
was
a
kind
of
base
number.
I
think
that
describes
yeah
a
set,
a
set
of
sub
elements.
I
thought
it
thought
it
was
related
to
module,
and
then
you
basically
use
relative
numbers
for
these
sub
elements,
so
you
have
a
bit
of
compression
and
then
the
module
number
is
kind
of
the
yeah.
E
B
You
see
that
the
top
level
of
this
compression
tree
is
usually
a
container
or
some
other
top
level
item.
Within
the
schema.
You,
you
don't
identify
the
module,
you
identify
the
top
level
item
and
since
this
item
has
a
namespace
that
namespace
indirectly
indicates
a
family
of
modules
and
there
we
are
because
we
have
this
family
on
on
the
name
name,
space
site
and
we
we
yeah.
This-
should
somehow
fit
with
the
sid
world,
where
also
the
the
same
sid
should
be
used
for
that
family.
B
D
B
Yeah
there
are
some
some
pretty
weird
things
in
the
young
jason
world
where,
for
instance,
if
you
go
from
32-bit
to
64-bit
numbers,
then
the
the
data
changes
between
integers
and
strings
and
so
on.
So
I
think,
on
the
restaurant
side,
the
the
clients,
the
management
stations
will
already
be
used
to
to
doing
weird
things,
so
I
think
they
will
be
rather
robust.
B
B
B
Then,
let's
quickly
go
to
the
coral
part
and
I
have
slides
for
the
href
part
of
coral.
Just
as
a
reminder,
the
the
href
document
defines
cris,
which
are
concise
resource
identifiers,
essentially
the
the
structured
binary
equivalent
to
uniform
reference
identifiers,
which
are
the
the
one
uniform
resource
identifiers,
which
of
course,
you
all
know
and
are
defined
in
rfc
3986.
B
B
We
have
submitted
the
dash
online
recently
and
and
part
of
that
actually
already
was
discussed
in
the
december
interim.
We
introduced
ctdl
features
as
a
way
to
talk
about
more
esoteric
parts
of
this
structure,
and
we
also
recognize
that
percent
encoded
text
in
your
eyes
really
are
byte
strings,
and
this
also
allowed
simplifying
the
encoding,
and
we
also
remember
that
fragments
can
have
percent
encoder
text
as
well.
So
this
is
old.
B
B
So
if
you
have
a
uri
with
a
single
path
segment-
and
that
is
empty,
this
is
now
different
at
the
cri
level,
from
a
uri
without
a
path
segment,
and
you
can
see
that
in
the
example
here
so
so
co-op
column,
slash,
full
slash
leads
to
a
cri
with
one
empty
path
segment
as
the
third
element
of
the
top
level
array,
and
if
we
leave
off
that
slash,
then
we
get
a
different
ci
now.
This
is
maybe
a
little
bit
surprising.
B
If
you
know,
schemes
like
coab
and
http,
both
schemes
actually
have
a
built-in
equivalence,
so
we
actually
have
rules
in
the
the
various
documents
that
talk
about
how
to
use
the
ui
schemes
that
provide
an
equivalence
here.
So
these
two
cris
are
equivalent
in
the
scheme.
The
scheme
co-op
tells
us
these
two
mean
the
same,
but
at
the
structure
level
of
of
the
ui.
B
Without
looking
at
the
scheme,
they
are
different
and
therefore
it's
not
really
the
job
of
of
the
ui
encoding
to
exercise
this
equivalent.
So
we
took
that
out.
On
the
other
hand,
of
course,
this
means,
if
you
actually
generate,
for
instance,
co-op
options
from
this,
then
you
have
to
implement
the
same
rule
that
you
already
had
for
uris
for
cis
as
well.
If
you
have
a
lone
md
path
segment,
then
you
leave
it
off
and
that
that's
actually
defined
in
rfc
7252.
B
B
B
B
This
is
something
that
was
already
present,
but
we
have
to
make
sure
that
our
implementations
actually
work
with
the
whole
document
and
in
particular
we
have
a
pull
request
with
test
vectors
and
we
need
to
make
sure
that
these
are
these
all
work
and
also
are
sufficiently
complete
that
we
can
give
that
to
implementers
and
say:
if
you
run
these,
then
you
can
be
pretty
sure
that
your
implementation
is
fine.
So
that's
where
we
are
with
cis
questions.
C
Yep,
thank
you.
So
the
focus
of
work
in
the
in
the
cri
slash,
choral
design
team
meetings
has
been
serialized
recently.
There
are
two
issues
tracked
in
the
issue:
tracker
that
I'd
like
to
point
out
to
you:
they're
also
referenced
in
the
minutes
minute.
One
is
one
that
I'd
like
to
complete
rather
soon.
That
is
the
the
decision
of
whether
this
is
all
an
open
world
or
close
world
system
with
the
proposed
resolution
to
allow
both
but
give
guidance
towards
building
open
world
systems
because
they
work
better.
C
C
If
you
have
any
ideas
about
these,
please
approach
me
us
say
something
now
or
input
it
into
the
issue.
The
other
issue
that
is
not
as
clear-cut
yet
is
the
issue
of
saying
something
about
the
security
model.
This
is
not
only
about
forms,
although
it
came
up
in
the
context
of
forms,
but
it's
just
the
same
about
links.
C
I
think
that
we
now
have
distinguished
a
bit
more
clearly,
at
least
in
the
internal
discussions,
that
what
we
expect
to
produce
is
not
something
precisely
like
what
is
happening
in
the
web,
but
more
informed
by
the
application
that
is
driving
it.
That
is
unlike
in
the
web.
We
don't
have
to
make
sense
from
a
user
clicking
on
the
link,
but
we
have
to
make
sense
of
an
application
saying
that
it
wants
to
with
these
characteristics,
with
these
characterized
authorizations
perform
a
particular
action.
C
Now
that
characterization
may
not
exactly
match
the
the
forms
model,
but
it
has
to
in
some
way
and
put
boundaries
on
on
in
one
direction
which
authorizations
can
be
used
at
all
and
in
the
other
direction.
What
assurances
from
the
server
about
the
or
from
the
source
of
the
form
about
the
authenticity
of
the
form
data
has
to
be
provided.
C
We
have
a
few
corner
cases
in
the
issue.
If
you
have
input
for
that,
we'd
appreciate
that.
Please
also
just
have
a
look
at
the
examples
there
and
the
corner
cases
so
that
we
can
be
sure
to
cover
the
relevant
topics,
not
in
terms
of
providing
a
full
security
model,
because
that
would
be
what
ace
and
the
walls
provide.
But
in
terms
of
providing
the
the
hooks
into
which
security
system
authorization
models
can
be
tied,
carson.
B
So
that
administrator
knew
about
this
proof
of
concept,
ui
and-
and
that
was
the
the
objective
of
the
mail
from
the
student
and
and
that's
fine.
But
then
the
administrator
forwarded
that
uri
to
another
administrator
and
the
other
administrator
didn't
quite
know
why
the
uri
was
in
this
mail
and
thought
the
first
administrator
was
telling
them
the
uri
to
click
on
it.
A
D
So
here
I'll
go
briefly
through
some
of
the
content
there,
so
not
all,
but
some
of
it
so
first
topic
we
have
in
section
221
and
that's
basically,
the
coding
of
names
of
application
groups.
So
there
we
added
quite
a
bit
of
examples,
and
the
structure
of
the
section
is
also
updated
to
accommodate
that.
D
So
there
are
some
ways
to
encode
the
name
of
an
application
group.
You
can
have
it
first
point
in
the
group
uri
of
the
core
request
and
there
it
can
be
in
various
places.
So
those
are
the
sub
bullets
here,
so
you
can
have
it
in
the
path
component.
Query
the
authority
component
as
a
whole,
the
host
subcomponent
or
even
in
the
port
subcomponent
and
those
are
presented
now
in
the
text
and
there's
a
second
class
of
ways
to
encode.
D
D
D
So
there
are
quite
a
bit
of
choices
there,
so
I'll
just
show
an
example
here
on
the
first
one,
so
there
we
have
an
application
group
name.
So
this
is
gp1
here
underlined
and
it
shows
up
in
the
group
uri
as
part
of
the
uri
path
and
then
in
the
draft.
We
now
have
a
complete
example,
also
showing
how
this
translate
to
our
co-op
requests
with
the
different
options
in
here.
D
D
I
think
we
also
mentioned
there
that
often
in
implementations,
this
uri
host
option
is
not
there,
because
the
server
normally
doesn't
actually
use
it.
So
it
just
looks
at
the
udp
level,
addressing
information
and
based
on
that
it
can
basically
derive
yeah,
derive
the
correct
ui
host
and
serve
the
correct
content,
so
it
doesn't
normally
doesn't
need
to
be
actually
encoded
in
the
request.
But
for
clarity
of
these
examples
and
correctness,
we
just
apply
it
here.
C
D
D
Yeah,
I
know
I
I
was
not
planning
to
explain
more
about
it
but
yeah.
Basically,
let
me
think
about
that.
So
the
question
is
okay.
How
can
I
not
be
in
the
group
ui
that
come
in
your
eyes
host
option?
Well,
it's
very
simple
suppose
you
start
with
the
group
uri
and
it's
actually
not
not
shown
in
slide
here,
but
suppose
this
group.example.org
here
is
there
and
or
sorry
it's
not
there,
and
then
you
replace
it
by
an
ipv6
literal
multicast
address
so
with
the
square
brackets
and
ip
multicast
out.
D
So
if
you
do
that,
then
the
uri
host
option
disappears
here
again
so
correct.
Then
you
can
send
the
request
without
uri
host
option.
So
now
the
trick
is
you
do
first,
the
translation
from
group
uri
to
the
actual
code
request
with
headers
and
then
in
your
implementation
code.
You
might
have
in
your
co-op
stack
a
process
that
basically
adds
it
back
in,
so
it
basically
adds
the
uri
host
option
with
some
custom
value.
C
F
D
Yeah,
I
wanted
to
say
it's
actually
not
because
if
you
take
a
group
uri
that
also
means
you're
sending
it
to
the
basically
the
authority.
That's
listed
here
if
you
use
ip
female
v6
multicast
address
literal,
for
example.
Here
that
means
you're
not
going
to
resolve
the
name
group.example.org,
but
you're
just
going
to
send
it
over
udp
to
that
ipv6
address
so
using
the
literal.
D
D
So
in
that
sense
it's
not
part
of
the
group.
You
write
so
only
added,
let's
say
in
the
last
instance
just
before
sending
it
out.
You
can
consider
that
it's
added
back
in
so
the
group
uri
is
already
defined,
has
already
been
parsed
and
that's
all
done,
and
now
you
can
still
decide
to
add
some
option
in
the
co-op
request.
Some
option:
that's
not
yeah,
basically
not
encoded
in
group
uri.
D
D
D
It
shows
now
that
you
can
also
encode
it
in
query
components.
So
there
are
two
ways
shown
so
you
either
use
the
entire
query
component.
So
that's
the
top
one.
You
just
have
a
gp1
query,
which
is
the
name
of
the
group
or
you
have
other
parameters
too,
and
then
you
might
want
to
use
the
key
equals
value
syntax.
So
then
you
have
something
like
gp
equals
gp1
to
encode
the
group,
and
this
is
for
the
rest,
it's
quite
straightforward.
D
D
D
D
D
So
the
the
known
corp
group
is
in
red,
underlined
and
that's
where
also
the
request
is
sent
to
using
dot
well
known
core,
so
you
can
get
link
formats
results
and
what
it
does
here.
It's
basically
looking
for
a
particular
resource
type
and
within
this
custom
application
context.
The
resource
type
starts
with
g
dot
to
indicate
the
group
and
then
the
thing
after
the
dots
is
some
information
about
the
type
of
group
in
this
particular
example
for
a
particular
application,
and
the
servers
then
respond
back
with
those
resources
that
have
that
type.
D
D
D
So
now
you
start
with
the
known
in
red,
so
the
basically
application
group
name,
so
you
know
the
path
encoding
of
that.
That's
in
our
examples.
It's
always
slash,
gp,
slash
something
gp1
is
here
the
group
name,
so
you
basically
look
for
those
resources
using
a
href
query
sent
to
all
co-op
nodes
in
a
particular
scope.
D
So
again
you
get
two
responses
here
from
two
servers,
so
in
green
you
can
see
that
also
the
core
group
is
responded,
and
after
that
yeah
you
see
again
the
the
requested
application
group
gp1
and
you
have
a
resource
type,
also
indicating
the
type
of
the
group.
So
in
this
application
example,
the
rt
contains
some
information
again
about
the
type
of
group.
D
D
D
D
A
A
And
we
did
have
version
13
after
itf-112
that
went
through
the
second
working
group
call,
and
we
have
already
received
a
very
good
reviews
from
esco.
Thank
you
very
much
for
that
in
two
separate
parts.
So
the
main
comments
were
first
mail,
then
more
editorial
comments
and
needs
followed,
they're
already
addressed
and
merged
into
the
editor's
copy,
and
there's
also
one
more
review
coming
in
soon.
A
So
I
selected
a
few-
and
this
was
I,
I
think,
the
most
interesting
to
consider
about
the
the
format
and
actually
the
storage
of
public
keys.
First
of
all,
we
we
definitely
have
to
improve
the
use
of
terminology,
because
right
now
we
are
using
public
key
in
two
ways
to
mean
both
the
actual
public
keys
to
verify
signatures,
but
also
to
refer
to
the
the
broader
container,
including
also
the
public
key,
which
is
authentication
credential.
A
A
Those
credentials
include
even
a
lot
of
metadata,
not
only
the
fundamental
signature
algorithm
but
also
think
of
issuer
subject,
key
use
and
expiration
for
the
public
key
and
most
important.
This
ensures
that
all
endpoints
here
are
going
to
consider
exactly
the
same
bytes
as
released
by
the
original
issuer
when
using
the
authentication
credentials
for
those
two
procedures.
A
So
you
can
see
that
as
a
trade-off
between
the
storage
you
have
to
live
with
and
and
the
complexity
that
you
would
otherwise
run
into
in
the
finding.
As
also
you
mentioned
in
in
your
review
was
called
the
the
relevant
subset
of
metadata
to
consider
and
and
how
to
encode
them
in
a
canonical
way,
and
you
have
to
do
that
for
for
every
credential,
keep
those
definitions
up
to
date
and
repeat
the
exercise
for
every
possible
future
credential
to
be
introduced
later
on.
E
A
B
A
D
Not
cute,
but
I'm
just
thinking,
maybe
I'll,
say
something
so
we
we
had
some
prior
work
hit
that
point
for
x549
certificates.
Specifically,
so
there
was
well,
you
can
have
the
whole
certificate
and
that's
for
constrained
implementations
yeah.
We
usually
ended
up
somewhere
between
half
and
one
kilobytes
for
a
certificate.
D
D
So
it's
just
taking
a
very
particular
part
of
bytes
from
the
x59
certificate,
but
you
have
to
know
and
define
exactly
which
byte
so
it
doesn't
need
to
be
specifically
defined
something
new,
but
you
need
to
define
it
as
yeah
in
a
very
exact
way
to
to
become
interoperable,
I'm
not
sure
about
the
size,
though
it's
probably
less
than
100
bytes.
I
think,
but
I
don't
remember
that.
D
Yeah,
so
the
ones
I've
been
working
with
the
interrupt
work
is
like
mostly
500
to
1000
bytes
in
that
area,
depending
on
what
you
put
in
sort
of
depends
on
yeah,
what
people
choose
to
put
in
and
how
long
the
strings
are,
etc.
So
the
public
key
is
much
shorter
than
that,
but
yeah.
That
was,
I
don't
recall,
the
size.
F
Yeah,
I
I
think
what
might
need
to
be
stated
in
the
draw
in
the
draft,
and
also
I
mean
for
this
discussion-
is
I
mean
the
relevant
subset?
Would
wouldn't
that
if
you
have,
if
you
know
what
the
relevant
subset
is,
couldn't
you
choose
a
credential
if
the
sort
of,
if
the
storage
limitations
are
really
strict,
couldn't
you
choose
a
credential
that
contains
essentially
the
relevant
subset.
D
Yeah
yeah,
you
don't
maybe
no
need
to
store,
but
maybe
for
some
applications.
You
do
need
to
store
the
entire
credential
for
proper
authentication,
because
if
you
only
store
the
public
key
well,
you
only
know
that
hey.
This
is
a
trust
device
that
authenticates,
but
you
cannot
link
it
to
any
other
information
of
the
device
like
okay,
who
was
the
the
vendor
or
what
role
does
it
have
in
the
current
network
deployment
or
which
authority
yeah,
basically,
which
name
of
authority
created
that
certificate?
E
A
Administrator,
creating
the
group
and-
and
this
is
then
ultimately
enforced
on
the
group
manager,
so
it's
not
something
that
the
group
members
really
negotiate.
So
probably
it's
a
good
thing
to
to
thing
from
the
start.
Considering
the
kind
of
deployment
I'm
going
to
have
is
just
better
to
go
for
this
authentication,
credential
type,
considering
the
impact
you
would
have
on
storage.
D
A
D
D
A
F
D
D
F
F
A
So,
of
course,
for
many
different
reasons,
the
group
manager
can
rekey
the
group
that
can
happen
multiple
times
and
and
every
time
that
happens.
The
group
id
changes
now.
The
details
here
depend
a
lot
on
on
the
specific
policies
the
group
manager
considers
for
picking
up
a
new
group
id
and
how
that
is,
formatted,
encoded
and
so
on.
But
at
some
point
the
group
manager
will
run
out
of
available
group
ids
that
have
never
been
used
before
and
it
will
start
to
reassign
already
used
group
id
values
in
the
past.
A
A
So
solving
the
the
original
problem
we
had
by
construction
and
all
this
is
summarizing
in
a
very
short
single
sentence
that
I
quoted
here
and
we
intentionally
did
not
explain
any
of
this
in
detail.
We
didn't
and
provide
an
example,
because
it
sounds
a
lot
like
discussing
design
considerations
that
we
did
have,
but
maybe
it
is
useful
to
to
add
more
explanations
about
this
instead
and
since
security
aspects
of
observation
are
involved
here,
maybe
the
security
consideration
sections
is
a
good
spot.
D
D
Basically,
how
many
group
ids
are
there
that
that's
maybe
the
question,
so
if
you
want
to
do
it
and
if
it's
really
a
kind
of
a
corner
case
that
normally
you
don't
run
out
of
buddies,
and
I
would
do
something
like
this-
maybe
yeah
in
a
separate
section
or
maybe
appendix
or
so
now
it
was
really
at
the
front
of
the
draft
and
to
me
it
seemed
quite
quite
complex
and
confusing.
So
you
want
to
keep
a
note
as
a
group
member
and
then
you
still
need
to
evict
it
for
this
security
reasons.
D
D
D
C
A
brief
note
on
the
topic
of
of
running
out
never
happens.
This
depends
on
on
how
large
gids
you
want
to
afford.
So
if
your
group,
if
you
just
accept
very
brief
gids
to
not
let
your
messages
exceed
some
bound,
then
you
might
say
have
a
liberal
for
a
nibble
for
the
group
identify
for
distinguishing
different
groups
and
another
liberal
for
counting
your
counting,
your
rekines
or
say
a
byte
for
each
and
then
you
can
realistically
run
into
that
condition.
C
E
D
D
A
Yeah,
I
think
we
should
definitely
give
more
context
around
this
in
that
section
already
and
then
maybe
as
a
dedicated
appendix,
but
a
main
input
I
I
got
from
you
before
esko
was
to
say
that
a
group
manager
can
potentially
actually
enforce
a
policy
to
never
recycle
group
ids
actually
and
well.
In
that
case,
when
the
possible
values
are
possibly
finished,
the
group
is
shut
down
and
and
that's
it
right.
A
A
E
D
Yeah
might
also
be
other
benefits
besides
observe
notifications,
because
not
more
than
every
application,
they
have
observe
active.
I
think,
but
could
it
be
benefits
that
that's
yeah
you
don't
need
to
for
most
members,
you
don't
need
to
change
the
key
material,
for
example,
or
it
can
just
keep
working
without
interruptions.
A
All
right
noted-
and
I
see
you're
agreeing
also
okay,
so
these
two
were
the
two
difficult
points
I
I'll
say
what
remains
is
easier
but
still
important
to
check
with
the
group.
Sooner
than
later,
yeah
we
have
a
section
10
mandatory
to
implement
compliance
requirements
exactly
the
same
title
and
purpose
of
the
corresponding
section
in
the
edoc
document
in
lake.
By
the
way-
and
I
got
from
one
comment
from
esco-
that
a
title
like
that
suggests
the
reader
to
expect
only
text
using
is
mandatory
to
or
must
and
shell
well.
A
Instead,
we
also
use
non-normative
statements
and
should
recommend
it
and
what
the
text
says
now
is.
Basically,
would
you
actually
mean
to
say
so?
A
good
fix
for
this
that
I
agree
it
does
require
fixes,
would
be
to
simply
change
the
section
title
to
implementation
compliance
because
I
think
that's
what
we
have
meant
all
along
and
that
will
still
include
both
actual
mandatory
to
implement
requirements.
But
but
not
only
would
this
be
good.
A
I
understood
from
that
draft
that
if
it
is
used,
it
works
also
on
verifiers
that
are
not
supporting
this
and
this
approach
themselves.
So
it
works
asymmetrically
which
helps
out.
But
still
your
point
remains
so
good
options
here
can
be
first
of
all,
keeping
the
reference
and
and
informative,
but
then
doing
one
of
the
following,
simply
switching
to
a
non-normative
recommended
or-
and
I
think
it's
better
rephrasing-
that
part
of
text
altogether
to
still
recommend
normatively
using
approaches
to
reintroduce
randomness
but
present
in
this
particular
document.
B
E
F
I
I
have
a
little
slight
problem
with
number
two
there.
I
I
think
it's
we
would
like
to
if
we
want
to
recommend
something
we
like
to
actually
make
precise
reference,
because
things
might
go
wrong
and
I
mean
in
this
particular
case.
This
draft
is
a
little
bit
stalled,
because
there
are
some
considerations
about
how
to
do
this
right.
So
so
we
can't
really
formulate
the
statement
of
this
draft
and
we
shouldn't
do
that
as
in
sort
of
as
text
we
should.
F
F
Yeah,
except
that
it's
not
really
clear.
What
is
the
I
mean
in
this
case?
What?
Because
this
is
this
work
in
progress,
so
I'm
not
sure
being
formulated
at
this
stage
exactly
what
what
properties
we
gain,
which
would
be
the
which
would
be
nice.
Of
course,
we
could
say
that
these
are
the
properties
you
gain
or
you
get.
B
E
F
B
Was
proposing?
Okay,
I
think
that
that
euron
has
a
point
here.
I
what
I
phrased
right
now
was
making
a
factual
statement
of
what
this
graph
does
and
that's
of
course
difficult,
because
the
draft
might
evolve
so
any
factual
statement
about
it
is
fundamentally
broken.
So
it's
better
to
say
that
that
technology
is
being
developed
right
now
and
simply
reference
that
that
document,
but
not
say
something
about
what
this
document
does,
but
that
the
technology
is
being
developed
to
do
this.
F
A
A
Okay
on
the
next
second,
from
last
point:
it's
a
similar
thing.
It's
still
the
same
cluster
of
comments.
It's
about
the
ace
group
manager
defining
that
draft
right
now.
Here
we
are
recommending
it
normatively.
I
I
think
this.
This
can
be
addressed
easily
by
just
keeping
this
an
informative
reference,
but
relaxing
the
text
around
it
to
simply
put
this
as
an
example
of
group
manager
to
to
use
still
having
highlighted
the
features
it
has,
and
that
would
be
it.
A
A
A
It's
mainly
used
in
an
appendix
as
an
example
way
to
do
challenge
response
synchronization
and
it's
the
equivalent
for
groups
of
an
appendix
of
all
score.
But
last
year
the
the
use
and
the
importance
of
the
option
in
group
score
has
raised
still
not
mandatory
to
implement,
but
it's
intentionally
recommended
method,
not
the
only
one
to
solve
another
issue
discussed
in
the
in
the
document
body.
A
A
D
A
A
Okay,
since
we
are
in
our
time
already,
I'm
done
and
we
need
to
start
actually
working
on
these
comments,
but
it
was
good
to
have
any
feedback
on
those
and
we'll
process
more
comments
as
they
come
and
earlier
today
I
posted
on
the
list
a
detailed
reply
to
esco's
review.
So
possibly
we
can
continue
there
too
and
yeah.
We
hope
to
have
version
14
submitted
before
the
next
itf
meeting.