►
From YouTube: IETF101-ANIMA-20180320-0930
Description
ANIMA meeting session at IETF101
2018/03/20 0930
https://datatracker.ietf.org/meeting/101/proceedings/
A
A
A
A
A
Thank
You
P,
and
we
also
have
the
remote
participation
at
least
we'll
have
to
present
our
today
from
remote,
Michael
and
Laurent,
the
Audion.
All
those
slides
are
already
uploaded,
so
you
can
find
the
materials
and
the
meninist
for
animal
still
the
one
of
the
main
working
place,
so
everybody
should
looking
at
them
subrata
looking
at
the
meninist
and
try
to
invoke
the
discussing.
If
you
have
anything
you
know
want
to
make
the
working
group
aware
this
meeting
is
called
and
chairs
by
myself.
King
and
the
terrace
occurred.
A
Already
set
in
the
editor
RFA
editor
for
almost
half
year:
it's
miss
wife,
because
the
ASAP
and
the
copper
also
the
enema
profits
management
is
already
also
in
the
Miss
ref
situation.
For
three
months
already.
It
means
ASAP
and
copper.
Also
the
put
stripper
and
grasp
crush
is
already
there
and
we
have
the
animal
vulture
with
RFC
editors
since
last
month.
So
that's
with
meal
and
there's
a
stable
connectivity.
A
We
have
the
reference
model
already
pass
today,
working
off
last
call
in
January.
It's
your
unity,
red,
helpful
document,
shivered,
hopefully
I'll.
Do
it
this
week,
waiting
for
the
IPR
disclosure,
confirmation
from
authors
and
the
bootstrapping
key
infrastructure,
it's
planning
to
have
a
working
group
classical
after
this
meeting,
so
she
ever
tolerated
tongue,
the
sole
review
and
I
believe
the
others
already
addressed
the
comments
right,
Terry,
alright,
and
we
have
one
new
working
group
document
since
last
meeting.
A
B
A
C
E
D
Okay
to
the
next
slide,
please,
okay,
relatively
few
changes
from
the
last
version.
This
is
all
practically
all
related
to
the
long
review
that
Chang
has
done
thanks
for
the
tradition,
so
this
is
a
lot
of
final
cleanups
before
we
go
into
the
publication
process.
So,
for
example,
we
had
still
a
lot
of
comments
in
about
the
current
scope
and
that
the
work
is
limited
to
the
charger
and
stuff
like
that.
D
That's
in
those,
so
the
wording
has
been
changed
basically
to
focus
on
the
first
simple
implementation
phase.
That
was
always
the
intention,
but
it's
it's
not
clear.
So
no,
no
factual
change
and
there's
just
editorially
different
phases.
Afterwards,
some
of
the
changes
that
were
more
relevant
is
the
distinction
between
well
Turner's
called
in
his
document,
the
the
chi
acp
and
the
acp.
D
We
have
the
generic
autonomic
control
plane,
which
is
essentially
it's
an
abstract
control
plane.
The
same
way,
we
talked
about
routing
protocols
as
a
control
plane.
So
it's
it's
a
generic
notion
of
a
control
plane,
whereas
the
ACP
is
is
a
specific
implementation
that
is
described
in
corresponding
ACP
draft
and
so
in
the
draft
in
the
reference
model.
Now
we
we
distinguish
more
clearly
between
when
we
need
a
generic
control
plane,
the
GAC
or
what
we
mean
the
implementation
of
the
ACP,
as
described
by
the
draft,
and
so
to
be
very
clear.
D
D
Then
the
state
we
had
lots
of
questions
and
what
happens
about
power
cycling.
So
now
the
state
diagram
includes
the
power
cycling
event
in
all
states
to
be
clear
about
that.
I
think
that
was
more
clarification.
That's
haven't
heard
any
more
feedback
on
that
either
there
were
some
clarifications
about
LF,
ID
and
I
define
gear
which
goes
out
in
which
case
that
is
also
clarified
now,
and
we
reduce
the
number
of
explicitly
mentioned
authors
to
five
and
it
reduced
to
contributor
section.
D
We're
playing
John
and
clear
are
are
in
now,
apart
from
that
lots
of
territorial
units,
and
that's
really
it
next
slide
is
so
we
have
two
working
gas
working
group
last
corners
past
and
yeah
next
should
be
the
is
she
review
and
Schenk
just
sat
down
on
his
slide.
That's
it
from
my
side
any
questions.
B
A
E
Okay,
so
we
had
in
100
we
had
the
number
12
and
we
still
had
a
good
review
afterwards
from
Brian
William
and
Yong
Cheng,
and
so
there
was
still
a
good
amount
of
you
know.
Fine-Tuning
of
a
bunch
of
you
know
things
your
others
thought
were
kind
of
obvious,
but
obviously
the
text
wasn't
so
you
know
like,
for
example,
the
vr
af-s.
Really
being
you
know
more
what
we
call
vrf
light
in
the
industry,
you
know
I
couldn't
find
for
the
heck
of
it.
A
really
good.
E
You
know
normative
reference
for
that,
but
many
people
what
would
confuse
what
we
call
the
VRS
with
an
MPLS
vrf,
which
has
this
very
strange
core
facing
and
behavior,
and
then
we
had
the
good
discussion
about.
You
know
why
we
do
I
pee
in
the
ACP
itself,
and
that
was
kind
of
resolved
through
that
acp
number
four
requirement.
E
Also
the
good
terminology
for
you
know
what
does
manually
configured
mean
right.
I
mean
we
meant
it's
not
autonomically
configured,
but
obviously,
in
the
times
of
Sdn
manual,
is
not
a
good
choice
of
words
anymore,
and
then
we
tighten
down
on
the
inter
ability
requirement.
So,
specifically,
on
the
security
side,
making
sure
that
a
aes-256
is
the
minimum
allowed
on
the
secure
channels
and
must
be
supported
and
well
I
guess
we'll
see
an
ISDN
review
further.
When
we
get
to
the
security
review
there,
the
longer
one,
the
other
zone
zone
ID.
E
So
that
ended
us
up
with
the
ACP
13
shank
did
the
Shepherd
write-up
of
that
then
it
went
over
to
is
three
and
then
basically
we're
getting
so
close
to
this
IIT
F
that
I
didn't
have
the
time
to
respond
to
the
feedback.
So
that's
what
I'm
going
to
do
next
week
going
through
all
the
reviews
and
doing
them,
so
we
had
general
review
we
had
I.
Would
he
Directorate
review
from
Pascal
secure
review,
early
review
on
the
end,
then
routing
peer
review
so
yeah?
E
A
B
F
Okay,
next,
please
so
we
define
some
cause.
The
Registrar
basically
is
for
easels
to
tell
the
cross
module.
Okay,
I
am
online,
and
what's
my
name
of
what
I
can
do,
etc
and
discovery
cause
a
negotiation
cause
synchronization
cause
of
fighting
costs.
These
cause
didn't
have
essential
changes
since
the
last
version.
Next,
please:
okay,
the
most
significant
changes
about
the
event
loop,
because
if
we
want
the
crust
to
be
run
in
the
very
small,
for
example,
level,
1
or
level
2
LT
notes,
we
need
something
to
handle
the
a
synchronization
communication
with
the
ASIS.
F
F
F
F
F
A
F
From
technical
perspective,
there's
no,
it's
not
a
big
deal,
but
we
are
chuckling
of
whether
it's
good
to
open
for
the
Aces
such
kind
of
detail,
because,
ideally
the
easels.
They
only
need
to
care
about
what
they
want
of
discover
the
we
don't
want
them
to
care
too
much
details
such
as
addresses.
So
that's
the
main
concern.
A
F
A
F
A
A
A
F
A
A
A
E
Think
the
main
issue
to
me
would
be
that
this,
the
functionality
expressed
over
grasp
is
meant
to
be
application,
information
right
and
so
the
the
the
trouble
is
a
little
bit
coming
up
with
me
to
establish
cross
application
standards,
and
so
I
try
to
do
that
in
the
DNS
SD
stuff,
which
is
trying
to
say
okay,
whatever
application
you
are,
if
you're
trying
to
signal
a
service,
then
here
is
a
standard
for
that
and
I
think
that's
the
type
of
functional
document,
not
an
API
document.
That
would
would
do
that.
E
F
Okay
and
we
still
need
help,
because
the
current
open
source
map
implementation
by
Ben
Carpenter
is
based
on
Python
and
for
Python
is
very
easy
to
deal
with
multi-threading,
but
for
C
program
is
even
loop.
We
still
need
more
experienced
C
programmer
to
help
us
to
check
out
whether
it's
okay,
sufficient
some
errors,
etc.
G
A
G
G
Next,
one
still,
okay,
so
just
a
quick
reminder
about
the
the
overall
goal
of
this
document.
The
goal
is
to
help
and
provide
guidelines
to
the
developers
for
the
general
design
of
their
code.
So
why
we
do
that
because
we
expect
the
ADA
to
be
written
by
a
very
diverse
set
of
people
programmer
developers
which
we
think
are
not
necessarily
specialized
in
the
protocols
or
the
internals
of
animal,
but
more
on
the
now
more
specialist
on
the
atomic
function
that
they
are.
G
G
Yes,
so
from
from
the
last
version,
there
have
been
a
couple
of
changes,
essentially
a
discussion
on
the
draft.
There
is
a
discussion
about
different
models
for
for
Asia.
There
is
either
on
the
meaty
threads
or
even
Qube
approach
and
so
I'm,
recognizing
that
for
simple
Asia,
some
of
the
discussion
may
not
be
relevant
or
fully
required.
We
implement
a
few
changes
to
explain
that
in
the
case
of
simple
Asia,
some
of
the
consideration
they
do
put
aside.
They
have
been
also
a
new
section.
G
So
you
have
a
main
thread
which
is
here
to
ask
the
main
I
will
say
point
of
azof
so
to
initiate
the
resource,
pool
and
stopped
a
number
of
of
thread
related
to
the
different
functions
of
grasp
so
to
the
aspect
of
floating
negotiating
garbage
collection.
It's
it
also.
If
you
go
to
the
next
slide,
yeah,
and
then
you
have
different,
auto
threads
that
are
running
in
parallel.
G
So
the
fluid
or
thread
in
order
to
early
key
food,
the
resource
pallet
or
to
all
grasped
roads,
the
negotiated
thread
adequate
weight
and
satisfy
the
negotiation
request
for
the
order,
grasped,
peers,
garbage
collector
in
order
to
compact
the
resource
pool.
This
is
very
specific
to
the
laser,
which
is
a
resource
management
arena
and
assigned
thread
in
order
to
manage
the
resource
requests
from
non
autonomic
devices
in
application
and
assign
the
resource
from
the
hood
next
slide,
and
so
we
we
have
been
discussing
this
drug
for
some
time
now.
G
We
still
are
making
progress
on
their
work.
So
what
remains
to
be
done?
I
mean
the
text
on
the
coordination
between
the
autonomic
function
is
a
preliminary,
so
just
the
first
iteration,
and
we
also
asked
for
the
group
to
provide
feedback
or
inputs
to
this
to
this
aspect.
What
should
be
considered
in
this
draft
to
add
the
developers
to
consider
weapons
to
be
taken
into
account
when
coordinating
among
economic
function?
G
We
are
also
starting
additional
thoughts,
but
order
to
bicker
interactions
between
Asia,
so
I
said
we
have
this
coordination
aspect
which
is
already
covered,
but
there
may
be
also
all
the
types
of
interaction
that
should
be
taken
into
account
and
discussed
in
this
draft,
for
instance,
when
the
different
Asia
needs
to
exchange
knowledge
and
agree
on
different
modes
of
exchanging
knowledge.
So
this
can
also
be
a
section
to
be
developed
in
the
draft.
G
Initially
configured
to
set
the
purpose
or
to
set
the
configuration
of
this
of
this
Asia,
so
there
is
also
this
interface
or
interaction
that
needs
to
be
documented.
There
may
be
also
other
interactions
to
be
considered,
and
this
is
also
a
question
to
the
group.
If
you
have
a
specific
inputs,
we
will
welcome
that
in
the
document.
So
there
is
also
in
the
work
an
example
logic
flow
for
even
book
model.
G
E
Tell
us
so
not
sure
if
it's
working
group
chair
our
core
contributor,
so
I
guess
as
a
working
robot
chair,
let's
say:
I
think
this
is
highly
useful
and
we'll
definitely
have
to
figure
out.
You
know
where
we
might
have
a
charter
issue
with
that,
because
ASAS
in
general,
I
guess,
are
not
in
charter.
I.
E
Think
that
the
main
issue,
what
we'll
have
with
this
draft
is
that
it
can
become
better
and
better
the
the
more
experience
we
gain
right.
So
that's
why
this
this
is
maybe
the
one
draft
where,
as
a
working
group
chair,
wouldn't
necessarily
want
to
have
it
finished
as
quickly
as
possible.
But
you
know
the
more
you
know
of
other
AAS
a
work
we're
doing
the
more
you
know,
I
think
feedback.
E
We
can
provide
for
this
draft
so,
for
example,
the
what
what
I
would
like
to
do
is
to
to
revisit
this
draft
versus
you
know
what
I
can
see
the
grasp
DNS
stuff.
You
know
as
a
kind
of
grasp
library,
on
top
of
grass
to
do
and
then
basically
feed
that
experience
back
and
hopefully
we'll
have
other.
You
know
input
into
this
draft
and
and
I
think
that
should
make
it
better
over
time.
G
Agreed
this
is
a
bit
of
challenge
of
making
it
available
for
to
help
the
designers
eat
the
proper
of
Asia,
but
also
I
mean
stabilize
it
in
order
to
make
it
useful
as
a
reference
to
be
used
and
maybe
send
some
updates
or
new
new
revision
I,
don't
know
how
to
Eastern
the
approach
from
a
process.
Point
of.
E
You
know
and
I
think
that
you
know
it
would
be
good
to.
You
know
say
that
the
working
group
really
wants
to
have
this.
If
we
want
to
have
the
you
know
ongoing
ask
for,
for
other,
you
know,
work
to
say:
okay,
you
need
to
feedback.
You
know
what
what
you
think
you
need
is
guidelines
into
this
draft
right.
Otherwise,
as
long
as
it
stays
individual
people
might
ignore
it
with
with
other
work
they're
doing
in
this
space,
yeah.
A
Shing
here
and
as
far
as
I
remember,
we
actually
have
at
least
two
document,
not
in
today's
at
India
for
those
two
document
which
they
try
to
share
in
some
deployments.
Experience
so
usually
have
a
conductor
with
us.
You
know
people
who
has
deployment
experience
and
to
correct
them
their
feedback.
On
this,
your
document,
our
document
yeah,
can.
A
F
B
It's
Alex
carries
I,
have
three
suggestion
for
your
Laura
and
others,
or
maybe
comment,
hopefully
in
a
positive
way.
Definitely
it's
absolutely
essential
to
deploy
ZZZ
animal
systems
in
many
ways
and
make
it
easier.
That's
taking
us
granted,
but
I
have
to
say
there
are
some
problems
here,
for
example,
in
one
area
which
could
be
improved
in
Europe
right.
Your
draft
is
to
better
describe
the
border
between
service,
let's
system
right
up
versus
si
right
up.
In
other
words,
what
are
these?
B
How
to
move
from
this
application
which
you
describe
towards
services,
because
that's
the
driving
force
I?
Don't
think
that
this
is
a
clear,
clear
answer
in
your
current
system.
Second,
it's
emerging
that
nav
is
coming
in
a
big
way.
There
are
some
research
work
with
a
V
of
improving
the
way
in
which
and
guideline
for
nav
application
to
be
written,
and
this
has
to
be
taken
into
account,
which
means
that
it's
a
time
to
embrace
the
virtualization
significantly,
because
that's
where
our
autonomy
City
will
be
applied
first.
B
Currently,
there
are
no
autonomic
networks
and
my
final
comment
is
autonomy.
City
has
a
big
subject
and
based
on
a
bit
of
my
experience
on
publishing.
Maybe
a
hundred
papers
on
this
is
that
there
is
not
such
a
thing
covering
all
the
aspects,
so
it
time
to
decouple
it.
Autonomy
city
in
terms
of
specific
self.x
capabilities
for
which
asa
application
or
other
parts
of
the
animal
could
be
better
applied.
B
One
framework
it
all.
It's
not
going
to
be
easy
to
put
in
in
deployment
in
all
the
aspects,
including
the
control
plane,
which
was
described
recently,
I
I'm,
afraid
I'm,
not
sure
that
this
is
deployable,
but
if
that's
not
deployed
but
Lisa
Aiza
application
could
be
better
deployed,
and
these
are
my
three
comments
can't
request
for
you
to
consider.
Maybe
two
who's
helped
others
thank.
G
B
F
F
Since
last
ITF
we
had
a
very
big
change:
the
zero
version
we
actually
merged
another
craft.
It
is
talking
about
even
service,
so
we
have
several
new
co-authors
from
the
craft
and
we
redo
a
comprehensive
analyzers
scenario
and
requirements
regarding
to
information
distribution,
and
we
also
discussed
the
relevant
grass
extension
to
realize
these
new
capabilities.
F
One
perspective
to
analyze
the
information
distribution
is
some
very
basic
scenarios.
The
first
one
is
one-to-one
communication,
which
is
quite
straightforward,
and
it
is
typical
request,
a
response,
or
we
call
it
client-server
model
and,
along
with
that,
we
also
have.
It
could
be
also
notification.
F
Why
not
actively
send
some
message
to
another?
It
doesn't
require
a
previous
request.
That's
a
one-to-one
scenario,
and
another
is
one
to
many
and
the
most
simple
way
is
just
flooding
and
another
a
little
bit
more
sophisticated.
Is
we
don't
simply
flood
the
message
to
all
the
neighbors?
We
can
do
some
reduction,
which
we
call
it
partial
distribution.
F
F
So
for
the
synchronous
communication,
the
the
main
principle
is
that
the
sender
delivers
the
message
directly
to
the
receivers
and
they
don't
and
they
need
to
wait
for
the
response,
because
there's
a
session
there
are
some
state
need
to
be
maintained.
This
is
a
synchronized
model
for
the
in
synchronize.
F
The
sender
can
also
deliver
the
message
directly
to
the
receiver,
but
they
don't
wait
for
any
response.
It
just
simply
send
a
messages
and
that's
all,
for
example,
fighting
is
in
this
model.
Another
approach
is
the
sender,
send
the
message
indirectly
it
will.
It
can
send
it
to
some
common
struct
or
common
module.
For
example,
we
can
call
it
a
word
port
or
shared
shared
space,
etc,
and
that
common
module
will
deliver
the
message
to
the
real
receivers.
F
That's
the
another
perspective
next,
please
so
for
the
in
synchronizes
we
listed
several
scenarios
and
possibly
will
happen
in
autonomy.
Network
and
the
first
one
is.
The
replied
might
take
a
long
time
so
that,
if
the
sender
is
just
waiting
for
the
receiver,
it
might
be
a
very
significant
performance
consideration
because
of
the
long
time
another
is
multiple.
Mcnulty
might
share
the
common
interest,
so
they
don't
need
to
necessarily
exchange
information
among
them
in
an
instant
model.
F
This
can
be
considered
as
some
kind
of
distributed
storage
and
they
have
the
same
database,
but
as
database
is
distributed
in
storage,
but
different
is
us
and
a
lot
one
is
there
could
be
one
of
the
it
aggregates
every
data
and
then
just
send
the
data
in
a
back
way.
There
are
several
scenarios
next,
please.
F
So
in
a
perspective
of
a
net
autonomic
node
in
order
to
support
the
different
patterns,
weather
is
synchronized,
so
in
synchronized
weather
is
one-to-one
or
one-to-many.
We
need
to
integrate
some
new
capabilities
in
into
the
node
other
than
the
current
cross
capability,
so
for
instant
information
distribution,
for
example,
the
one-to-one
mode,
the
cross
synchronization
message
already
supported.
So
this
is
quite
straightforward.
Next,
please.
F
And
but
for
the
in
synchronized
information
distribution
is
also
one-to-one.
Current
cross
doesn't
have
the
ability
allow
one
not
to
actively
send
some
information
to
another.
So,
along
with
a
synchronization
message
in
cross,
we
propose
to
add
a
new
message
as
solicit
synchronization
for
for
this
purpose
and
for
flooding
across
already
suppose
days.
F
F
F
For
example,
the
signorine
to
the
light
bubbles
switch
ON
switch
off
as
they
need
to
be
in
a
very
strict
queue,
and
this
is
a
logic
entity
to
handle
all
the
signaling
that
need
to
be
killed
and
regarding
to
how
grass
visitation
can
support
this.
We
we
haven't,
really
figure
it
out.
This
is
a
open
question
now
and
we
also
need
api's
to
open
them
for
the
SS
to
call
these
in
synchronized
communication
next,
please.
F
B
B
One
of
it
is
that
information
distribution
is
absolutely
essential
that
a
lot
of
mechanisms
were
already
in
place.
However,
sooner
it
I
want
to
deploy
it
you'll
find
out
that
you
need
to
link
it
with
one
of
the
six
information
models
available
which
is
used
in
industry,
and
the
issue
is:
are
you
thinking
about
an
information
model,
agnostic,
distribution
of
data
or
not?
And
this
is
a
key
question,
because
the
answer
to
this
question
will
help
progressing
the
distribution
of
information.
B
Loop
distribution
information
is
one
element
in
in
any
control.
Ops,
and
this
were
my
comments.
Some
of
the
points
which
are
meant
are
already
sorted
out
in
terms
of
what
could
be
solutions
and
I
offline
I
could
maybe
give
you
some
references
for
it,
but
I
feel
that
this
is
exactly
where
the
power
of
I
am
are
related
to
infrastructure.
Could
could
be
making
a
big
impact?
Thank
you
thanks.
F
For
comments
regarding
the
first
question:
the
information
model
as
far
as
I
understand
now,
the
distribution
mechanism
should
be
agnostic
to
any
specific
information
model
or
data
model
they
just
about
messaging
mechanism
how
to
deliver
messages
to
another
in
the
efficient
way.
That's
my
understanding,
but
maybe
when
we
come
to
real
design
may
be,
is,
is
necessary,
or
maybe
it's
better
to
binding
with
some
specific
information
model
or
data
model.
But
currently
we
haven't
figured
any
requirement
to
do
that
and
for
the
second
question.
B
Last
point
is
about
information.
Distribution
which
is
important,
could
be
seen
in
a
time
in
a
context
of
information
as
a
service
for
all,
and
there
are
many
other
functionality
in
addition
to
distribution
of
information
which
need
to
be
partly
put
together.
In
addition
to
that,
distribution
is
storage
and
processing,
because
not
all
the
information
is
needed.
Some
time
you
aggregate
some
disaggregate
for
a
service
of
the
use
over
in
a
particular
application.
Okay,.
F
And
I
agree
with
you
that
the
distribution
will
be
a
kind
of
service
provided
to
the
individual
notes
for
the
basis
for
other
aspects,
rather
than
simply
sending
recent
messages
for
them.
As
you
mentioned,
the
processing
of
the
information
that
how
to
aggregate
different
messages-
I'm,
not
very
sure
now
but
I-
think
maybe
that's
additional
application
layer.
Things.
F
H
This
is
Jefferson
Bobby.
First,
thank
you
for
this
valuable
work.
I
think
it's
it's
very
important
and
we
have
a
draft
which
is
called
a
NEMA
intent
policy
and
format.
I,
don't
know
if
you
are
aware
of,
but
there's
a
section.
Sheng
is
also
an
author
of
district
there's,
a
section
on
the
distribution
of
policies
that
I
think
that
maybe
we
can
you
know
we
can.
We
can
talk
about.
H
B
H
F
E
I
quickly
jump
in
sorry,
I
was
so
lazy
to
get
up
so
two
drafts,
the
the
the
more
fun
one.
If,
if,
when
you
know
this,
this
gets
adopted
as
a
working
group
draft,
probably
don't
want
to
do
it
earlier,
but
the
the
RFC
editors
have
been
asking.
If
folks
want
to
try,
you
know
getting
SVG
graphics
in,
and
you
know
your
slide.
Five
and
nine
look
exactly
like
making
this
a
lot
more.
E
E
Unfortunately,
Carson
isn't
here
kind
of
how
much
they've
been
able
to
explain
to
other
folks
the
benefit
of
seaboard
right,
but
then
the
messaging
with
grasp
and
then
the
communication
paradigms
which
are
multi-party.
Those
are
all
things
maybe
where
it
would
help
to
really
say
in
a
document
like
this.
So
if
you
know
this
would
have
been
available,
I
don't
know
ten
years
ago
for
the
following
IETF
standard
protocol
fubar.
This
is
how
you
could
have
done
it
better
and
then
even
better.
E
If
you
get
a
review
of
that
part
from
somebody
who
had
did
the
implementation
of
that
RFC,
who
were
so
right-
and
they
say-
yeah
I
mean
if
we
had
that
that
would
actually
been
how
we
could
have
done
it
better
right,
I
mean
even
starting
with
this
deceiver
stuff
right.
We
all
these-
you
know,
TLV.
You
know
one
of
tlvs
that
super
makes
easier
than
the
grass
the
the
standard.
I
Had
ridden
this
is
very
interesting.
This
is
kind
of
a
clarifying
question.
I
see
a
lot
of
parallels
between
this
and
some
of
the
big
data
projects
that
came
out
like
five
ten
years
ago.
One
of
the
underlying
issues
there
was
the
the
lack
of
concern
around
security
of
the
functionality
of
the
system,
so
it
was
something
that
was
kind
of
added
in
after
the
fact,
so
is
the
security
of
the
the
pub/sub
model
that
distributed
data
models?
Something
that's
part
of
the
initial
scope
of
this
drafter.
F
E
The
current
architecture
is
that
the
grass
is
expected
to
have
a
secure
transport
layer
right
so
that
all
the
grass
messages
are,
you
know,
secured
within
a
single
domain
right,
so
you're,
basically
having
a
grasp
domain
and
only
the
members
of
the
grass
domain
are,
you
know,
privy
to
you,
know,
receive
authenticate
and
decrypt
the
messages,
and
that
is
in
the
in
the
current.
You
know
a
and
iframe
work
done
through
the
ACP.
E
So
if
somebody
takes
grasp
puts
in
a
different
context,
he
would
basically
have
to
show
how
you
get
the
same
level
of
security
of
the
messages
right,
because
that
was
exactly
the
grasp
review.
We
had
with
the
iesg
security
review
from
Eric
that,
otherwise,
you
know
ya.
Grasp
is
fine,
but
if
you
need
to
start
encrypting
the
information
elements
inside
of
it,
we
haven't
really
achieved
a
lot
all
right.
So
so
the
main
issue,
I
think
with
respect
to
this
draft,
is
it's
very
easy
to
say
grasp
as
a
point-to-point
connection
just
use
TLS.
E
But
if
you
want
to
have
the
group
communication,
then,
basically
setting
up
the
group
security,
for
that
is
the
real
challenge
and
we've
done
it
with
the
ACP.
But
now,
if
people
don't
like
the
ACP
in
other
contexts
and
try
to
come
up
with
another
group
security
scheme,
right
I
mean
Brian
over.
There
knows
also
kind
of
a
lot
of
the
things
we've
done
in
the
past.
So
yes,
we
understand
this,
but
I
think
it
should
be
solution
below
this,
but
really
with
the
current
architecture
underneath
grasp.
Okay,.
I
So
just
one
more
question:
I'm,
not
an
expert
in
grasp
in
any
way,
but
is
the
authentication
of
the
transport?
Is
that
it
are
you
piggybacking
the
authentic
on
authentication
of
the
transport,
or
are
there
busier
abilities
to
layer,
different
authentication
models
on
top
of
just
transport
authentication,
so.
E
I
mean
right
now:
it's
it's
really.
You
have
a
set
of
certificates
that
form
the
group
and
that's
basically,
what
you
use
for
the
authentication
of
all
the
air
transport
connections
yeah,
but
it
could
equally
be
transport
right.
I
mean
if
I'm
saying
everybody
in
the
group
has
the
certificate
and
I'm
just
building
it
from
a
bunch
of
TLS
connection.
I
would
call
that
application
layer,
so
we're
just
using
IPSec
and
that's
why
we're
calling
it
Network
layer
so.
A
J
Mapping
of
we
were
just
about
finished
the
voucher
document.
It's
in
the
RFC
editor
queue
at
this
point,
and
one
of
the
needs
that
we
have
in
the
in
applying
some
of
the
stuff
to
other
tools
is
to
do
it
in
a
constrained
way.
Next
slide,
please
so
I'm
here
to
tell
you
about
a
document,
basically
reinterpreting
our
voter
yang
in
terms
of
sea
boar.
Please
ignore
the
pink
part
at
the
bottom.
J
J
So
right
now
for
animal
we've,
a
bootstrap
protocols
called
brewski,
it's
in
the
final
editing
stages
and
it
uses
HTTP
for
everything,
our
HTTP
and
we
think
of
that
as
four
big
devices
and
big
networks
like
ISPs
and
we'd
like
to
redo
this
again
and
smaller
networks.
So
right
now
we
have
a
document
in
a
sitz
just
been
adopted
actually
for
after
these
slides
were
made,
which
puts
EST
over
co-op.
J
J
J
You
might
remember
this
diagram
from
the
bottom,
which
was
maybe
three
years
old
or
something
like
that
and
it
kind
of
when
we
are
arguing
for
doing
the
weirwood.
We
do
the
voucher
work.
Would
it
be
a
net
comp
or
anima
or
six
dish,
and
this
diagram
basically
just
gave
the
kind
of
the
the
one
the
the
relationship
between
what's
happening
here
and
what's
happening
in
six
dish.
J
We
have
since
actually
renamed
things
such
that
both
both
six
Tish
and
anima
used
the
same
terminology
for
registrar's,
join
proxies
and
pledges
so
you'll
see,
there's
other
other
names
join
node
and
join
us
systems
at
the
bottom.
There
next
slide,
please.
So
how
did
the
vouchers
change,
essentially,
we
see,
relies
to
see
bor
and
we're
using
SIDS,
which
is
a
GI
camera,
what
the
acronym
stands
for,
but
it
is
a
specification
coming
from
the
core
working
group
that
essentially
tells
you
how
to
translate
yang
into
Seaborg
and
in
that
process.
J
We
have
a
request
which
I
find
still
bizarre,
but
I'm
not
going
to
argue
with
it
to
sign
the
the
smaller
seaboard
voters
using
CMS.
So
let's
make
the
inner
content
really
small,
a
C
bar
and
then
sign
it
with
something
kind
of
big.
It's
a
bit
bizarre
to
me,
but
the
argument
is
that
the
code
is
already
there
because
you've
run
GT
LS.
J
So
that's
why
they're
gonna
want
to
do
that
and
also
that
I
think
it
has
also
to
do
with
that
who
certain
certain
communities
are
not
very
familiar
with
cryptographic,
operations
to
begin
with
and
they're
just
getting
to
know
CMS
and
to
tell
them
to
do
something
else
again.
Will
be
just
too
weird,
we
also
would
like
to
sign
with
Cosi.
J
That's
that's
not
new
in
terms
of
it's
something
we
don't
do
in
in
the
current
voucher
document,
where
it
is
CMS
and,
of
course,
you
know,
we
would
like
to
have
the
voucher
operations
in
in
the
est
next
slide.
Please
who's
going
to
use
it
right
now,
fair
hair,
which
is
a
lighting
consortium
for
Building
Control.
Very
much
wants
to
do
this
kind
of
stuff.
They
want
to
do
it
in
there
essentially
they're
building
in
it.
They
they
they.
J
They
intend
to
build
an
ACP
between
they're
loading
lighting
controllers
and,
if
you
want
to
think
about
what's
happening,
the
building
owns
the
ACP
and
controls
all
the
lighting
controllers
and
the
tenants
control
the
light
switches
they're.
The
tenants
are
that
the
actual
app
and
users
as
it
were,
of
the
network
and
they
get
a
network
that
has
light
switches
to
turn
lights
on
and
off,
but
the
building
controller
owners
control
the
controllers
through
the
ACP.
J
J
So
the
GRC
is
the
thing
that
really
changes
the
most
okay.
So
that's
the
join
registrar
and
coordinator,
so
it
still
speaks
a
lot
of
different
connections.
Here
still
speaks
to
the
mass,
as
I
said
with
HTTP.
It
still
speaks
to
the
CA
back-end,
using
whatever
protocol
that
CA
wants
to
talk
to
that's
out
of
scope
for
us,
and
but
now
it
receives
these
green
connections,
which
are
going
to
be
over
Co
app
and
going
to
be
through
some
other
kind
of
proxy
mechanism.
So
IP
IP
is
still
a
possibility
with
Co
app.
J
So
I,
it's
looking
like
a
less
and
less
good
idea
to
make
it
in
common
with
them.
There's
also
the
Atlas
working
group,
so
where's
Edie
Hawk
puts
their
security
above
co-op
into
the
application
layer.
There's
also
an
attempt
to
do
the
same
thing
where
you
put
TLS
above
co-op,
so
that
would
be
ad
hoc
and
that
could
be
supported
as
well
if
you
wanted
to.
But
what
we're
really
talking
about
in
this
document
is
that
the
fact
that
you
have
vouchers
that
are
constrained.
J
Some
constrained
networks
want
to
do
that
and
other
constraint
networks
want
to
just
get
a
network
key
which
they're
going
to
rekey
with
and
so
the
relationship
the
trust
relationship
between
the
pledge
and
the
jrc
that
allows
the
pledge
to
join
the
network
may
be
an
ongoing
relationship
that
they
keep
alive
for
the
duration
of
the
network.
Next
slide,
please!
J
J
They
could
be
the
same
value
because
it's
really
the
same
object,
but
actually
in
two
different
containers,
and
so
that's
a
bit
weird
in
some
ways,
but
they're
gonna
resolve
that
next
slide.
Please
so
here's
an
example
to
do
do
things.
Well,
there's
a
parent
SID,
it's
a
3-bike
seaboard,
number
or
more
there's
an
allocation
mechanism.
It's
a
website!
J
You
can
go
to
get
your
own
own
group
of
50
Sid
numbers,
so
that
starts
as
a
number
and
then
we
have
positive
integers
to
basically
as
Delta,
so
they
work
out
as
one
byte
and
then
you
have
the
data
in
there.
In
fact,
I've
shown
the
date
that
way,
but
it's
quoted,
but
that's
wrong
it.
It
actually
would
has
to
be
a
sieve
or
date
object
and
then
a
bunch
of
things
that
content.
So
you
can
see
on
the
right-hand
side.
J
J
J
E
E
J
J
But
so
I
have
posted
a
number
of
times.
I
have
a
document
that
is
called
constraint.
Road
map
and
it
kind
of
puts,
takes
all
the
boxes
and
the
different
columns
together
and
it
son.
It's
it's
unclear
at
this
point
where
it
belongs
or
what
it
belongs
to,
but
it
has
five
boxes,
one
of
which
is
anama,
one
of
which
is
net
Kampf,
one
of
which
is
sixty
or
two
which
is
six
dish
and
then
has
a
new
one,
which
is
a
which
is
this,
which
has
a
been
created
middle
right.
J
Now,
it's
in
the
it's
in
the
IOT
directorate
wiki,
because
that's
where
people
thought
it
belonged,
and
it's
not
a
document
at
all
and
a
good
third
of
the
a
third
of
the
document
just
says.
This
document
is
in
working
group
X,
and
this
document
has
no
home
and
stuff
like
that,
so
just
to
keep
track
of
as
much
which
pieces
don't
have
homes
as
which
pieces
you.
This
is
one
of
the
pieces
that
do
not
have
a
home
as
yet.
Well
if.
E
J
E
K
Next
written
on
the
discussion
of
the
signing
format,
the
current
draft
is
empty
on
the
COEs,
a
format
and
I'm
asking
the
question
with
determination
as
to
whether
or
not
the
issue
is
that
people
just
don't
understand.
That
goes
a
format
and
haven't
generated
the
text
for
that,
and
thus
don't
have
anything
to
read.
Compare
against
whether
there's
actually
pushback
saying
they
don't
want
the
cose.
J
K
K
B
F
We
just
reused
cross
negotiation
message
as
a
transport
protocol
between
client
and
in
a
client-server
approach,
and
the
communication
model
is
a
little
bit
different
than
an
original
cross
negotiation
message,
because
it
will
require
some
asymmetric
approaches
and
the
co
of
the
craft
is
not
to
promote
cross
as
a
very
decent
transport
protocol,
but
rather
it
is
for
your
convenience.
If
you
only
need
to
do
some
some
information
to
be
transport
on
your
hand,
then
you
can
just
use
a
clasp,
so
this
is
not
for
a
better
performance
or
better
security
or
whatever.
F
It
is
just
for
simplification.
Next,
some
updates
seems
lost
yet
here
we
emphasize
that
it
is
for
your
convenience,
it's
not
for
performance.
We
don't
want
to
replace
FTP
OGF,
TFTP,
etc,
and
we
also
have
some
manner
technique.
Leverage
occasions
and
if
one
is
I
need
simultaneous
transfers
it
can.
It
is
separated
in
different
cross
new
machine
sessions.
F
F
Whether
it's
a
problem
for
some
transport
scenario
is
still
an
open
question
and
what's
the
use
case
in
you
know
what
kind
of
situation
people
want
to
use
grasp
as
a
transport
protocol,
and
maybe
we
also
need
to
define
some
dedicated
api
other
than
grasp
synchronization
api
for
back
transfer
and
whether
these
draft
is
for
your
information
or
maybe
a
protocol
standard
track.
These
are
some
open
issues.
I
think
that's
all
any
question
comments.
F
A
F
A
K
Thank
you
for
adjusting
the
schedule,
the
we
have
another
presentation,
next
door,
so
I'm
trying
to
bounce
it
back
and
forth.
So
this
was
just
presented
in
the
security
dispatch
working
group
discussion.
So
there
is
timeliness
here
in
the
conversation
in
that
they
just
talked
about
this
and
I'll.
Try
and
sync
the
two
up,
but
I
do
recommend,
while
I
through
these
slides
together,
I'm,
not
the
author
on
the
draft
and
the
they
have
a
set
of
slides
that
they
presented
in
security
dispatch.
So
I
do
recommend
looking
for
those
if
you're
interested
in
it.
E
K
You
so
predominantly
what
they're
talking
about
here
is
use
cases
regarding
when
you
would
do
a
short-term
certificate,
and
why
and
in
in
particular,
if
you
look
at
the
draft,
they
talk
about
autonomic
and
an
eye
as
the
largest
body
of
text
within
their
current
and
draft.
Although
the
authors
themselves
are
not
familiar
with
anima
and
when
they
presented
their
slides,
they
presented
a
slide
about
anima,
but
then
said
we
have
nothing
to
say
about
it.
They
don't
know
anything
about
anima.
K
The
other
use
cases
they
brought
up
most
consistently
was
around
data
centers
and
basic
environments
that
are
not
the
web,
and
the
conversation
within
security
dispatch
essentially
went
around
this
question
of
whether
short
life
time
certificates
would
be
appropriate
for
the
web,
as
in
lots
of
folks,
came
up
to
the
mic
and
said
hey.
This
should
be
talked
about,
even
in
that
use
case.
So
the
predominant
sentiment
in
the
room
I
might
say,
which
was
that
they
should
consider
expanding
their
scope,
even
though
they
were
trying
to
limit
it.
K
The
the
general
question
here
is
around
the
idea
that
there's
a
bunch
of
code
to
support,
revocation,
whether
it's
a
serial
distribution
points
or
OCSP
or
etc,
and
that
that
code
is
the
most
dangerous
code
in
the
world
is
kind
of
body
of
code
and
the
more
code
is
there.
That's,
run
infrequently
or
run
with
lots
of
options,
the
harder
it
is
to
get
everything
right
and
there's
certainly
a
lot
of
simplicity
that
can
be
achieved
by
just
simply
cutting
a
bunch
of
it
out
and
so
by
getting
rid
of
all
those
edge
conditions.
K
So
if
you
look
at
the
giraffe
section
for
as
a
series
of
these
operational
considerations
of
what
they
do,
the
lifetime
and
renewal
conversation
there's
a
couple
of
discussions
in
there
about
brewski
they're
referencing
our
documents
and
they're
lacking
knowledge
in
that
space
is
clear.
They
they
mix
up
a
couple
of
things
but
effectively.
What
they're
saying
is
between
brewski
and
est
and
Acme
that
it
is
possible
to
automatically
distribute
these
certificates
as
needed
in
keeping
them
up
to
date.
K
So
this
is
their
standing
on
our
shoulders,
even
if
they
haven't
understood
quite
how
we're
standing
up
yet
and
they're
talking
about
certificates
and
it's
just
a
very
short
lifetime,
which
is
very
similar
to
what
we've
done
with
our
vouchers
and
other
things.
So
it
is
very
consistent
with
our
vision.
K
K
The
the
the
general
statement
they're
making,
which
is
almost
exactly
the
statement
that
we've
made
with
in
the
voucher
documents
within
our
work,
is
that
this
is
really
no
different
than
having
an
OCSP
server.
Those
minor
key
issues.
They
do
talk
about
clock
skew
as
an
issue
in
addressing
that
which
we've
talked
about
a
lot
in
the
brewski
conversation
we
use
nonces
and
we
avoid
a
clock
issues
during
bring
up.
K
But
we
then
do
have
a
clock
which
we
worry
about
first
certificate
of
validity,
and
what
they're
really
just
saying
here
is
that
you
have
to
make
sure
that
clock
is
in
sync,
but
I
think
we
have
that
problem
anyway.
You
have
that
problem
with
those
CSB.
So
that's
a
no
op
for
us
I
believe
certificate.
K
Transparency
is
an
issue
because
you're
now
generating
multiple
certificates
at
a
much
higher
rate,
and
so
you
have
to
go
and
log
all
that
stuff
and
part
of
the
reason
why
they
wanted
to
avoid
the
web
use
case
and
talk
about
just
anima
or
data
center
is
because
certificate
transparency
is
and
is
used
in
our
use
cases.
It
makes
sense
for
us
next
slide,
and
so
the
other
point
I
want
to
make
is
this
all
just
dovetails
right
off
of
where
we
are
with
Bruce
key,
which
is
to
say
short-lived.
K
Don't
do
revocation
go
get
a
new
one.
Expect
your
server
in
this
case
the
massive
server
to
be
up
and
running
so
that
you
can
do
that
and
all
they're
really
just
saying
here
is
that
the
anima
ca
would
be
always
on
and
always
available
to
issue
new
certificates
to
any
of
the
devices.
To
me,
this
just
makes
all
of
our
animal
work
simpler
and
cuts
out
edge
conditions.
K
So
I
think
this
is
really
good
and,
like
I
said
it's
a
repeat
of
essentially
the
exact
same
argument
we
made
for
vouchers,
so
I
think
it's
very
much
an
align
with
our
stuff.
The
conclusion
in
the
security
dispatch
work
meeting
next
door
was
that
they
are
going
to
recommend
that
this
work
go
to
the
lamp
working
group
which,
as
was
commented,
is
a
might
be
an
adjustment
to
the
Charter
for
lamps.
K
E
E
K
E
I'm
talking
about
the
the
arrows
that
write,
the
the
shorter
you
make
the
lifetime,
the
higher
the
risk
that
you
have
an
issue
and
then
especially,
if
you
can't
to
get
a
voucher
again
because
of
the
type
of
deployment
case.
That's
basically
when
you're
the
modification
of
extending
the
recognition
of
the
LDAP
ID
for
the
EST
renewal
itself.
It
would
be
the
easy
way
out
unless
somebody
shows
that
there.
K
B
K
E
You
think
that,
basically,
the
goal
should
be
that
this
modification
of
the
semantics
of
the
expiry
lifetime,
in
terms
of
you,
can
extend
the
validity
of
the
certificate
for
the
purpose
of
renewal
that
you
know
something
like
even
standard
Trek.
You
know
introducing
this
could
be
done
through
this
draft.
We
wouldn't
need
another
one.
I.
B
K
E
K
J
Michael
Richardson,
so
I
just
quickly
scanned
the
document
you
pointed
out
and
I
guess
the
the
thing
that
they
get
wrong
is
that
they
believe
that
we're
we
have
specified
short-lived
certificates
when
we've
specified
short-lived
vouchers
in
our
document.
That's
that's
their
a
mistake
that
you're
referring
to
exactly
and
I
will
work
with
them
too,
and
that's
that's
great
so,
but
what
it
sounds
to
me
that
that,
as
you
just
said
it
will,
the
document
will
go
somewhere.
J
They'll
do
something
sounds
to
me
that
that
the
right
approach
for
us
is
in
the
future
to
write
a
BCP
on
operations
of
the
acp
and
that
it
could
refer
to
this
option
of
short-lived
certificates
rather
than
OCSP.
Ironically,
of
course,
the
acp
makes
the
OCSP
much
more
reliable
and
available.
So
in
some
sense
it's
it's
it's
relevant
for
everyone
else,
except
to
us
right.
J
E
Know
so
maybe
my
point
on
that
is
that
the
actual
Bruschi
mechanism
right
given
if
you
fail
right,
if
your
certificate
expires
right,
then
the
fact
we
can
still
use
the
brachot
the
brewski
proxy,
even
though
we're
just
doing
EST
renewal-
and
we
couldn't
do
that
across
the
acp
anymore,
because
our
short-lived
certificate
expired
right.
So
I
say
that
is
basically
the
culottes.
J
E
K
J
K
J
J
You
know
it
can
be
pointed
to,
but
at
a
future
point
that
the
the
you
know
the
someone
may
run
into
right
in
a
BCP
about
best
best
best
practices
for
operating
your
acp
right
and,
and
it
could
say
that
the
movement
to
shorter
turn.
Certificates
with
regular
renewals
is
a
is
a
good
and
good
thing
in
the
following.
E
I
think
the
other
part
also
is
that
they
think
most
of
the
other
co-authors
came
from.
You
know.
Data
center
and
other
environments,
where
we
don't
really
you
know,
have
I
think
right
now,
a
good
starting
point
for
the
ACP,
but
educating
that
you
know
you
can
still
rely
on
brewski
and
est
with
this
change
semantics
to
very
simply
have
also
a
non
a
and
I
just
brewski.
You
know
deployment
case
for
for
short-lived
certificates
that
are
fully
autonomically.
You
know
renewed
I,
that's
that's!
B
B
As
I
understand
it
as
a
basis
of
work
in
anima
is
a
concept
of
not
all
autonomic
note
which
could
be
put
together
in
a
form
of
a
network,
and
then
everything
else
is
defined.
The
control
plane
all
the
others.
Well
sure
this
is
good,
but
not
good
enough,
because
I
have
very
few
of
such
things
around
and
anybody
wants
to
add.
B
B
Animal
as
a
whole.
I
am
promoting
the
fact
that
it's
a
time
to
move
in
line
with
what
is
now
called
sub
particular
type
of
sub
networks,
which
are
called
slices
which
are
emerging
and
emerging
as
a
commercial
reality,
as
well
as
research
and
development
reality,
and
to
apply
or
try
to
readjust
animal
to
this
environment.
That
means
to
move
to
practically
from
existing.
B
B
This
issue
is
not
only
a
single
domain,
it's
multi
domain
and
to
end
so
that
when
you
add
these
complexities
to
it,
the
question
is:
is
it
anima,
as
it
is
now
easy
to
deploy
as
soon
as
a
time
to
move
a
bit
towards
the
way?
This
could
be
much
easier
to
be
deployed
and
I'm
also
going
argue
that
it's
a
time
to
piggyback
on
the
big
activities
called
Network
slicing,
which
is
basically
sub
networks
of
a
particular
kind
which
are
dynamically
created,
but
for
a
purpose
of
supporting
a
service
is
not
a
generic
Network.
A
Personally,
I'm
fine
with
that
I'm.
Actually,
that's
my
ambitious
to
be
able
to
handle
the
you
know
multiple,
my
issues,
but
the
reality
is
up
to
now.
The
animal
is,
you
know,
based
on
the
something
we
are
working,
a
single
domain,
so
I'm
afraid
you
know
there
are
a
lake
of
some
fundamental
supporting
to
do.
Much
to
me
in
my
working
group,
I
mean
I'm
fine
with
you.
He
has
that
he
knew
evasion,
but
you
know
it's
probably
we
did
the
two
Sampson
you
know
to
match.
A
B
A
very
good
comment,
but
from
the
positive
point
of
view,
multi
domain
issues
is
a
norm
now
for
operators
yeah
and
for
management.
For
why
not
to
do
you
constraint
too
much
to
a
single
domain,
so
multi
domain
could
add
a
lot
of
other
features
of
capabilities.
Don't
you
need
to
be
customized?
That's
a
complexity
of
yet,
but
still
it's
possible.
Yes.
B
F
B
Okay,
you
know
my
next
set
of
slides
I'll
just
point
out
further
work
which
need
to
be
done.
You
know
that
to
make
if
you
want
anime
technology
as
a
whole
or
parts
of
it
slice
aware
not
all
the
work
is
completed
in
this
draft,
but
it
will
continue
this
simple.
The
grammatical
form
says
that,
at
the
end
of
a
day,
slices
are
combination
of
network
resources
put
together
other
dynamically,
together
with
some
network
functions
for
the
purpose
of
supporting
of
a
service
and
can
have
many
such
slices
in
a
network.
B
It's
still
not
clear
how
many
can
properly
define,
but
the
whole
purpose
of
it
is
to
allow
some
network
being
customized
for
a
service,
and
that
means
that
there
are
the
mechanistic
ratings
I'm
to
manage
them
to
deploy
them
and
so
on.
It's
outside
of
animal
working
group,
but
it's
a
time
for
anima
to
take
advantage
early,
which
may
be
that
some
additional
interfacing
capability
for
differing
infrastructure,
part
of
anima
may
be
a
useful
seems
to
to
be
developed
further.
Thank
you
next,
just
to
restate
that
actually.
B
To
some
extent,
autonomy,
city
and
augment
automation
are
key
requirements
for
network
slicing.
It
is
unconceivable
to
create
millions
of
such
things
if
this
capability
are
not
deployed
it's
time
to
take
advantage
of
or
to
piggyback
on
this
activity
and
some
extent,
this
could
be
quite
easily
done
through
the
extension
of
animal
technologies.
Another
point
is
that
it's
a
time
to
go
above
the
issue
of
centralized
or
central
logically
centralized
management
approaches
for
for
doing
that.
It's
a
time
to
go
for
full
distribution
in
order
to
take
advantage
of
the
multi
domain
and
end-to-end
issues.
B
And
this
could
be
performed
if
new
capabilities
are
added
to
some
of
the
anima
drugs.
One
of
it
is
not
to
assume
that
the
whole
or
not
automation,
functionality
is
applicable,
but
to
customize
it
for
specific
sets
of
some
facts
functions.
Obviously
this
could
be
specialized
for
a
particular
slice.
Other
slice
will
be
different
and
that
help
a
bit
who
is,
in
my
view,
with
first
of
all,
separating
logically
the
autonomic
behavior
from
the
physical
underlying
network
resources,
but
also
take
advantage
of
it
to
make
it
easy
or
easier.
B
In
my
view,
the
probability
which
is
probably
a
a
good
objectives
next
slice,
so
a
number
of
issues
need
to
be
looked
at
in
terms
of
augmenting
other.
The
assumptions
or
some
of
the
issues
related
to
different
parts
of
anima.
First
of
all,
is
to
embrace
virtual
environment.
You
cannot
do
it
without
it,
and
obviously
this
could
be
done
in
many
ways,
but
this
it
is
important.
B
Autonomous
City,
then
there
are
other
important
point-
is
the
time
maybe
to
focus
on
few
specialized
as
they
are
defined
in
the
last
ten
years.
Autonomic
capabilities,
namely
self
configuration
self
monitoring,
self
optimization
self
elasticity,
which
will
be
also
key
to
put
it
in
place.
A
generic
or
dynamic
system,
in
my
view,
will
have
a
very
long
time
to
be
accepted,
so
it's
better
to
concentrate
on
this
part.
J
J
Virtual
machines
inside
of
nodes
could
participate
in
the
in
anima
and
as
far
as
I
can
see
if
using
you're
using
the
physical
layer
anima,
you
build
a
ACP
in
a
network,
and
then
you
put
up
a
bunch
of
virtual
routers
top
of
that
with
virtual
links
between
them.
That
there's
no
reason
you
can't
run
another
instance
of
anima
if
the
customer
wants
to
run
their
own
autonomic
Network.
J
On
top
of
that,
yes,
there
are
some
interfaces
that
you
need
to
be
able
to
configure
physical
vert
new
virtual
interfaces
below
so
the
upper
customer
he
wants
to.
Have
you
know
new
interfaces
plugged
in
from
place-to-place?
He
needs
a
new
connection,
but
that's
that's
in
the
space
of
some
customized
ASAE
to
me,
it's
not
a
core
architecture
elihss
with
anima,
so
you've
asked
her.
What
I
see
on
this
slide
and
correct
me?
J
B
Don't
understand
what
you
said
by
the
way:
yeah
I
sympathize
the
same,
but
I
do
respect
I
disagree
with
you,
okay,
good!
Now,
let
me
give
you
the
the
other
side.
A
slide
is
not
just
a
network,
it
is
an
service
network.
In
other
words,
the
combination
between
a
service
and
the
network
resource
yeah
is
a
unit
yeah.
If
you
decouple
say,
I
need
the
anima
or
any
other
network
technology
on
one
side
and
service.
On
the
other
side,
it
is
like
classical
way
to
handle.
Today.
This
is
not
a
case
for
slices.
B
J
J
B
Let
me
give
you
another
aspect
as
soon
as
you
move
to
this
slicing
or
virtual
environment,
you
have
suddenly
the
issue
of
scale
a
lot
of
virtual
machines,
not
few
thousand,
maybe
few
millions,
and
this
scale
okay,
dictates
to
be
a
bit
more
refined
in
terms
of
the
control
play.
You
cannot
do
it
for
all
of
them,
so
it's
a
time
to
think
a
bit
more
carefully
on
this.
Maybe
it's
not
new.
Indeed,
virtualization
is
older
than
networking
anyway
in
historical
terms,
but
I
think
that
this
aspect
requires
additional
attention
to
make
it
properly
used.
J
B
Have
some
more
slides
about
other
parts?
Are
the
requirements
not
only
on
si,
but
I
have
to
say
that
I'm
I
sympathize
were
saying,
but
I
think
it's
a
time
to
move
forward
rather
than
to
to
say
that
they
say
is
good
for
every
his
feet.
All
type
of
our
arguments,
I'm,
not
convinced
all
other
either
yeah.
A
A
If
that's
something
you
know
a
functional,
a
something
could
be
shared
along
multiple
visa,
maha
asa
that
that
could
become
something
generic
using.
It
may
get
done
to
some
more
fundamental
stuff
to
be
able
to
you
know,
handle
by
the
ad
my
working
group,
but
before
that
I'm
I'm,
you
know
thinking
you
know,
maybe
you
you
should
make
this
more
in
generic
way,
like
Samsung
virtual
resource
management,
design
that
maybe
you
know
in
in
in
you
know
better
share
to
be.
You
know
at
octopi
other
is
us,
then
that
makes
sense.
We
women
do
that.
A
E
And
I'm
still
trying
to
figure
out,
you
know
what
the
most
simple
instances
are
explaining
this
work
for
somebody
who
would
want
to
code
something
that
actually
runs
in.
So
if
I
think
about
the
ACP,
and
you
know,
I'm,
building
a
slice
and
that
consists
of
virtual
machines
across
a
bunch
of
devices
and
I'm
saying
oh
I
want
to
have
you
know
for
this
virtual
network,
an
ACP
to
manage
it
in
the
same
way
that
we,
you
know
currently
are
doing
it
for
the
physical
network.
Then
the
question
is
Harmon
building
the
ACP.
E
E
Because
you
know
you
already
have
that,
and
you
already
have
the
connectivity
into
all
these
devices
right
on
the
on
the
physical,
a
si
that
we're
building
so
far
we
had
to
I
mean
there
was
a
release
on
case
to
do
it.
Autonomically,
because
you
didn't
have
the
connectivity
you
first
had
to
bring
up
the
devices
you
built
that
if
you
do
it
for
a
virtual
context,
I
think
we
need
to
you
know,
find
the
good
deployment
operation
on
other
cases
to
do
it.
E
Autonomically
through
an
a
sa
instead
of
an
SDN
controller
and
scale,
can
be
one
reason
but
again,
I
think
that
you
know
there
is
a
lot
larger
scale
in
data
centers
for
for
context,
a
slice
and
a
service
provider
network
I
still
haven't
seen
reasonable
expectation
if
there
would
be
more
than
five
or
six
slices
I'm.
Just
you
know,
I'd
be
happy
to
get
get
the
answers
like
we
have
the
scale.
We
have
the
requirements
to
do
it
in
ASAS,
but
I
think
those
requirements
need
to
be
really
well
worked
out.
B
Just
a
comment
on
what
yeah
I
fully
understand,
what
you
saying
agree,
but
just
to
point
out
that
the
current
networks
are
not
all
easy
and
enabled,
and
potentially
autonomy
City
and
has
to
be
applicable
to
other
situation.
It's
a
time
maybe
to
embrace
networking
services
together,
and
this
is
a
the
plea-
that's
a
rather
than
saying
that
but
customization
of
the
control
plane
for
this
purpose.
B
L
L
I
have
worked
on
implementations
of
PKI
in
the
millions
of
devices.
Yes,
that
deployment
speed
has
been
traditionally
been
slow,
but
some
of
the
things
being
looked
at,
particularly
in
the
automotive
arena,
where
there's
going
to
be
need
for
fairly
fast
deployment
of
hundreds
of
millions
of
certificates.
We
are
looking
at.
The
scale
is
not
an
issue
that
there's
nothing
to
read
to
limit
Hardware
exist
to
do
the
operations
and
the
rest
of
at
at
speed
necessary
force,
giving
up
to
that
size.
It's
an
interesting
use
case,
one
that
definitely
looked
at.
L
B
The
only
thing
which
aren't
to
add
is
that
the
needs
for
network
slicing
are
dictated
by
the
use
cases
in
a
5g
environment.
There
are
around
20
or
30
and
that
driving
the
whole
industry
to
make
it
happen,
and
there
are
no
equivalent
push
for
animal
to
do
the
same.
So
it's
not
that
network
slicing
people
will
use
animal
it's
a
time
to
do
it
with
a
in
a
next
period,
2d
together.
Otherwise
there
will
be
a
mismatch
in
to
yes,
that's
a
sort
of
a
marketing
answer
to
your
question.
Technically
you
you're
right.
B
B
Actually,
it
will
be
better
that
what
is
called
animal,
autonomic,
node
or
network
is
defined.
What
how
do
you
describe
it?
Otherwise,
you
cannot
apply
to
anything.
So
it's
a
bit
to
make
it
a
bit
more
prescriptive,
and
this
is
clearly
needed.
Obviously,
it's
the
time
also
to
look
at
some
some
way
in
which
you
could
allow
this
capability
to
be
extended,
shrinked,
configured
destroyed
and
obviously
some
facts
in
terms
of
composition,
configuration
and
particular
monitoring
and
others
to
be
applied
to.
B
B
One
item
which
I
mentioned
before
that
there
is
a
interplay
between
a
tenant,
and
this
have
network
owner,
which
is
a
operator
the
interface
between
the
two
and
the
wine
which
this
one
we
negotiate
in
terms
of
using
information
analysis.
This
is
important.
This
is
missing
is
like
an
additional
element
to
make
anima
a
bit
more
applicable.
The
customers
ranima
are
not
defined
I'm,
just
arguing
that
the
tenant
of
these
slices
would
become
a
good
candidate
for
being
customers.
Therefore,
offering
capabilities
to
them
for
more
or
less
control
or
management.
B
B
Talking
to
my
colleagues
a
single
time
to
split
this
into
maybe
separate
items
to
be
more
concrete
if
you
want,
but
at
the
end
of
the
day,
this
is
a
plea
to
piggyback
on
current
emerging
but
substantial,
much
bigger
than
animal
work
in
terms
of
commercial
research
and
development
work
on
slicing,
which
is
mainly
about
well
G,
as
potentially
the
best
way
to,
in
the
probability
of
all
the
aspects
so
far,
without
changing
all
of
them,
but
adapting
that.
That
concludes
my
simple
presentation
about
it.
Thank
you.
Yeah.
A
Man
make
just
one
country
you
know:
I
I
can
I
can.
Can
you
say
you
know
I
like
your
shopping
list,
but
that's
not
the
way.
You
know
how
our
IDF
working
group
work.
You
know
you
should
come.
Not
just
tell
us.
This
is
your
shopping
list,
but
you
should,
you
know,
come
to
bring
a
PTO
solution.
You
know
it
give
us
something.
A
A
Somebody
you
know
in
this
room
would
do
that
I'm,
not
sure
we
don't
Widow
as
a
IDF
working
group
with
all
individuals.
We
don't
have
the
choice
to
just
you
know
to
produce
something
you
know
by
the
working
group
to
for
your
shopping
list.
So
we
actually
expect
you
to
give
us
detailed
solutions.
Actually.
M
Hi
Elliot
leer
I
think
what
you're
talking
about
our
next
steps
right
in
terms
of
how
you
might
how
you
might
evolve,
what
you've
started
in
a
draft
into
very
specific
protocol
proposals,
yeah
and
which
one
of
those
would
have
uptake
in
the
group
and
which
ones
perhaps
do
not
in
terms
of
you,
can
you
can
test
them
individually?
I
think
it's
perfectly
reasonable
comment
for
the
chair
to
have
made
in
terms
of
you
know,
leading
you
into
that
that
discussion
I
think.
That's
that's
actually
an
excellent
point
of
discussion
for
now.
All.
A
E
Next
slide,
all
right,
so
a
quick
reminder
of
the
background.
So
this
originally
started
out
when
you
know
a
bunch
of
the
you
know
flexibility
options
we
wanted
to
have
for
discovery
forward.
We
needed
in
the
a
and
I
est
and
Bruce
Corso
became
too
much
for
the
standards
track,
documents,
brewski
and
ACP,
and
then
I
started
to
write
up
how
to
more
generally
map
the
DNS
SD
attributes
and
add
to
it
what
we
could
do
even
more
than
DNA
SSD
into
you
know
something
that
applications
for
breasts.
Any
any
application
grasp
could
reuse.
E
E
Then
you
figure
out
what
what
happens
when
these
fail
and
you
configure
two
IP
addresses,
and
then
you
know
when
these
fail,
you
have
to
reapply
and
any
I
think
you
you
get
the
point
that
this
is
really
the
the
classical
way
on
how
to
bring
today.
You
know
an
A
and
I
network
with
a
knock
together
very
easily.
So
that's
basically
what
I
really
wanted
to
achieve
in
this
table.
Connectivity
next
slide
so
I.
E
Would
like
to
write
another
draft
sitting
on
this,
which
would
really
be
a
small
normative
draft,
as
part
of
the
example
use
case
with
this
table
connectivity
right.
So
the
current
draft,
which
is
in
the
RFC
editor
queue,
describes
the
framework,
the
goal
the
overall
and
basically
to
me
the
most
simple
starting
point
to
really
say:
okay,
your
heav'n,
a
and
I.
You
want
to
use
it
for
stable
connectivity.
Here
is
basically
the
services
that
you
already
have
in
your
network
equipment.
E
The
list
up
front
here
are
basically
the
most
of
them
already
have
a
DNS
SD
service
names.
This
is
basically
what
you
need
to
do
to
connect
an
existing
NOC
with
all
these
services
together,
and
that,
of
course,
would
refer
to
this
draft
right,
and
that
was
basically
for
me
kind
of
a
good
closure
for
the
stable
connectivity
use
case
to
really
show
how
to
first
deploy
a
and
I
with
a
knock,
and
that's
really
only
about
the
service
discovery
off
of
these
things.
E
If
we're
really
just
you
know,
discovering
all
these
services-
and
you
have
something
like
I-
don't
know
a
radius
client,
a
sis
lock
line
or
so,
and
it
uses
graph
to
discover
that
does
that
make
the
client
and
a
si
I
mean
it's
a
hypothetical
question
right:
I,
don't
really
care
because
I'm
just
only
interested
in
the
funk,
but
if
you
want
to
call
them
ASAS,
we
could
I
think
because
they're
already
using
them
the
ACP
they're
using
grasp
to
discover
the
service
and
the
rest
is
just
existing
functionality.
Next
slide
right.
E
So
there
might
be
other
things
to
do
with
this,
which
I'm
not
really
that
interested
in
right
now
from
an
animal
perspective.
They're
a
bunch
of
you
know
a
hybrid
MD
and
Sdn
SSD
solutions,
so
Bryan
and
I
discussed
whether
we
might
want
to
propose
also
just
using
grasp
domain
as
a
transit.
But
again
this
is
below
the
line
for
me
next
slide.
So
really
for
me,
the
first
step
would
be
you
know
getting
feedback
opinions
and
I'm
I
would
like
to
hereby
officially
ask
you
know
for
a
working
group.
Adoption
of
this
draft
hater.
F
M
M
There's
a
related
effort,
that's
going
on
in
the
DHC
working
group.
I
just
wanted
to
bring
to
your
attention,
which
is
that
they're
in
the
process
of
taking
the
DHCP
options
and
yang
off',
eyeing
them,
and
it
may
be
that
there's
some
some
way
you
can
leverage
that
mechanism
in
terms
of
not
having
to
respess
off'.
I
all
of
the
the
discovery
formats
and
things
like
that.
It's
I'm
not
saying
you
should
do
this
I'm
just
saying
you
should
be
aware
of
it,
and
it
may
be
something
useful
for
the
word.
E
Yeah
so
in
my
past
experience
and
I,
certainly
if
you
can
ping
me
with
with
the
draft
names,
if
I
don't
find
them
myself
in
my
past
experience,
you
know
DNS
SD
already.
Has
you
know
good
libraries
also
grasp.
We
can
have
a
simple
library
that
basically
server
in
the
NOC
uses
to
nouns
itself
with
a
few
parameters
and
I'm,
not
aware
of
any
really
good,
simple
lightweight
alternative
with
DHCP
right.
The
way
you
do
it
with
DHCP
is
a
lot
more.
E
M
I
don't
mean
that
you
should
use
DHCP
as
the
mechanism
right.
However,
the
yagna
fication
of
the
parameters
formats
can
save
you
a
little
bit
of
time
in
terms
of
maybe
what
you
really
just
need
is
an
encoding
rule
from
one
to
the
other,
and
it
can
save
you
a
lot
of
time
as
you
tackle
that
list.
It's
all
I'm
saying
yeah
agreed
Michael.
J
Richardson
here,
I
think
Elliott
definitely
has
a
very
good
point.
I
actually
think
some
of
this
stuff
could
really
be
killer
app
for
a
lot
of
stuff
for
a
lot
of
places,
getting
machines
configured
for
syslog
when
you,
when
there
otherwise
kind
of
a
topknot
autonomously
they're,
the
the
the
they
have
local
administrators
right
and
who,
with
local
rights-
and
they
regularly
don't.
You
know,
set
up
a
bunch
of
these
things
because
they
don't
think
about
it.
J
Getting
that
kind
of
stuff
happening,
I,
think
that
would
be
a
really
killer,
app
for
a
lot
of
things
and
particularly
in
a
bunch
of
ISPs,
and
you
can't
use
often
to
HCP
for
this
because
well,
the
machine
in
question
is
the
DHCP
server
and
you
know
using
it
too.
It's
just
it's
just
too
weird
to
do
that,
but
so
I
think
that
actually
would
be
really
really
good
and
I
and
I
on
there
and
it
and
in
place
of
your
TFTP
yuck.
You
can
cross
that
it
and
put
suit
server,
yeah
yeah.
E
No
I
mean
how
our
list
is.
Basically
what
you
know
in
a
running
implementation
of
you
know:
pre
standard,
a
and
I
we've
relied
on
to
really
provide
the
stable
connectivity
use
case,
so
I
feel
fairly
confident
about
the
value
of
this
50
percent.
I
have
to
everything
more
on
what
the
good
ask
would
be.
E
E
Mean
okay,
so
this
is
the
still
not
gotten
around
to
the
bloody
draft,
but
already
trying
to
you
know,
hire
some
more
help
to
get
it
done.
So
I
think
we're
really
missing
for
the
a
and
ia
yang
model
to
really
Express
how
its
configured
and
you've
in
the
first
things
they
aren't.
We
autonomic.
No,
we
just
have
the
autonomic
infrastructure,
and
even
that
has
a
few
things
to
configure
and
even
though
they're
they
may
be
not
that
much.
E
E
There
might
also
be
a
nice
simplification
in
the
data
model
which
also
from
you
know,
an
existing
implementation
made
the
deployment
a
lot
easier,
which
is
that,
basically,
you
don't
care
what
the
bloody
CA
it
does.
You
just
create
a
local
CA
on
the
jrc.
Just
you
know
for
for
most
of
the
lab
networks
and
tests
and
everything
that
simplifies
it.
A
lot
because
really
getting
a
production
CA
run
makes
a
deployment
of
any
you
know
a
ni
network,
typically
a
tyler
parameters
for
the
masa.
E
So
obviously
we
would
love
to
learn
them
from
the
IDF
ID
part
of
brewski,
but
if
we
have
existing
certificates
that
don't
have
that
yet,
then
we
would
need
to
have
some
explicit
masa
configuration
on
the
jrc
and
then,
of
course,
also
the
aforementioned
to
grasp
parameters
for
the
registry.
In
terms
of
you
know,
I
only
want
to
be
jrc,
I'm
EST.
I
have
this
priority.
Those
things
acp,
I,
haven't
even
gotten
through
the
whole
list.
I
need
to
revisit
my
own
draft
in
terms
of
what
parameters
we
had.
E
E
A
I
Handsome's
and
it
was
my
joke,
but
seriously
you
know
well
autonomic,
so
I
I
would
say
you
know
by
default
or
minimal.
We
should
have
asked
nice
as
configuration
operation
here
so
I
know.
In
many
scenario
we
have
to
have
some
Samson
to
be
able
there
to
be
able
to
influence,
but
you
know
you
should
add
to
the
replica
needs
say
by
default.
You
know
those
those
parameters
has,
you
know,
has
a
value,
so
it
doesn't
leave
me
a
fake
I
mean.
E
That's
definitely
true
right,
so
that's
what
I
said
at
minimum.
If
I,
you
know
go
back
to
my
experience
with
existing
implementation
was
really
just
the
domain
name.
You
have
default
addresses,
so
it's
only
the
domain
name
and
you
say
okay
and
start
locally
CA,
so
the
the
defaults
could
be
very
small.
E
But
let's
also
not
forget
that
we
would
like
to
be
able
to
resell
the
individual
components
like
brewski,
with
a
lot
of
flexible
parameters
into
other
spaces
that
don't
have
a
full,
a
I
and,
of
course,
which
raises
the
question
then:
should
it
be
one
draft,
should
it
be
a
separate
yang
draft,
a
brewski
I
think
we
can
get
to
those
decisions
later
next
slide.
If
anybody
wants
to
jump
in
right
now,
please,
yes,.
F
F
E
And
I
would
hope
very
much.
You
know
chiming
in
wishing
that
you
know
for
a
normal,
a
and
I
deployment
where
the
ACP
serves
grass.
We
don't
really
need
any
parameters,
but
given
how
I
would
also
like
to
make
grass
something
reusable
kind
of
the
parameter
model
expressing
the
parameter
model
is
definitely
for
breast
itself.
Also,
a
good
thing
to
do
next
slide,
not.
E
Right,
so
there
was
basically
there
the
question
about
the
modularity
right,
one
or
multiple,
of
course,
also.
If
we
start
thinking,
okay,
somebody
just
has
the
ACP,
but
no
brewski
right,
so
are
they
even
existing
models
to
provision
certificates
through
yang
I
was
looking
a
little
bit.
So
that's
good
investigation,
brewski
without
ACP
right
configured
proxies.
Is
that
something
we
need
I
hope
you
know.
Michael
would
have
some
opinions
about
that
and
and
Max
and
then
yeah.
E
The
he's
going
to
talk
when
he
wants
to
talk,
so
that
was
basically
configuration
the
next
one
is,
you
know,
operating
observing,
so
the
read
data
right
so,
first
of
all,
obviously
what
we
that's
fine,
what
is
additional
operational
data
as
far
as
state
right?
So
obviously
in
the
ACP
we
have
the
wonderful
neighbor.
They
are
also
in
the
reference
model,
the
neighbor
table
right.
So
that's
basically
additional
operational
data.
We
want
to
be
able
to
pull
and
then
a
little
bit
the
question.
E
What
are
the
most
core
underlying
components
that
we
would
need
to
make
sure
exist
so
that
we
really
can
feel
safe
that
the
troubleshooting
and
operational
model
of
an
ACP
even
or
a
and
I,
even
everything
being
autonomic?
If
stuff
fails,
do
we
have
enough
diagnostic
standardized
to
make
sure
people
will?
You
know,
get
this
working
so.
J
Toriel,
so
this
is
what
I
was
hoping.
You
were
gonna
talk
about,
I'm,
I'm,
guess,
I,
think
I'm
less
interested
in.
How
do
we
configure
with
the
Eng
an
autonomic
system
that
we
shouldn't
configure
and
much
more
interested
in?
How
do
we
find
out
what
it
did
and
why
and
whether
it
will
hit
another
pedestrian
crossing
the
street
or
not
so
III
yang
is
in
the
post.
Tell
me
I'm
I.
Believe
yang
is
the
the
you
know.
E
That,
but
if
you
like
kind
of
operations
figuring
out
whether
it
runs
into
something-
maybe
you
like
the
next
slide
or
not-
we
go
to
the
next
slide.
So
what
what
I've
seen
in
in
practical
operations
is
that
it's
very
hard
to
actually
figure
out
problems
if
the
only
way
you
can
figure
them
out
is
in
a
live
case,
where
exactly
at
the
time
when
they're
happening
right.
So
in
many
cases,
surely
the
more
embedded
the
environment
becomes,
the
harder
it
is
to
instrument
alive
environment
name.
E
Even
if
you
weren't
able
to
get
all
the
log
information
life
when
it
happened
because
yeah
you
didn't,
have
the
connectivity
to
look
at
the
logs
right.
So
that's
that's
one
of
these
core
problems,
so
I'll
hope
that
the
folks
who
know
yang
better
will
tell
us
what
the
best
ways
are
to
express
this
type
of
functionality
to
really
make
the
troubleshooting
be
as
good
as
it
could
be.
Next
slide.
E
Ok,
so
then,
the
the
brewski
specific
thing,
which
I
think
is
is
quite
important
to
the
operations
of
brewski,
is
really
how
to
express
the
policy
with
pledges
should
be
allowed
into
a
domain,
and
when
we
started
you
know,
brainstorming
and
architecting.
This
is
was
all
about
whitelist
or
blacklist
on
a
registrar
on
the
GRC,
and
we
figured
that
that
was
really
too
limited,
and
you
don't
always
want
to
have
that
type
of
policy
locally
in
a
network
device
like
a
jrc.
E
So
there
are
a
lot
of
things
now,
also
with
the
bunch
more
parameters
coming
in.
It's
not
only
binary
decision,
but
also
some
parameters
that
you
return
back
in
the
certificate
that
might
need
to
be
more
flexibly
assigned
on
a
per
pledge
basis,
and
so
maybe
the
way
to
go
is
really
define
in
the
model
order.
A
and
I
or
more
specifically,
for
the
GRC,
an
RPC
type
of
call
from
the
registrar
to
an
external
server
to
make
the
decision
right.
So
you
basically
simply
provide
the
IDF
ID
and
you
get
in
return
back.
E
You
know
binary
and
roll
it
or
not
and
the
parameters
of
the
certificate
and
that
basically
I
think
gives
us
the
smallest
and
most
lightweight
model
and
the
most
flexibility
to
in
Clemente.
The
solution
keeps
the
jrc
I
think
as
simple
as
we
can.
Similarly,
an
RPC
for
the
est
renewal
with
pretty
much
the
same
parameters
next
slide
right.
So
this
is
basically
what
I
was
saying
right.
So
then
we
have
outside
the
a
and
I
outside
what
we
define
through
the
model.
E
The
kind
of
you
know
policy
server
and
the
CA,
so
we
don't
need
to
model
them,
but
luckily
that
could
be
somebody
else's
problem.
Obviously
we
would
still
love
to
have
yang
models
for
those,
but
if
we
can't
get
them,
then
we
at
least
have
a
nice
model
for
the
a
and
I
won
right.
Yep
I
think
we're
done
on
the
time
right
so
yep.
So
basically,
this
is
what
I
would
like
to
see
happening.