►
From YouTube: IETF-GNAP-20211005-1600
Description
GNAP meeting session at IETF
2021/10/05 1600
https://datatracker.ietf.org/meeting//proceedings/
B
A
A
A
A
C
C
There
we
go-
hopefully,
hopefully
he
gets
that
all
right,
so
hi
everybody
welcome
to
the
grand
interim
meeting
for
october
2021.,
I'm
justin
richer
and
my
co-editors
aaron
and
fabian
are
here
as
well.
Next
slide,
please,
we've
got
a
bunch
of
things
that
we
want
to
touch
on
today,
because
this
is
only
an
hour.
We're
not
expecting
to
get
super
deep
into
things
here.
C
But
the
goal
of
this
is
to,
as
usual,
raise
the
topics
and
sort
of
set
the
directions
of
at
least
what
the
editors
have
been
thinking
and
sort
of
the
discussions
that
we've
seen
so
far
on
a
lot
of
these
bits
and
hopefully
use
that
to
kick
start
and
hope
and
drive
conversations
on
the
mailing
list
and,
where
appropriate,
in
specific
github
issue
trackers.
But
before
we
get
into
those
issues,
we
wanted
to
give
an
idea.
C
Give
the
group
an
idea
of
the
updates
that
we've
had
in
the
draft
they've
been
there
for
about
a
week
and
a
half.
I
think
we
managed
to
get
that
draft
out
and
it
consists
of
three
major
changes:
new
sections
in
the
draft,
but
first
next
slide.
Please
there
oh
yeah:
these
are
the
changes.
Sorry
I
forgot
our
own
slides.
C
We
there's
there's
one
sort
of
syntactic
and
semantic
change
that's
been
made
in
in
the
draft
in
in
the
current
version:
zero,
seven,
but
the
main
changes
that
we're
going
to
be
going
to
into
our
three
new
sections
that
are
all
they're,
technically
editorial,
but
they're
all
deeply
important
to
sort
of
understanding
and
situating
and
using
this
draft.
So
next
slide.
First
off
we're
going
to
talk
about
the
change
to
the
user
handle
syntax.
C
C
This
represents
the
same
user
as
best
as
I
can
tell
I'm
talking
to
you
on
behalf
of
the
same
end
user
that
I
was
talking
to
previously
with
all
of
the
extensive
work
that's
been
put
into
the
subject:
identifiers,
largely
that
was
fabian's
doing
so.
Thank
you
very
much
for
all
that,
but
with
that
extensive
work,
we
took
a
step
back
and
realized
that
we
kind
of
didn't
need
this
extra
sort
of
special
field
anymore.
C
We
had
all
of
the
pieces
to
reuse
the
different
bits
that
that
were
already
in
the
protocol
and
get
the
same
results
so
now
a
client
instance
is
allowed
to
send
an
opaque
subject
identifier
as
effectively
a
shortcut
for
saying
this
is
the
same
user
now.
The
client
instance
has
always
been
able
to
send
back
that
identifier.
C
Then
we've
now
got
this
built
in,
but
in
such
a
way
that
it
reuses
the
existing
machinery
instead
of
being
its
own
little
special
thing
on
the
side
simplifies
the
protocol
uses
exercises
stuff
that
we
already
have,
but
that's
the
only
syntactical
change
next
slide.
Please,
the
biggest
changes
in
the
document
are
the
trust,
relationships,
security
and
privacy
considerations.
D
D
Yes,
the
most
important
thing
about
trust
relationships
is
that
we
actually
wanted
to
do
that
for
a
long
time
and
it
doesn't
change
anything
in
terms
of
requirements,
but
it
does
change
the
description
of
what
we
do
and
the
intent
that
we
that
we
bring
to
it
and
the
way
we've
tried
to
approach.
This
is
not
to
import
any
security
or
privacy
issues
in
into
that
section
and
to
bring
that
as
as
one
of
the
first
section
in
in
section
1.4
and
we're
actually
using
a
definition
that
comes
from
from
my
theory.
D
So
that's
a
proposal
and
then
we
actually
identified
the
different
parts
of
the
protocol,
the
actual
the
actors
in
the
protocols
that
need
to
discuss
and
trust
each
other,
and
we
do
that
based
on
description
based
on
premises
and
and
trust.
So
that's
general
idea.
The
text
is
very
short,
but
it's
it's.
It's
really
an
initial
draft
to
actually
clarify
out
the
different
ideas.
C
All
right
thanks-
and
I
just
also
want
to
add
that
a
lot
of
this
is
based
on
some
very,
very
lengthy
conversations
that
the
working
group
had
that
teased
out
a
lot
of
these
relationships
going
back.
You
can
see
things
that
talk
about
you
know
asrs
relationship
and
client
as
relationship
and
how
those
are
different
from
each
other
and
how
the
expectations
are
different
from
each
other.
C
D
Yeah
something
just
to
add
than
that
we
can
actually
formalize
these
types
of
relationships,
because
you've
got
mathematical
model
behind
that.
So
if
people
want
to
have
a
look
at
that,
it's
it's
an
open
door
to
actually
formalize
the
trust
relationships
in
in
very
well
danielle
fed
type
of
situation.
I
would
say.
E
Thank
you.
Can
you
hear
me
yes
good?
Well,
I
looked
at
that
section
and
made
five
comments.
Four
comments
on
the
issue
three
or
six,
and
basically
the
the
section
called
trust
relationship,
does
not
define
trust
relationship.
In
fact,
trust
is
defined,
has
been
defined
by
iso
a
long
time
ago
in
the
last
century,
when
you
want
to
express
a
trust
relationship,
you
say
entity
is
said
to
trust
entity.
E
E
E
I
have
issue
a
draft
on
the
mailing
list
and
that
draft
is
defining
some
translation
ship
common
to
the
two
model
and
then
makes
a
clear
extension
between
the
cross
relationships
that
apply
to
each
access
control
model,
and
I
believe
that
we
should
support
both.
The
key
question
is
whether
draft
7
will
evolve
to
take
into
consideration
attribute-based
access
control.
E
A
D
Fabian
well,
first
of
all,
it's
it's
really
an
initial
draft,
so
there
might
be
some
relationships
which
are
missing,
and
it's
true
that
there's
at
least
one
that's
missing,
which
is
a
relationship
between
the
client
and
between
the
end
user
and
the
authorization
server.
The
reason
why
I
didn't
put
that
into
the
text
is
because
it's
actually
quite
a
complex
relationship,
because
in
in
practice,
you're
going
to.
C
I
I
think
we
lost
fabian's
audio
there.
He
did
say
he
was
mobile
today.
So
if
I
can
summarize
a
little
bit
of
what's
already
been
discussed
in
the
in
the
github
issue,
one
of
the
biggest
things
about
this
model
is
that
it
brings
in
it
brings
in
context
in
a
very
important
way.
Yes,
the
editors
are
very
aware
of
the
iso
trust
relationship
model
that
is
far
from
the
only
model
of
formal
model
of
trust
relationships
that
there
are
in
the
world.
C
This
one
brings
a
lot
of
really
important
context
to
each
of
the
relationships,
including
the
purpose
that
that
was
brought
up
before
it
is.
It
is
not
missing,
it's
actually
integral
to
what
is
being
what
is
being
discussed
here.
Yes,
we
know
it's
not
completely
complete
yet,
but
the
spec
is
also
not
done
so
more
feedback.
A
F
Yes,
another
question
related
to
this
agenda
item
is
whether
it
would
be
appropriate
to
consider
zero
trust
architecture,
at
least
as
it
is
defined
by
nist,
for
lack
of
a
more
formal
definition
and
discuss
that
explicitly
in
the
document,
because,
just
because
I,
for
one,
am
not
schooled
in
these
formal
modeling
exercises,
but
I
think
I
and
many
of
our
audience
would
be
interested
in
the
applicability
of
gennapp
to
zero
trust
architecture.
Thank
you.
A
C
C
Yeah,
that's
that's
exactly
a
key
part
of
the
problem
when
you
say
trust
and
trust
relationship.
It's
gonna
fall
out
in
a
lot
of
different
ways.
Zero
trust,
architectures
are
are
absolutely
brilliant.
I've
done
a
lot
of
work,
both
with
nist
and
and
with
other
groups
on
on
their
application.
That's
not
what
we're
really
talking
about
here
a
lot
of
times.
Zero
trust
means
that
you
don't
pre-establish
trust
based
on
an
authority.
That's
that's
kind
of
a
general
theme
with
zero
trust
system.
C
C
If
that
distinction
makes
sense-
and
so
I
think
it
does
make
sense
to
talk
about
how
these
get
formed
as
which
is
why
we
have
the
model
of
client
instances
identified
and
proved
by
keys,
for
example
and
the
and
why
we
split
the
asrs
trust
relationship
and
how
that's
mechanically
built
into
its
own
spec,
because
that
is
a
very,
very
distinct
part
of
the
of
the
system.
So
it
it's
it's
it's
related,
but
largely
orthogonal.
To
this
and
and
a
lot
of
that
comes
with
just
the
way
way.
F
Justin,
just
to
close
this
out,
I
am
not
at
all
interested
in
arguing
the
points
you
just
made.
What
I'm
saying
is
that
zero
trust
architecture
basically
introduces
specific
concept:
separation
of
concerns,
accountability
of
individuals
least
privilege,
authorizations
and
audit
capabilities
each
one
of
these
four
things,
regardless
of
what
we
choose
to
point
to,
as
a
definition
is
relevant
to
the
protocol
for
being
either
in
scope
or
out
of
scope,
and
rather
than
so
I
I
don't
see
that
as
being
squishy
at
all.
F
C
Thanks
adrian,
I
would
encourage
you
to
actually
file
file
that
as
an
issue
with
those
specific
four
points
against
the
core
document.
I'm
I'm
all
for
formalizing
this
stuff
everything
that
you've
said
like
formalizing.
These
relationships
is
going
to
allow
us
to
talk
about
things
in
that
type
of
in
that
type
of
way.
C
If
that's
something
that's
useful
for
for
the
group
overall
and
as
you
know,
as
you
know,
yarn
especially
has
been
always
about
formalizing
the
the
security
and
trust
analysis
of
this,
and
so
having
those
as
sort
of
primitives.
For
that
analysis,
I
think
would
be
helpful,
so
yeah,
please
please
do
that.
We
do
have
a
lot
more
slides
to
get
through
when
we're
on
number
five.
So
I'm
gonna
recommend
we
move
forward,
but
I
see
denise
is
back
in
the
queue.
C
I
will,
I
will
happily
respond
to
it
the
same
way
that
I've
responded
to
it
before
that
both
capability
and
our
back
and
and
abac
and
all
of
that
are
already
supported
inside
canap
and
ganap-
does
not
take
a
hard
stance
on
any
of
those
that
you
can
do
any
of
those
and
I've
showed
you
how
and
we've
written
it
down
several
times.
So
that's
still
my
response.
C
You
can
have
attributes
for
the
client
for
the
resource
owner
for
the
end
user,
for
the
authorization
server
for
the
resources
being
protected
for
the
subject,
information
being
returned,
all
of
those
attributes
can
go
into
the
formal
decision,
whether
they
are
represented
inside
the
access
token
or
in
the
data
model
that
the
access
token
is
used
to
look
up.
The
map
does
not
take
a
hard
stance
on
that.
That's
why
that's
been
pulled
into
the
into
the
rs
document.
All
of
that
can
be
done
today.
C
C
Probably
we
tried
to
take
a
very,
very
wide
swath
at
this,
and
a
lot
of
this
comes
down
to
what
a
lot
of
us
in
this
group
would
consider
to
be
common
sense
like
yes,
you
really
do
have
to
use
tls
and
yes,
if
somebody
steals
a
bearer
token,
they
can
use
the
bearer
token,
but
we
really
do
have
to
spell
all
of
these
things
out,
and
I
would
encourage
group
members
to
please
read
through
those.
We
know
that
there
probably
are
holes.
C
We
don't
know
exactly
what
the
holes
are,
which
is
what
makes
them
holes.
You
know
figure
out
what
we've
missed.
One
of
the
next
steps
that
the
editors
have
is
to
actually
sort
of
you
know
group
these
so
they're
reading
them
makes
a
little
bit
more
sense
that
we
have.
You
know
similar
issues
grouped
together
and
can
kind
of
tell
a
better
story
so
that
an
implementer
reading
through
this
document
can
actually
end
up
doing
the
right
thing.
C
So,
for
example,
bearer
tokens,
you
can
use
bearer
tokens,
but
you
are
going
to
have
to
need
to
know
all
of
the
considerations
for
if
you
use
bearer
tokens
by
default,
doesn't
use
bearer
tokens
by
default.
They're
they're
bound
to
the
client
instances
key,
but
you
can
make
that
special
flag
to
say
no,
really.
I
want
a
bearer
token
when
I'm
talking
to
this
resource,
and
but
when
you
do
that,
you
need
to
know
what
the
trade-offs
are
and
that's
what
this
section
is
all
about.
C
There
are
going
to
also
be
cases,
and
this
is
this
is
another
thing
that
the
editors
are
kind
of
asking
the
group
to
help
us
make
sure
we
get
all
these.
There
are
going
to
be
cases
where
something
is
stated
in
a
security
consideration
that
isn't
yet
tied
back
to
an
actual,
normative
requirement.
Earlier
in
the
document,
we
need
to
make
sure
that
we
have
all
of
those
requirements
stated
out
in
normative
language,
so
that
it's
not
just
a
security
consideration
that
says
hey.
This
would
be
a
good
idea.
C
We
need
to
have
other
companion
text
that
says
this
is
required
for
more
details,
go
see
the
security
considerations
which
tell
you
why,
but
you
still
have
to
do
it,
so
I
didn't
want
to
go
in.
You
know
it's
a
lot
of
text.
I
didn't
want
to
go
into
detail
about
everything
here,
but
I
will
pause
for
any
questions
or
concerns
or
considerations
for
this
piece.
G
E
Okay,
well,
since
the
structure
of
an
access
token
is
left
undefined.
This
is
currently
insufficient
to
say
that
it's
impossible
that
it
is
sufficient
to
say
that
it
is
impossible
for
our
nrs
to
verify
that
an
access
token
is
valid.
The
document
is
currently
still
a
framework
and
is
unable
to
define
secure
interval
protocol.
E
H
A
A
E
E
In
my
draft
that
I
publish,
I
consider
that
the
authentication
of
an
end
user
by
an
iteration
server
is
a
key
feature
and
I
do
not
need
to
consider
client
instances.
No
client
instance
keys.
This
is
a
fundamental
difference
now.
My
last
point,
which
relates
to
that
is
that
draft
7
consider
the
binding
of
an
access
token
to
a
key
by
a
client
instance
in
its
in
its
request.
E
E
C
Okay,
to
respond
to
that
just
very
quickly,
there
are
many
very
well
understood,
use
cases
where
there
is
no
end
user.
The
token
model
has
long
been
understood
and
used
to
represent
the
tuple
of
the
resource
owner,
implied
or
entity,
or
otherwise
the
client
making
the
request,
the
authorization,
server
or
authorization
entity
generating
this
and
the
context
that
it
has
there
and
the
rights
and
therefore
resources
being
granted
as
part
of
that.
C
C
E
E
C
Basically,
I
am
sorry
to
interrupt,
but
we
understand
what
you
are
proposing
and
you
have
yet
to
explain
sufficiently
how
putting
a
user
identifier
inside
the
token
means
that
I
can't
forward
it
because,
as
far
as
the
rs
is
concerned,
if
I
send
my
token
to
yarn
with
all
of
my
keys,
then
yaran
can
use
it.
And
the
rs
thinks
that
it's
me,
because
the
token
says
that
it's
me
and
all
of
the
proof
says
that
that's
the
entire
point
of
the
technological
abstraction.
E
H
E
C
E
E
Sorry
can
I
continue,
I
should
the
the
drug
does
not
make
clear
that
user
authentication
is
needed
and
I
gave
you
the
argument
coming
from
the
european
union,
where
we
need
to
have
multi-factor
authentication
and
at
least
two-factor
authentication
to
be
supported.
So
it's
fundamental
to
say
how
the
use
the
end
user
is
authenticated
and
the
draft
is
mute
about
that.
C
E
B
Hey
thanks,
so
I
think
we
need
to
table
this
discussion
that
we're
having
here
we
have
only
an
hour
and
we
had
attempted
to
do
a
breath.
First
kind
of
walk
through
all
of
the
material
we're
clearly
rat
holding
kind
of
down
a
particular
kind
of
issue
that
will
prevent
us
to
getting
kind
of
through
that,
so
guinea
and
and
justin.
I
would
ask
if
we
can
kind
of
table
this
discussion
honestly
just
keep
moving
through
the
material
we
have
thanks.
C
H
Sure
I
can
talk
through
these,
so
there
is
a
brand
new
privacy
considerations
section
in
the
document,
and
the
approach
we
took
here
was
to
go
through
the
points
brought
up
in
rfc
6793,
which
is
a
framework
for
making
privacy
considerations
for
specs
and
talk
about
the
ones
that
are
relevant
to
this
spec,
as
I
was
reading
through
that
turns
out.
Some
of
them
don't
really
apply
in
this
kind
of
framework
because
they
have
more
to
do
with
other
types
of
specs
like
http.
H
Just
does
think
it
has
a
lot
of
different
considerations
compared
to
a
delegated
authorization
protocol,
but
I
did
pick
out
the
topics
that
I
felt
were
relevant
to
to
get
app
and
then
went
through
each
of
those
points
and
addressed
addressed
each
of
the
points.
So
it
looks
like
we
lost
yarn.
Is
that
or
is
that
just
me.
C
H
The
obviously
the
client
is
the
thing
that
the
user
is
trying
to
use.
So
that's,
not
surveillance
surveillance
is
the
unintentional
monitoring
of
activity
the.
But
if
the
client
is
built
up
as
multiple
distinct
pieces
of
software,
where,
as
far
as
its
role
in
gnap,
it
is
considered
the
quote-unquote
client,
but
it's
actually
a
mobile
app
with
a
logging
service
in
the
cloud.
That's
reporting
usage
data
et
cetera,
et
cetera.
H
D
Yes,
do
you
hear
me
yes
yeah,
so
it's
an
open
discussion.
Actually,
we've
got.
We've
got
some
discussions
with
the
uad
security
workshop.
That's
that's
ongoing,
so
I
actually
plan
to
to
work
on
that,
but
the
framework
actually
comes
from
mark
burgus
from
cf
engine,
so
it's
been
used
in
the
it
quite
extensively.
D
The
the
fact
is.
It
actually
goes
much
further
in
the
in
the
definition
of
trust,
as
as,
as
I
said
before,
and
especially
trust
is
not
only
defined
as
something
you
rely
on
and
you
can
actually
put
some
evaluations
in
your
framework.
So
it's
it's
something
that
you
can
actually
implement,
but
yeah.
It
needs
some
some
further
work,
but
compared
to
to
existing
trust
frameworks
it
can
be.
C
I'll
just
jump
in
and
say
that,
from
my
perspective,
absolutely
there
are
def.
There
are
definitely
different
considerations.
The
editors
took
took
the
approach
of
focusing
on
filling
these
out
for
the
core
document.
First,
there
may
be
some
that
move
to
the
rs
draft
there
may
be.
There
will
probably
be
others
that
are
in
the
rs
draft.
The
core
will.
C
E
E
H
In
the
rs
draft,
I'm
really
not
appreciating
repeating
the
same
arguments
over
and
over
again
it
does
not
feel
constructive
and
yes,
this
core
document
says
it
is
not
defined
the
feign
app,
because
that
is
true,
and
that
is
what
the
separate
rs
draft
starts
to
get
into.
Is
that
particular
those
particular
kinds
of
issues?
H
H
A
C
Justin,
please
go
ahead
yep,
so,
unfortunately,
we
only
have
a
few
minutes
to
go
through
the
open
issues.
I
will
do
my
best
to
talk
quickly
through
these
pieces
before
we
before
we
get
to
the
end
here.
So
first
issue
299,
I
believe
yarn
raised
it,
but
he's
commented
on
it
at
the
very
least,
the
overall
question
of
how
symmetric
cryptography
either
fits
or
doesn't
fit
inside
of
canal,
and
this
is
something
that
we,
just
as
a
group
need
to
decide
where
we
land
on
this.
C
C
There
was
a
really
interesting
use
case
brought
to
us
by
the
solid
working
group
or
a
member
of
the
solid
community
rather,
and
the
idea
here
is
that
the
client
has
access
to
a
set
of
proofable
claims
about
the
end
user.
That's
currently
using
the
client,
and
it
can
get
those
to
the
as
in
and
for
the
purposes
of
getting
an
access
token
for
a
protected
rs
downstream,
and
this
brings
it
brings
up
a
bunch
of
really
interesting
questions
about
how
something
like
this
fits
in
with
knapp.
C
One
of
the
key
things
that
knapp's
architecture
does
is
that
it
backs
away
from
the
oauth
assumption
that
the
end
user
is
the
resource
owner
and
they
always
interact
with
the
as
probably
through
a
web
page
unless
something
else
and
something
weird
is
happening,
at
least
from
the
oauth
perspective.
But
we
need
to
be.
I
think
we
can
do
a
good
job
of
being
clearer
about
how
those
bits
fit
together,
because
if
we
look
at,
I
put
together
a
couple
of
very
simple
sequence,
diagrams
about
how
this
might
go
about.
C
In
this
case,
there
is
what
what
the
writer
of
the
use
case
called
the
end
user
extension
server.
The
eu
xs,
which
has
these
claims
about
the
end
user
in
this
sequence,
if
you
read
through
you'll,
see
that
it's
actually
the
client
that
goes
and
gets
those
from
the
eu
xs
and
then
presents
them
back
to
the
authorization
server
on
behalf
of
the
end
user,
this
kind
of
fits
what
had
been
talked
about
previously
with
the
ssi
digital
wallet
and
the
client
saying
like
hey.
C
Both
of
these
are
a
different
way
of
proxying
sort
of
this
rights
information
and
I
think
it's
kind
of
an
open
question
like
which
makes
more
sense
inside
knapp,
or
are
there
other
ways
to
layer
this
that
make
even
more
sense,
so
in
case
one?
We
presume
that
the
client
can
do
a
lot
of
work.
It
can
go
off
to
this
other
server
and
get
the
stuff
and
bring
it
back.
C
It
also
allows
the
client
to
kind
of
preload
some
of
this
stuff
and
just
say:
hey
here's
what
I
know
about
the
current
user.
What
can
you
do
with
it
in
case
two,
the
as
sort
of
turns
into
its
own
client
to
this
extension
server,
but
it
doesn't
normally
interact,
interacts
or
in
this
case
it
doesn't
interact
with
the
end
user
directly
and
when
writing
out
the
sequence
diagram
for
case
2.
C
This
also
brings
up
and
gets
us
into
another
big
question
of
differentiating
between
the
end
user
and
the
resource
owner
in
ganap.
These
are
two
different
roles:
the
end
user
talks
to
the
client
software,
the
resource
owner
controls,
access
to
the
resource
via
the
authorization
server,
and
so
those
are
two
different
relationships
in
our
key
diagram
in
oauth.
C
We
assume
that
they're
the
same
person
in
some
weird
extensions
they
can
possibly
not
be,
but
in
get
app,
it's
pretty
clear
how
we
can
kind
of
connect
those
together
for
when
talk
for
when
we're
talking
to
the
resource
server.
But
things
get
murky
when
we
start
talking
about
returning.
Subject:
information
directly
back
to
the
client
if
the
ro
is
not
the
same
as
the
end
user
and
I'm
returning
subject,
information
about
the
resource
owner
does
is:
is
that
actually
a
use
case,
or
is
that
a
privacy
violation?
C
C
C
C
All
right,
thank
you.
All
right.
Next
up
is
a
a
technical
bit
that
got
brought
up
a
while
ago
and
that
is
defining
the
resource
access
request,
the
access
type
field
in
a
generic
http
kind
of
way-
and
this
is
honestly
it's
a
really
clever
hack.
I
think
I
think
it's
a
really
neat
idea,
the
idea
here
being
that
I
don't
actually
know
much
about
the
kind
of
api
that
I'm
calling.
C
If,
if
there
was
no
appetite
within
the
ietf
to
define
this
because
the
type
field
is
recommended
to
be
a
namespace
collision
resistant
url
that
url
could
be
hosted
anywhere
and
how's.
This
document
that
says
here's
how
to
do
generic
http
stuff
and
what
that
kind
of
means.
But
the
relationship
of
this
work,
to
connect
core
and
to
this
working
group
is
not
yet
decided.
So
you
know
the
editors
would
like
to
know.
Is
this
something
that
people
have
an
appetite
for?
C
C
So
what
are
sort
of
the
key
things
that
we
can
focus
on
going
up
to
that
the
editors
are
once
again
going
to
have
at
least
one
more
revision
of
the
core
draft,
and
hopefully
the
rs
draft
by
then
as
well-
and
I'm
not
taking
a
shopping
list
right
now,
but
I
am
going
to
ask
people
to
continue
to
raise
topics
on
the
list
for
sort
of
next
next
generation,
stuff
or
next
next
meeting.
Sorry,
not
next
generation.
Quite
yet,
that's
the
whole
presentation,
so
darling.