►
From YouTube: CORE WG Interim Meeting, 2020-10-08
Description
CORE WG Interim Meeting, 2020-10-08
A
A
Okay,
okay,
so
then,
let's
start
the
section
for
today
so
for
today,
so
first
of
all,
let's
start
with
the
notewell.
As
you
know,
let's
be
nice
and
so
on.
We
all
are
very
senior
members
of
ideas,
so
we
all
know
what
what's
about.
For
today
we
have
the
the
two
topics:
state
list
and
resource
directory.
There
is
few
issues
left
and
michael
has
been
very,
very
nice
to
us
for
taking
a
bit
of
time
to
conclude
the
few
discusses
coming
from
isg,
so
we
are
going
to
go
through.
A
Okay,
well
I
mean
I
have
already
this
light
open,
so
we
might
as
well
just
go
with
the
stateless
and
I
can
present
from
here
and
then
later
you
can
present
rd
on
your
machine
right
yeah.
That
will
be
largely
on
issue
tracker,
but
yes,
oh
okay,
then
I
can
also,
you
know
either
act
as
a
proxy
cool.
So
please,
michael
the
floor
is
yours.
C
Yeah,
so
the
big,
my
big
reason
for
doing
this
is
that
this
document
is
holding
up
this
cluster
310,
which
is
full
of
roll
and
six
dish,
documents
which
I
I'm
an
author
and
so
came
to
that.
So
that
link
goes
to
the
bunch
of
issues
that
I
pulled
out
and
there
are
four
pull
requests
relating
this
next
slide.
I
guess.
C
Oh
hit
the
hit
the
big
screens
button,
so
you
can
just
hit
down
you
hit
that
that
thing
on
the
side
there
you
go
yeah,
so
okay,
so
these
are
the
issues
as
cars.
This
is
carson's
summary
of
the
issues
the
simplest
ones
is.
These
are
the
ones
that
maybe
we
should
say,
don't
won't
fix
on,
and
I'm
perfectly
happy
to
do
that.
I
don't
know
if
that
will
fly
well,
I
think
number
nine
in
particular.
I
think.
C
C
C
So
basically,
what
I've
done
is
I've
clarified
that
the
aes,
the
suggestion
of
using
aes
gcm
is
a
suggestion,
so
it
was
in
the
word.
Uppercase
recommended
it's
now
in
lowercase
recommended
supposed
to
be,
and
I
see
it
there
still
is
recommended
uppercase.
Why
is
it
that
way?
It's
supposed
to
be
lowercase,
based
upon
the
fact
that
this
is
not
normative
so
yeah.
That
would
be
great
if
you
could
change
that.
Thank
you.
Now.
C
Click
on
the
lot
click
on
the
the
instead
of
instead
of
writing
that
click
on
the
the
icon.
Next
to
the
preview,
no
you're
in
the
right
place.
Click
there,
yeah,
plus
yeah
click
on
not
preview,
go
to
the
next
icon,
the
next
icon
after
preview
to
the
right
of
preview
that
one
yeah
now
change
it
to
say.
Lowercase.
C
And
hit
add
single
comment
that
changes
it
right
there.
So
so,
then
the
other
part
was
it
said.
May
I
wonder
if
I've
missed
pushing
some
code
here
and
didn't
get
it
right,
because
I
thought
I
did
this
already
so
basically
it
just
says
that
this
is
all
a
local
decision.
The
only
reason
use
aes
ccm
is
because
that's
what
you
have
in
hardware.
If
you
have
something
else
in
hardware,
then
you
should
use
that
and
then
the
biggest
con.
C
The
most
of
the
text
was
about
the
fact
that
if
you
can't
keep
track
of
the
nonces,
then
probably
you
should
just
generate
a
new
key.
If
you,
whenever
you
couldn't
keep
track
of
the
nonsense-
and
I
I
guess
that's
the
real
question
that
needs
to
be
thought
about
is
whether
or
not
these
responses
are
going
to
have
to
outlive
a
case
where
a
device
is
sleepy
and
doesn't
and
and
can't
keep
track
of
the
nonces
or
not.
If,
if
you
understand
what
I'm
saying
tell
me
explain
that
more.
C
Okay,
so
let
me
let
me
maybe
just
start
for
everyone
at
the
beginning.
If
you
generate
a
key
and
you
keep
it
for
encrypting
your
state
and
you
go
to
sleep,
sorry
and
you
use
ccm
mode.
So
you
need
a
nonce
that
you
should
never
repeat
and
you
send
a
request
and
then
you
go
to
sleep
and
then
you
wake
up,
and
then
you
notice,
you
didn't
remember
the
nonce.
C
C
If
you
have
a
clock
that
always
increments
or
something
like
that,
and
but
if
it
turns
out
that
you
send
a
request-
and
you
expect
the
response
before
you
go
to
sleep,
then
you
could
just
generate
the
key
each
time
you
don't
have
to
you,
don't
have
to
keep
track
of
any
of
that
across
sleepy
times,
whether
that's
appropriate
for
your
device.
I
don't
know
it's
hard
to.
C
B
My
take
on
this
would
be
if,
if
the
device
can
remember
the
key,
then
either
it's
it's
committing
that
to
to
some
more
even
more
persistent
memory
or
it
can
or
or
it's
keeping
it
in
nvram
as
well,
and
even
if
it's
committing
the
key
to
some
more
persistent
memory,
then
there's
ways
that
we're
using
earth
core
to
make
sure
that
even
in
an
uncontrolled
shutdown,
the
nonsense
are
not
reused.
Without
hitting
that
memory.
B
D
Do
people
go
ahead?
The
implementation
approach
is
like
this.
So
if
you
do
this,
for
instance,
based
on
the
sequence
number,
then
once
you
have
booted
you
see,
what's
the
old
sequence
number,
let's
say
that's
7
000.,
then
you
increment
the
sequence
number
to
eight
thousand
and
write
that
to
persistent
memory,
and
then
you
are
free
to
use
seven
thousand
two,
eight
thousand
in
your
current,
not
in
your
current
volatile
state
without
further
touching
the
the
persistent
state
and
once
you.
C
C
C
C
C
C
Now
it
appears
here
it
is
yeah.
Now
it
appears
there,
you
go
yeah
my
I
guess
it
was
private
to
me
because
I
hadn't
shared
it.
I
hadn't
committed
it
anyway
I'll
go
through
this.
If
that's,
if
that's,
if
the
rest
of
the
text
and
the
concept
is
okay,
then
I'll
go
through
and
create
a
final
diff
for
that
and
I'll
reference
that
that
piece
you
just
suggested
there.
The
os
core
part
sounds
good,
okay,
so
next
slide.
I
guess.
C
Okay,
so
next
yeah
one
more
slide,
so
that
was
eight
put
down
a
bit,
so
numbers
number
ten
and
number
eight,
so
it
did
generate
text.
For
that
I
I
think
it's
pretty
good.
The
the
question
was
why
60
minutes
and
it
was
arbitrary
and
I
don't
think
I
quite
captured
what
maybe
carson
had
in
mind
with
the
business
with
doing
something
like
the
act
timeout.
C
C
C
The
point
is
that
if
you've
gone
to
find
out
what
the
extended,
what
the
extended
token
length
is
that
you
shouldn't
assume
that
it
has
a
value
that
it
still
has
that
value
many
minutes
to
hours
later,
particularly
if
it's
another
node
on
the
internet,
so
that
the
the
question
is
what
you
don't
want
to
go
too
often,
and
you
don't
want
to
go
too
less
often.
So
what
is
the
right
number?
C
So
whatever
your
dhcp
or
our
router
advertisement
lifetime
is
that's
how
long
you
could
cache
this
information
and
then,
if
it's
on
the
internet,
then
I
would
say
that
if
you
looked
it
up
with
dns,
then
whatever
the
time
to
live
for
the
dns
result
is,
is
a
good
upper
limit
on
how
long
you
can
wait.
How
long
you
can
cache
that
information,
because
you
can't
because
you're
not
if
you
don't
look
up
the.
C
D
C
A
C
Maybe
right
well,
no,
the
idea
isn't
that
it's
based
on
this
other
number.
It's
just
another
time
value
that
we
have.
We
can
configure,
and
I
don't
know
exactly
how
to
write
that
text
and
it
doesn't
seem
like
it
should
be.
It
belongs
in
the
well,
but
it's
in
section
two
two
two.
So
it
needs
to
create
a
new,
a
new,
a
new
value.
I
I,
it
seemed
loath
to
me
to
create
a
value
that
someone
has
to
figure
out
and.
A
C
C
So
minimum
and
maximum
is
also,
I
think,
important,
so
don't
ask
again
within
a
half
an
hour.
It
can't
change
within
the
half
an
hour,
but
after
a
day
you
should
chat.
You
should
do
it
again,
regardless
of
of
whatever
other
numbers
you
had.
That
would
be
my
suggestion
to
have
two
numbers
for
a
minimum
and
a
maximum.
If
you
don't
know,
if
you
did
get
it
from
dns,
then
you
know
after
that
dns
timeout.
You
should
ask.
C
I'm
not
saying
that
that
I'm
not
saying
it
can't
be
longer
than
that,
and
if
and
if
you
have
a,
if
you
can't
tell
what
the
what
the
you
can,
you
might
be
able
to
guess
what
a
neighbor
is
by
your
own
lifetime
right.
But
if
it's
on
some
other
part
of
the
internet,
you
have
no
idea
how
long
the
addresses
are
valid
at
that
end,
and
the
concern
is
that
you
know
colon
colon
2
goes
away
and
is
replaced
by
a
new
colon,
colon
2,
which
has
a
different.
C
If
it's,
if
it's
in
your,
if
it's,
if
it's
an
adjacent
node
like
you're
in
the
same
subnet,
the
odds
are
it
has
the
same
lifetime
that
that
you
do
so.
If
you
have
three
week
lifetimes,
because
that's
what
you
got
are
you
know
year-long
lifetimes,
then
you
could
assume
the
neighbor.
Has
that
long,
a
lifetime
too?
C
There's
a
lot
of
logic
to
figure
this
out,
but
you
know.
On
the
other
hand,
you
could
just
check
every
half
an
hour.
It
probably
it
hurts
your
battery,
but
it
probably
better
than
getting
it
wrong.
I
I
don't
I
I.
I
don't
really
think
this
is
going
to
change
that
often,
but
I
think
it's
a
bit
of
a
boogie
man
and.
C
Yeah,
so
I
don't
know
exactly
how
the
how
I
have
to
think
of
think
about
how
to
write
that
text
with
respect
to
like
ack
timeout.
I
don't
know
how
to
I'd
have
to
figure
out
how
to
do
that.
If
someone
knows
how
to
do
that
easily,
it
seems
to
be
it.
It
seems
you've
written
a
particular
way
to
call
out
that
these
are
co-app
values,
tunable
values.
A
C
C
C
D
D
D
A
A
C
C
A
B
A
B
A
D
C
D
C
D
C
A
C
B
B
B
Any
anyway
I'll
I'll
just
paste,
you
paste
over
links
when,
when
there's
somewhere
to
go,
and
if
you
could
follow
that
on
on
an
organizational
point,
I
unfortunately
didn't
still
didn't
manage
to
write
up
full
requests
for
all
the.
What
is
it
almost
2
000
lines
of
comment
processing
but
there's
a
few
points
where
I
actively
need
a
bit
of
assistance
and
I'd
like
to
go
through
those
and
other
than
the
last
time.
B
I'd
go
for
the
low
hanging,
fruit,
first
and
and
and
then
go
escalate
to
the
to
the
harder
ones.
So
there's
there's
one.
I
don't
have
really
on
the
issue
tracker,
but
we
got
a
comment
that,
on
on
the
paragraph
from
a
system
design
point
of
view,
the
ambition
is
to
design
horizontal
solutions
that
can
enable
utilization
of
machines
in
different
applications,
depending
on
their
current
availability
and
capabilities,
as
well
as
application
requirements,
thus
avoiding
silo-like
solutions
on
the
topic
of
this
being
buzzworthy
without
actually
saying
anything
now.
B
I
think
I
can
help
with
the
saying,
and
you
think
the
question
is
just
do
we
want
this,
this
level
of
possibility
buzzwordiness
that
I
do
agree
with
who
was
it
warren
kumari?
Is
there
do
we
want
to
keep
that
in,
or
is
this
really
just
something
that
happened
when
someone
was
coming
from
a
ceo
presentation.
B
If,
if,
if
we
have
any
reason
to
kind
of
keep
a
few
of
these
words
in
there
to
ensure
that
this
is
taken
up
well
by
by
some
target
community
that
I'm
currently
not
aware
of,
I'm
happy
to
keep
the
buzzwords
in
otherwise
I
just
at
least
there.
There
are
statements
in
there
that
I
think
are
valuable
on
that
that
contribute
to
why
we
are
doing
rd.
But
they
are
you,
you
have
to
know
the
buzzwords
to
to
get
through
them.
So
I
I
I
do
some
some
reverting
here.
A
C
B
D
B
Yeah
yeah,
so
so,
if
basically,
with
my
main
question
answered,
I
can
come
up
with
a
pull
request
that
that
we
can,
but
I
can
then
so
next
item
is
a
question
on
the
on
the
topic
of
dhcp
and
slack
one
is
it?
Is
it
crunched
slack,
I'm
not
sure
after
after
I
found
out
that
it's
not
cuddle
and
always
be
careful.
B
D
D
D
D
C
C
D
C
C
B
D
D
B
No,
not
so
not
exactly.
This
happens
a
bit
in
all
score
as
well,
but
in
all
so
in
in
dtls,
it's
sufficient
to
swallow
a
message
and
then
it
will
be
retransmitted
as
a
new
dtls
message
and
that
will
be
responded
to
and
the
original
dtls
message
will
not
be
kicked
out
of
the
replay
window
with
oscoro.
This
doesn't
happen
until
the
complete
request
times
out
and
the
client
tries
again
with
a
fresh
request
with
a
with
a
new
sequence
number.
B
Well,
because
none
of
the
requests
we're
sending
have
a
precondition
on
so
the
the
request.
The
responses
are
bound
to
the
request,
but
the
requests
are
not
bound
to
the
previous
state,
which
is
okay,
because
we
generally
expect
reordering
just
not
when
we
are
manipulating
resources,
where
we
in
other
cases,
have
an
image.
B
B
This
would
not
even
need
to
be
time
based.
This
could
be
event
based.
So
basically,
the
the
echo
value
is
an
echo
value
is
good
as
long
as
their
only
registration
updates
happen
like
a
plane.
Lifetime
refresh
has
happened,
and
only
when
the
value
is
actually
changed,
then
the
old
values
are
not
good
anymore,
so
this
would
be
really
really
a
more
counter
thing
than
than
a
time
based
thing.
B
B
I
mean
this
is
the
thing
is
for
resource
directory.
This
is
probably
not
as
critical
as
it's.
It
will
probably
be
for
for
other
for
other
core
applications
right,
so
I
can
sketch
this
up.
For
this
case.
It's
just
another
change
that
will
happen
without
that
will
happen
very
late
in
the
process
that
has
a
very
weak
attack.
B
C
B
Now
the
restoring
it
it
can
keep
a
registration
alive
for
some
time
unless
the,
unless
the
client
puts
it
it
puts
it
explicitly
deleted
and
the
other
way
around
the
attacker
can
delete
a
registration
that
has
previously
deleted
itself.
So
if
a
device
always
deletes
its
registration,
when
it
goes
to
deep
deep
sleep,
then
one
of
those
deletions
could
be
stored
and
used
later
to
kill
the
registration
right
after
it
came
up
that
that's.
C
A
Yeah
and
and
actually
reviving
a
registration
does
it
also
revive
or
bring
back
existing
all
the
other.
I
don't
know
like
observations
from
the
in
the
case
of
lightweight
with
them
too,
for
instance,
the
server
and
rd
are
collocated.
No,
it
wouldn't
bring
anything
back
right.
It's
just
a
registration
entry.
B
A
B
C
Is
a
real
big
deal,
I'm
just
trying
to
think
about
the
other
case.
Where
and
and
and
so
if,
if
there
was
a
half
solution
that
made
deletes
not
replayable
but
made
ads
are
playable.
So
so,
if
if,
if
some
node
deletes
its
entry
and
then
goes
into
a
deep
sleep
and
some
an
attacker
puts
the
entry
back
in.
B
But
there's
there's
a
third
class
of
changes
that
we
don't.
We
can't
say
much
about
yet
because
we
don't
have
them.
That
is
changes
to
registration
attributes,
so
the
registration
attributes
we
have
now
are
pretty
tame
because
either
they
can't
be
changed
like
endpoint
and
sector
or
there
are
things
like
lifetime,
which
is
probably
changed.
Rarely
just
as
well,
but
any
registration
up
attribute
update
could
have.
This
could
suffer
the
same
fate,
but
for
lack
of
entries
in
that
registry
we
don't
we
can't
anticipate
yet
what
what
the
effect
will.
B
Things
replay
protection
doesn't
catch,
this
really
replay
protection.
This
is
just
even
easier
because
you
don't
have
to
swallow
the
request
and
wait
for
the
re-transmit
to
go
through
and
only
have
as
many
attempts
as
you
swallowed,
but
you
can
just
replay
and
replay
and
replay.
So
this
is
worse.
If
replay
protection
is
off
and
it's
worse
in
dtls
than
it
is
north
core,
but
it
can
still
happen.
It
just
gets
gradually
harder,
as
you
can
go
from
dtls
without
replay
protection
to
oscore.
C
B
Things
I
I
don't-
I
don't
mention
this
in
here
yet
because
I
wasn't
sure
how
how
brave
the
problem
is
perceived
really
and
what
other
mitigations
we
might
have,
and
certainly
just
having
dtls
replay
protection
is
something
we
want.
As
we
discussed
last
time,
we
want
to
have
enough
in
co-op
anyway,
because
nobody
is
aware
that
this
is
off
by
default.
B
D
C
B
D
B
E
B
B
This
so
if
there's
no
more
questions
or
points
on
this,
then
there's
there's
one.
One
point
that
I
think
is
is
a
bit
easier
again.
That
is
the
topic
of
commissioning
tools.
So
we
had
a
comment
on
the
or
a
question
really
about
whether
the
this,
whether
the
actions
of
commissioning
tools
are
a
one-time
event
or
or
happen
more
often,
and
I
do
agree
that
we
the
way
it's
phrased.
It
looks
a
lot
like
those
commissioning
tools,
act
in
the
original
setup
phase
and
then
go
completely
away.
B
C
My
understanding
is
that
the
commissioning
tool
arrives
with
the
installer
of
some
kind.
It
may
be
attack
his
phone
or
maybe
attached
to
their
phone,
and
then
it
leaves
never
to
return
yeah.
That
would
be
bad,
so
I
don't.
I
was
surprised.
I
didn't
know
this
text,
so
I
was
surprised
to
see
that
it
would
have
to
do
some
kind
of
a
a
keep
alive
or
something
is
what
you're
saying.
C
D
B
B
Okay,
that
brings
me
to
two
remaining
points.
One
is
the
one
where
I've
stuttered
around
a
lot
in
the
last
meeting
on
the
topic
of
author
of
how
do
we
bind
authorization
to
resources
and
given
that
this
has
come
up
implicitly
in
one
of
the
comments
this
I
I
now
have
a
better
example
for
this,
unfortunately,
still
without
without
much
text
here.
But
if
you
go,
could
you
go
to?
Where
is
it
the
discover,
the
uri
discovery,
and
basically
just
above
section,
five.
B
E
B
Discovery
not
limit
the
set
yeah,
so
what
what
we
have
been
allowing
for
some
time
is
that
the
that
in
discovery,
basically,
you
are
directed
to
a
directory
some
at
some
other
host
now
in
connection
with
all
the
authorization
that
we
now
more
explicitly
prescribe
to
happen
where
the
end
point
verifies
that
the
credentials
of
the
rd
are
good
to,
for
example,
keep
its
links
secret
to
some
to
some
to
be
defined
group
there.
The
client
relies
on
the
resource
to
be
actually
be
a
direct
resource
directory.
B
So
imagine
a
case
where
you
have
a
border
router
that
is
queried
for
discovery
and
that
border
router
has,
in
its
well-known
core
a
link
to
the
actual
resource
directory.
This
would
this
would
be
aligned
with
the
with
the
lookup
recommendations
and
the
other
border.
Router
would
say
there
is
at
co-op
colon,
slash,
rd.example.com
rd,
there's
a
resource
directory,
and
then
the
client
connects
to
that
host
verifies
that
the
host's
credentials
are
good
to
be
a
trustworthy
resource
directory
and
post.
These
links
there
so
far
is.
B
B
Who
did
something
wrong
there
or
what
went
wrong
there?
And
this
is
happening
here
in
discovery,
because
we
don't
protect
the
discovery
steps
because
we
say
that
discovery
doesn't
need
protection,
because
that
later
the
rd
will
be
authorized
we'll.
We
will
have
its
authorization
checked,
but
it
seems
not
to
quite
cut
it
and
the
same
problem
is
showing
up
again
when
people
are
when
people
want
to
trust
links
found
in
the
resource
directory.
B
B
B
B
C
You
see
we're
not
alone,
so
so
you
know
in
the
ola
space,
the
answer
is:
don't
have
don't
have
resources
with
different
kinds
of
authorization
on
the
same
host.
You
should
just
make
up
some
more
names
and
put
them
in
different
places,
and
you
know
doctor
it
hurts
when
I
do
this.
So
don't
do
this,
but
I
guess
it's
just
spelled
out
that
you
that
this
is
a
problem,
because
I
think.
B
I
mean
that
that
basically
shifts
the
the
that
basically
shifts
things
that
we
in
all
our
co-op
examples
treat
as
hosts
into
or
treat
as
resources
and
entry
points
for
services
into
into
dedicated
hosts,
which
means
that
that,
for
example,
we
need
to
maintain
much
more.
We
might
need
to
maintain
many
more
oscar
contexts
than
we
probably
than
we
naively
would
have
to.
B
That
is
that,
if,
if
a
client
relies
on
any
properties
of
a
properties
of
a
resource
for
for
something
that
matters
and
phrasing
that
will
be
the
hard
part,
then
it
will
have
to
verify
that
information
by
looking
it
up
from
the
well-known
core
of
that
host
again.
So
this
is
a
place
where
we
could
put
the
attributes
in
a
way
that
the
client
may
trust
them
in.
B
In
the
concrete
example,
that
would
mean
that
the
client,
after
having
found
the
link
to
what
it
thinks
of
as
the
resource
directory
to
go
to
the
host
will,
which,
which
it
authentic,
which
it
authenticates
query
it's
well-known
core
file
for
just
that
very
single
record,
possibly
even
without
getting
more
than
a
few
bytes
as
a
response.
If
we
phrase
that
adequately
and
then
rely
on
the
information
which
is
now
authoritative
in
the
application
of
the
resource
directory.
C
Probably
so
it
was
just
said
that
so,
if
you
made
up
new
host
names,
you'd
have
to
establish
more
os
core
contexts.
Now,
I'm
trying
to
imagine
a
situation
where
there
were
some
other
credential.
I
don't
know
what
carson
has
in
mind
exactly
here.
That
was
on
a
per
resource
basis
and
there's
you
know
things
above
co-app
can
do
that.
But
wouldn't
that
still
mean
that
you'd
have
multiple
contexts.
You
wouldn't
be
reducing
the
number
of
contexts
at
all.
B
You
might
so
if,
if,
if
we
had
a
situation
where,
for
example,
the
the
authorization
information
about
the
host
says
not
that
this
horse
is
generally
trusted
to
serve
a
re,
serve
as
a
resource
directory
as
a
confidential
resource
directory,
but
this
particular
resource
on
that
host
serves
as
a
resource
as
a
as
a
trustworthy
resource
directory.
Then
the
client
would
get
the
information
when
it
obtains
the
authorization
information
and
see
the
mismatch
and
bail.
B
B
B
B
B
So
there
is
still
a
bit
more
language
about
particular
certificates
in
there
than
I
would
like
to
have.
But
for
me
this,
this
should
be
this.
For
me,
this
should
roughly
capture
what
I
think
is
a
good
is
a
good
default
policy,
especially
on
on
the
topic
of
the
the
the
different
subject-
alternative
names,
I'd
like
to
have
this
this
reviewed
again,
because
I
think
so
so
we
talked
about
this,
but
I'm
not
sure
I
captured
it.
A
B
So
that,
for
me,
that
concludes
the
big
open
issues
where
I,
where
I
know
that
I
would
where
I
needed
active
input,
I
might
still
come
up.
Something
might
still
come
up
when
I
process
the
rest,
but
I
think
I
can
make
everything
of
of
everything
of
the
comments
into
either.
We
do
it
like
this
because
or
into
a
pull
request,
and
I've
already
started,
merging
pull
requests
as
well
to
get
things
into
a
more
consistent
shape
again.
B
Those
probably
that
is
the
the
echo
mitigation
and
the
topic
of
authorization.
I
probably
won't
merge
them
in
there,
but
they
don't.
They
don't
pertain
to
right
on
point
to
particular
comments
that
we
got
either
so
at
least
we
can
have
a
version
that
addresses
the
comments
that
came
up
and
then
still
let
them
know
that
there
are
things
that
we
are
pondering,
that
that
might
be
good
to
include
or
see
what
the
status
is
by
then.
B
A
Very
it's
very
good,
okay,
so
and
from
the
meeting
today,
there
were
a
few
items
that
I
think
people
could
probably
provide
feedback
if
they
prioritize
it
by
monday
at
latest,
and
then
maybe
we
can,
by
the
end
of
next
week
optimistically,
we
could
submit
the
new
version.
If
not,
then
the
next
one,
I
suppose.