►
From YouTube: IETF113-ANIMA-20220325-1130
Description
ANIMA meeting session at IETF113
2022/03/25 1130
https://datatracker.ietf.org/meeting/113/proceedings/
A
A
The
one
thing,
that's
always
very
much
appreciated
for
the
people
in
the
room
when
you
step
up
to
the
microphone
before
that,
please
you
know
click
on
raise
the
hand
so
that
the
remote
audience
will
also
see
your
name
in
the
queue.
I
think
that's
the
most
important
one,
otherwise
standard
procedures,
itf
note.
Well,
everything
is
public
and
there
are
a
lot
of
interesting
bcps.
When
you
can't
sleep
that
you
should
be
aware
of
right
logistics.
I
think
there
is
nothing
of
importance
here.
A
A
So,
let's,
let's
go
through
some
of
these
reminder,
slides
here
that
I
hope
are
always
useful.
We've
got
the
early
ipr
disclosure
process
so
by
the
time
that
we're
adopting
a
document
we're
already
asking
the
ipr
question
so
that
we're
not
surprised
later
on
about
a
possible
ipr
in
the
document.
When
we
try
to
offload
the
document
to
isg
to
become
an
rfc.
A
We
also
now
have
eight
rfcs
so
especially
for
the
folks
amongst
you
that
are
implementing
either
of
those
when
you
find
any
bugs
and
problems,
of
course
raise
them
with
a
list.
But
specifically
when
they're
against
the
text,
we
have
an
errata
system
in
the
ietf
that
allows
you
to
track
any
such
textual
issues
and
when
you
are
implementing,
you
obviously
also
want
to
read
the
erratas
of
of
those
rfcs
in
case
they
do
impact
the
implementation,
which
I
think
a
few
of
them
do
so
right.
A
So
now,
let's
get
through
the
actual
working
documents
that
we
have
so
the
first
one,
the
oldest
one,
is
the
asa
guideline
document.
There
is
no
slot
for
it.
I
think
the
main
author
is
well
asleep
in
new
zealand
right
now,
and
it
is
an
auth
48
for
45
days.
So
I
think
that
leaves
it
three
more
days
no
kidding
but
yeah.
It
should
be
a
an
rfc
pretty
soon
and
I'm
not
aware
of
any
issues
in
the
author
48
process
left.
A
48
hours
48
days,
I'm
sorry
that
was
a
a
badly
explained
joke,
but
yeah
I'm
yeah.
It's
it's
actually
meant
to
be
48
hours,
but
we
are
seeing
a
large
variation
of
how
long
earth
48
takes
so
that
number
of
days
is
actually
not
not
really
untypical
for
how
long
that
stage
of
the
process
takes
sorry
for
reminding
me
that
that
joke
should
have
been
explained
all
right,
then
so
I've
been
trying
to
track.
A
You
know
where
work
actually
happened,
so
you'll
see
that
most
of
the
working
group
documents
that
we
have
have
been
doing
good
work
and
we're
having
slots
for
them.
So
no
need
to
mention
that
in
more
detail
here,
what's
specific,
so
we've
got
the
constraint
join
proxy.
That
is
in
the
process
of
being
submitted
to
isg.
So
I
think
the
current
state
is
a
ad
review,
so
that's
hopefully
going
through
well
we'll
hear
in
the
slot.
A
We've
got
the
brucey
essing
and
roll,
where
there
will
be
a
name
change
coming
up.
That's
the
unusual
thing
about
that.
One
we've
got
brewski
prm
that
all
those
are
talked
in
slots.
We've
got
the
constraint
voucher
where,
in
the
last
ietf,
we
felt
we
needed
a
more
early
review
from
the
broader
community.
I'm
going
to
talk
about
that
separately
in
general,
but
that
has
happened
very
nicely.
Since
itf-112
we've
got
the
jws
voucher
standard
ongoing.
A
Now
we
have
grass
distribution.
I
talked
with
the
authors
and
there
is
no
slot
here
for
this
one.
The
shepherd
has
done
an
extensive
review
since
the
last
version
and
the
authors
are
working
on
a
reply,
but
they
couldn't
come
to
the
ietf
this
time
around.
So
that's
why
they
didn't
request
a
slot
and
and
didn't
hurry
with
their
update
to
meet
the
deadlines
for
this
idea.
So
hopefully
we'll
talk
about
that
one
in
philadelphia,
then
we've.
B
A
Right
so
one
thing
that
slipped
through
the
cracks,
michael,
the
voucher
delegation-
that's
expired,
nothing
for
it,
so
it's
it's
just
kind
of
in
the
whole
list
of
priorities
just
at
the
bottom
end,
all
right.
So
let
me
just
quickly
take
a
note
on
that.
One
voucher
delegation:
it's
just
low
priority
versus
the
other
working
group
drafts.
Okay,.
A
C
A
A
A
Just
let
me
quickly
finish
and
get
to
the
the
real
work.
So
one
of
the
ongoing
issues,
please.
You
know
when,
especially
when
you're
an
author
of
a
document
in
the
working
group,
you
know
mutually
review
other
working
group
documents
to
help
the
the
working
group
to
really
do
its
job
and
move
forward
and
if
you're
not
sure
which
document
would
be
good
for
you
to
review.
Just
ask
us
shares
and
I
will
be
happy
to
help
doing
that.
A
So
I
guess
we,
as
working
group
chairs,
are
going
to
reach
out
more
to
the
authors
of
of
the
different
documents
to
help
that
to
help
more
mutually
in
the
coming
months
as
appropriate,
seeing
which
of
these
documents
are
far
enough
in
the
process
that
a
shepherd
would
really
be
helpful
technical
discussions.
So,
yes,
these
working
group
meetings
are
always
overboarding
with
process
status
updates,
but
that's
just
the
cost
of
doing
business
in
an
organized
fashion,
and
it's
not
the
only
way
on
how
we
can
do
work.
A
A
A
Sent
out
to
list
okay
right,
so
that's
another
tpd
for
me,
we'll
we'll
send
an
update
for
that.
Also,
we
do
have
a
github
it's
great,
especially
when
you
want
to
collect
and
structure
any
feedback
that
you're
getting
one
of
the
most
easy
things
to
make
sure
that
any
concern
you
have
about
a
document
doesn't
get
lost
in
mailing.
This
discussion
is
to
open
up
an
issue
in
the
github
entry
for
that
particular
document,
and
that's
already
a
good
enough
reason
that
all
of
the
animal
documents
should
have
a
github
entry.
A
I
think
so
far.
That
is
true,
because
it
is
great
for
tracking
any
issues
better
than
the
mailing
list
alone,
but
obviously
any
real
issues
should
always
go
to
the
mailing
list,
but
tracking
is
is
very
nice
on
github
and
I
think
that's
it
with
process.
So
who
would
like
to
step
up
first
to
the
microphone
we
have?
I
think
michael
here
listed
for
the
status
update
on
the
constrained
voucher
and
the
hackathon
that
had
seemingly
has
happened
for
it.
E
E
E
Right
here
you
go
yeah,
please,
okay,
so
the
constraint
voucher
document
is
actually
it's
at
16.
I'm
sorry,
I
think
it's
at
16,
not
15.
panos
esko
peter,
and
I-
and
you
know
this-
is
the
I
really
like
this
big
duck.
It's
really
nice,
but
a
little
bit
about
it.
I
mentioned
brewski.org
before
I'll
mention
again
and
but
constrained.
Voucher
is
rfc.
E
8995
re-implemented
in
terms
of
cosi
and
c-bor
over
dtls,
using
coap,
so
take
all
of
the
regular
big
protocols
and
replace
them
with
constrained
ones,
and
that's
what
you
get
since
112,
there's
a
url.
If
you
have
the
slides,
you
can
see
the
thing
many
small
edits,
you'll
see.
There's
I
think
I
counted
like
17
or
18
diffs,
or
something
like
this,
and
most
of
them
are
one
word,
changes
we
fixed
and
validated
all
of
the
examples.
E
We
realized
that
one
of
the
things
we
had
wrong
and
actually
my
code
is
still
wrong
about-
is
the
pro
proxy
the
assertions
map
them
to
strings,
which
is
wrong
because
there's
no
reason
to
send
that
many
bytes,
but
piang
doesn't
actually
do
the
mapping
for
you.
So
we've
actually
put
a
table
in
the
document
which
does
that
we've
not
made
it
an
iana
registry,
because
in
order
to
change
that
thing,
you
would
have
to
go
back
to
the
yang
doc
yang
part
and
extend
it.
E
E
Ietf
has
set
up
the
hackathon
efforts
has
set
up
in
a
layer,
2
vpn.
Initially
it
was
a
raspberry
pi
requirement,
and
then
it
became
a
micro
tick
box
requirement
and
at
least
two
of
us
are
now
able
to
run
that
regularly.
Mine
just
is
running.
You
can
ping
it
if
you
like
peter
turn
it
on
and
off,
and
we
can
do
things.
The
reason
why
that's
useful
to
us
is
because,
of
course,
we
have
a
discovery
protocol
that
runs
over
l2
and
needs
multicast
and
that
actually
works
over
the
vpn.
E
So
we
can
actually
test
that
we
have
not
yet
done
that
because
there
are
other
things
that
have
gotten
in
the
way,
and
I
would
say
the
biggest
problem
is:
probably
time
zones
just
getting
everyone
to
to
say.
Okay,
I'm
going
to
work
together
at
this
time
and
it's
not
always
convenient
for
everybody,
but
we're
continuing
to
do
that
and
we're
very
open
to
more
people
joining
this
and
the
vpn.
E
E
I
guess
you
know:
we've
used
6502,
which
is
a
private
use
value
and
we
need
we
need
to
come
back
and
mr
chair
and
please
can
we
do
this
early
allocation
on
this,
because
that
would
be
useful
to
do
and
then
we'll
have
to
fix
our
code
to
actually
support
both
for
a
little
while
and
come
back
to
that.
That's
just
for
the
content
format
on
the
co-app
right
on
that
request.
So
it's
not
not
super
critical,
but
it's
it's!
It's
just
annoying.
E
E
So
the
s
s
and
I
must
be
set
correctly
or
you
won't
get
to
my
correct
server
and
so
that's
kind
of
useful
because
it
turned
out.
It's
revealed
a
number
of
bugs
and
a
number
of
other
clients
that
otherwise
were
not
revealed
by
other
instances,
so
that
is
there's
whatever
is
called
that
draft
use
it
or
lose
it
kind
of
thing.
E
E
Even
to
have
that
right
and
we're
going
to
figure
that
out,
you
know
going
on
because
it's
getting
in
the
way
of
things,
so
those
are
kind
of
the
issues
it
would
be
nice
to
have
everyone
come
to
philadelphia
and
be
in
the
same
room
and
not
have
any
distractions,
so
that,
I
think,
is
the
major
advantage
of
being
in
person.
The
major
disadvantage,
of
course,
is
when
you
find
a
bug,
it
might
take
you
12
hours
to
fix
it,
by
which
point
the
hackathon
is
over
right.
E
So
that's
the
downside
of
not
doing
that
and
that's
really
it
any
questions
or
whatever
thing.
The
document
is
really
ready
for
working
group
last
call
or
additional
reviews,
there's
some
feeling
that
the
examples
maybe
aren't
proven
to
be
correct
until
we've
all
interoperated
successfully
with
all
of
them.
But
at
this
point
I
feel
actually
that's
probably
it's-
that's
probably
boiling
the
ocean-
we're
probably
they're-
probably
good
enough
at
this
point
so
and
we'll
resume
meeting
in
in
april,
not
next
week
but
the
week
after.
F
Yeah,
hey
yeah,
michael
just
to
remark
yeah,
so
the
examples
you
mentioned,
so
we
still
have
the
kind
of
older
examples
in
and
they
were
not
yet
updated
to
the
latest
and
the
results
of
the
hackathon.
But
I
agree
with
you
that
for
the
document
not
considering
these
examples,
I
think
the
rest
is
ready
for
the
review.
Indeed,.
E
I
kind
of
consider
examples
are
updatable
into
auth
48
and
that's
one
of
the
things
that
you
might
do
in
auth48
is
make
sure
really
be
sure,
but
you
know
we
can
go
through
all
the
reviews
we
don't
have.
I
don't
think
we
have
to
wait
for
all
of
that
to
get
the
rest
of
the
reviews
happen.
Yeah.
I
agree
so
expect
the
document
soon
rob.
A
A
E
A
A
G
G
So,
let's,
let's
see
what
we
have
next
slide
so
here
to
to
recover
a
bit.
So
this
is
another
form
factor
to
the
original
voucher,
rfc
8366,
which
specifies
cms
signed
json,
and
here
we
see
another
option
which
is
jws
sign
json.
So
there
are
no
changes
to
the
yang,
and
so
this
new
voucher
format
could
be
used
for
standard
briskies
or
8995
or,
and
it
also
also
the
brisket,
prm
and
so
pledge
and
responder
modes
relies
on
the
jws
form
factor
here.
G
So
we
do
not
want
to
have
a
difference
here,
because
this
other
form
factors
also
support
multiple
signatures
on
on
on
on
the
voucher
payload,
so
this
this
is
why
we
are
switched
to
this
other
form
factor
and
we
will
see
it.
I
think,
on
the
next
slide.
Yes,
here
I
have
a
voucher
representation.
So,
on
the
left
hand
side
you
can
see
yeah
general
jws,
json,
serialization
syntax.
G
Looking
at
the
payload
yeah,
you
can
see
it's
a
voucher
with
some
fields.
Everybody
should
know
so
assertion.
Serial
number
nones,
for
example,
created
on,
pin
domain
certificate,
and
then
we
see
the
signatures
array
at
the
bottom.
So
here
it's
only
showing
one
signature,
but
the
the
brackets
in
brackets
indicate
that
you
can
have
multiple
signatures
in
that.
G
So
and
so
details
can
be
found
in
the
in
the
draft,
so
figure
one
gives
more
details
on
that
and
then
we
also
have
an
example
in
the
appendix
which
is
then
the
the
ddt
voucher
itself
as
an
example.
So-
and
you
can
see
it
here-
we
have
the
payload
a64
encoded
and
then
we
again
have
the
signatures
array
with
the
protected
header
of
a64
encoded
and
the
matching
signature,
also
base64
encoded,
and
that's
all
so
to
the
syntax
and
to
the
example.
G
That's
that
one
and
then
yeah
the
next
step
is
to
enhance
the
description.
So
I
think
content-wise
we
are
complete,
but
we
need
some
more
writing
to
to
give
some
some
more
meat
in
there
and
to
make
it
easy
for
for
the
for
the
reader
to
get
a
good
understanding
of
what
we
are
doing
and
how
the
how
the
form
factor
is
meant
to
be.
G
Then
we
have
regular
alignment
in
the
design
team
calls.
We
circulate
the
outcome
to
the
mailing
list
and
we
have
poc
implementations
together
with
brisket,
prm
and
yeah.
Also
here
working
group,
you
appreciated-
and
I
think
that's
it-
it's
only
the
appropriations
yeah,
that's
it
are
there
questions.
I
D
D
So
I'm
starting
from
the
beginning
so
issue
15
was
we
incorporated
an
option
for
additional
signature
of
the
voucher?
So
this
is
what
thomas
just
mentioned
in
the
those
are
the
old
slides
yeah
anyway,
we
incorporated
in
the
additional
signature
for
the
voucher,
which
is
intended
to
provide
the
proof
of
procession
of
the
registrar
proof
of
possession
of
the
registrar
private
key.
D
So
in
brewski
prm,
the
we
reverse
the
the
roles
of
the
pledge
and
the
registrar
in
terms
of
pushing
information
down
to
the
pledge
and
at
first
the
registrar
agent
pushed
down
pushes
down
the
registrar's
certificate
to
the
pledge.
But
the
pledge
doesn't
have
a
proof
of
procession,
so
we
use
a
second
a
second
signature
of
the
voucher
itself
to
provide
that
information
down
to
the
to
the
pledge
when
the
voucher
comes
back
from
the
mazar
and
descent
forwarded
via
the
pledge
agent
down
to
the
to
the
registrar.
D
So
I
have
a
slide
afterwards
to
that
as
well.
So
then
we
included
a
new
endpoint
on
the
registrar,
which
became
necessary
because
we
want
to
deliver
the
wrapped
enrollment
request.
So
we
have
a
pkcs10
which
is
typically
provided
to
the
est
simple
enroll
endpoint
in
brewski
prm.
We
are
using
a
signature
wrapped
pk
cs10,
so
that
was
a
reason
to
define
an
own
endpoint
on
the
registrar
to
not
to
not
change
esd
at
that
point
in
time.
D
We
were
thinking
in
the
very
first
beginning
to
support
multiple
csrs
during
the
run
of
brewski
prm,
but
then
decided
to
have
a
single
cr
csr
certificate,
signing
request
to
enroll
for
an
ldf
id
and
entity
certificate,
which
is
a
generic
ldfid
and
based
on
the
elder
generic
ldfid.
Further
certificates
may
be
bootstrapped
for
the
endpoint,
so
that
can
be
done
using
the
existing
endpoints
on
the
on
the
registrar.
D
But
it's
not
intended
to
do
that
on
the
first
flight,
so
that
was
the
reason
to
to
drop
the
support
for
multiple
csrs
and
consequently,
we
also
have
dropped
the
support
for
additional
signatures
on
the
enrollment
response,
as
we
just
have
a
single
generic
lfid
certificate.
As
response
for
the
enrollment
request,
so
based
on
the
poc,
we
also
verified
that
we
utilize
the
itf
ztp
types,
the
young
definition
for
that
correctly
and
issue
number
four
is
also
solved.
D
D
So
then,
in
in
the
context
of
bootstrapping,
we
introduced
the
registrar
agent
that
provides
some
information
to
the
pledge,
and
one
of
the
information
here
is
agent
sign
cert.
Up
to
now
we
had
it
as
a
single
certificate,
and
now
we
changed
it
to
an
array
to
also
address
situations
in
which
the
registrar
agent
may
have
a
different
certificate
or
a
certificate
pass
than
the
registrar
itself.
So
having
the
array
would
allow
to
also
provide
intermediate
certificates
for
the
agent
signed.
Third.
D
So
then,
there
was
some
some
further
enhancement
of
the
text
that
better
provides
authorization,
checks
of
the
registrar
agent
and
some
further
housekeeping
with
providing
a
more
elaborate
inquiry.
Description
of
the
examples
that
we
are
provided
for,
the
triggering
of
pledge,
voucher
requests
and
enrollment
requests.
D
D
So
then,
sorry
for
for
having
the
old
slides
here
so
issue
number
15.
I
already
addressed
in
the
in
the
first
version
here
in
the
first
change
to
version
one.
So
we
finalized
here
the
handling
of
the
additional
signature
verification.
So
it's
basically
some
enhancement
of
the
text
that
was
included
here
to
have
the
order
of
the
signature
verification
when
the
the
voucher
which
which
is
now
signed
also
by
the
register,
is,
is
received
by
the
pledge.
D
D
That
gives
some
more
detail
on
the
interaction
between
the
pledge,
the
registrar
agent
and
the
domain
registrar,
and
what
we
try
to
do
here
or
what
we
defined
here
is
basically
the
provisional
accept
that
is
used
in
brewski
in
the
original
brewski,
based
on
the
preliminary
provisional
accept
and
the
tls
handshake.
We
rebuilt
that
here
by
providing
the
certificate
in
the
first
flight
and
the
trigger
of
the
voucher
request
message
from
the
registrar
agent
down
to
the
pledge.
D
We
have
the
registrar
included
here,
but
in
contrast
to
the
original
brewski,
where
you
already
have
a
proof
of
possession
by
the
registrar
of
the
corresponding
private
key
through
the
tls
handshake.
We
don't
have
that
here.
So
that
was
the
reason
to
enhance
the
voucher,
as
you
can
see,
on
the
left
hand,
side
with
the
second
signature
and
that
signature
is
provided
on
the
way
back
from
the
from
the
mazda
to
the
domain
registrar.
D
The
domain
register
provides
that
additional
signature
of
the
voucher,
and
then
we
describe
the
order
in
which
to
verify
the
signatures
of
this
double
sign.
Voucher,
to
enable
the
pledge
to
on
one
hand,
accept
the
contained
pinned
domain
certificate
as
new
trust
anchor,
and
also
verify
that
the
registrar
with
whom
he
is
in
contact
really
possesses
the
private
key
to
the
certificate
that
he
has
that
he
has
received
in
the
first
flight.
D
D
A
K
K
Just
a
quick
recap:
what
of
what
brewski
ae
is
about?
The
idea
is
that
it
is
a
variant
of
standard
brewski
where,
instead
of
the
usual
use
for
when
doing
the
certificate,
enrollment
step,
not
to
use
est
simple
enroll,
but
to
use
any
other
certificate.
Enrollment
protocol
that
supports
self-contained
request
messages
with
such
type
of
request
messages.
K
To
this
end,
it
can
optionally
request
further
certificates
that
it
may
need
during
the
enrollment
or
later
it
can
optionally.
Also
ask
for
specifics
certificate
request,
attributes
to
include
in
the
request,
and
then
the
mandatory
step
is
to
actually
request
a
certificate,
and
this
is
done.
These
three
steps
are
done
in
the
new
protocol
or
whatever
protocol
you
want
to
have.
K
A
Yeah,
just
a
intolerance
here,
so
this,
and
I
think
the
prior
one
as
well
always
makes
me
sad
to
see
that
these
wonderful
diagrams,
maybe
just
temporarily
shown
once
in
a
working
group
meeting
as
what
I
think
where
they
would
really
be
great
in
the
in
the
document.
So
if
you
folks
are
interested,
would
really
be
cool.
If
we
could
try
to
see
what
the
the
current
processes,
by
which
we
can
get
at
least
that
in
the
pdf,
mr
richardson,
is
against
it.
A
In
the
in
the
pdf
versions
of
the
document-
oh
that
sucks
well,
but
I
mean
this-
this
one
actually
might
still
be
very,
very
nice,
even
in
grayscale
right
so
grayscale
it
is
not
black
and
white.
So
I
I
stand
with
my
opinion
that
it's
it's
a
shame
if,
if
that
work
was
lost
as
opposed
to
make
it
into
the
rfcs
even
in
the
pdf
version,
so
if
you're
interested
right
ping
me-
and
we
can-
we
can
talk
with
the
rfc
editors,
then,
if,
if
for
how
the
tool
chain
works,.
B
B
A
K
By
the
way,
I
owe
this
picture
mostly
to
steven
freeze,
so
I
just
added
the
specifics
of
of
highlighting
the
brisk
the
iep
or
ae
portion
of
it
yeah.
Then
we
can
move
on
to
the
next
slide
on
the
current.
The
recent
changes.
Yes,
since
the
last
version,
or
which
was
referenced
in
the
last
iatf,
where
we
split
the
document
from
the
brisket
prime.
G
K
K
K
So,
meanwhile,
I
would
say
the
document
is
in
the
pretty
stable
status
already
where
it
should
be
pretty
convenient
to
read
and
therefore
yeah.
I
think
it's
a
good
opportunity
also
to
ask
any
of
you
who
is
interested
to
have
a
look
at
it
and
do
an
informal
review
on
vray
would
be
very
glad
to
receive
for
their
comments
on
it.
K
K
Apart
from
the
cmp
instantiation,
the
plan
was
also
to
have
an
est
with
full
cmc
instantiation
of
risky
ae.
This
should
be
provided
by
elliot,
but
unfortunately
he
hasn't
had
time
apparently
to
work
on
this.
So
we
would
need
to
see
how,
if
we
can
get
some
more
details
on
this
or
I
can
just
leave
the
esd
section
as
it
is,
which,
in
a
not
very
detailed
fashion,.
A
C
B
E
B
E
Okay,
so
I'm
gonna
talk
about
83
66
bits
which
we
adopted.
What
was
it
december?
I
guess
in
the
end,
maybe
it
was
january,
and
what
was
the
initial
motivation
for
this.
Is
that
particularly
coming
from
the
alternate
enrollment
was
that
we
realized
that
we
wanted
to
extend
this
yang
enumerated
type
called
assertion
and
that's
not
possible
to
do
that
without
revising
the
yang
module,
and
so
this
isn't
was
motivated
by
this
and
of
course,
we
wouldn't
like
to
repeat
the
effort
again.
E
We
make
put
it
in
a
sub
module
and
which
we
import,
and
then
we
arrange
for
ayanna
to
manage
this
module
and
we
can
create
a
registry
around
it
and
essentially,
what
happens
is
that
whenever
someone
comes
along
and
follows
the
ayanna
considerations
to
allocate
this
value,
then
the
iana
will
in
fact
turn
around
and
essentially
edit,
the
yang
module
and
create
a
new
yang
module,
a
new
entry,
a
new
revision
there
with
the
new
stuff
there
so
effectively.
What
we've
done
is.
E
We've
turned
the
iana
people
into
yang
editing,
robots,
which
we
can
remote
control,
and
hopefully
they
won't.
You
know,
take
over
the
world
or
something
like
that.
So
my
belief
is
that
this
has
no
effect
on
any
bits
on
the
wire
that
that
everything
looks
the
same
at
the
end
of
the
day
and
if
you
know
someone
was
actually
generating
code
from
yang
modules,
this
would
be
useful
because
then
they
would
have
the
most
up-to-date
things.
E
So
what
do
we
do?
We
turned
it
all
into
markdown,
since
the
rfc
8366
was
first
worked
on,
it
was
in
a
git
repository,
but
that
was
long
before
martin
thompson's
make
fall
existed,
so
we've
added
that
a
bunch
of
rules
to
process
the
yang
file
in
the
make
file
and
to
do
all
the
right
things
and
the
working
group
adopted
the
document.
Finally,
so
what's
next,
so,
first
of
all
we
used,
what's
it
called
the
one
before
essex
structure,
yang
data
model,
and
that's
apparently
not
sexy
anymore.
E
So
for
me,
oh,
I
thought
someone
says
that
that's
not
sexy
anymore.
Now
we
should
be
using
rfc
8791,
which
is
this
essex
structure
stuff.
I
don't
really
understand
the
difference
between
the
two.
I
think
that
it's
just
a
different
way,
a
yang
way
of
expressing
things,
and
I
think
that
it
will
result
also
in
no
wire
changes.
Just
we
would
now
be
expressing
our
yang
module
in
the
modern
2020
onwards
away.
E
E
Secondly,
we
need
to
go
through
8366
and
see
if
there
are
optional
things
that
we
spoke
about.
We
wrote
about
that
either
need
clarification
at
this
point
or
we're
just
dumb
ideas,
and
we
should
just
remove
them.
Okay,
the
goal
of
this
is:
could
we
publish
his
internet
standard
at
the
end
of
the
day?
Okay,
as
opposed
to
proposed
standard,
and
that's
a
question
for
our
a.d
rob
over.
There
he's
not
really
paying
attention
to
us
probably
friday
afternoon
anyway.
L
So,
on
that
specific
question,
I
was
paying
attention
on
that
specific
question.
I
think
going
to
ps
first,
for
this
document
would
be
better.
I
think,
going
directly
to
internet
standard
might
be
questionable
in
terms
of
how
much
stuff
is
changing.
I
can
have
a
look,
but
I
think
it's
a
question
of
whether
the
changes
are
significant
or
not.
So
I
think
I
need
to
review
that
carefully,
but
I
could
get
back
to
that
right
so
so,
just
to
to
restate
it.
E
We're
really
changing
the
yang
the
expression
of
the
content,
but
not
any
of
the
content
itself,
so
it
could
be
that
we
introduce,
I
agree
with
you.
It
could
be
that
we
introduce
unintended
bugs
in
the
yang
in
how
we
express
it,
but
I
think
that's
relatively
unlikely,
but
what
you're
suggesting
is
that
we
publish
as
ps
and
that
a
later
isg
could
could
redesignate
it.
You
know
if
we
think
we're
okay.
That
would
be
the
safer
way
that.
I
I
M
E
E
A
A
E
We
don't
have
code
generators
that
are
going
to
actually
process
it,
but
we
do
have
have
have.
We
do
know
how
the
serialization
works
and
all
that
other
stuff.
So
that
that's,
I
think,
okay,
so
I
have
a
second
question
or
the
third
question.
Actually
so
one
of
the
things
that
we
are
doing
in
well
so
jws
voucher
is
one
of
the
unique
documents
that
doesn't
extend
8366
at
all
constrained.
Voucher,
extends
it.
E
There's
another
document
that
extends
it
now.
I
can't
remember
what
it
is:
there's
two
or
three
documents
that
have
taken
8366
and
extended
it
often
in
in
orthogonal
directions,
and
you
should
actually
be
able
to
combine
the
extensions
at
the
same
time.
I
don't
know
how
to
express
that.
So
the
question
is
those
documents
now
they're
still
extending
8366
and
the
sir.
The
question
is
well:
should
an
8366
bis,
should
it
go
and
now
reach
in
and
take
those
extensions
and
include
it
into
the
83
66
bit
document?
E
E
I
don't
know
the
answer
to
that
question.
In
particular,
I
don't
know
how
to
tell
someone
to
use
8366,
plus
whatever
constrained
voucher
comes
up
with
plus
say:
whatever
delegated
voucher
comes
up
with,
because
those
are
orthogonal
extensions,
you
should
be
able
to
combine
them,
but
I'm
going
to
say
I'm
going
to
tell
you
here's
three
rfcs
to
implement
and
I
don't
know
how
to
mix
that
yang.
If
I
was
doing
a
code
generator,
I
wouldn't
know
how
to
to
put
that
yang
together.
E
A
I
think
process
wise
will
will
stay.
I
mean
the
smart
money
is
on
keeping
it
separate.
If
I
were
thinking
about,
you
know
trying
to
write
a
document
that
has
all
the
ipv6
extension
headers
together
and
then
you
know
things
were
retired
later
on
what
you
do
right,
so
that
would
affect
the
everything
together.
So
by
keeping
things
in
separate
documents,
it
also
means
that
we
can
change
their
status
accordingly.
E
L
Robleton
is
kent
still
in
the
queue
I
don't
know,
but
I'll
I'll
jump
in
anyway.
Just
one
observation,
you
also
got
the
wonderful
updates
tag
that
is
very
vaguely
defined,
so
you
could
also
update
the
other
two
extensions.
If
there's
anything
required
to
explain
how
they
worked
with
the
updated
version
of
8366.
8366.
E
That's
a
good
point
and
I
think
the
timing
will
be
such
that
they'll
actually
be
published
beforehand
anyway,
or
maybe
at
the
same
time,
but
anyway.
Okay.
Thank
you.
That's
all
I
have
anyone
else.
Have
any
questions,
some
people,
that's
you
guys,
are
still
in
the
queue
kent
did.
You
have
another
thing
to
say.
I
Yes,
regarding
pulling
things
into
83
66,
another
consideration
is
that
I
would
imagine
the
biz
would
obsolete
the
8366
right.
That's
the
typical
thing.
That's
done
yet.
We
have
8572
scpp,
which
depends
on
836
and
would
not
be
able
to
incorporate
whatever
orthogonal
extensions
you're
referring
to
yeah.
F
I
E
A
E
E
No,
I
think
it's
okay,
if
we
obsolete
it,
because
the
document,
because
the
new
document
has
the
same
content,
and
so
it's
perfectly
fine
for
the
the
other
documents
to
just
say:
oh
well,
we're
just
moving
up
to
the
new
new
one
and
that's
fine.
I
think
that's
as
long
as
the
content
is
the
same
right.
That's
what
that's!
What
kent's
point
was
that
otherwise
you'd
have
to
say
new
document
minus
this
other
stuff
right
and
then
it's.
I
think
too
complicated
carson.
E
E
So
just
to
remind
you,
there's
a
section
in
brewski
that
says
that
devices
may
want
to
talk
to
the
cloud
directly
instead
of
talking
to
a
local
registrar
and
is
intentionally
potentially
does
not
specify
that,
and
this
document
does
so
we
started
with
a
bunch
of
different
use
cases.
I
think
four
of
them.
We
got
rid
of
a
couple
of
them
and
essentially
there's
two
use
cases.
E
F
E
E
We
went
through
security
considerations
before
the
last
itf
and
I
think
they
were
reasonably
well
accepted,
but
we're
really
ready
for
working
group
last
call-
and
you
know,
reviews
sector
review
would
be
great
and
maybe
even
some
review
from
http
people
or
something
like
that.
They
could
tell
us
if
we
got
307
right.
I
think
that's
it
yeah.
That's
the
last
slide
any
questions.
A
A
K
A
O
O
First,
I
will
have
a
review
about
our
draft,
and
the
portal
of
this
draft
is
one
two:
to
establish
a
site
of
autonomic
negotiation,
my
mechanism
to
achieve
the
negotiation
and
the
distribution
of
the
network
results
in
the
domain
network,
and
that
means
it's
a
real
negotiation
with
a
service
plant
and
decide
how
many,
how
much
resource
service
you
can
use
in
the
domain
network,
and
we
think
the
draft
can
slow
the
the
target
of
the
draft.
So
first
is
we
want
to
the
resource-based
network,
can
get
the
resource
autonomy
and
satisfies
the
truth.
O
When
the
request
results
mandates,
I
want
to
write
results,
they
will
send
a
message
to
providing
resource
manager
asap
and
in
the
negotiation
part
state,
and
this.
This
mechanism
allowed
multiple
runs
of
negotiation,
and
so
two
asa
will
decide,
decides
how
many,
how
much
resources
are
respect
and
the
third
requesting
resource
measure
asa
will
decide
at
each
round
how
much
the
results
need
to
offer
and
the
providing
resource
management
will
respond.
A
lot
to
the
results
they
can
offer
under.
O
That
means
so
providing
resource
manager
asa
will
consider
the
network
state
under
the
service
information
and
decide
how
much
resource
can
offer
and
after
negotiation,
the
two
asa
guides
the
result
and
the
providing
results.
Microasyl
will
remove
the
iterable
results
from
the
resource
part,
and
we
should
emphasize
that
this
graph
is
about
negotiation,
how
much
resources
resources
can
offer
to
the
servers
and
it
now
to
release
the
results
hold
by
hope.
O
O
O
This
is
a
negotiation
message
and
I
was
the
first
one
so
as
I
will
ask
the
10
10
megabit
bits
per
second
on
the
bandwidth,
so
the
x
turns
0
10
under
the
0
bandwidth
and
the
tenants
of
value,
but
I
think,
but
as
far
as
providing
resource
mindset,
it
receives
a
message
and
if
the
network
is
not
very
busy,
it
will
respond
accept.
But
if
the,
if
the
network
is
the
result,
is
she
will
license
page
says
it
will
respond
to
eight?
And
the
next
round
is
r
is
the
results?
O
It
is
request,
results,
major
ace
and
she
will
decide
the
eight.
If,
if
the
eight
is
eight
is
enough-
and
I
think
says
the
pinterest
in
its
sense,
eight
megabit
has
is
enough,
so
she
will
send
us
a
message
under
the
providing
resource
manager
will
accept-
and
this
is
the
example
of
negotiation
process,
and
this
is
a
new
step
when
we
add
in
the
draft
and
is
it
about
how?
A
A
Yes,
what
would
be
good
to
to
to
to
bring
this
down
to
a
fully
explicit
example
use
case,
and
I'm
not
sure
what
what
type
of
you
know
proof
of
concept
code
you
have,
but
I
think
such
a
proof
of
concept
code
that
would
actually
you
know
result
in
the
reservation
of
of
of
a
resource-
would
help
a
lot
so,
for
example,
you're
showing
the
step-by-step
process
to
talk
with
the
nodes
along
the
path.
But
how
do
you
know
the
path
for
a
particular
service
instance
that
you
want
to
do?
A
I
think
that's
not
being
answered,
and
then,
of
course
you
know
picking
some
way
to.
I
guess
actually
reserve
guarantee
the
bandwidth
that
that
that
should
also
be
given
as
an
example
and
yeah.
I
I
guess
that
the
example
you're
showing
would
be
some
form
of
alternative
to
something
that
in
the
past,
rsvp
has
done,
and
I
guess
that
discussion
of
how
this
mechanism
would
be
better
in
comparison
to
to
such
prior
examples.
That
would
also
help
to
distinguish
the
proposal.
A
O
A
A
N
A
O
O
Yeah,
okay,
I
I
will
start
about
this
draft
under
this
draft
is
about
autonomic
ip
address
to
access
control,
group
mapping
and
I
first
I
will
reveal
the
basic
idea
of
the
draft,
and
this
is
a
picture
of
an
example
of
campus
network
and
the
in
this
network.
It
improves
exercise,
note
and
the
acer
we
defined
in
the
draft,
and
here
the
aap
represents
the
absence
of
a
dictation
point.
O
Starter
share:
share
common
network
policy,
for
example,
if
one
user
adapts
the
network
but
and
if
they
change
the
exercise
point
say:
maybe
that
is
a
different
ip,
but
we
think
that
the
user
wants
to
get
the
same
network
servers
so
that
our
driver
want
to
slow
this.
This
price,
this
project-
and
this
is
our
chain
from
the
last
version
and
in
our
slab
we
will
do
the
example
about
how
this
mechanism
work,
and
I
think
this
will
make
others
know
more
about
our
draft.
O
This
page
will
show
the
gra
the
diff
grasp
what
we
define
in
the
draft,
and
it
includes
aap
objective
under
the
pp
objective,
and
this
is
our
def
defined,
and
this
page
is
about
an
example
about
how
aap
does
ip
address
and
group
id
might
be.
Information
for
a
house
for
a
host-
and
it
weighs
in
is
its
prior
knowledge
for
animal
objective,
and
we
must
emphasize
that
this
is
only
just
an
example
and
it
is
not
built
standard.
O
O
And
if
the
pep
receives
this
message,
they
will
start
some
tape.
Mapping
table
in
their
local
memory
and
they
will
respond
to
negotiation,
and
the
message
this
is
this
picture
is
about
how
the
pp
uses
ip2
group
information
to
enforce,
to
enforce
the
policy
and,
as
an
example,
the
user,
a
user
whose
ip
address
is
ipa,
want
to
send
send
a
package
to
the
data
database
machine
whose
ip
address
is
ipb.
O
H
O
H
M
Actually,
I
answered
a
little
bit
more
regarding
jungkook's
question
about
the
security,
so
at
one
of
the
courses
yeah,
I
think
in
it
is
in
broad
scope.
We
can
say
that
it
is
also
for
security
purpose,
but
I
guess
most
likely
will
consider
is
like
for
the
policy
policy
enforcement,
so
so
it
depending
on
how
you
categorize
this
so
in
broad
scope,
yeah,
it
is
security
in
narrow
scope.
O
O
B
B
B
M
Yeah
yeah,
that's
that's
a
good
question,
so
so
maybe
we
can
take
a
look
at
the
previous
page.
First
yeah,
that's
regarding
so
as
eugene
just
now
showed.
This
is
just
an
example.
So,
basically,
if
the
whole
system
deployed
the
animal,
we
are
thinking
that
would
be
one
of
the
essential
components
for
the
whole
animal
deployment.
Here.
This
is
just
to
just
to
show
the
readers
that
even
even
some
part
is
not
animalized.
M
B
M
B
M
Yeah
for
the
next
one
yeah
you're
right,
we
are
using
the
negotiation,
so
it
can
be
treated
as
a
single
single,
with
a
request
and
reply
mode
of
the
negotiation.
So
basically,
of
course,
this
is
basically
like
the
pep
stop
pep
point
receive
this
negotiation
negotiation
request.
Of
course.
Here
we
are,
we,
our
assumption
is
have
just
just
approves
such
negotiation,
this
mapping
unconditionally,
but
in
the
real
deployment
of
course,
because
the
paper
is
a
policy
enforcement
point,
it
can
use
some
pre-defined
policy.
M
F
B
M
Oh
yeah
yeah
so
because
this
one
actually
was
added
to
the
latest
version,
which
also
suggested
by
tolus,
and
I
think
by
brian,
because
the
original
version
was
too
abstract.
Currently
we
are
using
this
flowchart
to
give
a
more
solid
example,
so
I
think
a
one
of
the
way
to
deal
with
it.
We
can
try
to
add
something
say
that
if
there
is
that,
if
the
pep
doesn't
allow
this,
then
actually
the
negotiation
ad
sorry
negotiate
negotiation
and
message.
It's
not
a
hundred
percent
accept
case.
It
can
be
something
like
the
deny.
M
A
So
that's
that's
not
free
to
wrap
up
to,
but
I
think
the
problem
is
that
if
you
don't
do
it
at
some
point
in
time
the
people
who
do
know
those
technologies
will
come
for
review
and
say
well,
we
can
do
everything
that
you're
trying
to
do
new
here
already
with
the
old
stuff.
Maybe
it's
a
little
bit
more
crappy,
which
certainly
everybody
agrees
to
is
most
of
the
stuff.
That's
30
years
old,
but
as
long
as
it
it
can
be
done.
The
you
know
desire
to
do
something.
A
A
So,
for
example,
what
you're
showing
here,
where
you're
pushing
stuff
out
to
multiple
points
that
that
is
getting
in
the
direction
where
the
typical
aaa
solutions
do
not
work
well,
because
they're,
typically
really
based
on
request
reply
based
on
you
know
a
new
device
showing
up
at
some
place.
That's
where
you
know
the
request
reply
for
the
authentication
authorization
is
triggered,
yeah,
let's
not
to
carry
on
too
long.
We
can
take
it
to
the
list,
but
that
was
the
general
idea.
Thanks.
A
All
right
last
slot:
this
is
about
two
drafts
that
I
had
presented
a
couple
of
times
in
the
past
already
and
then
never
found
the
time
to
prioritize
them
on
my
own
top
of
the
line
due
to
the
the
other
animal
work.
So
I
wanted
to
get
back
to
that
with
a
couple
of
the
co-authors.
We
now
have
on
these
two
documents
and
revive
this
and
also
then
ask
for
working
group
adoption.
A
A
So
we've
got
the
autonomic
networks
that
we
want
right.
Brewski
is
autonomic,
we
hope
zero
touch
except
you
know
power
and
ethernet
cables,
maybe,
but
what
if
anything,
goes
wrong?
How
about
the
troubleshooting
side
right
and
how
about
the
acp
then,
which
supposedly
is
booted
automatically
after
brewski?
So
the
first
and
most
simple
use
case
I
would
like
to
finish
up-
is
really
to
get
something
that
we
described
in
rfc
8366,
which
is
the
you
know,
acp
for
the.
A
That
automatically
runs,
and
can
you
know
signal
you
know
any
type
of
thing
that,
for
example,
happens
from
the
brewski
proxy
back
to
the
registrar
or
a
syslog
server
in
some
other
place,
so
that
we
actually
know
when
something
goes
wrong,
but
equally,
when
something
is
working,
that
the
registrar,
for
example,
uses
this
lock
to
to
notify
when
a
new
device
is
being
enrolled
and
that
then
the
next
steps
can
be
taken
in
in
some
automated
workflow.
So
syslog
is
the
the
the
first
service
right
that
that
all
the
acp
nodes
can
start
syslogging.
A
What
they're
doing
in
the
a
infrastructure,
brewski
proxy
and
and
whatever
else
the
components
are
clock
synchronization
to
some
selected
ntp
service
across
the
acp.
We
need
good
times
even
just
for
basic
crypto
and
certificate
validation.
We
did
a
lot
of
jumping
around
hoops
to
try
to
minimize
dependency
against
clocking
in
brewski,
but
of
course,
life
is
a
lot
easier
if
you
do
have
good
synchronized
time,
even
if
it's
just
you
know,
tracing
of
event
propagation,
just
you
know
this
message
came
here.
That
message
came
there.
A
Oh,
there
were
five
milliseconds
apart,
which
was
first,
which
was
second
very
easy
to
do
if
you
have
ntp,
otherwise
you're
kind
of
very
much
lost
and
then
the
remote
access
to
the
nodes
via
the
acp.
That
would
really
be
ssh
through
the
acp.
But
these
days
it's
really
very
convoluted
and
not
good
enough
just
to
rely
on
ssh
authentication
through
the
acp
certificates.
A
So
it's
a
lot
easier.
If
you
have
the
standard,
authentication
and
authorization
of
access
into
ssh
for
controllers
for
operators,
when
you
can
rely
on
the
standard,
authorization
and
authentication
tools
chain
through
radius,
tacx
or
diameter,
radios
being
the
foremost
standard
of
the
ietf
in
that
space.
A
Recently,
ken's
work
in
the
working
group,
the
call
home
where
you
discover
a
netcon
server
and
you
are
after
you're
being
enrolled
by
brewski
and
have
an
acp
you
would
discover
hey.
There
is
a
net
called
home
server.
Let
me
connect
to
that
so
that
the
rest
of
the
configuration
happens
through
netcon,
for
example.
A
Simply
just
you
know,
the
poor
operator
using
the
cli
could
then
much
easier,
get
rid
of
having
to
look
at
ipv6
addresses
by
simply,
you
know
also
having
dns
set
up,
that
it
has
a
good
dns
names
for
all
the
operational
ipv6
addresses,
because
so
far
the
operators
are
really
well.
I
can't
remember
these
long
addresses
at
least
all
right,
and
that
brings
us
really
to
the
draft
anima
services
dns,
auto
config,
which
really
is
just
trying
to
achieve
exactly
what
the
prior
slide
said
right.
So
the
operator
sets
up
servers
in
the
knock.
A
Those
servers
need
to
support
ipv6,
syslog
ntp,
dns
radius,
diameter
netconf,
whatever
subset
of
those
the
operator
fields
he
wants
to
have
automated
running
in
the
ani
connects
those
servers
to
the
ani.
Typically
through
an
acp
connect
interface
to
the
noc,
that's
specified
in
the
acp
rfc,
of
course
nothing
yet
happens.
A
Then
the
operator
enables
the
service
announcements
for
the
acp
right,
so
those
could
simply
be
automatically
by
the
servers
themselves
using
dns
sd
over
mdns
or
the
service
announcements
are
a
feature
on
that
edge
router
the
acp
connect
when
those
existing
servers
don't
support,
dns
sd
right.
So
now
all
the
acp
nodes
start
getting
through
the
acp,
the
service
announcements
and
they
automatically
start
their
local
agents,
the
ntp,
agent,
dns
radius,
so
basically
the
asas
for
exactly
those
infrastructure,
services
and
yeah.
A
So
now,
how
do
we
announce
those
services
across
the
acp?
Well,
we
have,
and
we
want
to
use
grasp
across
the
acp,
but
we
do
not
want
to
reinvent
the
wheel
when
there
already
is
a
wheel
and
that
will
exist,
and
that
is
really
you
know
the
service
definitions
that
we
have
in
dns
sd.
That
has
pretty
much
most
of
what
we
need.
It
has
the
services,
the
services
name
with
the
wonderful
iana
registries
and
then
a
bunch
of
interesting
parameters.
A
Service
instance
names
priority
weight,
tax
parameters-
none
of
this
is
actually
specific
to
dns.
Dns
is
just
the
transport
and
yeah
I
just
got
some
information
on
are
going
to
add
about
the
history
of
this.
This
actually
originated
way
before
ip
and
apple's
local
talk
as
service
discovery
and
binding.
A
So
in
the
same
way
we're
just
trying
to
decouple
this
now
from
the
dns
binding
so
that
we
can
use
it
across
graphs
where
actually
it
will
hopefully
become
a
lot
easier,
and
this
is
here
actually
how
it
would
look
like
in
grasp.
So
this
is
the
draft
eckerd
anima
grasp
dns
ssd
in
dns.
The
data
for
a
single
service
instance
is
split
across
four
or
more
resource
records,
so
the
quad
a
is
to
get
the
address
resolution.
J
J
I
can
give
you
examples
of
other
contexts
that
are
not
widely
used
outside
of
apple,
but
they
are
examples
of
what's
been
done
over
bluetooth,
the
same
namespace
of
service
types
is
used
to
describe
ip
services,
but
over
bluetooth
discovery
frames,
which
are
not
dns
formatted,
and
it's
also
used
in
peer-to-peer
wi-fi
again
encoded,
and
I
don't
know
the
details,
but
some
kind
of
wi-fi
public
action
frame.
That's
also
not
using
dns
format
messages.
So
we
do
have
a
precedent.
A
Not
only
the
the
service
types,
but
also
the
parameters
that
we
have
right
priority
weight
so
that
the
whole
management
of
you
have
multiple
service
instances,
how
you
think
about
redundancy
selection
that
that
is
as
consistent
as
we
can
get
it.
So
the
the
only
thing
that
I
figured
out
we
can
add
in
the
case
of
grasp
is
that
we
have
a
notion
of
distance
to
the
server
because
we
hop
by
hop
forwarded,
which
we
kind
of
always
fail
to
do
correctly.
In
multi-hop
mdns,
that's
been
the
pain,
but
so
we've
got
the
distance.
A
As
one
added
you
know,
criteria
we
can
use
which
may
not
be
applicable
to
all
environments,
but
which
would
then
only
be
for
the
acp
case
right
so
in
in
dns.
It's
split
up
across
a
bunch
of
different
resource
records,
and
that
also
means
you
have
multiple
back
and
forth
hubs.
You
need
to
go
through
before
you
have
all
the
information
if
you
haven't
cached
it
in
before,
and
then
grasp.
A
It's
really
very
simple
because,
because
we
can
just
for
the
announcement
of
flooding
service,
information,
put
everything
into
a
single
grasp
objective
and
that's
what
I've
shown
you
on
the
right
hand.
Side
and
if
you
look
at
the
words
here,
you'll
find
all
the
same
things
that
you'll
find
scattered
around
the
mdns
solution
like
the
instance,
the
service
priority
weight
and
then
the
additional
extension
and
extensive
text.
Things
kv
pairs,
so
that's
all
being
mapped
and
then
only
the
distance
would
be
a
new
one
that
we
can't
really
map
back
to
mdns.
A
E
E
The
only
way
to
get
the
answers
from
the
reverse
map
is
to
use
the
local
recursive
dns
server,
because
if
you
use
a
public
one,
of
course
you
won't
get
anything
useful,
and
so
that's
really
important
as
to
to
in
your
you
know
in
your
syslogs
when
you're
receiving
them
from
other
things,
you'd
like
to
put
the
name
of
the
actual
machine,
not
its
current.
You
know
the
ip
address
that
currently
happen
to
use
to
talk
to
you,
so
we
actually
need
to
think.
E
Maybe
whether
or
not
we
want
to
do
reverse
map
updates
using
dns
update
using
some
sig
zero
type
key,
which
of
course
we
would
have
to
discover
with
grasp
to
find
out
which
server
to
update
to
or
whether
or
not
we
want
to
actually
do
reverse
map
updates
using
grasp
yeah,
okay,
so
that
might
be
an
interesting
asa
that
we
might
just
find
that
might
be.
It
might
be
easier.
E
E
We
are
opinionated
as
the
about
how
you
named
the
that
piece
of
equipment
such
that
you
want
to
go
through
the
acp
versus
you
name
it
such
that
you
know
you'll
just
go
over
your
public
network
because
there's
reasons
to
do
both,
and
sometimes
you
actually
want
to
check
if
the
public
network
is
working
and
sometimes
you
actually
want
to
check.
If
actually
the
machine
is
up
in
the
in
and
going
through,
the
acp
is
a
better
choice,
because
that
is
more
likely
to
be
working.
So
that's
actually
other
side
of
thing.
E
E
A
E
E
A
Right
so
I
mean
I'm
just
trying
to
discover
the
services
there
and
yeah.
I
I
I'll
have
to
think
more
about
what
I
think
is
the
good
logical
separation
line
between
different
pieces
of
work
so
that
each
of
them
can
best
be
reused
without
creating
unnecessary
dependencies
yeah.
Thank
you
all
right.
So
how
do
we
operationalize
the
whole
thing?
A
So,
ideally,
if
we
think
about
you
know
we
write
asa
so
whatever
it
is,
we
introduce
an
application
api
through
which
service
announcement
and
discoveries
can
be
made,
and
I'm
thinking
about
whether
we
can
have
just
a
very
simple
you
know
announce
discover
abstract
api
specification
in
the
draft
and
then
the
api
library
can
actually
select
whether
to
use
grasp
or
dns
as
an
implementation
choice,
maybe
by
automatically
discovering
the
context.
Well,
I
do
have
an
acp.
Let
me
use
graph
otherwise
use.
Let
me
use
dns
on
the
acp
router.
A
A
So
I
think
brian
gave
a
good
counter.
Example.
Brian
gave
an
example
of
an
objective
that
was
just
meant
to
give
service
parameters
that
are
specifically
to
grasp
itself
for
those
type
of
things.
It
wouldn't
be
necessary
or
beneficial
to
to
use
the
serve.name
thing,
because
it's
specific
to
the
grass
protocol
all
right.
So
summary
proposal
is
for
the
two
bra
two
drafts,
which
are
serving
very
much
combined
goals
but
independent
of
each
other.