►
From YouTube: CORE WG Interim Meeting, 2020-04-16
Description
CORE WG Interim Meeting, 2020-04-16
A
C
A
For
some
reason,
I
didn't
get
the
to
work
now
he's
working.
So
welcome
everybody
to
the
second
course
session.
I
am
hi,
Mickey,
Minnie
and
together
is
with
Marco
Toluca.
We
are
the
chairs
of
the
working
group
today
session.
We
assume,
as
always,
that
people
have
been
reading
the
drafts
and
are
aware
of
the
latest
and
greatest
in
the
working
group.
We
also
well,
as
you
know,
we
are
having
this
remote
participation
and
we
will
be
using
sorry
first,
they
appear
so.
The
the
note
well
applies
to
this
course
session
and
well.
A
A
Yeah
another
point
is
that
we
will
have
the
remote
session.
So,
as
you
know,
there
is
the
jabber
where
you
can
ask
for
cueing.
We
are
not
that
many
people,
so
it
might
be
that
you
can,
just
you
know,
politely
just
jump
in
especially
later
on.
As
we
have
a
discussion,
it
will
depend.
So,
let's
see
how
it
goes
along
the
discussion
session.
I
assume
you
all
know
how
to
use
the
cube
boat
that
we
have
in
the
jabber.
If
not,
you
can
use
also
the
WebEx.
So
the
Thursday
session
has
a
bit
on.
A
You
can
see
there
the
topics
and
we
will
have
a
bit
on
Discovery
topics
and
on
on
some
new
drafts
on
link
a
new
link,
relation
for
implementation,
information
and
some
research
directory
updates.
Then
we
will
have
a
coral
and,
in
general,
core
applications
discussion
there
at
1:45.
We
will
have
that.
That's
a
new
thing
that
we
are
trying
out,
which
is
more
having
a
bit
more
debate
in
the
in
the
in
the
group
for
for
technical
decision-making
and
then
finally,
we
will
have
the
sentimental
cluster,
so
I
think
I
didn't
forget
anything.
E
E
Defining
the
creation
types
should
be
a
relatively
lightweight
thing
to
do
so.
I
just
went
ahead
and
wrote
a
couple
of
paragraphs
for
a
link,
relation
type
I
called
imple
info.
Well,
it
could
have
been
implementation
information,
but
then
we
would
always
waste
that
space
and
we're
non-call,
so
I
called
it
employee
info,
and
that
is
meant
for
links
that
point
to
implementation
information.
E
We
could
do
that
later,
so
we
can
start
using
this
before
we
have
this
media
types
defined,
which
might
be
a
bigger
effort,
or
we
could
actually
think
well.
For
instance,
HTML
is
a
great
media
type
for
having
descriptions
of
implementation
information
out
there.
So
again,
the
proposal
is
not
to
define
these
media
types.
Now.
E
Yes,
of
course,
also
concerned
that
adding
more
to
when
on
call
might
help
those
people
who
are
using
when
on
call
for
DDoS.
So
there
is
a
little
bit
of
text
in
the
ER
that
that
discusses
that
point
and
reinforces
that
you
really
should
be
using
the
mitigation
that
has
so
defined
in
RFC.
Seven,
two
five,
two
next
slide,
so
that
the
previous
slide
should
be
the
end
of
my
presentation.
E
But
one
interesting
point
that
came
up
is
that
there
is
an
activity
going
on
defining
something
called
security
text
and
it's
highly
controversial
because
clearly
this
this
can
be
used
in
a
stupid
way
and
it
also
can
be
abused
in
interesting
ways.
But
on
the
other
hand,
it
also
has
upside.
So
there
are
people
proposing
going
forward
with
this
document
and
as
far
as
I
remember
it
so
nicely.
E
Last
call
right
now,
not
sure
I
haven't
checked
this
week,
so
we
might
want
to
do
something
like
security
door
text
for
for
this
space,
because
security
or
text
itself
is
not
the
right
thing.
It's
it's
meant
for
websites,
it's
meant
for
pet
websites
or
website
that
are
maintained
by
people
and
and
where
people
are
looking
at
and
so
on.
E
So
what
we
are
doing
here
is
more
like
a
kettle,
a
kind
of
thing
anyway,
so
there
there
are
various
kinds
of
information
that
would
go
into
such
an
security
dot
text
and
we
would
have
to
find
a
way
to
merge
that
information
or
to
point
to
multiple
sources
and
so
on
so
I'm
again
I'm
proposing
not
to
tackle
this
at
the
moment.
But
of
course
we
should
discuss
this.
So
please
discuss.
C
I
think
this
is
a
great
idea.
Carsten
I
mostly
agree
with
your
comments
about
security
text,
maybe
that
the
format
that
security
text
has
proposed
is
something
to
consider
other
than
for
HTML
I'm
concerned
about
HTML,
because
I
don't
think
we
really
want
to
have
someone
embed,
JavaScript
and
stuff
into
it,
and
so
I'm
concerned
about
that.
F
F
From
to
this
link,
yes
I'm
unfamiliar
with
the
details
of
security
txt,
so
I
can't
really
comment
on
that.
But
from
a
very
high-level
point
of
view,
it
looks
like
something
that
would
be
a
discussion
behind
it
around
which
meet
which
count
informed
on
which
information
should
be
there.
But
the
device
itself
can't
shouldn't
probably
have
any
more
information
than
I
am
this
and
for
any
implementation.
Information
just
see
there.
G
F
G
A
Going
back
to
the
queue,
so
my
one
question
I
have
for
Carsten
on
the
security
txt
other
than
the
hiring
information
that
maybe
is
not
so
relevant.
He
said
at
the
end
of
the
day,
it's
just
a
list
of
emails
of
who
are
the
security
response
that
those
responsible
for
the
security
of
in
the
case
of
IOT,
that
particular
IOT
device.
So
you
mentioned
at
some
point
that
it
will
depend
a
lot
on
the
deployment
you
space
and
who
is
I
mean
what
how
do
you
envision
this?
A
Is
it
something
that
the
management
company
of
the
devices
or
the
manufacturer
of
the
device
has
to
provide?
Or
how
is
it
done,
because
that
will
change
everything
and
also
considering
mods?
That's
also
done
during
the
something
that
is
supposed
to
be
at
the
factory.
The
deployment
scenarios
matter
for
their
security,
dot,
txt
and
then
to
the
link.
Relation
III
also
agree
with
Christian
yeah
in
in
general,
so
with
doing
Christian
so.
A
Mean
I
mean
for
the
security
dot
txt.
You
will
have
information
about
those
responsible
for
the
security
of
the
specific
endpoint.
If
they,
if
somebody
finds
a
vulnerability
who
are
those
I
mean,
wouldn't
even
make
a
difference
if
it
is
x,
owning
the
device
or
deploying
the
device
or
because
it
could
be
different
companies.
Yes,.
E
I
would
like
to
separate
implementation
information
which
might
give
you
a
pointer
for
who
wrote
the
code
from
deployment
information
which
gives
you
an
information,
might
give
you
information
on
who
forgot
to
to
probably
configure
the
firewall
or
something
like
that,
and
right
now,
I'm,
not
sure
that
we
would
get
very
far
with
deployment
information,
and
we
can
think
about
that.
But
typically
people
who
commissioned
devices
will
not
be
very
successful
and
in
putting
deployment
information
in
there.
E
Well,
maybe
we
can
invent
something
for
that,
but
I
was
hoping
that
this
really
is
something
that
can
be
set
at
the
factory
like
mud
can
be,
and
I
requested
it
for
my
girls
next
in
the
queue.
So
what
is
the
relationship
between
this
and
mud?
What
would
I
have
a
well
I
already
have
some
mud
stuff
going
on
in
the
DHCP
or
whatever
the
device
uses
to
gain
access
to
the
network.
Now,
how
is
the
the
the
mud
information?
E
H
C
So
so
it
the
the
the
mud
URL,
even
if
you
couldn't
retrieve
it
at
all,
would
essentially
allow
you
to
fingerprint
the
device
and
therefore
know
and
probably
lie
examining
URL
you
would
know
who
built.
It
is
much
more
interesting
than
I
think
that
it
contains
Lib
co-op
I,
just
I
wanted
to
I
got
in
a
queue,
because
I
wanted
to
say.
C
I
would
strongly
wanted
to
urge
Lib
co-op
from
answering
this
by
default
with
any
with
saying,
Lib
co-op
version,
because
I
think
I
really
really
really
think
we
want
to
have
something
about
who
uses
it,
who
which
library
it
is,
but
I
could
be
persuaded
otherwise,
I
think
Carsten
that
so
you
could
put
the
mud
URL
in
dhcp
yeah,
which
doesn't
work
at
all
when
you
have
ipv6
ra,
only
so
you're
never
going
to
get
that
information.
So
that's
an
interesting
place
where
something
could
cut
them
and
ask
the
device
a
commode
controller.
C
E
Yes,
I
was
just
thinking
about
what
expectations
we
are
creating
here.
So,
given
that
that
modify
really
is
a
declaration
from
a
device
to
its
surrounding
network
environment,
it
may
not
accurately
describe
how
that
device
actually
looks
like
on
the
outside,
so
I'm
not
sure
that
the
mud
URL
is
always
very
useful
for
someone
who's
trying
to
find
out
what's
going
on
with
a
bad
reputation
over
there
in
the
network.
A
This
is
very
interesting,
but
we
really
have
a
tight
schedule
and
I
think
Marco.
You
just
mentioned
that
we
are
several
minutes
behind.
So
if
that's
okay,
let's
put
a
pin
on
this
I,
think
the
presentation
was
nice.
I,
don't
think
we
are
asking
for
adoption
or
anything
like
that
at
the
moment,
right,
Carsten.
A
I
would
say
on
the
okay
I
see
that
at
least
there
is
two
people
in
the
jabber
that
will
be
in
favor
of
that
I
would
suggest.
Let's
take
it
to
the
main
list.
Let's
not
do
it
right
now
and
if
we
have
sufficient
people
in
the
list
that
are
positive
and
discussion
also
goes
on
there.
We
will
we'll
consider
the
adoption
all.
F
A
F
So
I'll
try
to
make
this
quick.
This
is
not
really
a
document
presentation.
It
touches
on
a
document
that
custom
has
written
some
time
ago,
but
it's
really
more
about
a
topic
that
I'd
like
to
warm
up
the
discussion
about
how
we
as
a
working
group,
want
to
go
forward
with
this.
The
main
theme
is
unsolicited
responses.
F
Then,
is
your
sender
II
you
something
happened
some
time
ago
and
then
the
server
decides
to
send
a
client,
a
response
where
the
client
probably
knows
from
some
context
or
something
in
the
message
that
what
it's
a
response
to,
even
though
it
didn't
explicitly
request
it
now,
the
there
is
president
next
latticed
there's
some
precedent
for
this
already
in
the
core
protocol
from
observation.
Does
this
on
a
very
fundamental
level?
Multicast
responses
are
a
bit
related
because
they
don't
risk
arrived
from
the
original
address,
but
there
been.
F
This
has
come
up
over
and
over
again
in
in
different
applications.
So
this
draft
mentions
triangle
setups,
where
request
descent,
but
the
risk
device
expect
the
response
over
different
transports.
Something
like
this
was
also
in
coop
over
SMS
sometime
ago.
The
most
talked
about
blocks
to
transfer
with
larger
window
sizes.
Thoughts
recently
requested
something
similar
and
it
could
be
used
for
cache
creep
up,
pre-population,
just
as
well
and
last
but
not
least,
the
multicast
notifications
I
talked
about
last
time.
F
They
do
something
they
do
something
very
similar.
They
say
suppose
you
sent
that
request
and
you're
getting
responses
to
this.
The
the
crus
of
the
thing
is
always
the
tokens.
So
in
four
observations,
it's
very.
It
works
there
because
there
was
a
prior
request
and
some
of
those
cases
could
probably
profit
from
from
a
similar
setup
where
we
say
that
okay,
it
because
there
really
is
this
in
that
condition,
there
can
be
multiple
response.
F
I
E
Document
actually
opens
up
a
number
of
alternatives
and
I
think
the
question
has
pointed
out
that
there
is
one
alternative
that
actually
might
be
low-hanging
fruit
here
and
I
agree
that
that
this
is
probably
an
approach
that
could
be
used.
I
think
the
hard
part
here
will
not
be
defining
the
the
actual
protocol,
but
defining
the
the
context
and
the
usage
that
we
actually
envision
for
it.
E
F
Yeah
we
had,
there
was
a
male
on
the
dots
and
qualms
mailing
list
recently
about.
We
are
observing
the
block
1
and
we
want
to
first
block
and
we
want
to
get
follow-up
locks
through
the
gate
after
you
just
as
well,
because
our
back
channel
might
be
clocked.
So
we
just
want
to
send
out
everything
and
and
hope
for
the
best,
and
then
they
can
still
selectively
get
missing
parts.
Okay,.
D
D
E
Good
good
part
of
discussion,
so
the
the
multicast
notification
relies
on
actually
having
a
token
defined
for
that.
So
it's
a
more
efficient
way
of
doing
this,
while
this
year
is
something
that
that
may
be
more
useful
for
out
of
the
blue
stuff
and
and
again
we
should
be
discussing
the
contexts
and
the
usages
that
we
have
in
mind
and
maybe
at
the
end
we
find
out
that
the
multicast
case
actually
is
is
the
one
that
is
most
useful
and
we
are
not
going
to
do
the
other
ones
on
the
block
to
thing.
E
Yes,
we
designed
block
2
to
be
flow,
and
if
we
need
something
that
works
under
attack,
which
is
what
the
the
that's
people
need,
we
might
want
to
craft.
Something
specifically
for
this
use
case.
I'm,
not
sure
that
this
will
will
actually
be
of
general
use,
because
there's
probably
a
need
to
actually
play
lose
and
fast
with
the
congestion
controllers.
I.
F
E
A
F
So
brief
update
on
resource
directory
status,
our
next
slide,
please,
the
24
M
has
been
published
with
all
the
things
that
we
discussed
in
in
ITF
106
and,
most
importantly
of
those,
is
that
now
we
have
this
very,
very
minimal
subset
of
RT
18
SSD
interaction
I'm
explicitly
written
out
there.
So
this
can
so
this
the
so
DRD
can
be
discovered
over
BN,
SSD
and
you've,
probably
read
the
rest
of
the
change
law.
F
We've
received
two
reviews
in
the
in
the
ASG
process
already
from
secretary
and
Jen
art
and
I
did
go
in
the
next
slide
over
the
smaller
to
larger
problems.
That
will
that
will
need
addressing
in
some
way
next
slide.
Please
so
the
the
simple
stuff
is
already
being
processed
and,
lastly,
has
pull
requests
on
github.
F
F
F
F
F
The
resource
directories
point
of
view.
It
looks
at
the
security
context,
but
clients
might
but
look
but
clans
at
the
firm
look
up
my
term
I
may
or
may
not,
depending
on
the
application,
put
some
meaning
to
the
endpoint
names
and
if
they
do
they,
hopefully
do
this
honorary
subtract.
We
that
enforces
any
meaning
in
them.
This
is
for
cases
where
no
meaning
as
a
sign
there
and.
A
Here,
when
you
say
guidance,
my
one
side
might
suffice,
but
what
other
options
are
there
like
some
in
in
some
in
lab?
Wouldn't
win?
No
actually
anyways?
The
point
is
that
do
you
suggest
that
it
is,
they
are
deeds
somehow
are
signing
some
hash
to
the
endpoint
name
and
not
allowed,
because
remember
that
we
have
this,
you
are
in
draft
on.
That
is
basically
the
endpoint
will
use
potentially
could
use
these
URLs,
and
it
decides
I
mean,
like
the
endpoint
name,
will
be
picked
by
the
device
registering.
F
Don't
hear
you
sorry,
I
was
muted
yeah.
This
is
exactly
this
is
exactly
about
the
case
where
the
client
picks
the
random
identifier,
but
the
client
will
still
need
to
know
basically
how
long
that
random
identify
needs
to
be
in
order
to
work.
So
if,
if
if
this
thing
with
the
urines
is
coming
up,
that
might
be
something
we
can
put
in
there
and
because
your
ends,
because
we
know
that
your
hands
never
collide,
we
won't
we'll
never
run
into
trouble.
So
that's
exactly
what
I'm
asking
for
here.
Is
it
good
enough?
F
Next
slide,
please
the
harder
part,
and
especially
the
part
where
I'm
asking
the
working
group
for
a
bit
more
input
is
the
interaction
with
endpoint
names
derived
from
from
certificate
details.
So
there's
this
common
name
field
and
we've
only
recently
put
more
bit
more
text
in
there.
That
says
that
how
this
can
be
used
and
what
makes
it
unique
but
turns
out.
This
wasn't
all
correct.
F
So
if
someone
is
experienced
in
where
the
all
most
fields
in
x.509
certificates
come
from
and
how
they
could
be
used,
it
would
really
be
helpful
if
we
could
sit
down
with
someone
and
talk
this
through
about
what
can
actually
be
used
to
work
from
a
certificate
and
not
yet
on
the
slides,
but
came
up.
Kind
of
in
parallel
is
the
is
the
general
question
of
what
what
do
we
want
to
prescribe
in
terms
of
security
policies
so,
right
now
there
is.
E
So
I
kind
of
didn't
pay
attention
when,
when
this
entered
the
discussion
and
I,
think
it's
completely
misguided
to
to
have
anything
in
this
document
that
talks
about
certificates
at
all
and
I.
Think
I'm
also
not
particularly
happy
about
doing
a
separate
document
later,
but
maybe
there's
a
reason
to
do
that.
E
I
think
the
underlying
problem
here
is
that
the
the
resource
directory
actually
is
a
protocol
that
can
be
used
by
a
set
of
applications,
and
each
of
these
applications
have
different
authorization
requirements,
and
it's
not
the
purpose
of
this
document
to
define
those
applications
and-
and
so
we
are
not
going
to
get
to
a
situation
where
we
can
say
much
about
the
authorization
considerations.
I
mean
it's
like
HTML
HTTP
was
was
going
to
define
how
a
web
application
actually
runs
its
database
with
user
names
in
it
and
so
on.
No,
you
don't
do
that.
E
That's
the
application
that
defines
that,
so
we
should
focus
on
on
the
things
where
the
protocol
actually
interacts
with
something
and
I'm,
not
even
sure
that
we
need
to
have
x.509
in
there
at
all.
So
we
have
things
like
ace
where
we,
actually
you
can
carry
around
x.509
stuff
if
we
we
want
to,
but
resource
structure
should
be
free
of
this
stuff.
F
I
E
Are
people
who
have
the
the
SNMP
scars
so
snmpv3
actually
came
with
their
his
authorization,
but
it's
over
time
and
basically
the
the
idea
was
that
in
a
network
you
would
have
a
situation
where,
where
the
network,
the
network
management
would
would
somehow
provide
an
overall
authorization
scheme
and
any
single
agent
would
be
able
to
plug
into
that.
But
I
think
that
that's
not
at
all
the
deployment
idea.
A
Ok,
if
I
can
just
jump
in,
maybe
to
summarize
the
discussion
I
guess
we
have
some
opinions
in
the
jabber
as
well.
Those
have
been
reflected
reflected
in
the
etherpad
I.
Don't
think
we
are
trying
to
add
another
20
pages
of
how
to
do
ace
with
resource
directory
in
the
resource
area
document
right
nobody's
trying
to
do
that
as
far
as
I
know,
so
I
guess
maybe
some
guidance,
because
right
now
there
is
nothing
on
on
no
pointers.
A
I
believe
too
how
to
do
that,
how
to
do
authorization,
so
maybe
like
small
text
on
on
how
like
pointers
to
relevant
documents
and
perhaps
later
on
down
the
road,
because
this
has
pop
up
in
other
areas
and
in
other
discussions
how
to
use
for
de
and
ace
together.
It
could
be
something
that
could
be
done
in
into
seeing
or
in
Elba
core
elsewhere.
A
A
A
F
So
things
things
we
can
do
in
a
resource
directory,
but
we
don't
specify
next
like
this
in
the
main
document,
because
we
don't
need
to
because
we
have
extension
points
and
next
like
this,
and
it
might
also
be
helpful
here
to
explain
how
to
build
on
resource
directory
in
in
other
documents.
What
I
have
written
through
this
is
is
a
document.
That's
really
next
slide,
please
a
mixed
bag
of
things
that
could
be.
It
could
be
tacked
on
to
a
resource
directory,
so
one
topic
run
through
them
briefly
and
one
drug
topic
is
reverse.
F
Proxying
device
wants
to
register
the
resource
directory,
but
doesn't
even
have
a
public
address
that
it
can
properly
use.
So
just
ask
the
resource
rectory,
to
make
one
up
and
put
that
in
instead
of
the
actual
address
thing
think
turn
a
bit,
especially
for
those
cases.
You
might
also
want
to
have
in
infinite
lifetimes,
because
you
have
route
ESP
connection
open
and
as
long
as
that,
open
I,
the
registration
is
good.
F
F
F
I'm,
pretty
sure,
we've
built
something
like
this
at
ITF
at
some
point
in
time,
so
probably
experience
from
there
could
be
gathered
in
one
is.
This
is
a
document
that
contains
a
bunch
of
suggestions,
some
which
might
be
interesting
to
the
working
group
and
I'd
like
to
hear
whether
any
of
this
is
interesting
enough
that
people
want
to
join
in
working
on
this
or
at
least
express
an
interest
that
keeps
me
active
on
them
to
make
this
go
forward
next
slide.
F
Please
there's
a
few
documents
that
are
not
a
few
ideas
that
are
not
in
this
document,
but
kind
of
similar,
because
they're
also
describing
Rd
extensions.
Many
are
dat
and
SST
is
the
obvious
example.
Coral
reef
I
already
mentioned
our
key
replication
and
protocol
negotiations
plays
a
bit
into
it,
even
though
it
needs
to
work
without
resource
directory.
F
It
does
have
aspects
of
of
querying
one
that
will
be
extensions
to
an
our
team
and
the
law
when
one
on
half
years
ago,
with
a
group
membership
in
the
group
concept
of
RT
was
overhauled,
we
might
have
lost
a
few
use
cases
that
could
also
be
specified
in
a
separate
document.
Next
slide,
please
so
of
those
things.
What
is
the
interest?
What
what
is
something
there
is
interest
for
other
particular
things
that
you
think
are
very
important.
Well,
there
are.
That
should
not
be
followed.
F
A
I
A
I
have
been
seen
some
requirements
coming
from
oh
ma,
I,
don't
know
we
have
the
I
wouldn't
turn
folks
in
the
coal
at
the
moment.
I
don't
see
it,
but
some
of
the
Rd
requirements
were
where
there
a
lot
of
the
interesting
stuff
that
I'm
more
interested
in
at
least
for
for
research
director,
has
to
do
with
doing
complex
queries
for
the
lookup
interface.
F
A
And
I
was
also
I,
mean
particular
I
mean
in
my
case
I'm
interested
not
in
this
document.
Actually,
it's
the
distributed,
Rd
that
you
start
it
that
someone
is
in
still
interesting
for
me,
but
I
haven't
had
time
to
work
on
it
and
the
last
two
items
in
this
list.
Multicast
aggregation
also
sounded
interested,
but
I
haven't
dedicated
in
all
type
to
contribute.
A
A
G
A
G
G
Okay,
the
first
item
is
about
the
draft
that
does
not
exist
yet,
but
we
discussed
about
this
in
Singapore
and
I
think
also
in
Montreal
already.
So
this
is
a
quick
reminder
of
what
we
agree
them
and
the
status
update
and
the
status
update
can
be
done
quickly
because
nothing
has
happened
yet
since
then.
So
what
we
did
we
talked
about.
G
A
G
A
I
don't
know
if
the
group
is
up
to
date
with
this
topic,
but
I
would
like
to
hear,
especially
there
is
any
any
particularly
negative
opinions,
because
it
might
be
that
we
have
over
seen
some
issues
with
this
idea.
So
basically
the
idea
would
be
like
to
have
a
registry
also
of
existing
limiting
relations.
A
G
A
G
G
G
Okay
then
first
issue-
and
that
was
an
interesting
discussion
with
Jim
and
Christian
and
I
noticed
that
we
write
your
eyes
or
our
constraint
versions
of
your
eyes
and
we
always
have
a
bit
of
overhead.
So
if
we
look
at
this
example
your
eye,
then
we
of
course
have
these
different
UI
components,
and
so
we
have
some
data
like
co-op
and
example,
calm
and
foo
and
and
so
on,
and
then
they
are
in
between
some
delimiters
so
colons
and
slashes
and
this
overhead.
G
But
it's
necessary
overhead,
because
if
there
weren't
any
delimiters,
then
we
couldn't
figure
out
where
one
of
those
component
starts
and
and
where
the
component
ends.
So
we
need
to
have
these
lights
between
the
components
that
separate
them
in
some
way.
Of
course,
if
we
can
minimize
the
overhead
so
express
the
same
information,
but
with
fewer
bytes
in
between
that
would
be
very
useful.
G
So
if
we
do,
this
can
call-
and
we
you
see,
bear
and
we
have
your
eye,
then
we
would
have
see,
bore
a
text
string,
that's
major
type
23
and
this
your
eye
has
49
bytes,
because
we
have
this
very
long
path
segment.
At
the
end,
and
so
we
use
additional
information
24-
and
this
is
one
extra
byte
49-
it
will
have
the
link
and
total.
G
We
would
have
44
bytes
for
for
the
components
and
7
bytes
for
these
telemeters
and
the
initial
column.
C
bore
prefix,
which
are
seven
fights
so
7
bytes
of
overhead.
And
the
question
is:
can
we
minimize
this
overhead
and
if
we
know
at
how
it
and
the
HOF
draft,
we
also
have
these
components
and
each
component
or
sub
component?
G
Is
it
similar
to
co-op
where
we
have
options
so
there's
an
option
number
and
an
option
value
length,
and
then
that's
followed
by
the
value
itself
and
in
sibour
we
would
encode
the
option
number
as
an
unsigned
integer.
So
that's
major
type
0
and
additional
information
0
for
for
optional
and
for
the
yeren
scheme.
Here
it's
text
strings
major
type,
3
and
Link.
This
for.
G
So
again
we
have
44
bytes
of
data,
but
10
bytes
of
overhead.
So
in
this
point,
SIBO
encoding
actually
does
not
help
to
make
this
very
concise.
So
I
was
thinking.
Can
we
maybe
improve
on
this?
Somehow,
and
one
thing
we
could
do
is
we
could
throw
away
the
overhead
then
is
generated
by
SIBO?
That's
these
type
indications
for
the
unsigned
integer
and
the
text
strings,
because
if
we
know
the
option
number,
we
also
know
the
type.
G
So
we
could
combine
the
option
number
and
the
option
value
length
into
a
single
byte
of
three
bits
for
the
number
and
five
bits
for
the
length,
and
so
we
only
have
four
bytes
for
the
four
components
and
then
we
wrapped
the
whole
thing
in
a
sea
bore
byte
array,
so
we
have
in
the
end
34
bytes
of
data
and
six
bytes
of
overhead.
What
do
you
think.
E
So
I'm
not
sure
the
queue
exist,
it
actually
does
work.
So
yeah
we
have
this
RFC
called
7
2
5
2,
which
gives
us
a
really
nice
encoding
of
multiple
options.
So
maybe
we
could
use
that
I'm
wondering
if,
if
that
actually
is
worth
adding
more
decoding
and
encoding
stuff
to
it
or
what's
already
in
NC
ba
so
I
think
that
that
that
has
to
be
carefully
balanced,
but
yeah
I
mean
that
to
format
we
came
up
with
for
co-op
is
pretty
good.
E
Well
again,
it's
more
work
and
we
should
decide
whether
it's
worth
it.
So
in
this
particular
case
we
are
saving
some
slightly
less
than
10%.
If
we
think
that
that's
generally
worth
it,
then
we
should
go
for
it.
It
probably
shouldn't
invent
I
mean
everybody
of
us
can
come
up
with
something
that's
even
more
efficient,
with
lots
of
bit
twiddling
and
and
stuff.
Probably
shouldn't
invent
a
third
form.
E
So
for
me
what
the
decision
would
be
between
sticking
with
this
as
a
data
structure
that
is
expressed
in
Siebel
or
carrying
around
a
couple
like
data
structure,
but
then
we
would
really
follow
the
core
be
examined,
so
we
would
actually
use
data
encoding
for
the
option
number
and
so
on.
So
it
would
be
exactly
like
her,
except
that
the
number
of
space,
of
course,
is
different
from
from
the
one
we
use
for
coop
itself.
F
G
G
That's
not
a
lot.
I
agree
the
other
hand.
We
are
assuming
very
constrained
devices
with
very
limited
memory,
so
those
devices
probably
won't
be
storing.
You
are
elsewhere
with
hundreds
of
bytes
anyway,
and
so
this
might
actually
be
in
the
ballpark
of
that
will
be
used
in
practice.
But
then
again
we
noticed
a
couple
of
times
already
and
other
protocols
that
putting
in
hard
limits
that
are
low,
like
this
eventually
hurts
us.
G
It's
difficult
thing
here
to
estimate
what
would
be
the
right
thing:
I
noticed
in
my
implementation
that
I
get
a
lot
of
benefits
if
the
separators
or
these
prefixes
before
the
components
have
a
fixed
size.
So
if
we
use
the
court
message,
format
and
and
adult
encoding,
and
all
of
that,
we
would
like
and
see
bohr
have
a
variable
length,
encoding
off
of
the
number
of
bytes,
and
that
would
actually
hurt
my
implementation.
A
lot
more
to
think
about
here.
A
A
J
I
Noise
now,
yes,
no,
you
have
okay,
I,
just
reconnected.
One
of
the
things
that
I've
been
trying
to
do
is
figure
out
exactly
what
the
app
structure
looks
like,
because
he
wanting
to
actually
write
a
document
for
an
app
and
it's
just
been
kind
of
hard,
because
nobody
really
knows
so
hard
for
me
to
see
it's.
K
I
D
C
I
I
So,
by
link
basically
is
is
the
standard
thing
what
you're
doing
today,
so
you
basically
say
here's
a
link
and
the
relation
type
is
is
this
is
a
collection
and
by
the
fact
that
you
know
it's
a
collection
or
you
know
it
has
a
specific
interface
to
find.
You
know
exactly
how
to
interact
with
that,
because
so
and
you
can
potentially
put
in
multiple
relations,
you
could
say
this
is
it.
This
is
a
collection
which
says
this
is
how
you
would
do
get.
This
is
how
you
do
it
fetch.
I
I
The
second
is
is
basically
similar,
but
it
you're
basically
defining
objects,
so
you're
gonna
say
you
know.
This
is
a
collection
of
items
and
and
bytes
and
you,
the
item
is
basically
a
parameter
that
you
can
change
so
that
basically
says
you're
gonna
support
a
kitten
fetch
and
have
an
item
that
supports
getting
fetching
that
delete
alive,
which
is
inherits
from
an
item,
but
it
did
adds
the
definition
of
delete
next.
I
Reef,
there's
at
least
a
couple
of
different
versions
of
reef
running
around
there,
but
there
they
all
are
basically
the
same
thing.
This
is
an
application
of
how
to
talk
to
a
resource
directory,
there's
also
over
in
the
ACE
working
group.
The
group
keen
administration
document,
which
basically
is
exactly
the
same
thing,
and
when
you
look
at
these,
they
have
a
lot
of
commonalities.
I
mean
there's
all
of
them
have
contain
of
objects.
All
of
them
have
to
have
objects.
I
J
I
I
H
H
I
H
A
So
III
can
say,
as
far
as
pub/sub
is
concerned,
that
I
feel
that
it
would
be
nice
to
have
some
sort
of
high-level
guidelines
for
how
to
do
these
applications,
especially
we
move
into
the
coral
territory
right
now.
That's
my
high
level
thought.
Maybe
we
move
from
the
queue
now
Thomas
you're
there
whoops.
G
Bertrand
theas
that
and
open
at
the
I
you
specify
which
URLs
available
and
what
operations
on
which
URLs
are
possible
and
if
we
use
hypermedia,
then
we
discover
all
the
URLs
from
service
responses.
But
basically
we
would
like
to
have
something
like
open,
API,
except
we
wouldn't
have
all
the
URLs
and
in
the
file.
D
A
I
Well,
I
mean:
is
it
something
we
need
to
have
talked
about
the
one
other
thing
that
the
potentially
needs
to
be
added
to
this?
Is
you
still
have
potentially
the
reef
content
type
schema
to
talk
about,
in
addition
to
to
the
this
list,
I
think
I'll
go
ahead
and
try
to
write
it
up
something
and
mail
it
to
the
list
and
see
if
we
get
any
more
comments.
Discussion.
H
A
Maybe
like
so
Jim,
you
can
also
maybe
wait
after
one
of
the
interims
that
we
will
have
own
applications
anyways.
Maybe
we
have
some
more
clarity
on
this
topic.
A
A
B
So
this
is
one
proposal
for
reporting
foreman
for
co-op
API,
so
it
is
very
much
based
on
the
Sailor
work
that
has
been
done
in
in
steel
and
with
RFC
1707
was
published
last
November
in
Singapore
and
and
it's
going
through,
Twitter
ation.
Since
it's
been
presented
in
the
core
upside
meeting,
where
the
sense
of
the
room,
if
I,
if
I
ever
misinterpreted
it,
it
was
that
this
might
be
useful
work
and
works
for
XI.
B
So
we
good
discussion
both
offline
with
Carsten
cloud
option
using
payment
and
whose
code
today,
yes
as
well
as
all
the
mailing
list
with
nice
receipt
from
Jimin
and
further
comments
from
me
from
Christian,
just
to
say
that
this
is
it's
not
been
around
for
ages,
but
it's
not
completely
in
life
or
so
maybe
this
is
actually
a
good
time
to
discuss
what
we
want
to
do
with
that
with
a
wider
group.
Let's
call
this.
Hopefully
very
short.
Presentation
is
first
recap
a
bit
what
the
proposal
is.
B
Obviously,
I'd
recommend
you
go
and
read
the
draft
as
well
and
second
to
present
some
pending
issues
and
questions
and
third
proposed
one
specific
way
forward
that
we
have
discussed
between
the
quarters,
which
we
informally
call
the
core
organization,
and
you
get
the
hint
from
that.
Finally
discuss
the
draft.
Let's
say
fate:
okay!
B
So
the
problem
has
this
simple
form
with
a
global
area
in
the
local
area.
The
global
area
contains
good
points
of
to
source,
allow
precise
or
identification
namespace
and
type,
and
the
second
category
that
comprises
common
fields
that
are
likely
to
be
shared
across
many
resolve
errors.
Let's
say
the
variable
part
for
for
those
with
an
inclination
towards
asn.1
can
be
seen
as
an
enemy
find
by
name
space
finding
space,
so
the
keys
defined
here
have
scope,
meaning
line
spacing
is
used
as
one
would
expect
as
the
semantic
anchor
these
NS
code
points
name.
B
So
it
is
that
when
and
if
an
API
goes
public
remembering
happens,
bike
revving
in
public
and
it's
good
point
from
the
registry
and
maybe
providing
a
spare
document
with
that.
But
it's
not
it's
not
mandatory
and
the
rest
I
mean
all
the
types
and
any
extension
that
comes
with
it
stay
the
same.
So
basically
remembering
the
Divi
numbering
operation
consists
of
re3
routing
the
semantic
tree.
B
B
See
some
problems
over
operation
with
localization
hi
Jim.
So
is
there
anything
we
do
to
help
here?
Should
we
recommend
a
default
language
as
we
stand,
it
looks
like
something
can
be
done
at
least
the
title
metal
by
mapping
msn
tied
to
the
localized
title
string.
But
then
the
variable
parts
like
details
in
any
extensions
are
much
more
tricky
to
handle.
B
Okay,
so
for
reference,
you
can
look
at
appendix
B
of
RFC
66
48,
if
you're
interested
there's
a
good
analysis
on
the
problem.
There,
in
a
nutshell,
is
that,
when
moving
from
private
to
public,
if
the
producer
doesn't
update
and
therefore
the
private
names
base
sticks
in
the
environmental
consumers
buy,
by
which
I
mean
not
just
the
cool
Clarence
but
the
whole
logging
pipeline,
or
at
least
significant
chunks
of
it,
they
need
to
cope
with
that
for
an
unbounded
amount
of
time.
B
Here
is
that
consumers
don't
seem
to
have
much
power
in
this
tribal.
So
what
could
we
say
here?
No,
she
did
this,
provide
some
guidance,
discussion
and
strategies
for
minimizing
the
risk
of
is
eternal
pollution,
but,
for
example,
I
recommend,
sweet
or
whatever
automated
software
ugly
mechanism
prefer
would
be
one
thing,
but
maybe
there's
more
to
do
there.
B
Was
a
question
from
Jim
Jim
suggested
subsuming
did
a
gnostic
pilot
under
the
problem
structure,
so
not
for
all
agnostic,
palin
hughes,
but
at
least
for
the
extended
tracing
pattern,
which
seems
to
be
very
useful
in
both
from
an
api
developer
point
of
view,
as
well
as
the
to
diagnose
a
by
pathological
situations
in
the
field.
So
we
need
to
do
that.
We
could
do
that
very
simply
by
adding
an
optional
diagnostic
team.
The
global
map,
which
we
don't
have
at
the
moment
discussion.
These
questions
seem
a
bit
doubtful
about
that.
B
His
comment
was
the
API
said
something
similar
could
add
their
own
extension,
and
that
is
very
true.
In
fact
grabbing
it
you
could
point
in
local
map
is
very
cheap,
very
cheap
operation,
so
I
think
the
question
is:
is
this
usage
pattern
going
to
be
common
and
useful
enough
that
it?
It
is
worth
factoring
it
out
proactively
or
not.
B
Transition,
yes,
so
the
idea
hi,
Klaus
and
myself
have
been
discussion
discussing
is
about
moving
these
42
quorum.
If
you
do
pro
cons
analysis,
we
have
on
the
good
side
the
fact
that
this
would
be
technically
superior
in
that
it
completely
absorbs
encoding,
compression
and
transfer
to
be
right
and
then
there's
a
dual
aspect
as
well.
That,
from
the
core
point
of
even
problem,
provides
a
fully
integrated
and
reusable
people
block.
That's
the
quarrel
toolbox
could
use
the
coincide.
There's
the
dependency
on
quarrel
machinery
and
things
to
understand
is
how
strong
is
the
dependency.
B
So
can
we
make,
for
example,
a
minimalist
implementation
that
is
comparable
in
complexity
to
the
current
spec
or
not,
and,
and
the
other
thing
is
so
long,
will
it
take
to
get
it
out,
which
is
really
a
question
about
coral
stability
at
this
point
in
time,
in
a
sense
that
how
can
we
detect?
When
can
we
expect
Cora
moving
the
moving
parts
of
coral
to
be
stable
enough
to
become
still
good
enough,
so
that
we
can
put
this
on
top
of
that?
B
Yeah
there
are
three
big
questions.
I
see
here,
first
and
foremost
is
whether
standardization
of
a
problem
format
is
actually
good
or
not
and
Sebastian
it.
Certainly
that
is
it's
the
question
about.
Is
this
the
document
in
this
shape,
ready
for
adoption
or
not
and
and
third
as
the
parking
bytes
us
to
cool
it
is
whether
to
quarrel
and
not
to
quarrel.
I
have
a
I
know
how
to
answer.
Do
the
last
one
I'd
like
to
hear
from
the
group.
A
Before
going
sorry
for,
thank
you
for
the
presentation
very
good
before
going
into
the
queue,
I
would
like
to
quickly
ask
who
has
read
the
draft
on
the
you
can
answer
on
the
WebEx
or
on
the
jabber.
A
On
the
jabber,
and
then
if
you
could
also
mention
in
the
jabber
now
a
will
be
in
favor
of
adopting
this
draft
in
core.
We
thought
whether
to
coral
or
not
to
coral,
we
may
go
for
a
link
format.
Well,
I
mean
I'll,
prefer
coral
of
is
I,
see
only
a
plus
will,
apart
from
the
others,
I
suppose,
I
see
three
four.
A
C
A
E
A
A
Okay,
so
I
mean
this
document
is
actually
rather
simple.
It's
a
shame.
We
didn't
have
the
time
for
the
presentation.
We
can
send
it
to
the
list,
but
I
mean
this
is
something
we
need
we
have
been
discussing
before
with
the
cinema
more
units.
We
have
had
a
lengthy
discussion
with
the
ad
and
it
this
was
a
comment
that
basically
was
voiced
out
and
the
document
itself
is
rather
simple,
so
I
think
we
should
adopt
it
but
I.
A
A
A
Enough
so
less
they
say
for
adoption
on
this
one
will
say
to
the
main
list
and
then
people
will
be
able
to
discuss
it
there
as
well.
Thank
you,
sorry
again,
for
the
lack
of
time.
We
didn't
maybe
think
this
through.
We
were
too
ambitious
on
the
timing.
Sorry,
for
that
we'll
have
a
lot
of
interviews
to
discuss
everybody.