►
From YouTube: IETF110-SACM-20210310-1200
Description
SACM meeting session at IETF110
2021/03/10 1200
https://datatracker.ietf.org/meeting/110/proceedings/
A
A
A
Adam
we
give
another
minute
or
two.
I
was
wondering
if
you
wanted
to
check
your
audio
as
somebody
that
I
expect
might
be
speaking.
A
A
A
There's
only
or
two
people
I
was
thought
might
be
here
that
I
don't
see
at
the
moment
so
we'll
go
ahead
and
get
going
good
morning
afternoon
good
evening.
Welcome
to
the
stack
and
working
group
at
ietf,
110.
A
A
A
Fantastic
there
is
the
committee
tool
if
you
want
to
use
that
as
well.
A
Or
you
can
take
them
separately
as
a
notetaker,
you
can
choose
your
poison.
So
that's
the
minutes.
The.
A
Agenda
is
below
it's
a
pretty
short
agenda
in
hindsight.
I'm
not
sure
why
I
requested
two
hours,
it's
possible
that
it's,
because
that
little
reload
everything
from
the
last
meeting
is
just
a
tiny
bit
too
convenient.
A
So
first
up
on
the
agenda
is
coastwood
there.
You
will
have
seen
a
bunch
of
github
traffic
on
this,
and
so,
as
I
kind
of
suspected
hank,
would
you
like
to
talk
to
what
the
current
status
of
the
coast
would
document
is.
C
Yeah
hi,
this
is
saying.
Actually
I
would
like
to
do
that.
My
my
dear
cole,
editor,
dave
waltermeier
is
also
dearly
missing
right
now,
so
I
will,
I
will
jump
in
here
and
improvise
if
that
is
fine.
Also,
I
do
not
mind
that
we
have
scheduled
two
hours
because
we
could
go
and
run
through
all
the
restated
and
re-qualified
issues
from
roman.
I
don't
know
in
what
order
we're
going
to
do
that.
I
can
give
a
concise
overview
of
the
status
right
now.
A
Well,
I
mean,
I
think
it's
it's
dave.
Waltermire
was
the
one
person
that
was
one
of
the
people
I
was
was
was
looking
for,
so
maybe
we
will
do
the
meeting
part
first
and
then
we
will
go
back
through
and
go
through
the
the
issues.
If
that's
okay
with
you
a
little
bit
more
time
to
get
dave
here,
the
only
thing
is-
and
I
I
probably
should
have
reached
out
to
them
individually
was-
I
was
looking
for
dave.
I
was
also
looking
for
kathleen
because
of
her
architecture.
C
I
can
give
this
short
summary
about
what
we're
doing.
C
Thank
you
so
again
this
is
hank
hi
everybody,
one
of
the
editors
of
the
course
with
id
yeah.
As
karen
highlighted,
there
was
a
lot
of
traffic
on
the
github
tracker
due
to
our
attempts
to
address
romans
and
kathleen's
last
latest
input
there.
There
are
some
logistical
steps
to
open.
They
are
basically
all
ayana
or
registry
based
like
media
types
and
such
so
so
that's
on
dave's
plate.
I
can't
give
updates
on
that
today
skimming
the
list
of
reiterated,
open
issues
from
roman.
C
I
assume
there
by
by
just
reading
that
list
that
I
think,
like
90
of
that
is
covered
and
actually
has,
is
addressed
in
in
some
text
or
has
been
deemed
basically
not
applicable.
It's
only
a
few
cases,
so
we
can
run
through
these
later
and
our
estimate
is
that
yeah.
This
is
unfortunate,
a
little
bit
slow.
C
I
would
like
to
see
this
a
little
faster,
but
we
are
at
the
end
of
the
tunnel
here,
there's
not
only
light
at
the
end
of
the
tunnel,
but
we
are
at
the
end
of
the
tunnel.
So
I
think
this
is
the
last
round.
We
need
to
do
to
ship
this
and
yeah
details
upcoming.
I
might
want
to
have
a
small
report
here
on
this
front.
We
are
preparing
right.
The
moment.
C
Work
in
the
rats
working
group
that
will
make
use
of
a
coal
switch
and
create
a
rim
wrapper
around
that,
and
we
have
a
complement
to
code
switch.
We
currently
call
commit
the
concise
module
identifier
for
the
hardware
components
that
software
resides
on
to
identify
these
and
that
can
be
composed
of
composite
devices
of
various
complexity
and
also
addresses
the
problem
so
to
speak,
of
firmware
that
does
not
reside
in
a
file
system.
Just
as
a
reminder
goes
with,
or
switz
in
general
are
based
on
rely
on
file
system.
C
Existence
firmware
sometimes
does
not
bring
its
own
file
file
system.
Some
do
but
then
again,
there's
a
firmware
in
the
ranges
of
hundreds
of
megabytes.
C
Smaller
firmware
typically
doesn't,
and
so
it
is
feasible
to
cover
reference
values
and
hashes
and
data
about
that
in
in
on
the
hardware
side,
because
it's
about
the
firm
things
here
so
so
that
is
upcoming
just
as
a
highlight,
and
that
also
was
a
one
of
the
implementers
here
consumed
codes
with
and
therefore
created
new
running
code,
which
is
very
helpful.
There
are
three
implementations
now
out
there
that
two
of
them
freely
available.
C
C
Yeah
we
addressed
his
issue
actually
to
some
extent,
and
then
he
stated
more.
So
what
we
did
is
we
provided
a
single,
a
single
rule
in
cdda,
that
is
the
root
rule.
Now
that
covers
all
combinations
of
tagging.
Signing
tags.
We
have
two
corresponding
sections
in
the
id.
One
of
them
is
appropriately
called
text
co-switch
and
the
other
one
is
signed
code
switch
there.
We
also
made
a
very
early
on
statement
here
that
sebor
tags
are
not
software
tags,
so
software
tag
is
a
software.
C
Switz
effect
switch
a
term
attack
term
originating
from
the
switch
and
iso
domain
and
sibo
tags
is
attack
term
originating
from,
of
course,
the
sibo
wg
here
in
itf.
C
So
these
are
not
the
same
tags
and
we
disambiguate
them
early
on
in
the
section
that
is
called
tagged
code
switch
and
we
also
play
with
redundancy
to
make
it
very
clear
that
tagged
codes
with
tags.
This
name
includes
two
tag,
types
that
is
unfortunate,
but
it
can't
be
avoided.
We
have
to
live
with
this
terminology,
it's
not
from
us.
We
do
not
make
that
choices
that
are
not
conflicting
here,
but
we
can
disambiguate
them.
C
So,
having
said
that,
you
can,
for
example,
tag
the
outer
structure
of
a
signed
co-switch.
In
this
case
you
are
tagging
a
prefix
and
everything
with
the
sibo
attack
in
front
of
the
cosy
tag
of
the
cosy
envelope
in
which
a
coaster
then
resides
and
due
to
the
signing
via
cosy.
That's
the
thing
you
can
emit
the
attack.
You
can
have
it
redundantly,
you
can
add
the
code
coast
with
sibo
tag
outside
of
the
cozy
envelope
and
then
again
inside
in
front
of
the
actual
code
switch
with
the
redundant
tagging.
C
We
allow
from
that.
That's
not
super
cool,
but
sometimes
we
have
these
policies
and
companies.
That
say
we
never
touch
a
switch.
We
keep
it
pristine
and
we
have
the
policies
that
say
that
has
to
be
unmodified,
and
then
you
can't
strip
attack
from
that
when
you
sign
it,
if
it's
an
unsigned
tag,
and
so
you
can
leave
it
there
now
and
just
edit
again
on
the
outside,
so
have
this
tagged
device.
So
all
these
combinations
of
sign
and
taking
and
all
covered
with
new
cdl
that
is
also
mandatory.
C
There
was
a
comment
about
how
does
this
really
work?
Why
is
this
in
the
appendix
and
we're
like?
Okay?
Then
it
is
a
normative
change.
We
move
that
up
into
the
document.
That's
the
end
of
the
body
here
and
basically
add
cdda.
That's
also
normative,
reflecting
the
normative
language
and
tell
people
how
this
is
done
so
for
signing
and
tagging.
C
Then,
after
doing
all
this
and
having
this
one
type
for
the
each
claims
that
lawrence
want
to
use
codes
within
because
lauren
said
yeah,
but
you
don't
need
an
outside
tag.
I
don't
I
don't
want
that.
I
was
like
yeah,
that's
fine,
that
you
don't
want
that
some
people
might
so
the
option
not
having
it
on
the
outside
is
there,
so
it
is,
it
is.
C
Is
it
possible
to
to
include
that
in
a
way
that
lawrence
wants,
but
it
is
also
possible,
in
theory,
to
include
it
now
and
eat
in
a
way
that
lawrence
does
not
prefer,
I
would
say,
having
a
tagged.
Sibo
attacked
coast
with
in
a
semantically
well-defined
claim
is
again
some
redundancy.
If
the
claim
label
tells
you
this
is
a
code
switch.
You
factually
do
not
have
to
tag
the
sibo
item
with
a
sibo
attack.
That
is
saying
this
is
a
go
sweat,
but
I
think
again,
due
to
supply
chain
procedures.
C
There
might
be
instances
where
this
cannot
be
avoided
due
to
having
things
pristine
and
policy
is
telling
you.
You
may
not
touch
this.
I
think
that's
fringe
cases
in
general.
That
should
be
possible,
and
I
hope
I
have
not
have
not
talked
with
lawrence
about
that,
and
I
don't
think
he's
here.
No,
he
isn't
so
so
that
is
a
thing
that
we
have
to
align
on
still,
but
I
am
relatively
confident
that
we
are
like
99.5
to
the
text
that
lawrence
wants,
so
so
that
that's,
I
think,
covered.
B
A
All
right
that
sounds
good.
So
at
this
stage
I
mean
you
said
earlier
that
we
had
a
few
remaining
open
issues.
Milestone-Wise,
do
you
have
a
rough
estimate
of
of
how
long
you
think
it'll
take
to
get
through
those,
or
is
it
kind
of
depend
on
the
issues.
C
Yeah,
it's
a
little
bit.
I
think
my
my
fellow
co-editor,
I
think
getting
us
on
this
in
the
same
meeting-
is
the
biggest
challenge.
Actually,
it's
not
the
content,
so
we,
as
there
was
a
cut
off
this
just
kind
of
was
pressing
and
we
managed
that.
Unfortunately,
now
as
the
cutoff
is
passed
behind
us,
it
is
relatively
hard
to
find
a
coherent
session
at
the
moment
that
is
on
us.
C
That
is
not
the
problem
of
the
issues
and
that's
not
the
problem
of
this
working
group.
That
is
our.
We
are
the
reasons
for
this.
Unfortunately,
having
said
that,
I
still
think
there
are
only
the
logistic
issues
of
registry,
and
maybe
a
few
of
romans
are
still
open,
so
my
guesstimate
would
be
if
we
get
a
meeting
done
or
two
meetings
we
have
we're
done.
This
should
be
done
in
two
or
two
one-hour
meetings.
C
So
so
I
that
that's
my
my
premise
here
for
guesstimate
off
and
off
april
yeah-
and
we
are
that
bad
at
meeting.
A
Okay,
so
you
don't
see
too
much
work
left,
it's
just
a
scheduling
issue,
yeah.
A
Oh
all,
right
great,
so
with
that
during
this
room.
C
Of
april
yeah,
I
think
we
need
six
weeks
to
do
two
hours.
That
is
my
my
new
from
speaking
from
life
experience.
My
new
guestimate
here.
A
Yeah,
that's
fine!
So
I
I
haven't
modified
the
agenda
that
I'm
showing,
but
basically
we're
going
to
go
through
this
agenda
and
then
at
the
end
of
it,
we'll
go
after
the
way
ahead.
The
any
other
business
will
be
working
stepping
through
the
issues.
If
that's
okay
with
you.
A
Okay,
so
next
up
is
the
sakam
architecture.
Document
adam
and
bill
are
both
here.
I
believe
bill
you're
going
to
lead
the
conversation.
Is
that
correct?
A
I?
I
guess
I
could
kick
this
off
with
there's
been
no
update
to
the
document
and
the
last
email
traffic
on
this
was,
but
you
can
stay
speaking
bill.
A
There's
no
update
to
the
document
and
and
kathleen
sent
comments
about
six
weeks
ago,
but
we
haven't,
I
mean
I
haven't
seen
any
response
to
those,
so
I'm
not
sure
if
you
all
have
been
discussing
them
in
the
background.
So
with
that
architecture
update,
please.
B
That's
that's
pretty
much
the
update
I
can
defer
to
adam
as
well
on
on
anything
further
going
on
there,
but,
like
you
said,
the
last
real
activity
was
in
fact
kathleen's
comments
on
that.
So
I
think
it
kind
of
rolls
into
some
of
the
the
way
ahead
and
pieces
of
that
and
you
know
getting
getting
people's
opinion
and
feedback
on
where
they
want
to
go.
F
Hey
good
morning
yeah,
I
think
I
I
think
bill
might
you
might
be
being
a
little
bashful,
but
he
is
also
working
on
an
implementation
of
the
ecosystem.
It's
not
exactly
from
what
I
understand
like
to
the
letter
of
what
the
draft
is
today,
like,
I
think,
in
implementing
bill,
you
may
have
learned
a
few
things
that
might
find
their
way
into
the
draft,
but
really
yeah.
At
this
point
we
have
the
draft
in
its
current
state.
We
have
a
a,
I
guess,
a
nominal
implementation
like
very
basic.
F
We
want
to
see
this
working
type
of
implementation,
not
anything
that's
deployable
or
you
know
product
ready
or
anything
like
that.
But
mostly
I.
What
I'd
like
to
see
is
you
know
additional
feedback.
I
know
we
got
excellent
feedback
from
from
both
roman
and
kathleen
yeah.
I
think
that's,
basically
where
we
are
bill.
If
I
mischaracterize
the
implementation
that
you're
working
on,
I
apologize.
B
Yeah,
I
can
do
that
honestly,
the
that
that's
what
I
was
just
gonna
talk
about
was
the
fact
that
the
what
what
I've
done
is
basically
the
product
of
kind
of
my
own
personal
hackathon
in
the
past
two
and
a
half
days.
So,
but
I
have
a
bit
of
what
I'd
like
to
call
a
few
of
the
components:
working,
yeah
and
and
working
I'll
say
loosely.
B
It's
a
basically
a
management
and
orchestration
component
that
can
basically
interface
with
a
collection
component
to
perform
some
hard-coded
collections
using
s-cap
related
content.
It's
just
some
basic,
some
very,
very,
very
simple,
oval
instructions,
and
that
collection
has
hooked
into
the
tool
that
we
happen
to
have
here
at
cis,
amazingly
enough
and
it.
But
it
can
send
messages
to
ensure
that
different
components
are
awake.
B
If
anybody's
looked
at
the
draft,
there's
a
an
operation
in
there
called
the
heartbeat,
and
so
that's
basically
just
sending
a
ping
message
to
each
of
the
components
it
does
that
I
can
onboard
a
couple
of
the
components
like
the
orchestration
collection
components.
So
those
messages
that
message
exchange
and
a
small
amount
of
capability
information
can
be
exchanged
and
then
basically
publishing
the
collection
instructions
to
to
to
have
that
collector
perform
collection.
I
had
that's
as
far
as
I
got.
E
D
Architecture,
all
right,
so
I'm
gonna
jump
in
for
bill
for
anomaly
up.
So
what
do
you
mean
by
that
roman.
E
Yeah,
so
so
that
this
is
a
little
bit
of
a
guess,
the
lar
I
mean
I'm
thrilled.
We
have
an
implementation
because
it
makes
the
architecture
real.
What
I'm
trying
to
get
my
head
wrapped
around
is
you
know
what
what
is
kind
of
the
architecture
really
codifying
and
are
there
technologies
we're
developing
that
and
that
we
feel
we
need
to
standardize
as
part
of
this
process
so
long
term?
I
mean
what
there
were
a
bunch
of
questions
about.
You
know
we
got
some
reviews
on
the
architecture.
E
G
Yeah,
that's
a
good
question.
It's
really
what
were.
B
I
think
the
the
the
sacchamine
things
that
are
about
it
are
kind
of
dealing
with
the
the
roles
and
and
the
interfaces
and
and
kind
of
the
the
different
message
structures
that
go
that
are
transported
back
and
forth
between
components.
But
I
think
implementation
of
each
of
the
components
is.
However,
folks
would
like
to
do
it.
B
It's
just
a
matter
of
the
the
different
types
of
messages
over
whatever
you
know:
kind
of
operational
interface,
that's
being
defined
in
the
draft
and
that's
kind
of
whatever
the
taxonomy
or
ontology
section
or
whatever.
B
I
think
it's
labeled
taxonomy,
so
that
sort
of
defines
the
different
topics
that
are
communicated
over
the
things
that
are,
you
know
where
things
get
published
or
subscribed
to
or
the
different
sort
of
directed
message,
topics
that
that
are
made
available
as
well,
so
that
that's
really
what
I
guess,
that's
the
most
sacchamine
portion
of
it.
D
E
I
I
guess
I
may
have
a
different
mental
model
than
others,
but
you
know
I
look
at
what
the
sack
and
working
group
has
actually
published
and
or
is
in
flight.
We
have
co-suid,
we
have
a
an
aposter
enterprise
use
case.
We
have
requirements
and
we
have
software
inventory
messaging.
So
when
we
say
we're
doing
sacchamine
things
and
we're
rolling
that
in
I,
I
guess
I
don't
see
where
the
working
group
developed
technology
is
being
inserted
here.
I
can
see
that
we're
talking
about
apis
but
we're
inventing
the
whole
cloth
in
this
document.
E
It
seems-
and
so
I'm
just
trying
to
get
a
sense
of
whether
this
this
architecture
document
is
tipping
or
hinting
that
there
is
new
standards,
work
to
be
done
or
what
we're
trying
to
do
is
develop
a
self
just
a
self-contained
document
and
that's
going
to
be
the
end
of
it,
and
this
is
again
just
tipping
my
hand.
I
mean
I'm
trying
to
understand
what
the
way
ahead
is
and
I'm
trying
to
understand
whether
this
is
an
architecture,
that's
defining
more
work
that
we
need
to
do
or
or
if
it's
not
that
we're.
D
F
I
guess
I'll
just
talk,
yeah,
okay,
so
sorry
I
tried
to
raise
hands
and
all
that
roman.
That's
a
really
good
question,
so
I
mean,
and-
and
this
might
be
a
discussion
for
the
way
ahead
as
well,
so
in
in
my
mind,
right
now,
the
architecture
drafted
as
bill
was
mentioning
chris
bill.
Chris
were
mentioning
it
defines
components,
roles
the
interfaces
and
right
now
like
in
the
in
the
notional
implementation
that
bill's
been
working
on
we're
using
essentially
s-cap
information.
You
know
messages
to
go
back
and
forth.
F
Like
that's,
that's
the
payload.
If
you
will,
between
all
these
different
components,
when
sacrum
first
started,
we
had
the
idea
of.
F
Evolving
those
that
portion
of
I
guess
this
architecture
in
a
sense,
so
we
had
the
idea
of
you
know
bringing
in
a
way
to
model
assets
a
way
to
improve
on
fccdf
possibility
the
way
to
improve
oval.
F
I
think,
back
in
the
day,
oval
was
even
submitted
to
the
working
group
as
a
way
for
mitre
to
kind
of
say
it's.
You
know
to
kind
of
bless
the
effort,
I
guess
so
to
answer
your
question
really,
I
think,
requires
additional
discussion.
We
could
leave
the
architecture
the
way
it
is
and
just
to
find
the
interfaces
and
sorry
hank.
F
I
know
you're,
probably
cringing
at
all
the
different
terms
that
I'm
using
and
then
make
the
message
payloads
that
go
back
and
forth
kind
of
like
more
extensible
in
a
sense,
so
it
could
handle
s-cap.
It
could
handle
other
types
of
messages,
or
we
could
do
that
and
move
beyond
that
and
try
to.
F
I
don't
want
to
say
reinvent,
but
you
know,
create
the
checklist
format
create
a
better
oval.
If
you
will
things
of
that
nature,
like
we
tried
to
do
this
information
model
back
in
the
day
that
was
massive
like
I
don't
think
we
need
that,
but
anyway,
that's
my
thinking
on
it.
So
I
don't
know
if
that
helps
characterize
what
what
it
is
you're
after,
but
maybe
it
does.
E
We
there's
a
decision
point
here
about
whether
there's
working
group
specificity,
but
the
contribution
of
the
of
the
implementation
that
bill
was
talking
about
correct
me.
If
I
have
it
wrong,
is
that
utop
took
the
roles
in
this
document
as
they
were
kind
of
defined
and
found
a
series
of
kind
of
technologies
that
were
that
is
able
to
kind
of
demonstrate
a
manifestation
of
said
architecture.
E
H
B
Thanks,
I
guess
the
last,
if
I,
if
I
may,
like
the
last
point,
that
I'd
like
to
kind
of
share
and
it
kind
of
goes
along
a
little
bit
of
you
know
what
adam
was
kind
of
talking
about
about
more
extensible
message,
payloads
and
and
things
of
that
nature.
B
Like
the
you
know,
some
of
the
stuff
that
I
kind
of
discovered
in
this
while
I
was
kind
of
trying
to
put
something
together,
was
in
the
the
kind
of
capability
discovery
or
capability
advertisement
between
the
different
components
like
a
certain
piece
could
say,
you
know
defines
you
know
like
I
speak
oval
or
I
I
understand
coast
with
and
things
of
that
nature,
and
I
think
that
those
one
of
some
you
know
some
or
many
of
those
things
could
be
defined
in
in
the
draft
as
well.
B
To
kind
of
help
illustrate
the
different
I'll
call
it
languages
that
components
can
speak.
B
E
Yeah
I
mean
what
you're,
what
you're
kind
of
saying
makes
makes
kind
of
total
sense
to
me
kind
of
bill
about
how
they
could
suggest
future
work.
I
guess
I'm
coming
from
the
perspective
of
who
would
do
that
work
and
I'm
not
gonna.
We
can
save
that
for
the
way
ahead,
because
I'm
a
little
skeptical
that
we
have
the
bandwidth
to
pick
that
work
up.
E
D
C
D
B
Bill,
do
you
have
something
for
that?
I'm
sorry.
I
was
doing
some
notes,
so
I
I'm
I'm
repeat
the
question.
I'm
sorry.
I
And
I
am
sorry,
I
just
moved
my
headset,
so
you
might
hear
a
spinny
toy
in
the
background,
so
I
I
think
what
adam
and
bill
are
saying
and-
and
we
I
think
what
adam
and
bill
are
saying,
makes
sense,
and
you
know
just
in
terms
of
how
do
we
do
posture
assessment?
How
do
we
do
the
things
sakham
sets
out
to
do?
I
You
know
backing
it
up
with
the
implementation
is
very
good,
and
then
yesterday
I
had
presented
in
rats
it
might
be
interesting
to,
and
that
would
expand
this,
so
it
may
make
it
take
longer,
but
it
might
be
interesting
to
also
include
the
intersection
of
other
types
of
work
to
ease
posture
assessment
and
just
advance
this,
but
that
would
make
it
bigger
and
take
longer.
So
I
don't
know
if
there's
tolerance
for
that.
D
A
I
apparently
muted
myself,
so
I'm
not
sure
what
anybody
has
heard
that
I
just
said.
But
anyway
that's
beside
the
point,
so
we
have
status
on
coast.
We
have
status
on
saccum,
we
have
and
then
the
next
document
is
on
the
agenda
because
it
is,
it
is
a
document
we
have
been
working
on,
but
there
have
been
no
updates
and
it's
expired,
and
I
wanted
it
on
here
to
sort
of
complete
the
status
review
before
we
moved
away
ahead.
So
does
anybody
want
to
say
anything?
B
This
is
bill
there.
There
hasn't
been
a
lot
of
work
on
that,
probably
since
early
december,
they
we
had
stephen
banghart
and
gabe
alford
from
red
hat,
and
I
had
kind
of
regularly
scheduled
meetings
for
a
little
while
you
know
I'd
say
since
the
the
previous
previous
ietf,
and
that
was
moving
along
nicely.
I
feel
like
and
part
of
it
was
focused
on
the
draft
and
getting
it
ready
and
part
of
it
was
focused
on,
I
think,
red
hat
trying
to
do
an
implementation
of
it.
B
B
K
E
E
You
know:
do
we
really
have
the
energy
to
do
this
work
because
I
ask
in
august
we
did
a
call
for
adoption
and
we,
you
know
we
did
not
have
enough
energy
to
even
adopt
this
document,
so
I'm
a
little
kind
of
confused.
Maybe
I
missed
the
interim,
which
is,
I
know
we
talked
about
at
the
interim.
But
what
are
the
facts
that
have
changed
on
the
ground
in
august?
We
couldn't
even
get
enough
folks
to
to
to
marshall
up
enough
support
to
adopt
this.
So
what's
the
thinking
here.
A
I
think
that
this
is
really
on
on
me,
more
so
than
the
authors
it
was.
It
was
basically,
I
wanted
all
of
the
documents
on
here
that
we
had
any
progress
on
before
I
moved
to
the
review
of
milestones
and
the
way
ahead
discussion,
because
that
tease
up
the
conversation
the
way
I
organized
it,
okay,
perfect.
Thank
you.
A
Okay,
so
now
that
we've
gone
through
the
three
documents
that
we're
currently
making
summer
some
progress
on
or
that
we've
at
least
had
contributions
on
I'm
going
to
go
to
the
way
ahead,
and
I
wanted
to
preface
this
a
little
bit
with.
This
is
all
just
my
opinion
and
chris,
and
I
had
a
a
really
quick
conversation
about
this
so
and
roman
had
sent
an
email
a
little.
While
back
that,
oh
I
didn't.
A
I
didn't
really
think
all
the
way
through
until
I
started
trying
to
write
slides
on
this.
So
our
current
milestones-
this
is
what's
currently
listed
and
I
went
through
all
of
these,
and
this
explains
how
I
constructed
the
agenda,
and
this
is
where
we
are
with
these
milestones.
A
The
ones
that
I
marked
through
are
things
that
so
you
know
to
sort
of
refresh
our
memory.
If
I
guess
it's
now,
maybe
it
must
have
been
like
the
2017
time
frame.
We
did
a
rechartering
and
in
that
rechartering
we're
like
okay.
We
need
to
have
really
concrete
milestones
that
we
can
make
progress
on,
and
these
were
the
milestones
that
we
published
and
clearly
we're
not
updating
the
dates
on
them.
A
A
couple
of
these
items
we
haven't
gotten
any
input
on
at
all,
and
that
is
the
two
that
I
have
marked
out.
The
roley
document
we
have,
as
roman
has
already
indicated.
We
have
no
adopted
working
group
document
on
this,
yet
the
I
I
actually
marked
the
software
descriptor
as
as
I
think
I
marked
that
one
wrong,
because
I
think
that
one
is
was
decided
to
be
set.
A
I've
actually
confused
the
status
of
software
descriptor
and
configuration
checklist.
This
is
what
happens
when
you
do
slides
late
at
night
architecture,
as
we've
already
discussed,
was
last
updated
in
september
and
coastwood
was,
has
been
submitted
to
the
isg,
and
it
is
slowly
making
progress
and
we've
talked
about
that.
So
our
milestones,
look
pretty
bleak.
In
addition
to
that,
our
mailing
list
is,
is
pretty
much.
A
There's
been
no
activity
since
the
last
meeting,
except
a
whole
bunch
of
github
activity
on
the
coastwood
document
and
kathleen's
review
of
architecture.
So
basically,
what
are
we
doing
here?
So
this
is
my
list
of
next
steps
that
we
could
take.
A
And
again,
this
is
my
opinion,
as
teased
out
of
conversations
with
chris
and
roman,
but
doesn't
was
not
reviewed
with
them.
So
I
get
all
the
blame
proposal.
A
drop,
all
the
milestones
which
aren't
co
sweater
architecture,
see
if
we
can
get
some
realistic
milestones
on
the
table
for
the
architecture
and
then
add
a
milestone
about
closing
or
rechartering
by
the
end
of
this
year.
A
I
do
believe,
like
I
didn't,
look
up
the
exact
date,
but
it
seems
to
me
like
six
months
or
a
year
ago
we
were
like
we're
going
to
keep
the
working
group
around
for
another
six
months
to
see
if
we
can
get
to
the
end
of
our
work
or
get
some
energy
and
we're
basically
rehabbing
that
conversation
proposal
b.
So
basically
it's
a
proposal.
A
was
a
recharger
proposal
b
was
to
to
finish
coast,
wood
and
pause.
A
Where
we
are
with
that
so
comments
questions,
what
do
people
think
we
need
to
be
doing.
F
F
L
L
I'm
kind
of
leaning
a
little
bit
towards
proposal
a.
I
think
it
would
be
interesting
to
me
to
see
the
architecture
mature
more.
I
think,
with
the
attestation
proposal
and
rats
and
with
some
related
work
we
have
going
on
in
oca
in
terms
of
the
saccum
or
the
s-cap
architecture.
L
F
I
mean,
I
think,
the
thing
that
concerns
me
and
I
think
the
thing
that's
concerned
me
for
a
little
while
is
is
the
participation
right.
So
I
mean.
F
You
know:
we've
been
working
on
the
architecture
for
a
while
granted,
it
hasn't
been
consistent
right.
It's
like
a
sine
wave
right
like
we
get
involved
with
it
and
then
other
things
overtake
with
priority,
and
then
we
can
come
back
to
it
and
so
on.
F
I
I
guess
I
have
no
problem
with
proposal
a
I
would
just
you
know,
we'll
keep
putting
out
calls
for
participation.
I
guess
right
like
so
when
we
see
reviews
or
like
when
roman
posted
his
review
and
kathleen
posted
hers
yeah.
I
think
it
would
just
be
nice
to
have
additional
participation
in
these
things.
D
So
I
have
a
question
in
adam
before
you
kind
of
yeah
before
you
walk
away,
which
is,
do
you
believe
it's
do?
You
have
any
feeling?
I
don't
know
if
it's
a
belief
or
as
an
evidence
by
anything,
do
you
have
any
opinion
on?
Is
it
easier
to
participate
against
a
you
know,
kind
of
a
a
demo
piece
of
code
versus
I
mean
I've,
read
the
architecture
draft,
I'm
not
sure
really
what
the
meaningful
feedback
can
be.
D
F
Yeah
I
mean
it's
a
what
I
I
think
I
would
ideally
like
to
see
is
two
implementations
of
what
we
have
written
or
close
to
what
we
have
written
so
that
they
inform
what
we
have
written
right,
and
I
think
we've
said
that
for
a
little
while
at
this
point
like
that,
the
draft
is
where
it
is,
but
we
can't.
F
F
And
that
to
me
means
that
we
should
have
at
least
one
preferably
at
least
two
implementations
that
could
potentially
work
together
right,
like
so.
D
D
D
I'd
love
to
hear
some
feedback
on
that,
because,
presumably,
if
we
did
some
kind
of
alternate
implementation
that
might
be
able
to
work
with
the
cis
implementation,
sorry
bill.
If
that's
not
how
I
should
phrase
it,
maybe
it's
the
bill
implementation,
then
you
know.
Does
anybody
have
objections
against
opendxl.
F
Just
a
quick
comment
before
anyone
objects
or
not-
and
I
think
bill
you
might
have
to
keep
me
honest,
but
I
think
the
use
of
opendxl
is
something
that
we
can
rely
on
for
implementations.
It's
not
something
we
would
require
for
the
architecture.
I
would
prefer
to
see
the
architecture
draft.
C
Yeah,
so
I
really
want
to
have
a
and
then
people
have
to
do
bandwidth
to
do
that
as
just
I
hate
it,
and
I
I'm
not
doing
a
at
the
moment
as
apparent
it's
very
apparent,
so
so
I'm
I'm,
I
can
only
commit
to
be,
and
I
would
really
like
to
see
a
happening
without
being
a
part
of
the
solution
right
now.
So
so
that's
why
I
was
hesitant
to
to
speak
up
so
because,
what's
that
kind
of
an
opinion,
you
know
not
helping
the
only
wish
list,
no
contribution.
C
Adding
to
this
bill
was
talking
about,
and
that's
a
side
conversation
here
with
chat
about
that
also
about
mqtt
as
the
the
broker
solution
here
used,
so
so
personally,
having
worked
with
xmbp,
mqtt
amqp
and
everything
what
we
internally
used
when
building
broker
or
inter
broker
systems
for
for
years
now,
even
with
itf
hackathons
at
I
don't
know,
90
something
itfs,
we
used
kafka
because
kafka
was
basically
the
broker
tool
to
buy
to
rule
them
all.
C
It
was
so
easy
to
implement
that
we
could
combine
yang
push
with
xmpp
and
because
the
interfaces
were,
I
don't
know
a
little
bit
clunky.
Sometimes
we
just
use
kafka
as
a
broker
in
between
it
was
easier
to
write
anything
else,
so
so
that
is
what
we
were
stuck
with
so
so,
when
I
think
about
implementing
second,
for
example,
at
some
point,
I
think
that
the
broker
should
be
exchangeable
and
that's
what
we
need.
An
architecture
for
the
architecture
tells
you
what
solution
will
fit
here.
C
Mqtt
is
the
proof
of
comp
concept
and
if
mqtt
can
do
the
trick,
kafka
can
also
do
it,
and
so
so
that
is
something
I
would
voice
interest
in
and
but
but
I
guess
that
in
the
current
itf
iteration
that
I
would
have
not
even
close
to
any
bandwidth
left
for
that.
C
But
but
I
think
that
the
the
the
idea
of
an
architecture
is
exactly
about
that
and
bill's
code
is
facilitating
a
proof
of
concept
for
exactly
that,
and
that
is
nice
to
see,
because
I
then
will,
I
think,
have
another
cool
tool
to
work
with
and
if
the
second
architecture
fits
that
it
would
be
very,
very.
M
A
E
A
A
It's
expired.
We
did
a
rolly
configuration
checklist,
which
was
an
individual
which
is
still
an
individual
submission
and
it
has
expired.
A
So
that's
why
I
have
not
put
rolly
on
these
either
of
the
really
documents
on
this
list
and
I
think
possibly
the
primary
proponents
of
the
documents
are
not
in
the
meeting
this
morning
so
anyway.
So
now
you
go
ahead.
A
E
Thanks
so
I
guess
my
personal
observation
is
that
I
see
a
lot
of
aspiration
to
potentially
do
more,
but
not
a
lot
of
energy
or
plan
how
to
get
there.
So
we
for
a
long
time
have
been
limping
along
for
a
very
wide
scope
in
the
charter,
but
the
work
that
we're
doing
is
not
commensurate
with
the
wide
scope
we
have,
so
I,
I
think,
really
to
get
us
to
closure.
E
We
can
kind
of
do
that,
but
what
works
with
proposal
a
is
that
we
have
a
switch
that
says
if
we
don't
have
energy,
which,
frankly,
you
know
the
last
kind
of
two
years
on
the
mailing
list
have
demonstrated.
You
know
we
have
a
graceful
exit
where
we
can
declare
success
on
on
the
focused
things
that
we
have.
What
I
would
like
to
hear.
I
didn't
hear
anyone
pushing
for
it
for
proposal
b.
Actually,
I
heard
everyone
push
for
proposal
a
so
this
may
be
kind
of
a
non-sequitur.
E
Frankly,
and
what
appealed
to
me
for
proposal
a
is:
we
have
an
approach
to
light
that
up
and
then
selfishly
for
me
about
why
even
keep
the
working
group
open
as
long
as
january
2022
is
that
I
envision
that
there's
going
to
be
some
iesg
time
to
iterate,
revised
comments
on
the
architecture
and
the
coast
with,
and
that's
that's
sometimes
a
little
bit
of
an
unpredictable
timeline
and
having
a
working
group
to
help
resolve.
Those
comments
is
actually
a
lot
easier
than
one.
That's
disbanded
right,
okay,
but
I.
A
A
The
other
observation
I
would
make
on
your
comment
about
narrowing
the
scope
is,
I
feel,
like
the
last
time
we
recharted
we
had
that
exact
same
conversation
where
we
were
like
we're
going
to
narrow
our
scope,
and
I
guess,
from
your
perspective,
the
scope
is
still
much
broader
than
what
we're
actually
accomplishing
and
we've
been
down
this
road
once
already
where
we
tried
to
narrow
it
and
get
concise
things
so
completely
agree.
A
And
I
see
a
plus
one
from
ira
in
the
chat
for
proposal
a,
I
think
we
I
mean
we
will
do
a
really
quick
confirm
this
on
the
mailing
list,
but
I
I
the
consensus
of
this
meeting,
definitely
appears
to
be
proposal.
A.
E
So
fine
question
karen:
if
we're
really
heading
down
the
path
of
proposal,
a
which
is
what
it
looks
like
you
know,
there's
I
think
two
potential
there's
one
negotiation
thing
that
if
we
can
try
to
get
feedback
on
as
well,
which
is
the
dates
of
december
2020
and
january
2022
were
added.
F
I
I
can
offer
a
comment
on
that:
it's
kind
of
off
the
cuff,
but
relative
to
what
I
was
saying
earlier
about
preferring
to
have
one,
preferably
two
implementations
rolling
on
it
and
this
assuming
that
those
implementations
will
help
inform
the
shape
of
the
draft,
I
would
say
we
could
leave
it
as
is
right
now.
F
A
A
A
The
I
I
guess
we
we
have
no
idea
what
the
future
of
ietf
meetings
is,
but
I
I
think
in
particular
some
some
working
groups
work
really
well
without
face-to-face
meetings
and
for
better
for
worse.
This
appears
to
be
a
working
group
that
does
derive
some
energy
and
motivation
from
a
regular
face-to-face
meeting
and-
and
I
think,
we're
making
progress
in
hackathons
and
I
think
it's
proving
to
be
a
lot
more
difficult
for
us
in
this
world.
A
So
all
right
so
proposal
a
is
our
choice
of
the
meeting
and
we
will
reconfirm
it
on
the
mailing
list
and
that
takes
us
back
to
any
other
business.
The
only
other
any
other
business
I
had
was,
I
don't
think,
and
and
chris
you
can,
you
can
speak
up
here
as
well.
Oh
I
see
we
don't
have
plans
for
a
virtual.
A
A
D
For
us
to
actually
I
know
that
if
we
schedule,
if
we
schedule
roman,
you
can
tell
me
I'm
wrong.
If
we
schedule
kind
of
semi-regular
design
type
meetings,
then
those
have
to
be
announced
in
minutes
and
the
rest
right.
Just
like
a
virtual
interim.
D
Right
and
so
karen
I
would,
I
would
ask,
and
I
would
ask
the
group,
would
we
rather
do
you
know,
have
a
supported
bi-weekly?
Maybe
you
know
more
than
that?
Less
than
that,
I
don't
know,
or
would
we
rather
schedule
an
intro.
E
E
I
can't
prognosticate-
and
this
is
not
an
official
statement
kind
of
for
anyone,
but
I
don't
know
whether
we're
gonna
really
meet
in
person
in
the
summer
time
so
best
case
we're
maybe
talking
about
one
in-person
meeting,
and
if
we
really
just
have
two
more
meetings
to
close
this,
I
I
really
think
we
need
more
intermediate
milestones
to
to
make
sure
we
make
progress.
A
Yeah,
I
might
have
my
my
commentary
on
face-to-face
meetings,
was
more
about
what
it
was
was
less
about
setting
our
milestones.
I
I
think
the
miles
there's
four
months
between
now
and
the
next
meeting
are
almost
five
months.
A
I
don't
think
we
can
sit
around
and
wait
if
we
really
think
we're
going
to
meet
the
end
of
the
year
deadline.
I
think
we
need
to
see
some
progress
between
now
and
then.
The
question
is
whether
that
progress
needs
to
be
driven
by
the
chairs,
scheduling,
virtual
interim
meetings
or
whether
it
needs
to
be
driven
by
the
primary
editors
of
the
architecture,
document,
scheduling,
architecture,
editing
meetings.
A
So
I
I
I
mean
perhaps
chris
and
I
could
have
done
a
better
job
of
scheduling,
virtual
interims,
although
between
the
last
meeting
and
this
one
was
kind
of
tough,
I
think,
but
do
you
all
want
a
virtual
interim
or
adam?
I
mean
you
and
bill.
What
do
you
think?
F
Yeah
so
kind
of
having
an
open
conversation
with
bill
in
front
of
everybody,
but
to
me
I
think
that
the
more
frequently
we
meet
the
better,
but
that
said,
bill's
the
one
who
really
does
most
of
the
implementation
stuff
like
all
of
it
actually,
and
so
it's
really
going
to
depend
on
his
availability.
F
That
sort
of
thing,
but
I
mean
to
me
the
more
frequent
meetings
things
just
get
done
right.
You
can
chunk
things
up
into
smaller
bites,
it's
easier
to
take
those
smaller
bites,
it's
more
regular,
it's
more
front
of
mind!
All
of
that,
so
my
preference
would
be
to
meet
more
frequently
than
scheduling
virtual
interims.
F
Bill
feel
free
to
throw
me
under
a
bus,
or
you
know,
push
me
off
a
cliff,
whatever
makes
sense.
B
I
I
would
agree-
and
you
know
I
can-
I
can
take
an
action
item
I'll-
have
to
go.
You
know
back
to
my
boss,
who's
kind
of
a
hard
case
about
scheduling
but
yeah
we'll
take
that,
as
as
an
action
to
find
find
times
where
we
can
get
some
editing
meetings
scheduled.
A
A
And
chris,
I
don't
know
if
you
want
to
speak
up
on
this,
do
you
have
a
do?
You
want
to
plan,
for
you
know
penciling
in
a
virtual
interim
halfway
between
or
do
we
want.
D
D
C
I
absolutely
would
like
to
spend
some
regular
interval
time
on
getting
up
to
things
and
discussing
why
things
are
there
how
they
are
in
implementation?
I
have
to
admit.
I
have
no
idea
how
the
implementation
looks
like
I'm,
not
even
sure
what
to
look
at
it,
and
so
so
yeah
like
like
starting
these
meetings
for
a
catching
up
is
also
a
there's,
a
blocker
on
my
schedule.
You
know
I
I
call
in
there
is
time
reserved
for
that,
it's
easier
than
to
say
I
will
do
it
at
some
point.
L
Same
for
me,
I'm
not
really
good
this
pandemic
about
like
actually
following
up
on,
but
if
you
put
it
on
my
calendar,
I
might
I
guess
I
would
like
to
see
us
use
a
little
bit
of
time
to
talk
about
deconflicting,
a
bunch
of
efforts
as
well.
L
I
think
kathleen's
out
of
station
document
has
a
role
here.
I
know
there's
related
work
in
oca,
that's
very
similar
to
what
adam
and
bill
are
trying
to
do
here.
I'd
like
for
us
to
take
some
time
to
like
really
sit
down
and
figure
out.
What
are
we
doing
and
where
are
we
doing
it
with
the
knowledge
that
you
know
I
know
adam
and
bill
are
like
throwing
this
boat
alone,
so
I
think
we
need
to
do
some
resource
allocation
as
well
to
the
extent
possible.
J
A
Okay,
so
coming
out
of
this
adam
and
bill
are
going
to
schedule,
design,
team
meetings,
design,
team,
slash
editing
meetings
and
chris,
and
I
will
schedule
a
virtual
interim
in
roughly
two
months.
The
agenda
of
the
virtual
interim
will
be
a
touch
point
on
where
the
the
architecture
document
is,
and
it
will
be
deconfliction.
A
All
right
any
other,
any
other
business.
Besides
hank's
desire
to
go
through
the
issues
of
the
coast.
A
A
A
So
that
is
the
approach
we
will
take
at
this
point,
I'm
going
to
close
the
main
meeting
and
hand
it
over
to
well.
Let
me
I
I
mean
we
didn't
actually
ask
roman
if,
if
he
wanted
to
sit,
if
he
wanted
to
work
on
issues
now
or
if
he
wanted
to
do
it
later,
so
perhaps
we
should
do
that.
E
K
Something,
let
me
let
hank
share
his
screen
just
share,
if
possible,.
A
B
Discussion
or
if,
if
we're
good
on
notes,.
A
I
hank
do
you,
I
wasn't
making
this.
K
Part
of
the
minute,
so
do
you
want
this
minute
or
do
you
actually,
I'm
not
sure?
Yes,
it
seems
like
a
good.
C
C
To
some
extent,
two
windows
should
be
visible:
yes,
cool.
A
A
C
So
to
speak,
of
course
you
are
so
thanks,
roman
for
the
time,
I
will
not
be
able
to
speak
with
confidence
to
everything
because
summer
this-
and
this
is
yeah-
the
commit
from
dave
waltermeier
to
the
text.
So
we
can
dig
up
some
of
the
items,
but
I'm
familiar
with
most
like
with
eighty
to
ninety
percent
of
the
items,
so
we're.
C
A
Dave
yeah,
I'm
not
going
dave,
but
we've
ended.
A
And
now
we've
transitioned
to
editing
coast
with
and
we
didn't
notice
when
you
joined
so
can
you
speak?
Are
you.
K
C
Start
with,
in
any
case
so
running
through
the
items,
as
I
see
them
here
right
now,
you
annotated
them
with
when,
since
when
does
this
apply,
or
when
did
you
check
this,
I
think
it's
the
first
one.
E
Yeah
the
nomenclature
of
the
draft
version,
so
I
think
we've
seen
15
16
and
17
15
was
the
original
review.
So,
where
possible,
I
tried
to
annotate
it
in
such
a
way
where
it
was
clear
that
the
comment
was
first
made
in
that
document.
In
some
cases,
text
changes
have
occurred
or
discussion
has
occurred.
So
so
I
annotated
it
below
sometimes
talking
about
multiple
version
numbers,
as
you
might
see
in
the
next
entry
around
section
2.9.4,
where
there's
commentary
on
the
16
and.
H
The
17
as
well
now
I
get
it
so.
The
stars
indicate
the
item.
C
And
you
have
two
multiplica,
I
see
now.
Okay,
now
I
get
it
that
was
a
little
bit.
This
is
even
less
than
I
thought,
because
the
stars
indicated
yeah.
As
you
know.
Thank
you.
First
item
is
since
15,
so
so
the
the
the
initial,
the
initial
response
of
the
editors
was
we
don't
get
the
question.
So
let
me
try
to
reflect
what
we
understand
or
what
I
now
understand
here.
E
Yeah
I
mean
what
I
meant
there
was.
There
is
no
version
field
being
jammed
into
the
coast
wind.
I
was
checking
whether
that's
an
explicit
design,
that's
an
explicit
design,
and
it's
really
as
simple
as
do.
We
need
a
tag
in
in
the
coast,
width
that
says
this
is
version
1.0
or
whatever.
We
want
to
call
it.
E
C
J
C
Yeah,
okay,
so
so
yeah,
so
that
makes
it
that
this
is
what
we
thought,
and
so
no
there
is
no
versioning
of
the
cdda
specifications,
and
that
is
intentional,
because
versions
are
things
that
always
are
difficult
to
align
in
when
you
think
about
the
iot.
C
So
so
the
idea
is
here
to
have
a
very
stable
core
specification
that
you
can
extend
this
specifications
again
and
these
specifications
you
can
pull
in
or
not
every
parser
or
encoding
mechanism
or
decoding
mechanism
should
be
careful
with
things
that
that
are
extensible
and
check
what
it
knows,
and
and
and
just
not
assume,
that
there
are
items
in
a
in
a
map
that
you
are
familiar
with,
or
even
complete,
sub-maps
that
you
are
familiar
with.
C
So
that's
more
like
a
scalable
approach
to
versioning
versioning
should
be
solved
outside
of
cddi
in
general.
There
is
sometimes
a
thing:
some
city
specifications
use
something
like
a
qualified
name
for
their
structures.
For
example,
if
you
define
a
protocol
like
update
or
delete
like
crud
messages
with
ctga
you
can
you
can
give
that
operation
a
qualified
name?
That
also
tells
you
I
am.
C
I
am
the
first
of
my
kind,
and
another
operation
would
be
at
the
same
operation
name
but
tells
you,
but
I
am
the
second
version
of
my
kind
that
that
it
is
possible
to
do
this
with
qualified
names
again
that
would
be
per
nested
structure
in
the
ctl,
for
example,
operations
or
payload
types
or
unions,
or
something
we
are
not
doing
this
here
with
co-switch,
because
we
have
a
very,
very
flexible,
extensive
extensibility
mechanism
that
should
allow
for
for
emitting
versions.
C
E
Is
just
trying
to
trying
to
come
up
with
an
alternative
data
model
to
what
we
already
do
in
xml
in
the
suit
format,
and
the
suite
format
in
its
xml
manifestation
doesn't
have
an
explicit
version
number
and
that
it's
probably,
I
guess,
handled
by
some
namespace
versioning,
and
we
are
handling
that
namespace
versioning.
That
swit
does
in
cdl
by
you're
just
going
to
recognize
it
by
the
fields
that
are
in
there.
C
The
swift
has
a
identifier
for
different
version,
which
is
the
year.
That's
because
it's
an
iso
standard,
so
I
think
current
is
2015..
Some
would
say
this
is
a
version.
So
how.
C
E
So
how
will
we
know,
because
I
was
under
the
impression
from
how
dave
answered
some
of
the
earlier
questions
that
iso
is
going
to
update
their
their
version,
so
we're
going
to
have
a
2015
one
and
our
suite
our
coast
with
thing
will
only
ever
align
to
2015
or
are
we
gonna?
How
do
we
future
proof
it
that,
when
we
do
an
update
to
this,
because
I
assume
there
will
be
interest
to
do
that,
how
will
we
recognize
the
2022
update
versus
the
2015
update?
E
Is
it
really
just
gonna
be
well,
it's
just
there'll
be
new
fields,
and
that's
how
I'm
gonna
see
it.
You
know,
based
on
the
normal
cddl
way,.
C
Exactly
so,
if
the
assumption
is
that
it
is
very
unlikely
that
the
structure
presented
in
the
cta
today
will
change
and
it
is
not
intended
to
change.
Actually,
there
might
be
a
critical
error
to
all
of
this,
and
then
we
have
to
go
to
abyss
and
actually
change
it.
But
I
don't
think
that
will
happen.
C
Actually
to
be
honest,
but
you
never
know
the
extensibility
mechanism
provided
here
will
allow
for
a
another
rfc
or
another
id
that
basically
extends
the
current
ctda
to
the
version
that
might
be
upcoming
with
iso.
But
knowing
that
authors
of
the
isospec
are
authors
of
the
with
spec,
the
ice
respect
will
basically
align
more
to
the
kosovo
spec,
and
that
will.
C
L
E
C
You
your
parts,
so
so
I
think
from
a
software
point
of
view,
you
are
a
parser,
of
course
widths
and
you
are
using
the
initial
version
and
you
encounter
a
item.
It
is
allowed.
You
are
excited
yeah,
that
is
a
summer
creeping
in
via
extension
points.
You
don't
know
the
any
field
could
also
so
so
you
you
can
encounter
a
new
thing
that
you
don't
know,
and
you
don't
have
an
extension
for
that
this
all
will
be
captured
by
the
any
attribute.
C
So
you
can
parse
it
today
due
to
the
structure
of
the
cdda,
but
you
don't
know,
that's
a
future
version.
It's
just
an
unknown
attribute
to
you.
If
you,
if
you
are
now
the
code
that
is
updated,
you
now
know
that
it's
a
future
version,
but
you
again
arbitrary
items
go
to
the
any
attribute.
So
this
this
this
layering
mechanism
so
to
speak,
allows
you
to
not
use
versions
anymore.
It
allows
you
to
just
be
aware
of
the
current
state
or
not
and
parse
any
attribute
any
it's
cause
you
get
in
any
case.
C
By
the
introduction
that
says
this
is
a
based
on
200
2015.,
you
could
added
attributes
and
say
we
never,
but,
but
I
think
we
already
say
this.
This
specification
does
not
make
any
assumptions
how
the
switch
iso
standard
will
evolve
and,
however,
the
voice
we
can
parse
it
due
to
the
nature
of
our
structure,
and
we
already
say
that.
C
Okay:
okay,
if
that's
feasible
to
you,
I
think
it's
very
feasible
to
things
that
are
a
difficult
to
version
update.
So
we
don't
expect
kosovo
to
have
millions
of
branches
and
versions
so,
but
but
we
adhere
to
the
idea
or
the
the
benefits
ctda
provides
and-
and
that's
basically
the
point
why
we
don't
have
a
version
if
you
would
really
be
at
a
month
on
adding
a
version.
That's
that's
a
no-brainer,
but
it
is,
I
think,
actually
a
blocker
long
long
term.
E
Yeah,
I
mean
listen.
If
that's
the
design
you
want,
I
my
caution
is,
I
think,
that's
going
to
break
the
future
version,
but
if,
if
really,
what
we
want
to
do
is
have
this
very
strict
thing
like
we
have,
in
our
one
hand,
the
2015
thing
and
we're
doing
it
based
on
the
2015
thing
and
we're
comfortable
with
the
drift.
I
I
I
think
that's
fine,
because
then
we'll
have
the
ietf
coast
with
and
then
we
have
the
squid,
that's
kind
of
something
else.
E
C
N
E
That
so,
if
I
packed
a
2015
and
made
a
co
suite
on
the
wire
and
it
had
field
a-
and
I
have
no
versioning
information,
then
at
some
point
you
know
the
meaning
of
a
change
to
be
a
a
prime.
When
I'm
on
the
wire
as
an
implementer-
and
I
read
the
switch
the
coast
with
because
I
don't
have
a
version
number,
I
don't
know
how
I
because
I
don't
know
whether
it's
2015
or
the
new
one
that
has
the
a
prime
definition.
C
But
you
do
because
you're
doing
a
conversion,
and
the
converter
of
course
knows
what
version
the
new
suite
is
and
if
the
converter
does
not
know
what
it's
converting
into
the
old
switch
and
doesn't
throw
an
error,
that's
implementation
problem,
and
so
of
course
you
can't
translate
a
new
switch
attributes
from
a
future
version
that
are
not
covered
here.
Of
course,
it's
that's
apparent.
You
can
put
them
into
the
any
field
and
just
pass
them
through.
C
Yes,
but
also
the
converter
would
know,
because
you
implemented
that,
and
it
knows
that
it
passes
a
new
thing
now
and
if
you're
not
implementing
that
correctly.
That
is
not
a
problem
of
the
specification
actually
because
a
specification
says
this
is
equivalent
to
2015.
an
implementer.
How
probably
read
that
when
implementing
the
spec
so
so
again,
I
think,
assuming
that
everything
is
updated
correctly,
with
versions
in
in
a
lot
of
things
is
unlikely.
C
It
is,
it
is,
I
think,
more
graceful
to
to
have
a
ctda
that
allows
for
for
the
any
attributer
which
we
inherited
from
the
from
the
swift
rhyme
natively.
Actually
so
so
I
think
still
that
this
is
a
fine
way
to
move
forward.
E
Wait
so
what's
the
converter
we're
talking
about
I'm
confused,
because
I
thought
that
what
was
going
to
happen
is
some
software
producer
was
going
to
drop
something
in
the
file
system
for
me
and
it's
going
to
be
a
coast
with
blob
and
then
I
not
knowing
how
the
coast
wood,
blob
got
red
have
find
this
blob
on
my
file
system
and
then
I'm
going
to
take
my
my
implementation
and
I'm
going
to
try
to
parse
that
blob.
I
have
a
2015
implementation,
which
has
the
definition
of
a.
C
E
C
You
will
have
the
new
thing
when
you
create
a
new
thing
and
this
is
created
via
software.
So
again
it's
this
converter
thing.
So
when
you
have
this
notion
of
a
version
of
switch
and
the
version
of
code
switch,
then
you
need
something
that
makes
this
connection
a
software
implementation
that
makes
this
connection,
and
that
is
the
software.
What
I
was
talking
about,
if
you're
just
creating
cosmetic
and
do
not
care
about
switch,
you
don't
have
this
problem.
You
only
have
the
problem
when
you
have
a
new
swift
version.
C
As
you
are
postulating,
and
then
you
are
creating
with
this
new
swift
version,
something
that,
as
a
new
sorry,
a
mismatching
cement
tech
with
an
existing
coast
with,
and
that
is
uncatched.
But
that
cannot
happen
if
you
adhere
to
the
specification
because
you're
not
creating
co-switch
anymore
and
and
therefore
you-
because
you
know
you
know
creating
close
with
a
prime-
that
that
fear
would
look
like
the
same
thing
as
the
switch
a
prime
you're
postulating,
but
there's
no
specification
covering
close
with
a
prime.
C
E
E
Okay,
no
so
well
right,
but
so
then
I
don't
understand
this
implementation
thing,
because
I
feel
the
piece
of
software
that
and
with
that
software
I
got
the
coast
with.
I
don't
I
mean
so
this
is
now
you
know
on
my
network
and
I
have
my
old
implementation
that
the
2015
implementation-
I
have
no
knowledge,
whether
switz
or
coast,
winds
got
updated.
E
All
I
know
is
I
have
a
file
on
my
file
system
and
I'm
trying
to
consume
it
and
when
I
consume
it,
the
only
understanding
of
field
a
that
I
have
is
the
one
hard-coded
in
my
implementation
but
unbeknownst
to
me.
The
code
switch,
the
codes
would
work
evolved
and
a
is
no
longer
a
it's
a
prime,
so
so
it's
kind
of
the.
E
So
how
would
I
recognize
that
if
I
don't
have
a
version
number?
Is
it
that
if
that
actually
occurred,
what
should
have
happened
by
the
producer
of
the
software?
They
should
have
recognized
that
issue
kind
of
from
sweden.
They
would
have
created
a
different
tag
and
that
tag
would
have
been
different.
My
2015
implementation
wouldn't
have
recognized
it,
and
then
it
fails
is
that
the
fail-safe.
C
C
So
if
you
are
putting
out
a
software
onto
a
device
that
is
actually
consuming
coswets
and
and
therefore
has
to
interpret
them
and
then
the
if
the
software
that
you
you
put
out,
there
is
abandoned,
for
example,
the
company
goes
away
and
it's
not
maintained
anymore,
but
still
working
so
and
now
you
have
basically
out
of
life
software
running,
and
then
you
encounter
a
code
suite
that
is
newer,
but
the
software
is
not
updated
and
can
never
be
versioned
anymore,
because
it's
abandoned,
then
you
will
have
a
problem,
but
I
think
when
you
arrive
at
that
point,
you
already
had
so
many
problems
beforehand,
that
you
did
not
solve
with
respect
to
software
management
and
versioning,
that
that
that's
not
the
fault
of
the
cddi
and
the
coast,
where
that
is
adhering
to
a
based,
co
switch,
which
again
is
unlikely
to
happen,
because
that
is
the
only
problem
here.
C
If
the
semantics
change.
That
is
the
only
problem.
If
you
add
more
semantics,
that
is
not
a
problem
with
the
original
course
right
here.
So
so,
if
you,
if
you
encounter
a
that
scenario
where
you
have
an
abandoned
piece
of
software,
not
maintained
they're
running,
not
aware
and
not
versioned,
due
to
the
versioning
of
the
missing
versioning
of
the
new
business
coast
with
irc,
then
you
have
a
problem
that
is
correct.
C
There's
no
failure!
Detection
for
that,
if
the
semantic
of
tag
it
changed
somehow
and
and
when
we
made
that
happen,
we
are
abyss.
This
software
will
never
be
able
to
understand
that
change.
That
is
correct.
E
Yeah,
so
I
think
I
think
I've
reached
the
same
conclusion
that
we
don't
need
a
change,
but
for
a
different
reason,
because
I
think
that
if
the
existing
swit
implementation
changes
to
do
this
a
versus
a
prime
thing,
what
should
the
right
thing
that
should
happen
from
the
co
switch
side
is
that
we
would
use
a
different
tag
for
that
field
and
then
that
would
break
the
the
the
implementation,
the
older
implementation.
C
Okay,
exactly
exactly
that
is
fine.
The
next
version
of
cta
would
would
make
sure
that
the
previous
vision
will
fail,
that
that
is.
That
is
a
very
good
way
to
do
this
exactly
because
we
fail
hard
and
then
the
the
abandoned
software
that
you
should
not
use
in
any
case
anymore,
because
of
life
will
now
fail
hard
when
consuming.
E
Into
that
effect
that
we
would
expect
future
coast
with
versions
that
are
tracking
you
know,
tracking
kind
of
swin
would
create
kind
of
new
tags.
If
said
semantics
occurred,
you
know
we
explicitly
aren't
putting
version
numbers,
because
that's
not
the
cddl
way.
C
Yeah,
I
think
I
think
what
what
you
could
say
is
if,
if
the
semantics
of
the
already
defined
codes
would
change,
this
has
to
be
expressed,
or
this
could
be
expressed
via
maybe
not
mandatory,
but
and
to
prescriptively
bad.
This
could
be
expressed
via
a
new
tag,
and
that
is
fine.
C
D
C
Okay,
yeah,
there
is
no
date
field
in
in
cttl.
We
are
using
the
time
field
as
we
are
not
typing
x
as
date
in
switch,
we
are
having
sx.
I
think
it's
date,
time.
E
C
Oh,
that
is
a
different
issue,
so
yeah.
G
C
Has
nothing
to
do
with
time
date
is
like
calendar,
stuff
and
and
and
such
so
and
and
time
is,
is
about
time
stamps
and
such
so
there
are
different
types
and
you
were
talking
about
access
date
in
the
first
place.
So
I
was
maybe
maybe
taking
this
too
literally.
Maybe
you
meant,
what's
it
called
an
xml
access
date
time?
I
think
right.
Yeah.
C
Yeah
it
it
x
daytime
is
the
only
time
relevant
value
used
in
a
type
sorry
for
value
used
in
the
xsd,
and
we
decided
to
go
with
the
binary
one,
which
is
tag
one
time,
tag
right
and
and
but
but
there's
one
thing
that
we
I
actually
elaborated
on
in
the
text.
C
There's
a
small
discrepancy
between
zero
and
one
zero
is
the
standard
iso
time
and
a
string
and-
and
that
can
express
leap
seconds
because
you
can
say
it's
60
seconds,
you
know,
but
you
can't
express
that
with
posix,
and
you
just
may
have
to
make
very
sure
that
you
do
not
issue
a
signed,
a
payload
codes
with
on
a
leap.
Second,
that
would
be
bad
because
you
don't
know
which
second,
that
is.
This
is
the
bond
before
one
after
you
don't
never
know,
there's
no,
no
standard.
C
But
for
the
sake
of
brevity
and
not
using
strings,
oh
my
god,
we
are
using
time
tag
one
and
it's
it's
it's
more
than
good
enough!
You
you
just
can't
express
leap
seconds.
E
E
C
C
E
C
E
Right
so
yeah,
if,
if
that's
time,
if
integer
time
is
tag,
one,
then
we're
good
yeah.
C
C
There
are
now,
I
think,
a
lot
of
this
isn't
dave's
stuff
here.
I
think.
E
C
Here
you
can
see
it,
there's
explicit
text
about
process
name,
for
example
edit
here
at
the
end,
this
is
maps2
and
we
even
have
an
x-path
expression
that
tells
exactly
what
it
maps
to
we
address
that
with
every
place
where
that
happens,.
E
H
C
Is
not
the
thing
you
want
to
look
at
sorry?
I
will
share
please
I'm
so
sorry.
I
was
not
aware.
Thank
you
for
highlighting,
and
now
you
can
see
my
highlighting.
I
hope
is
that
better.
C
E
C
C
So
yeah
we
moved
the
file
entry
stuff.
There
was
another
request,
actually
outs
or
the
world
that
it's
confusing
how
we
ordered
it.
We
mimicked
the
order
of
the
switch
iso
text,
but
that
was
apparently
confusing.
C
No,
that
was
not
covered
here,
dang
it.
So
we
moved
everything
about
file
hashes
into
a
single
section
now
and
you
were
asking
about.
Does
fire
entry
have
a
hash
entry,
but
does
that
yeah?
So
it's
the
other
way
around.
Sorry,
I'm
not
getting
this
right.
Yes!
In
switch.
There
is
the
option
to
attach
a
file
hash
to
the
any
attribute
of
every
file.
Actually,
the
switch
specification
itself
uses
the
any
attribute.
The
code
with
sophistication
is
more
specific
here,
but
the
option.
E
C
Yeah
yeah,
it's
it's
covered
in
english
text
and
says,
use
any
and
put
this
there
and
it's
like
okay
yeah.
We
made
this
more
extra
set
path.
Elements
there
is
the
path
elements
is
just
a
a
helper
structure.
I
can.
Maybe
it
could
go
back
to
this
full
thingy
here
and
now
here,
search
for
path
elements.
C
Okay,
this
is
basically
a
we
created
that
one
because
it
used
in
two
places.
C
C
H
C
Okay,
so
that
was
done,
but
that's
just
an
explanation
of
things
that
have
been
done
for
a
long
time.
Sam
bear.
I
think
we
we
we
fixed
the
ref
for
some
bear.
It's
an
actual.
It's
an
actual
reference
now
here,
as
you
can
see,
it's
not
only
a.
I
don't
know
what
it
was
before,
but
now
it's
in
real
full-blown
reference,
no.
E
H
C
C
I
I
have
no
strong
feelings
here:
referencing
these
iso
spec
and
saying
we're
doing
it
the
same
way
as
in
not
using
somewhere,
but
this
year
suite
is
fine
with
me.
It's
a
minor.
E
Change
text
yeah,
that
was
in
the
dash
15.
I
talked
a
little
bit
about
how
other
folks
would
ballot
on
that
document
and
there's
a
desire
to
point
to
something
tighter
and
if
you
do
the,
if
you
do
the
reference
where,
if
we
list
the
iso
reference
that
will
make
it
an
okay
reference
and
if
someone
really
wants
to
get
the
details
through
the
iso
reference
you'll
be
able
to
click
through
that
link
that
you
already
have
so
we'll
cover
it
as
kind
of
an
administrative
thing.
In
that
way,.
C
E
I
mean
there's
no
reason
why
you
can't
you
know,
have
an
informative
reference
to
semvair
in
the
inline
text
that
actually
explain
it,
but
when
we
have
to
have
a
formal
reference
to
explain
that
that
particular
iana
registry,
we
use
the
iso
spec
instead
understood.
So
this
is
the
first
open
review.
Thank
you.
No,
the
second
one.
C
B
C
Okay,
cool:
could
you
at
like
an
action
summary
like
action
on
sibo
attack
for
next
version
and
or
the
assembler
item
so
like
they
have
a
small
action
item
list
here
in
the
minutes?
It
says
fine
with
you
here
super
cool
thanks
and
thanks
roman
for
reminding
me
about
the
sibo
attack,
which
I
probably
would
not
have
forgotten.
C
So
yeah,
I
can't
I
never
never
know
now
so
next
item.
What
are
the
normative
requirements?
Yeah.
There
are
a
lot
of
normative
requirements
now
and
you
are
asking.
Is
there
something
in
swift,
preventing
normal
guidance
that
says
should
or
must
sign.
E
The
new
section
I
appreciate
the
new
kind
of
section
describing
how
to
precisely
do
the
signing
in
coast
with
so
so
there's
an
analog
to
xml
kind
of
sig
in
kind
of
swift.
That's
great!
Now
the
question
is
you've,
given
the
blob
of
how
to
do
it
right,
but
what's
the
operational
workflow
about
when
it
should
be
applied
and
is
there
something
some
parallel?
We
need
to
apply
from
suit,
or
is
there
something
new?
We
should
say
here
about
that.
C
No
actually
suit
is
as
ambiguous
as
we
are.
So
what
you're
basically
saying
how
you
do
it
and
you're,
not
with
a
single
word,
mentioning
that
you
must
do
it
or
recommend
when
to
do
it.
That
is
due
to
the
nature
of
switz,
for
example,
if
you
create
an
evidence,
switch
tag
on
your
system,
it's
basically
like
a
claim
set
for
for
attestation
evidence
because
you
are
creating
all
the
hash
values
for
the
files
that
are
running
right
now
so
and
the
oh.
C
They
were
executed
right
at
some
point
and
are
running
right
now,
so
they
think
that's
better
phrased.
So
so
that
is
a
suit
that
you
can
create
ad
hoc
on
a,
for
example,
a
target
environment
and
rats
for
for
clips,
and
that
would
be
super
fine
and
that
is
not
signed
by
itself.
The
the
the
testing
environment
will
sign
all
the
whole
other
things
you
you
bang
it
in
there,
so
that
it
probably
would
use
an
unsigned
switch
with
an
evidence,
tag
that
is
signed
by
a
let's
call.
C
It
authorized
entity
on
on
the
on
the
producer
side,
so
so
that
is
why
we
are.
We
have
no
text
in
here
when
to
sign,
because
the
document
cannot
know
when
you
sign
stuff,
it's
it's
the
application
usage
scenario
that
basically
tells
you.
If
you
want
to
sign
something
or
not,
this
is
just
the
format
and
how
to
do
it.
E
Right
that
makes
sense.
I
think
what
we
could
benefit
from
is
a
sentence
in
the
security
consideration
that
says
something
on
the
order
of
this
document
only
provides
a
data
format,
any
application
that
adopts
it
will
need
to
strongly
consider
you
know
its
operational
environment
and
the
security
constraints.
C
C
Okay
got
it
so
we
are
now
we
have
10
minutes
left
and
one
two,
three
four
five
items
with
our
rate,
not
necessarily
enough
time.
So
let
me
check
your
next
item.
Please.
C
Oh,
that's
basically,
the
same
item
we
could
would
do
that
that
notion
of
how
to
how
secure
the
provisional
validation
logic
and
how
to
make
the
trustworthy
into
the
security
requirements
right.
E
C
Maybe
false
collapses
with
the
previous
item,
because
I
think
it's
actually
in
the
same
scope
of
the
and
thank
you
for
that
of
the
security
considerations.
Okay,
moving
on
to
this
item
here,
swoosh
and
your
newest
comment-
is.
C
E
Well,
so
what
struck
me
is
the
gestalt
here
is
that
we
just
have
a
data
format
and
all
of
the
application
considerations
are
out
of
scope,
but
then,
later
in
the
security
considerations
text,
we
actually
talk
about
the
behavior
of
the
applications
and
how
they
can
use
that
data.
So
if
we
are
going
to
go
through
the
trouble
of
talking
about
how
applications
will
process
it,
I
do
think
we
need
to
say
the
very
explicit
thing
which
is:
if
you
don't
have
intel.
E
C
Okay,
thank
you,
I
think
that's
valid.
If
you
open
that
can
of
worms,
you
kind
of
have
to
deal
with
the
consequences.
Correct,
that's
right,
yeah,
yeah,
yeah!
I
get
it
yeah.
It
was
hard
to
follow,
but
I
think
your
reasoning,
I
thank
you
for
the,
for
the
connotation
really
helps.
C
C
E
So
this
is
a
semantic
play
on.
I
I
understand
the
definition
that
you've
created
this
word
called
authoritative
codes,
co,
swit
tags,
which
is
meant
to
say
the
place
that
created
them
is
the
authoritative
place.
But
again
this
is
back
to
the
previous
thing,
which
is
to
comment
to
say
you
can
call
it
authoritative,
which
makes
it
seem
like
that's
the
place
you
get
it
for.
But
if
you
didn't
sign
it,
there's
no
way
of
knowing
whether
it's
authoritative
or
not,
because
I
can
modify
it
at,
will.
C
So
this
again
collapses
with
that's
a
there's,
a
top
there's
a
semantic
discrepancy
between
the
two
items.
C
Okay,
yeah.
I
will,
I
don't
have
an
easy
fix
for
that.
I
see
the
problem.
I
think
there
isn't.
There
does
not
need
many
words,
but
I
think
we
have
to
place
it
well.
I
think
that's
the
actual
challenge
here
where
to
place
the
the
words
okay
yeah.
I
can't
I
can't
provide
a
answer
right
now.
C
I
we
will,
but
that's
a
really
open
issue
then,
and
that's
the
first
okay,
I'm
not
worried
still
and
there's
a
net
which
we
can
cover
then
and
then
there
is
yeah
pub
key
is
my
fault,
I'm
I'm
I!
This
is
force
of
habit.
I
apologize.
E
So
the
the
challenges
of
some
of
the
challenges
were
were
kind
of
laid
out
in
that
last
paragraph,
and
all
I'm
saying
there
is
that,
in
addition
to
input,
standardization,
loop
detection,
actually
adding
signatures
might
help
us
in
mitigation
as
well.
So
it's
just
input,
sanitization,
comma,
loop,
detection,
comma,
signed
side
tags
is
a
way
to
address
these
concerns.
C
Okay,
yeah,
then
we
can,
we
can
yeah.
Okay,
then
I
can.
This
is
a
place
where
maybe
even
address
then
section
six
problem
here:
okay,
yeah,
I
see
the
the
okay,
that's
an
easy.
That
is
almost
a
nits
okay.
I
will
do
this
and
sounds
actually
doable.
Maybe
we
will
be
done
with
this
earlier
than
april.
C
A
No,
no,
no
you're
there
I
was.
I
was
wondering
if
hank
was
going
to
say
something,
but
it
seems
to
me
that
we're
at
a
good
place
to
okay,
say,
say
goodbye
and
give
everybody.
M
B
They
publish
and
it
opened
up
the
link
for
it
for
the
kodi
md.itf
notes.
D
Yeah,
okay
and
I
took
notes
as
well
so
I'll
I'll,
merge
and
deal
with
it.