►
From YouTube: IETF-CORE-20220511-1400
Description
CORE meeting session at IETF
2022/05/11 1400
https://datatracker.ietf.org/meeting//proceedings/
A
Okay,
so
welcome
everyone
to
this
intermeeting
of
the
co-working
group,
I'm
marco
tiloca.
My
co-chairs
are
high
mahi
menetz
and
carsten
berman
and,
as
usual,
the
not
well
applies-
and
this
is
an
official
itf
meeting,
we've
been
recorded,
be
sure
to
be
familiar
with
the
not
well.
If
you're
not
already,
it's
not
only
about
apr.
It's
also
about
code
of
combat,
so
please
be
nice
and
professional
with
one
another.
A
We
should
be
okay
but
any
further
bashing
to
the
agenda.
Otherwise,.
C
A
C
Okay,
there's
something
happening
with
my
machine,
so
there
is
a
good
chance
that
something
might
go
wrong,
but
let's
just
hope
that
this
is
okay.
Now.
C
C
Okay,
so
hello,
everybody-
and
I
see
that
we
don't
have
very
many
participants
today,
but
there's
everything
in
jabba.
But
I
firstly
apologize
that
I
couldn't
stay
for
the
whole
session
and
I
needed
to
start.
C
I
needed
to
start
the
the
presentation
as
there's
the
first
first
presenter
so,
but
let's
continue
so
I'm
going
to
be
presenting
the
conditional
attributes
are
draft
the
work
that's
going
on
there.
The
the
quick
update
is
that,
a
few
days
ago
I
was,
we
were
draft
version
zero.
C
Two
and
now
we
have
moved
up
to
zero
four,
the
the
reason
being
that,
as
soon
as
I
updated
to
zero
three,
there
was
another
addition
that
was
sent
to
the
to
the
document,
and
then
I
I
then
incorporated
that
just
just
in
terms
of
this
meeting
so
so
version
zero
three
had
something
to
do
with
the
with
the
parameter
names
and
then
version
zero.
C
Four
has
this
reference
code
and
to
take
the
the
list
of
the
two
first,
the
reference
code
was
simple
update.
C
It's
just
that
the
previous
code
was
from
the
old
time
being
draft
it
existed
for
a
while
and
then
the
other
thing
also
was
that
we
changed
the
the
parameter
type
of
band
and
so
on,
so
that
it
was
a
presence
parameter
rather
than
one
with
a
boolean
value.
So
michael
updated
the
draft,
we
included
the
functionality
of
h
inside
the
draft
as
well.
C
What
I
mean
cell
reference
code
as
well,
so
not
very
controversial,
quite
straightforward
and
then
the
next
part
was
about
the
parameter
names,
and
I
wasn't
here
at
the
last
interview
meeting
we
didn't
have
a
discussion,
but
in
the
idf
113
we
were
discussing
about
the
the
parameter
names
in
conditional
attributes
and
there
were
some
opinions
here
and
there.
So
some
people
were
kind
of
okay
with
anything.
C
If
I
could
just
continue
speaking
from
where
I
left
off
and
please
let
me
know
if
if
there
is
a
disconnect
from
my
audio,
so
at
the
last
call
meeting
we
we
were
talking
about
the
parameter
names
and
the
simplest
option
seemed
to
be
to
to
amend
the
attribute
names
slightly
without
calling
it
a
namespace,
but
anyway,
just
to
prevent
any
kind
of
clashes.
C
It
seemed
the
best
thing
to
do
is
to
is
to
prepend
some
something
to
the
parameter
name.
So
so
I
decided
that
maybe
c
dot,
something
might
be
nice,
so
p
main
becomes
c
dot,
p
min
and
so
on
down
the
list,
and
that's
that's
the
only
change
I
made
to
the
the
draft
and
that's
all,
that's
all
that's
been
done.
Otherwise
all
the
issues
have
been
resolved.
So
this
is
okay
with
everybody.
Then
we
should
be
moving
to
working
group
last
call.
C
D
D
I
don't
know
I
haven't
thought
about
it.
I
think
c
dot
is
fine,
but
yeah,
so
that
will
be
an
faq.
C
We
might
have
to,
of
course
answer
some
questions
about
that.
But
but
essentially
it
was
just
a
name,
it
was
a
character
picked
at
random
and
and
it
seemed
to
be
a
nice
one
considering
we
have
so
many
things,
starting
with
c.
D
Yeah,
I'm
just
wondering
what
the
next
draft
that
picks
up
on
this
convention
is
going
to
do
if
they
also
were
using
c
or
maybe
using
a
different
one,
and
maybe
we
could
warn
a
little
bit
on
on
how
we
plan
to
use
this
in
the
future.
I
mean
this
is
the
infraction
on
the
front
law
of
the
server
developer.
D
Obviously
forget
the
bcp
number,
and
so
we
will
do
this
with
a
lot
of
restraint.
Yeah,
that's
just
a
meta
comment:
it
doesn't
in
no
way
influences
the
the
the
progress
of
this
drought.
C
Yeah,
I
think
I
think
we
we
will
have
to
wait
for
comments
from
others
as
well
and
then
and
then
see
if
there
is
need
for
for
change
here,
but
essentially
it
was
just
the
simplest
thing
to
do
to
to
prevent
any
kind
of
like
overlaps
in
future.
Of
course,
if,
if
somebody
decides
to
do
that,
then
no
anybody
can
use
these
names,
of
course,
but
they
seem
to
be
the
most
obvious
way
of
doing
this
right
now.
A
A
Okay,
okay,
thank
you
bill.
Any
more
comments,
questions
for
bill.
A
And
then
I
think
indeed
the
natural
step
here
is
to
start.
The
working
group
last
call
on
this
document
for
two
weeks,
so
we
started
today
ending
on
wednesday
25,
so
I'll.
C
A
D
D
May
10th
yeah
okay,
so
we
had
a
pretty
good
discussion
about
this
two
weeks
ago,
so
I'm
I'm
going
to
quickly
remind
people
what
this
was
a
about.
D
So
there
is
an
rfc
7807
that
gives
some
some
structure
that
you
can
use
to
send
back
with
an
error
response.
D
That
they,
they
don't
have
enough
balance
on
their
account
to
pay
for
excuse
me
and
then
you
could
receive
this
problem
detail
statement,
and
this
has
a
number
of
standard
components,
type
title
detailer
instance
and
a
few
application
specific
components
like
balance
and
accounts
the
this
is
being
used
by
3gpp
and
because
3gpp
also
wants
to
be
able
to
do
similar
things
in
the
the
co-op
sieber
environment.
D
They
were
expecting
that
we
were
going
to
finish
our
problem,
details
document,
which
has
been
sitting
there
since
july
2020
waiting
for
the
completion
of
coral,
and
they
really
need
this
like
next
month.
So
we
agreed
to
to
quickly
finish
this
in
in
a
way
that
hopefully,
will
still
show
a
way
forward
to
doing
this
in
coral
at
some
point
in
time.
But
we
cannot
expect
coral
to
be
done
next
month.
D
So
we,
we
discussed
two
approaches
last
meeting
and
there
was
a
little
more
discussion
after
the
meeting
and
there's
also
a
ton
of
discussion
in
the
rfc
7807
bis
github
repository,
because
the
the
http
api
group
is
discussing
what
what
the
next
version
of
that
document
would
be.
D
And
it's
really
very
interesting
to
to
see
that
they
try
to
get
by
without
a
registry,
and
that's
that
has
turned
out
to
be
very
problematic.
So
we
decided,
whatever
we
want
to
do,
will
probably
make
the
use
of
of
the
registry
and,
in
particular
the
the
type
element
the
type
member
excuse
me
of
the
the
json
map
has
turned
out
to
be
problematic
because
that's
a
uri
actually
structurally,
but
people
actually
pull
put
the
simple
strings
there,
and
and
without
knowing
implicitly
invoke
uri
resolution.
D
Ui
reference
resolution
and-
and
you
get
weird
results
from
that
and
so
on.
So
we
we
really
decided.
We
didn't
need
that
type
thing,
but
what
we
need
is
something
called
custom
problem,
details
entries
which
not
just
gives
the
the
type,
but
also
all
these,
these
other
things,
the
the
balance
and
the
account
from
from
from
this
example.
D
These
are
really
things
that
only
mean
anything
in
the
context
of
their
type,
so
it's
probably
a
better
idea
to
actually
define
them
in
the
same
environment
in
which
the
type
itself
is
is
being
created.
D
In
the
end
there
we
also
have
a
map
with
with
members
that
can
be
registered
and
the
the
interesting
point
here
like
cwt,
you
can
have
multiple
elements,
I'm
saying
element
again,
multiple
members
of
that
map,
which
are
registered
separately
from
each
other,
but
that
combine
into
a
reasonable
picture
of
the
problem.
So
you
might
have
a
general
custom
probability
entry
for
the
status
of
your
account
and
then
you
might
have
a
specific
entry
that
comes
with
that.
D
That
explains
how
that
status
of
the
account
didn't
quite
make
the
execution
of
the
request
possible
so
that
there
is
something
a
little
bit
like
multiple
inheritance
going
on
here,
but
without
all
the
problems
that
has
in
a
programming
language
and
that
can
turn
out
to
be
a
quite
useful
way
to
actually
factor
the
the
problem
detail
space.
D
So
this
is
an
example.
I
had
the
last
time
that
has
hasn't
changed,
so
the
idea
is
that
we
have
some
standard
problem,
details
that
have
negative
numbers,
a
title
detail,
in
instance
for
instance,
and
we
have
registered
problem
details
that
have
non-negative
numbers
unsigned
numbers
as
their
map
keys
and
these
numbers
zero
and
one
these
are
actually
defined
in
the
the
specification
that
is
used
for
registering
47-11.
D
So
they
are
not
themselves
registered
because
they
are
nested
in
the
namespace
of
where
the
47-11
is
being
registered,
but
yeah
they
they
can
be
defined
by
by
whoever
registers
47-11,
and
there
is
an
interesting
little
problem
that
I
think
we
are
not
discussing
in
the
draft
right
now.
What
if
that
person
who
has
registered
47-11,
suddenly
thinks
there
should
be
a
number
two
as
well.
D
We
haven't
discussed
this,
but
that's
actually
a
detail
that
will
come
up
in
a
minute
in
a
different
context
anyway,
because
we
don't
expect
everybody
to
actually
register
these
things.
You
also
can
use
a
ui
in
in
a
place
of
the
registered
number,
and
that
means
you
can
actually
keep
the
whole
specification
to
your
api
documentation
and.
D
D
That
just
wants
to
build
an
api
internally.
That
might
just
use
this
mechanism
here.
D
Okay,
and
what
probably
also
is
worth
mentioning,
is
this.
D
This
example,
where
we
use
multiple
inheritance,
where
we
have
a
common
set
of
problem
details
that
are
sent
with
every
problem
detail
said:
I'm
not
sure
if
a
process
id
and
a
process
name
are
great
examples
here.
Maybe
we
should
use
something
else
and
something
that
that
is
specific
to
using
accounts
yeah,
something
like
this
can
can
be
used
for
multiple
inheritance
of
a
composition.
D
D
We
also
have
discussed
what
happens
if
somebody
has
a
78
or
7
specification
and
really
just
wants
to
tunnel
this
in
in
one
of
our
problem
details
and
it
turns
out
that's
relatively
easy,
because
we
can
just
define
a
custom
problem,
detail
entry
called
7807,
that's
the
number
of
the
we
register
for
this
thing,
and
that
has
two
entries
zero
and
one
that
are
predefined,
which
are
essentially
taking
the
type
and
the
status
that
that
we
don't
have
in
the
base.
D
D
Custom
problem
details
entry,
so
this
direction
is,
can
be
done
today.
The
other
direction,
possibly
tunneling,
coil
problem
details
instance
in
7807
problem
details
instance,
is
a
bit
difficult
because
7807
does
not
have
a
registry,
so
we
cannot
really
indicate
whether
a
problem
details
object
actually
does
this
now
78
7807.
D
This
is
going
to
define
a
registry.
I
think
that
that's
pretty
much
decided.
So
when
7807
bis
comes
out,
we
might
quickly
register
the
inverse
direction
of
of
the
tunneling.
But
we
cannot
really
do
this
now,
because
78
or
7
bits
is
still
under
development
and
I
think
it
will
become
stable
only
really
at
the
end
of
this
process.
D
D
So
yeah,
that's
essentially
the
the
set
of
things
that
are
really
about
problem
details,
but
we
have
one
more
problem.
So
when
we
recognize
call
this,
we
definitely
should
include
http
api
on
on
the
list.
So
so
they
know
this
is
being
last
called
and
can
maybe
contribute
some
of
some
more
of
the
wisdom
they
have
accumulated
in
the
708
bis
process.
Again,
the
the
github
repository
is
really
just
amazing.
You,
you
learn
a
lot
from
there,
so
there's
another
problem.
D
That
is
really
a
sibo
problem,
but
it's
not
not
so
surprising
that
we
have
this
so
in
in
sibo
we
usually
do
things
that
that
are
for
for
constraint
devices.
So
we
we
haven't
had
an
actual
need
in
cbo
based
standard,
yet
to
support
tax.
That
is
meant
for
human
consumption,
and
human
here
is
not
the
developer.
D
So,
quite
a
while
ago,
peter
axel
went
ahead
and
registered
tag
38
to
be
able
to
to
do
this,
so
there
is
a
tag
that
has
been
around
for
for
almost
a
decade
now
that
defines
a
array
of
a
language
tag
and
a
piece
of
text
as
a
way
to
do
this,
and
we
generally
like
this
thing
and
would
have
loved
to
to
use
it.
But
there
is
a
problem
here,
because
the
the
internationalization
people
have
decided.
D
You
really
cannot
infer
a
writing
direction
from
a
language
tag,
and
you
really
need
to
read
these
two
two
references
that
are
on
the
slide
to
fully
understand
why
that
is
the
case.
So
you
often
can
guess
the
base
direction.
But
this
this
guessing
is
is
very
ad
hoc.
It's
a
little
bit
like
media
type
sniffing,
so
you
will
be
right,
95
percent
of
the
time,
but
you
you
essentially
as
a
sender
of
these
data
objects.
D
D
D
Problem
detail,
then,
you
really
should
be
telling
people.
This
is
a
right
to
left
string
and
it
this
ring
is
actually
really
funny
because
in
my
editor,
it's
shown
left
to
right
and
in
the
slide
presentation
software,
it's
right
to
left,
so
it
right
there
demonstrates
the
the
the
problem.
While
I
was
editing
these
slides
anyway,
so
this
is
new.
This
is
something
that
take38
couldn't
do
so
far
and,
of
course,
we
could
decide.
D
Let's
just
do
this
completely
separate,
define
a
new
tag
for
direction
or
actually
probably
one
hr
tag
and
one
r2l
tag.
That's
one
way
of
doing
this.
D
D
Zebra
documents
that
can
be
probably
interpreted,
but
this
is
in
a
tag
and
again
we
we
haven't
done
that
yet.
On
the
other
hand,
it's
it's
essentially
from
the
point
of
view
of
somebody
who
who
tries
to
do
the
the
right
thing
for
initial
internationalization.
D
This
is
just
a
severe
bug
of
of
the
existing
tank
38
definition,
so
this
would
be
a
bug
fix
a
bug
fix
that
conveniently
gives
us
the
the
functionality
we
need
here,
but
that
is
really
required
for
any
proper
use
of
this
tag
38.
So
I
would
feel
much
less
unhappy
with
to
be
then.
I
would
be,
for
instance,
in
in
fixing
tag
for
the
floating
point
tag
to
actually
increase
its
domain
to
big
num
exponents.
D
and
that's
okay,
because
different
areas
of
application
will
be
fine
with
tag
four
or
will
need
the
additional
complexity
of
two
six
four.
So
it's
proper
to
separate
that,
but
here
for
for
language
taking,
there
is
no
proper
use
to
use
a
tag
of
for
a
tag
like
38
as
it
has
been
defined
because
you
need
to
supply
the
direction
information,
at
least
according
to
the
consensus
of
the
people
who
are
who
have
been
discussing
this
subject
for
the
last
decade
or
so
yeah.
D
So
the
the
text
on
this
slide
is
is
taking
right
off
out
of
the
document,
so
take
38
would
be
defined
as
an
array
with
two
mandatory
and
a
third
optional
element.
The
take
38
direction
would
be
a
false
or
a
true
where
fault
stands
for
atr
and
true
stands
for
the
rtl,
and
while
we
are
there,
we
might
actually
import
the
language
text
syntax
from
rfc5
into
the
cdl.
D
So
the
the
summary
from
the
authors-
it's
too
bad-
that
thomas
cannot
be
here
due
to
a
conflict
that
came
up
recently.
The
the
view
from
the
authors
is
that
this
is
ready
for
wikileaks
call.
A
Sounds
like
no
okay,
I've
read
the
whole
document
this
morning.
I
think
it
is
pretty
stable
and
also
considering
the
urgent
schedule.
A
D
Would
that
work
for
you
kirsten,
certainly
the
the
I
think,
the
the
of
all
the
the
elapsed
terms
we
use
in
the
itf,
the
the
working
blast
call
period
is
probably
the
the
most
sacred.
D
So
I'm
I'm
not
sure
that
we
are
so
urgent
that
we
actually
have
to
violate
that,
but
you
you
can
could
make
it
so
that
in
in
the
next
interim
we
have
the
results.
So
you
could
make
it
tuesday
evening
or
something
exactly
then.
A
We
can
close
it
on
the
24.
yeah,
that's
fine
and
yeah.
It
was
the
plan
already
to
include
sieber
in
the
loop.
As
you
said,
http
api
will
also
be
put
in
copy
yeah.
A
That's
great
and
yeah.
You
can
see
from
the
chat.
Christian
has
all
your
issues,
but
it
take
the
the
zebra
point
separately
in
cbore,
as
it's
done
here,
I'm
going
with
it.
Okay
and
you
can
also
review
so
we
should
have
two
reviews,
at
least
otherwise.
More
are
welcome.
A
E
E
D
Go
to
the
thing
at
the
top,
where
there's
a
hand
right
to
the
hand
yep
thanks.
Sorry,
I'm
gonna.
E
D
E
Great,
I'm
sorry,
I'm
not
still
not
used
to
this
too.
Okay,
so
yeah
hi,
I'm
martin.
I
want
to
talk
about
our
draft
again,
the
dns
queries
of
a
co-op
draft,
and
so
first
I
give
a
quick
introduction
for
those
who
don't
know
about
this
and
then
go
right
into
the
discussion
section,
basically
picking
up
what
we
started
at
the
last
itf
meeting.
E
So
our
attack
scenario
is
basically
that
we
that
people
can
eave
drops
dns
requests
and
as
a
counter
measure,
we
want
to
encrypt
this.
There
are,
of
course,
solutions
like
doh
or
doq,
but
we,
but,
as
most
of
you
know,
this
is
not
feasible
for
the
constraint
iot.
E
So
our
proposal
is
to
do
dns
over
corp
and
use
encrypted
communication
that
we
have
there
with
either
dtls
or
score,
and
this
also
would
give
us
some
additional
advantages
that
by
the
co-op
api
by
the
core
suit
that
like
block
wise
transfer
or
that
we
can
share
the
system
resources
with
the
co-op
implementation.
Making
this
the
implementation
of
dns
a
bit
smaller.
E
And
yeah,
basically,
from
the
update
perspective,
we
didn't
do
much
on
the
draft
since
itf,
but
we
did
do
some
evaluation.
E
Last
time
I
spoke
here,
we
presented
two
options
on
how
to
deal
with
discrepancy
between
the
co-op
max
h
and
the
dns
ttl
ttl,
and
this
was
do
it
like
either.
Do
it
like
doh,
or
do
it
like
with
this,
what
we
now
call
eol,
where
we
basically
adopt
the
ttls
to
the
minimum
ttl?
So
basically
one
is
one
of
the
ttl.
So
all
of
the
tdls
are
zero.
E
So
we
have
also
now
a
simplified
version
where
we
basically
just
say:
okay,
take
the
ttl
and
set
it
to
zero
and
then
at
the
client.
We
set
it
to
the
max
h
and
of
course,
this
only
assumes
that
there
is
one
record
set
cases
where
there
are
multiple
records
as
this
for
examples
in
an
end
user
setting
the
cname,
where
you
have
the
cname,
but
most
of
these
this
time
at
the
times
these
ttls
are
also
in
sync.
E
So
here's
our
evaluation
of
this,
as
you
can
see
in
the
cdfs,
for
when
there
is
no
caching
most
of
the
methods
actually
compared.
We
use
different
methods
other
than
the
one,
the
fetch
method
we
presented
in
the
we
proposed
in
the
draft,
so
we
can
actually
see
the
caching
effects
and,
with
the
do
h-like
approach,
we
already
get
some
see
some
huge
benefits
for,
of
course,
get
and
fetch
which,
where
the
responses
are
cachable
but
for
posts.
E
Actually,
we
see
some
disadvantages
due
to
the
additional
overhead,
and
with
year
ltts
we
actually
see
a
little
bit
of
a
a
little
bit
of
an
advantage
of
that.
E
The
smallness
of
the
advantage
is
actually
because
of
our
setup,
because
we
just
had
two
hops,
and
so
there
wasn't
much
that
could
be
optimized,
but
we
get
with
a
set.
There
is
some
advantage
because
fetch
and
get
profit
from
it
and
the
year
out
benefit
benefits
from
the
cash
validation
where
we
have
ten
percent.
E
More
queries
received
in
less
than
two
seconds
within
the
first
three
transmissions
with
get
because
they
get
gains
more
benefit
because
the
query
actually
is
fragmented
and
with
fetch
we
get
about
five
percent
small
queries
in
the
first
retransmission,
then.
The
other
issue
I
wanted
to
bring
up
again
is
how
abstract
the
draft
should
be
in
that
was.
E
This
was
a
little
bit
discussed
on
the
mailing
list,
that
and
rather
than
to
doing
some
heavy
protocol
specifications
specific
by
just
the
rest
api
that
the
server
needs
to
implement
and
then
leave
the
specifics
to
the
implementations.
E
Carson
interpreted
this,
as
that
klaus
was
only
pointing
out
the
so-called
restatement
anti-pattern.
However,
when
we
discussed
this
a
bit
between
the
courses,
there
was
some
disagreement
about
this,
so
that
that
we
don't
do
this.
But
maybe
we
do
this
so
just
to
bring
this
up
on
the
discussion
again.
E
C
E
Just
to
not
have
them
forgotten,
but
in
the
interest
of
time
I
didn't
mention
them
here.
There's
also
these
other
two
points
of
do.
We
need
consider,
observe
and
a
sibo
based
message,
content
format,
which
I
started.
The
discussion
thread
on
the
mailing
list,
as
proposed
by
marco
last
time.
E
Yeah,
that
was
always
a
plan.
Sorry
yeah.
D
So
observe
would
be
really
interesting.
I
haven't
thought
about
that
very
much,
but
I
think
that
that
that's
really
great
so
one
of
the
we
have
this
project
going
on,
where
we
try
to
do.
D
Network
security
based
on
mod
specifications
and
and
one
of
the
problems
with
mod
specifications
is
that
they
describe
connectivity
in
terms
of
dns
names,
usually
at
least,
and
the
problem
is
of
course,
if
the
ip
address
behind
the
dns
name
changes,
you
actually
have
to
change
your
network
filter,
and
so
something
like
like
an
observed
function
would
be
interesting
there.
But
this
is
more
of
a
research
thing
right
now
and
not
something
that
that
we
already
know
how
to
use
operationally.
D
But
the
the
danger
here
and
the
actual
anti-pattern
is
if
the
document
tries
to
make
normative
statements
that
essentially
restate
elements
of
the
normative
references,
because
it's
just
way
too
easy
to
suddenly
change
the
base
standard
that
you
are
ostensibly
are
using
and
the
the
worst
case
that
can
happen
is
that
you
actually
fog
the
ecosystem
by
by
creating
a
special
version
of
co-app
that
is
needed
to
actually
run
your
your
protocol
so
that
that's
the
problem
with
the
the
restatement
anti
pattern.
D
I'm
not
sure
anybody
has
written
this
up,
but
in
in
the
the
time
I've
been
in
the
idf.
I
have
seen
this
multiple
times
and
and
often
with
actually
ugly
results
and,
and
so
so
referencing
standards
have
unwittingly
changed
the
reference
standard
by
restating
things
in
there
and
so
on.
So
let's
try
to
avoid
the
statement
anti-pattern.
So,
let's,
let's
explain
this
in
term
of
let's
define
this
in
term
in
terms
of
what
what
the
co-op
service
interface
is.
D
But
let's
also
have
examples
that
that
bring
this
back
to
to
the
ground,
and-
and
so
you
can
have
both
feet
on
the
ground
and
see
what
that
actually
means,
and,
of
course,
by
by
doing
this
as
a
rest,
yeah
api
is
so
what
I
don't
like
very
much
but
anyway
doing
this
by
by
defining
this
on
top
of
rest
patterns,
of
course,
gives
you
the
the
best
reusability
of
of
this
specification.
D
We
have
seen
exactly
the
same
problem
when
people
were
putting
eap
on
top
of
cowep,
so
they
they
were
trying
to
explain
for
for
every
eap
message
how
that
is
mirrored
in
a
co-op
message
and
of
course
that
means
they
have
to
explain
all
of
cohab
again
or
they
are
defining
a
new
protocol
that
it
all
is
almost
but
not
entirely
unlike
corp,
and
we
managed
to
to
stop
that
there-
and
I
would-
I
haven't,
reread
this
draft
in
in
a
while,
but
I
I
would
love
if
we
could
avoid
running
into
the
same
problem
here.
E
Interestingly
enough,
when
it
comes
to
examples,
we
saw
that
for
doh
exactly
that
problem
happened
when
they
used
the
exam.
When
we,
when
you
look
at
the
examples,
because
it
seemed
that
some
of
the
servers
basically
or
some
of
the
users
expected
the
url
for
the
dns
resource
to
be
like
it
is
proposed
in
the
examples,
even
though
the
actual
rfc
doesn't
say
anything
about
how
the
url
has
to
look
like
like
I
don't.
I
think
it
was
like.
E
Subject:
indian
s,
minus
query,
and
so
basically
every
user
of
doh
now
expects
the
the
doh
server
to
present
to
serve
the
dns
messages
at
dns
minus
query,
even
though
that
isn't
in
the
standard,
but
so
for.
To
give
some
example
where
the
example
basically
defines
the
standard
somehow
but
but
but
from,
but
actually
for
our
example.
E
If
we
lesson
learned
or
from
that
situation,
we
try
to
make
it
clear
that
this
is
not
what
we
want
and
I
actually
think
we
need
use
the
root
resource
basically
to
make
this
a
bit
clearer
but
other
than
that.
E
Well,
we
set
use
fetch
and
we
said,
use
block
voice
transfer
when
the
message
is
too
big,
but
I
don't
think
we
basically
said
that
something
that
contradicts
the
actual
standard,
maybe
with
a
coup
block
option.
This
could
run
into
problems,
but
on
the
other
hand,
when
it
comes
to
rest
apis,
defining
rest
api,
I'm
a
little
bit
afraid
that
it
then
becomes
too
abstract.
And
then
we
have
differing
dog
standards,
because,
while
the
implementers
implement
the
rest
api,
how
they
do
it
is
differing
with
among
the
implementations
a
bit.
D
So
generally,
we
have
tried
to
define
interactions
on
resources
and
leave
it
to
the
server
what
the
exact
ui
for
that
resource
is
going
to
be
so
the
the
entry
point
is
server
defined
and
we
usually
then
use
resource
difficut
discovery
to
actually
find
this
place
and
since
resource
difficult
discovery
meshes
nicely
with
service
discovery.
This
is
not
just
unnecessary
overhead,
but
this
is
actually
useful,
so
you
could
go
for
for
for
a
multicast
request.
D
This
is
there
anyone
who
has
an
arty
equal,
something
and
then
right
ahead,
use
that
as
a
dns
reserver
yeah,
but
what
you
just
should
try
to
avoid
is
saying:
oh
and
then
a
retransmission
happens,
or
this
needs
to
be
done
in
a
separate
response
or
something
like
that.
That's
fine
for
an
example,
but
that's
not
fine
for
for
actually
defining
the
protocol.
E
Yeah,
I
guess,
but
we
don't
do
that,
but
we
can.
We
can
go
through
the
draft
again
and
maybe
maybe
find
some
ways
where
we
can
be
more
abstract.
I
guess,
but.
D
Yeah,
if
you're
already
doing
this,
this
is
great.
I
just
wanted
to
point
out
that
this
restatement
stuff
is
happening
as
it
did
in
the
ace
working
group
with
the
the
eap
over
grab
work
and,
let's,
let's
try
to
minimize
that
as
much
as
possible.
A
E
Yeah
there
was
sadly
little
feedback
last
time,
but
maybe
push
putting
this
on
the
table
here
again.
Maybe
some
more
discussions
can
happen
right.
D
D
Yeah,
so
the
the
way
I
see
this
is
that
we
we
need
a
couple
of
people
who
do
what?
What
I
just
said,
and
if,
if
these
reviews
point
out
that
this
thing
is
ready
for
adoption,
then
we
should
have
a
another
look
at
our
charter
and
see
whether
we
actually
can
fully
justify
why
this
is
in
our
charter
and
and
then
adopt
it.
D
Yeah,
so
we
don't
have
to
to
have
a
to-do
free
document
to
adopt
it.
We
definitely
have
to
do
a
to-do
free
document
to
last
call
it.
But
if
people
who
really
would
like
the
general
direction
and
agree
that
that
a
this
is
something
they
want
to
spend
energy
on,
completing
and
and
b,
it's
not
going
to
to
kill
the
internet
or
something
like
that.
E
Okay,
so
for
my
end,
there's
not
more
things
to
discuss.
E
E
I
mean
there
was
some
people
already
who
said
during
the
itf
that
they
want
to
review,
but
we
didn't
receive
any
reviews
from
that.
Maybe
those
people
can
be
reactivated
and
I
also
wanted
to
ping-
maybe
some
dns
up
people
if
they
could
look
over
that.
D
Yeah,
I
think
it's
important
when
you're
pinging,
the
dns
of
people
to
say
we
are
just
in
the
state
of
adopting
this
so
tell
us
where
we
are
completely
wrong,
but
we
we're
not
yet
looking
for
the
last
dot
on
the
eye
and
then
the
cross
on
the
t.
I
think
that
that's
usually
important
to
explain
the
the
what
they
should
be
expecting.