►
From YouTube: IETF113-ACME-20220321-1200
Description
ACME meeting session at IETF113
2022/03/21 1200
https://datatracker.ietf.org/meeting/113/proceedings/
A
B
B
B
How
to
share
slides.
C
C
C
C
So
yeah
welcome
everyone
to
the
acme
meeting
of
itf
113
there
in
vienna,
austria
or
wherever
you
all
are.
C
So
I'm
sure
you've
seen
this
thing,
and
this
is
preferential
treatment
for
the
remote
users
who
can
actually
sit
with
the
reading
glasses
and
read
this
as
opposed
to
the
people
in
the
room
who
have
to
squint.
C
Since
this
is
one
of
the
early
sessions,
I'll
mention
this
is
the
noteworld.
Please
read
it
read
it.
It
has
a
large
bearing
on
what
happens
if
you
have
any
ipr
that
is
relevant
to
this
to
the
contents
of
this
meeting.
If
you
have
any
questions
well,
there
are
links
on
the
slide.
You
can
ask
your
chairs,
you
can
ask
your
ads.
C
C
Yeah,
okay,
great,
thank
you.
Okay,
so
we're
gonna.
Do
the
document
status
and
then
see
four
percent,
and
then
we
have
four
presentations
and
if
any
times
left
there's
always
the
any
other
business
part.
C
Okay,
so
document
status,
we've
got
the
acme
authority
token
and
the
acme
authority
token
tn
off
list
both
are
an
isg
evaluation
or
rather
have
been
in
asg
evaluations
for
several
months
now
they
have
some
open
discusses
and
both
have
the
revised
id
needed
attack
and
they
both
had
these
this
tag
for
months.
D
There
I
am
hi,
you
know,
I'm
I'm
basically
asking
kind
of
the
same
question,
but
I
want
to
push
it
a
little
more.
It
took
many
months
to
get
a
d
feedback
resolved
and
now
we're
seeing
a
bunch
of
months
waiting
for
the
isg
kind
of
feedback
result.
Is
there
something
we
can
do
to
help?
Do
we
need
more
authors
or
editors?
I
I
don't
know
how
to
make
this
go
faster,
but
it
seems
like
there's
a
lot
of
waiting,
always.
C
C
Anyone,
oh
oh,
just,
leave!
Okay,
so
this
weekend.
B
C
Okay,
okay,
so
next
there's
the
dtn
node
id
document
and
it's
been
submitted
to
the
isg
and
we've
got
the
retroact
reviews.
There's
a
new
new
version
posted
and
there's.
The
new
version
is
rather
recent
and
we're
configuring
the
changes
with
the
working
group
until
april
1st.
So
so
we're
encouraging
you
all
to
read
this
and
comment
soon
and
that's
it
so
and
but
but
we're
going
to
have
a
presentation
about
this.
So
let's
not
spend
too
much
time
of
the
document
status
part.
C
So
I
can
be
client.
We've
had,
I
think,
no
traffic
on
the
list
since
the
last
itf,
so
yeah
kathleen.
Can
you.
F
George,
a
couple
of
comments.
We
should
start
to
see
traffic
pick
up
on
this
because
of
several
efforts
around
supply,
chain
security
and
essentially
tying
into
s-bombs
and
signatures
for
code,
signing
signatures
on
software
and
so
either
for
the
next
meeting
cycle
or
the
one
after
that
and
I'll
be
reaching
out
to
some
of
the
folks
on
acme,
because
sigstor,
for
instance,
is
being
used
but
doesn't
quite
match
the
workflow
for
acme,
and
it
would
be
good
to
have
that
use
a
standard.
F
And
so
their
workflow
does
an
open
id
call
first,
and
that
information
is
packaged
up
and
then
is
used
to
generate
the
certificate.
And
it's
just
slightly
different
from
how
acme
works.
So
I'm
going
to
be
reaching
out
to
a
few
people
to
see
if
we
can
collaborate
and
determine
the
best
path
forward,
because
I
think
sig
store
could
be
further
secured
by
using
acme
and
then
there's
one
other
effort
that
I
don't
think
I
can
mention
the
name
of
yet.
F
C
So
another
thing
that
is
not
a
working
document,
but
we
have
looking
at
it
since
last
itf
is
the
acme
renewal
information
there
is.
There
have
been
some
threads
in
the
list
and
having
more
than
one
thread
for
acme
document
is
pretty
good
at
this
time.
C
No
new
revision
since
last
itf,
but
we
are
having
a
presentation
later.
So,
let's
wait
for
that.
Okay,
so
and
acme
integrations
and
acme
subdomains.
There's
both
had
the
new
versions
one
in
december,
one
in
march,
and
both
of
them
seem
like
they
have
synchronized
slides,
are
asking
us
if
we're
ready
for
working
with
last
calls
on
kind
of
foreshadowing
their
presentations.
B
C
Okay,
so
next
thing
is
dta
node
id
yeah
brian
I'll,
see
how
I
get
to
release
this
share
screen
yeah
or
do
you
want
us
to
share
the.
G
If
you
can
bring
them
up,
then
I
can
flip
through
them.
I
said
I
yeah
if
I
just.
C
G
Okay,
okay,
so
the
most
recent
version
dash
nine
was
published
recently.
One
editorial
change,
but
it
is
a
big
help
is
that
the
dtn
documents
that
are
referenced
are
now
actually
rfcs
published.
So
that
is
good.
G
The
references
to
those
were
updated.
The
major
changes
since
dash
six-
and
some
of
these
were
what
remit
had
mentioned
on
the
mailing
list
message.
One
of
them
is
editorial,
adding
a
more
explanation
of
dtn
terminology
and
and
hopefully
helping
the
reader
to
understand
what
this
document
is
supposed
to
be
covering
and
what
it's
not
the
second
change.
G
This
is
structural.
Changing
the
the
logic
for
the
better
is
separating
the
tokens
from
the
challenge,
identifier,
and
because
of
this
separation.
It
avoids
overlaps
in
in
how
these
things
are
used
and
what
they
mean,
and
it
also
brings
this
behavior
into
very
close
alignment
with
rfc
8823,
the
email
validation.
So
the
logic
that
applies
there
and
here
now
is
practically
identical.
The
only
difference
being
the
transport
of
email
versus
dtn
bundles,
the
one
other
structural
change
that
was
made
in
this
last
edit
was
based
on
some
advice.
G
What
this
is
doing
is
adding
algorithm
agility
in
the
protocol
to
have
the
acme
server
provide
a
list
of
what
algorithms
it
finds
acceptable
and
have
the
client
choose
one
and
use
that
as
the
the
key
authorization
digest
now
shot.
256
is
still
mandatory
to
be
present
in
that
list,
but
it
doesn't
have
to
be
the
highest
priority
and
or-
and
it
doesn't
have
to
be
the
only
element
and
then
the
last
three
changes
were
typos
and
some
some
editorial
comments.
G
So
the
one
known
issue
as
far
as
the
document
is
concerned-
and
this
is
not
strictly
an
issue-
is
just
that-
the
hash
algorithms
registry,
that
this
is
referencing
is
not
a
published
rfc.
Yet
it's
still
in
auth48,
but
it
is
going
through
the
the
last
stages
of
getting
that
out
and
it
is
part
of
the
cozy
discussion
at
a
co-timed
meeting
with
this
acme.
G
C
Okay
and
as
always,
we'll
take
you
to
the
list
to
get
more
volunteers.
C
Okay,
anything
else
any
comments,
screams
and
groans,
moans
and
niggles;
okay,
so
thank
you,
brian
and
on
to
the
next.
C
H
All
right,
hello,
everyone
it
is
5-
am
on
the
west
coast
of
the
united
states,
so
any
typos
in
his
slides
I'm
going
to
blame
on
it
being
5
a.m.
Right
now,
and
not
regardless
of
what
time
I
actually
made
them.
H
H
New
version
zero
two
has
not
yet
been
published.
I
am
still
new
to
figuring
out
how
all
this
works
and
I
didn't
realize
there
was
like
the
publication
freeze
right
before
the
meeting
so
there
there
are
some
changes
in
the
pipeline
coming
up,
but
they
will
be
published
as
draft
zero.
Two
shortly
after
ietf113
is
over
gonna
go
over
what
those
changes
are
in
detail,
but
basically
updated
url
construction
as
a
result
of
feedback
on
the
list.
H
H
So
this
part
is
the
same.
Url
construction
is
still
based
on
a
base
path
contained
in
the
directory.
This
new
renewal
info
key
that
points
at
an
endpoint
next
slide,
but
rather
than
constructing
the
path.
After
that,
endpoint
is
a
series
of
slash
delimited
path,
elements
each
based
on
different
aspects
of
the
certificate,
we're
just
cribbing
wholesale
from
ocsp
and
taking
the
cert
id
asn
1
sequence,
from
an
ocsp
request,
which
contains
the
certificate
serial
number
hashes
of
its
issuer
name
and
issuer
key
and
for
algorithm
agility.
H
We
don't
want
any
of
those
things,
so
we're
going
with
just
this
cert
id
component,
but
similar
to
how
the
acme
spec
currently
does
things
like
passing,
certificates
back
and
forth
like
when
you
fetch
a
certificate.
That's
a
bunch
of
base64
url,
encoded
data
that
gets
returned
by
the
server
we're
doing
the
same
thing
here.
You
have
this
dur
object.
H
You
base
you,
you
have
this
asn
1
object,
you
encode
it
as
dur,
you
encode
that
as
base64
url
and
that's
the
format
that
you
use
on
the
network
to
pass
things
back
and
forth.
So
we
encode
this
whole
thing
as
base64
url
strip.
The
any
padding
equals
signs
from
the
end.
Just
like
you
do
in
other
parts
of
acme,
and
that
is
the
path
component.
And
then
you
make
a
get
request
to
the
renewal
info.
Endpoint,
slash
that
giant
blob
next
slide.
H
This
I
I
felt
like
having
a
fun
diagram
here.
This
is
basically
just
all
the
components
that
are
necessary
to
construct
this
request.
If
your
client
can
construct
an
ocsp
request,
then
your
client
can
construct
a
re
request.
It's
exactly
the
same
pieces
of
data
going
into
it
just
with
fewer
layers
of
wrapping
around
the
outside,
but
you
have
a
cacer.
You
have
the
end
of
tcert.
You
have
a
hash
algorithm,
you
construct
this
object,
a64
url
it
and
that's
how
you
build
the
url
next
slide.
H
Yeah,
so
you
concatenate
that
here
I've
split
that
base64
url
into
multiple
lines
for
the
sake
of
readability,
but
you
just
concatenate
the
base.
Url
slash
the
base64
url
path
component
make
a
get
request
and
all
the
rest
of
this
is
the
same
as
in
version
zero,
one,
the
server
responses,
identical
same
status,
codes,
same
retry
after
etc,
so
no
changes
in
the
rest
of
it.
There
next
slide.
H
It's
still
part
of
the
renewal
endpoint
a
renewal
info
endpoint,
but
in
addition
to
having
this
get
functionality
just
to
get
the
renewal,
the
suggested
renewal
window
for
your
certificate,
we're
also
adding
the
ability
to
do
a
post
as
get
request
to
the
same
endpoint
to
update
the
renewal
state
of
the
certificate.
H
H
H
This
lets
the
server
do
a
bunch
of
real
well,
first,
the
way
you
do
this
is
bog
standard
acme
you
make
a
post
as
get
request
to
the
renewal
info
url
in
the
directory.
The
body
of
that
post
is
get
request,
is
formatted
exactly
the
same
way.
You've
got
the
protected
section
with
the
key
id
the
nonce,
the
url
that
you're
making
the
request
to
for
the
sake
of
replay
protection.
H
You've
got
the
signature
and
the
payload
is
that
same
exact
cert
id
from
the
get
request
encoded
in
exactly
the
same
way,
which
is
the
same
way
that
you
make
a
revocation
request
to
acme.
It's
the
base64
url
of
the
dir
of
the
whole
certificate
body
for
a
revocation
request
here,
it's
base64
url
of
dur
of
the
cert
id
and
a
little
bit
of
metadata
right
now.
H
The
only
metadata
is
this
kind
of
redundant
seeming
replaced,
true
thing,
but
we
can
imagine
other
kinds
of
metadata
and
that's
part
of
the
open
questions
at
the
end
here.
So
you
make
this
this
update
request
and
then
the
server
can
use
this
information
for
a
bunch
of
things.
In
particular,
yeah
go
on
to
the
next
slide.
H
Right
so
one
thing
here
is
obviously
this
request
must
be
signed
by
the
original
subscribers
key
for
revocation
there's
like
three
different
kinds
of
revocation
paths
it
can
be
signed
by
the
original
subscribers
key.
It
can
be
signed
by
the
key
of
a
subscriber
who
has
proven
control
of
all
of
the
names
in
the
certificate
or
it
can
be
signed
by
the
certificate
key
itself
here.
No
just
the
subscriber's
key,
there's
no
reason
for
anyone
else
to
update
this.
That's
added
complication
like
if
we
can
talk
about
that.
H
Maybe
there's
other
reasons
for
it,
but
for
now
we're
saying
just
the
original
subscriber's
key
and
then
the
server
can
use
this
information
for
a
variety
of
things,
including
not
sending
reminders
like
saying
hey.
Your
certificate
is
about
to
expire.
Make
sure
you
renew,
if
you
have
a
positive
confirmation
that
it's
already
been
renewed
and
replaced,
don't
bother
doing
that
if
someone
keeps
polling
for
renewal
info
after
a
cert
has
already
been
marked,
as
replaced
just
start
returning
empty
bodies
or
errors,
because
the
cert
doesn't
need
to
be
renewed
anymore.
H
It's
renewal
information
is
don't
and
in
sort
of
the
most
emergency
case,
if
the
ca
is
in
the
process
of
revoking
and
replacing
a
bunch
of
certs
having
a
positive
confirmation
that
this
cert
has
been
replaced
already,
can
let
the
ca
revoke
it,
knowing
that
it
is
completely
safe
to
do
so,
as
opposed
to
potentially
causing
operational
problems
for
the
subscriber,
so
those
are
some
of
the
benefits
of
having
this
new
endpoint
yeah.
A
Michael
richardson,
at
the
mic,
so
the
question
you
said
something
that
if
the
certificate
has
already
been
replaced
that
you
could
just
replace
to
return
an
empty
body
because
it
doesn't
need
to
be
replaced
and
I'm
thinking
about
the
situation
where
you
have
some
monitoring
system,
that's
monitoring
things
and
I'm
thinking
that
it
might
actually
like
to
know
what
certificate
replaced
it
does
that
make
sense.
And
so
I'm
thinking
empty
body
might
not
really
be
the
right
answer
there
or
maybe
yeah.
H
Yeah
we've
been
thinking
exactly
the
same
thing
and
you
have
if
you
actually
go
onto
the
next
slide.
Okay,
there
you
go
yeah,
so
one
of
the
open
questions
that
I've
been
thinking
about
is
like
what
other
metadata
might
we
want
in
this
certificate?
H
Renewed
update
and
one
of
the
ideas
we've
had
is
the
serial
of
the
replacement,
cert
or
perhaps
even
the
full
cert
id
of
the
replacement
cert,
and
that
would
let
us
do
exactly
that
sort
of
thing.
Oh,
it's
been
replaced
by
this,
sir
great.
We
can
provide
that
information
in
general.
The
mapping
of
one
cert
to
its
replacement
is
a
very
hard
problem.
H
Speaking
from
let's
encrypt
experience,
lots
of
large
integrators
do
things
like
issue
a
hundred
certs
for
a
hundred
names,
each
based
on
which
domains
are
behind
which
load
balancers
and
then
three
months
later,
when
they
come
back
and
renew
all
of
their
certs.
Those
names
are
completely
shuffled
between
the
certs
and
so
mapping.
Oh,
this
cert
is
a
replacement
to
that.
One
is
very
difficult
because
they
have
totally
different
sets
of
names
and
so
yeah.
H
It
would
sort
of
push
that
mapping
onto
the
client
to
say:
hey,
you
not
only
tell
us
when
you
have
satisfactorily
replaced
the
serp,
but
you
tell
us
what
you
believe
actually
replaced
it
so
yeah.
This
is
one
of
the
things
we're
thinking
about.
We
don't
know
the
answer
here,
yet
whether
this
is
sufficiently
valuable
to
justify
the
extra
bytes
on
the
wire,
but
maybe
it
is
yeah.
So
that's
one
of
the
big
open
questions.
H
Still
another
open
question
is
related
to
one
of
the
email
threads
that
is
on
the
acme
mailing
list.
This
explanation
uri,
it's
not
a
big
open
question.
I'm
pretty
sure
I
want
to
include
this.
The
there
hasn't
been
a
whole
lot
of
discussion
about
it.
Basically,
the
idea
is
hey.
Let's
recognize
that
acme
clients
are
not
the
only
client
in
the
ecosystem.
H
There
are
other
players
in
the
ecosystem,
such
as
certificate
monitoring
systems
who
have
their
own
customer
base
of
people
who
want
to
know.
Oh,
my
goodness,
my
certificate
hasn't
been
renewed.
I
don't
have
good
monitoring
on
my
acme
client,
but
I
do
have
this
service
that
pings
my
domain
name
every
24
hours
and
lets
me
know
if
my
certificate
is
too
close
to
expiration
and
so
certificate
monitoring
services
could
do
things
like
could
provide
additional
value.
H
Essentially
if
they
had
additional
information
about
why
a
certificate
has
a
particular
renewal
window
and
in
the
normal
case
this
is
just
going
to
be.
Your
certificate.
Has
this
renewal
window
because
that's
a
safe
number
of
days
before
it's
going
to
expire,
but
sometimes
it
might
be.
Your
certificate
has
this
renewal
window
because
rca
does
dynamic
load
balancing
and
it
was
determined
that
your
certificate
should
be
renewed
a
little
bit
earlier
or
a
little
bit
later.
H
So
yeah
there's
sort
of
this
idea
that
the
response,
the
renewal
info
response,
could
contain
a
url
pointing
at
a
web
document
that
describes
the
current
reasoning
behind
the
renewal
window
and
that
that
url
could
be
blank
most
of
the
time
but
set
in
certain
circumstances
when
it
might
be
useful
to
the
user
and
to
clients
that
are
more
interactive
than
the
average
acme
client
clients
like
certificate
monitoring
systems,
so
yeah.
H
Those
are
the
things
that
we're
still
thinking
about
right
now,
plan
to
publish
version
two
in
like
a
week
and
a
half
after
this.
This
whole
week
of
meetings
is
over
yeah.
Any
other
questions
comments.
Things
like
that.
H
I
I'm
treating
the
whole
document
like
any
other
code
project,
getting
code
reviews
from
various
other
configurators
and
stuff
like
that,
and
so
all
of
the
changes
I
discussed
today
are
currently
in
that
code
review
stage
so
getting
like
minor
editorial
feedback
on
them.
C
Okay,
so
since
the
myq
is
still
empty,
I'll
ask
my
two
questions
so
one
regarding
the
explanation:
uri,
are
you
planning
to
also
standardize
the
content
of
that
resource.
H
Not
the
idea
is
no
I'm
happy
to
talk
about
other
reasons,
but
the
idea
is
basically
like.
This
is
something
that
is
actually
intended
for
the
human
not
for
mechanical
systems
to
process.
The
url
is
intended
for
mechanical
systems
to
send
in
an
email
or
whatever,
but
then
the
contents
of
that
page
should
just
be
a
page
that
can
run
javascript
in
order
to
determine
what
locale
it
should
translate
the
page
into
and
all
that
sort
of
stuff.
So
the
idea
is
that
it
would
just
be
a
web
page.
I
see.
C
So
no
cozy
object
or
anything
just
just
having
natural
language.
C
That
was
my
participant
question
now.
My
chair
question
is
so
why
you
bring
this
here.
Do
you
do
you
plan
on
asking
for
this
to
be
adopted
as
a
working
document.
H
I
would
love
for
this
to
be
adopted
as
a
working
group
document.
Again
I
don't
really
know
the
process
behind
that
or
when
it's
appropriate
to
ask
but
yeah.
Well,
it's
always.
C
Appropriate
and
the
process
is
asking
us,
then
we
ask
the
group,
give
people
two
or
three
weeks
to
comment
on
whether
it's
a
good
or
not
a
good
idea
and
then,
if
they
all
agree,
then
then
we
ask
you
the
serious
questions.
Do
you
know
that
you're
giving
up
change
control
because
the
group
has
changed
control
and
then,
if
you
say
yes,
then
yeah,
it's
we
adopt
it.
Well,
we
just
make
sure
with
the
ideas
that
it's
within
our
scope,
but
I
don't
think
that's
going
to
be
a
problem.
C
Okay,
so
we'll
do
that
after
the
oh
after
the
itf
week,
because
asking
people
for
comments
right
now
is
like
now
they're
concerned
about
the
session
tomorrow,
better
when
they
get
back
home.
C
Okay,
right,
none
of
that
so
I'll
see
if
I
manage
to
find
the
button
that
replaces
the
deck
rather
than
closing
the
deck
and
opening
another
one
yeah.
I
think
I
did
so
time
for
acme
integrations.
D
I
Okay,
well,
this
is
rafat
here
happy
to
hear
to
be
here
in
person.
Finally,
so
unfortunately
owen
is
not
here,
so
I'm
gonna
be
talking
about
this
and
we
have
the
team
here
next
slide.
Please.
I
So,
since
that
the
version
5,
we
did
mainly
editorial
changes
so
aligned
with
the
dns
terminology
added
some
missing
terminology
acronyms
and
just
again
using
proper
terminology
all
over
the
document
just
to
be
consistent.
So
that's
what
we
did
in
that
in
that
version
next
slide.
I
Some
minor
edit
editorial
stuff
still
in
in
the
in
the
next
version,
but
otherwise
we
are
as
as
authors,
I
think
we
this
work.
This
document
is
ready
and
we
should
be
going
to
a
work
group
last
call
in
this
one
and.
I
C
C
You
we're
making
good
time
today.
So
last
presentation
is
the
acme
subdomains.
A
C
A
B
A
A
B
A
A
A
I
that
will
actually
change
the
slides.
For
me.
No
evidence
he's
a
real
person
anyway,
okay,
so
the
document
was
actually
adopted.
I
think
just
before
the
last
ietf,
we
split
the
document
out
of
integrations,
and
so
we
had
to
do
a
bunch
of
work
on
it
to
make
it.
You
know
flat
showed
out
as
a
real
document.
A
It
was
adopted
next
slide.
Please!
Yes,
so
again,
like
the
previous
document,
you
know
we
fixed
a
bunch
of
the
terminology
to
be
more
correctly
acme,
and
there
was
some
you
know
some
some
other
terms
in
there
that
were
a
little
bit.
You
know
certificate
certificate
authority,
such
a
certification
authority.
Things
like
that
that
were
fixed
and
kind
of
the
most
interesting
part
is
that
there
was
some
criticism
of
that.
A
Some
of
the
json
content
for
some
of
the
order
parts
were
were
a
bit
confusing
they're
a
little
bit
contrived,
and
so
we
fixed
that
based
upon
some
thing
and
there's
some
text
there
to
fix
to
clarify
the
examples
next
slide.
Please.
A
So
there's
the
example:
we
had
this
domain
name
space,
which
you
know
kind
of
made
sense
at
the
time,
but
further
reading
it
you
know
just
sub
domains
is
true
or
not.
This
is
when
you're
asking
for
an
authorization
about
whether
you
want
to
do
everything
below
it
or
not
and
again
the
same
thing
domain
namespace
true,
because
it
became
subdomain
just
to
make
it
really
clear.
There's
not
really
a
lot
of
it's
really.
It's
pretty
obvious.
A
I
think
how
to
do
subdomains
just
you
know
to
write
it
down,
and
everyone
has
to
agree
and
that's
really
about
it
and
next
slide.
I
think
that's
the
last
one
rifat
and
I
both
work
live
in
ottawa,
but
we
only
only
talk
when
we're
here
at
an
itf
meeting
and
owen
is
12
hours
ahead
of
us.
So
it's
a
real
challenge,
so
we
think
this
document
is
probably
also
ready
for
working
group.
A
Last
call,
it
obviously
hasn't
has
much
time
in
the
working
group
as
a
document,
but
really
you've
seen
it
from
the
very
beginning
there.
It
would
make
sense
to
me
to
you
know,
read
them
all
together
there
and
I'll.
Just
mention
that
there
is
a
document
in
lamps
that
will
that
is
now
referenced
by
the
previous
document
that
we'll
get
into
rfc
editor
q,
miss
ref,
but
that's
not
our
our
fault.
We
should
do
our
do
our
do
our
finish
up
our
work
here.
That's
about
it!
Thank
you
any
questions.
C
Okay,
that
term
brings
us
to
the
end
of
first
slide,
and
I
guess
the
same
thing
is
true:
that
yeah
submit
to
zero
three
and
then
we'll
do
the
working
group
last
call
probably
do
them
together.
C
Quite
connected
to
each
other,
okay,
so.
C
Now,
let's
get
back
to
the
share,
slides
and
then
I
have
to
go
all
the
way
here
right,
so
we
got
to
the
any
other
business
part
with
plenty
of
time
can
just
mention
that
assuming
those
working
group
last
calls
finished
successfully
will
be
totally
out
of
work
unless
we
also
adopt
an
ari.
So.
C
Depending
on
how
that
turns
out
might
not
have
any
more
content
so
we'll
see
by
next
itf
whether
ari
is
adopted
and
whether
clients
actually
has
a
content
for
us
all
right.
Anybody
else
has
anything
to
say
on
any
other
business.
C
Going
once
going
twice
well,
so
thank
you
all
for
participating
in
the
first
ever
hybrid
acme
meeting.
C
D
C
So,
thank
you.
Bye.