►
From YouTube: IETF-TOOLS-20220303-2000
Description
TOOLS meeting session at IETF
2022/03/03 2000
https://datatracker.ietf.org/meeting//proceedings/
C
D
A
A
So
I
would
like
to
ask
everyone
to
remember
that
this
session
is
being
recorded
and
will
get
pushed
to
youtube.
So
the
side
effect
of
using
the
intermediating
mechanics
for
the
group
having
the
recording
is
useful
and
having
it
pushed
to
youtube,
isn't
isn't
going
to
hurt
us,
but
we
do
need
to
remember
that
what
we,
what
we
say,
is
going
to
be
captured
in
that
record.
A
A
I'm
planning
to
just
go
through
these.
As
with
a
quick
introduction
for
the
proposals
as
exist,
I
think
our
conversation
should
have
a
tenor
that
is
not
unlike
what
the
isg
uses
at
their
buff
coordination
call.
We
need
to
refine.
You
know
what
the
workshop
would
talk
about,
but
not
try
to
have
the
workshop.
While
we're
on
this
call.
A
A
A
A
A
Renderer
is
pulling
bibxml
from
common
sources
that
it's
actually
producing
what
the
the
submitter
intended.
The
agenda
interface
is
kind
of
long
in
the
tooth.
There
have
been
suggestions
for
how
to
improve
it.
I
think
lars
has
taken
a
stab
at
some
of
these
things
already
in
his
bootstrap
5
branch,
and
there
are
some
large
suggestions
about
making
adjustments
to
the
role
models
and
the
utilities
that
we
have
that
use
them
to.
Let
us
build
views
that
do
better
things
for
access
permission
without.
A
A
A
B
Well,
to
help
you
to
help
you
not
feel
that
way.
I
just
wanted
to
confirm
that,
even
if
the
developers
were
to
just
get
on
with
it,
part
of
that
process
would
be
checking
to
make
sure
that
what
was
being
developed,
addresses
sort
of
the
ui
ux
issues,
so
the
workshop's
intent
is,
is
merely
to
understand
the
issues
better
or
maybe
identify
other
issues
to
put
into
this
project.
A
E
A
E
Infrastructure
workshop
that
we
did
earlier
so
my
main
concern
about
some
of
these
is
that
it's
like
inviting
bike,
shits
right
and-
and
I,
if
we
can
find
a
way
to
avoid
this
and
to
keep
the
discussion
sort
of
on
the
things
that
that
don't
need
to
be
bike.
I
think
that
would
be
useful,
like
with
the
interface
right.
E
I
can
see
that
going
pear-shaped
very
quickly,
and
maybe
I'm
colored
by
the,
like
the
whole
discussion
on
how
we
the
simple
proposal,
to
make
auth48
public
that
we
thought
was
very
small,
straightforward
and
it's
getting.
You
know
rebuild
by
a
few
people,
yeah
yeah.
Well,
you
know
that
I
would
like
to
avoid
plus.
The
other
thing
is
that
some
of
these
things-
I
don't
know
if
the
broader
community
really
has
much
insight
like
the
role
management,
for
example.
A
Well,
specifically,
you
know
the
conversations
around
should
we
should
we
attach
roles
to
the
to
documents.
What
would
what
would
working
group
chairs
find
useful
for
being
able?
You
know
more
than
they
have
now
for
being
able
to
attach
a
person
to
a
document
and
have
that
person
have
different
ways
to
interact
with
the
document
based
on
that
attachment?
A
The
the
the
core
team
here
will
have
to
do
a
lot
of
prep
for
each
of
these
in
order
to
make
them
successful
so
and
maybe
towards
the
end
of
today's
call,
we
should
talk
about
criteria
for
success.
You
know
what
is
it
that
we
really
really
want
to
have
come
out
of
these,
and
if
and
if
you
see
in
line
that
something
that
we
really
need
to
address
around
that
question,
just
go
ahead
and
jump
in
carson.
I
see
you've
got
your
hand
up.
F
Yeah,
I
just
was
wondering
how
we
actually
communicate
about
these
things,
so
the
the
road
management
part
I
actually
can
imagine,
because
this
is
essentially
a
brainstorming.
But
there
are
a
few
other
things
here.
That
really
essentially
would
need
a
prototype
to
talk
about,
because
it's
so
hard
to
to
visualize,
so
that
this
would
need
extensive
preparation
and-
and
I'm
just
wondering
how
how
we
could
make
those
parts
work.
A
Yeah
mock-ups
things
of
that
nature.
It's
a
good
point,
but
we
would
you
know
it
fits
in
with
the
it
would
require
quite
a
bit
of
preparation
to
make
a
group
conversation
make
sense
and
maybe
the
we
should
change
the
focus
of
it
to
be
less
about
refactoring
and
talk
less
about
what
the
changes
in
the
code
are.
A
But
talk
specifically
more
about
have
a
workshop
on
how
the
data
tracker
can
help
you
better
and
bring
some
of
these
questions
like
do
we
want
to
more
carefully
start
tracking
on
contributor
affiliation,
I'm
going
to
say
we're
away
from
the
word
author,
even
though
that's
what's
in
the
in
the
in
the
thing
right,
but
this
is
a
conversation
that
we
could
have
with
the
community
to
find
out.
You
know
how,
if
there's
institutions
or
what
we
would
would
gain
out
of
having
a
better
sense
of.
A
A
A
Do
we
want
people
to
land
on
a
metadata
page,
which
is
really
what
the
rfc
editor
has
been
pushing
for,
or
do
we
want
our
search
when,
when
people
are
just
walking
up
to
the
system
and
trying
to
find
something,
do
we
give
them
the
content
of
the
document
so
a
if
this
were
held
in
a
workshop?
It
would
be
kind
of
like
a
you
know,.
A
E
A
E
C
C
So
yeah
they.
So
I
think
I
I'd
slightly
disagree
with
robert.
I
think
we
might
have
to
do
the
two
separately
here,
because
I
think
that
the
rfc
editor
one
changes
to
that.
We
still
need
to
understand
what
role
the
rswg
will
have
in
that.
You
know.
That's
been
discussed
through
the
rs
editor
future
program,
where
the
some
of
us
have
been
trying
to
limit
it
to
setting
principles
and
strategy
for
the
how
that
website
should
work,
not
choosing
the
colors,
you
know,
but
we
I
think
we
need
to
go
through
that
process.
C
You
know
if
we
wanted
to
so,
but
in
both
cases
I
think
we
we
really
ought
to
consider
trying
to
lose
this
dichotomy
between
a
a
la.
You
know
a
metadata
landing
page
and
a
content
page
and
try
to
consider
a
design.
That's
so
you
know
solves
people's
tasks.
They
want,
which
is
a
c
vote
yeah.
We
would.
E
It's
a
quick
segue,
but
we
would
probably
also
want
to
have
some
high
level
ideas
from
this
ux
people
for
the
data
tracker
because,
like
what
carson
talked
about
right,
this
different
ways
of
getting
notifications,
but
just
I
mean
data
tracker's
like
organically
grown
over
decades
and
and
there's
no
unified
methodology
to
to
anything
really
right.
It's
basically,
some
pages
are
new.
C
E
Yeah
to
say
something
positive
though
I
do
like
the
the
the
blob
storage
right
I
mean
our
our
most
of
our
materials
are
like
we.
We
turn
them
into
key
value
things
right,
so
it's
a
natural
way
to
store
that
right,
everything,
nothing
ever
changes.
We
just
create
new
versions
right.
So
this
is
exactly
what
a
key
value
is
good
at.
A
A
D
A
G
Almost
30
minutes
sorry
robert.
This
is
alice.
I
just
want
to
go
back
to
what
lars
said,
so
the
to
clarify
two
points-
one
is
the
html
for
rfcs
of
the
v3
era,
does
use
javascript
to
put
the
metadata
header
at
the
top,
the
gray
box
header,
and
there
is
some
change
to
to
making
the
html.
You
know
desire
to
make
that
html
version
be
more
prominent,
and
I
no
one
that
I
know
of
at
the
rfc
production
center
has
a
strong
tie
to
having
the
metadata
page
be
the
landing
page.
G
But
that
was
the
outcome
of
a
long
discussion
regarding.
Do
I
have
what
the
doi
resolves
to
and
if
the
doi
resolves
to
metadata
at
the
top,
an
html
version
of
the
rfc
at
the
bottom,
that
we
have
no
strong
feelings
against
that,
but
there
has
been,
as
you
know,
multiple
discussions
about
whether
whether
to
go
forward
in
that
way,
the
google
scholar
indexing
improvements
are
pointing
to
the
html
file
itself,
not
the
metadata
page.
G
But
the
I
I
agree
with
you
that
there
there's
some
modernization
to
be
also
the
concept
of
how
the
metadata
is
displayed
on
a
v3
era.
Html
rfc
is
different
than
how
metadata
is
displayed
on
a
old
one.
So
I
I
like
the
idea
of
including
rfc
editor,
although
I
see
jay's
point
about
the
role
of
the
rswg
in
the
future,
but
I
I
think
the
workshop
has
more
value
when
it
includes
rfcs,
as
well
as
ideas.
E
Yeah,
I
agree
and
sorry
I
didn't
mean
to
imply
that
the
rpc
was
somehow
like
you
know,
holding
us
back
or
had
opinions
that
were
like
outdated
or
something
I
actually.
I
tried
to
like
john
levine,
specifically
where
it
seemed
pretty
pretty
opposed
to
the
idea
to
move
away
from
the
landing
page.
I
think
it
was
actually.
A
Next
on,
our
list
is
a
workshop
about
how
people
are
using
our
mail
list
archive
interfaces,
the
mailart.ietf,
mailarchive.iatf.org
and
imap,
and
how
they
interact
with
subscriptions.
This
would
be
the
place
where
we
would
further
refine
the
suggestion
that
jay's
made
towards
moving
towards
an
integrated
interface
from
the
data
tracker
for
subscription
management
into
whatever
our
distribution
system
is.
C
Can
I
add
something
to
that
it
it?
It
strikes
me
as
odd
that
mail
archive
as
a
tool
is
doesn't
tell
you
anything
more
about
the
mailing
lists,
so
you
know
that
there
isn't
a
subscribe
to
the
mailing
list,
link
from
mail
archive
or
am
or
anything
else
there
so
as
well
as
the
subscription
management
stuff
that
I've
done
a
a
you
know,
a
design
for
in
order
for
us
to
think
through
it
not
not
to
intend
it
to
be
the
final
design.
C
I
I
it
would
be
useful
to
hear
people's
views
about
where
we
can
go
with
integrating
that
with
mail
archive
as
well.
You
know
whether
malaka
should
sit
alone
or
whether
it
should
be.
You
know
effectively
that
once
you
have
your
I'm
dealing
with
mail
tall,
you
get
archiving
and
management
and
description.
C
All
of
that
all
together-
and
the
second
question
I
have
is
to
understand
whether
we
should
aim
to
make
the
mail
archive
tool
more
than
just
a
mail
archive
tool,
but
also
have
the
java
logs
within
it
and
attempt
to
timeline
or
thread
those
so
that
you
can
see
you
know
the
messages
you
know
in
the
sequence
in
which
they
arrived
almost
across
those
things,
because,
quite
often,
I
think
people
are
having
sort
of
a
semi-real-time
conversation
across
jabber
and
email,
and
is
it
possible
for
us
to
help
people
unpick
that?
Historically.
D
D
The
subscription
part
I'm
skeptical
about,
because
the
search
assumes
that
you
want
to
search
a
whole
bunch
of
of
lists,
because
you
know
conversations
sometimes
migrate.
All
over
the
place.
We
just
had
one
that
must
have
gone.
You
know
from
the
coin
research
group
to
the
main
list
that
often
then
ended
up
over
in
the
ieb's
architecture
thread
anyway.
The
the
point
is
to
find
those
kinds
of
things
you
need
to
search
a
group
of
lists,
and
so
then,
when
you've
got
hits
on,
you
know
10
different
mail
lists.
A
A
So
I
think
I'm
hearing
interest
in
actually
the
the
this
one
is
resonating.
Having
a
conversation
about
the
way
people
use
and
interact
with
the
mail
system
is
something
that
is,
people
are
resonating
with
even
more
strongly
than
just
a
conversation
about.
You
know:
how
do
you
interact
with
the
data
tracker
and
want
to
make
your
interaction
with
the
data
tracker
better,
so
we'll
come
back
and
prioritize
these
in
a
minute.
The
next
one
on
this
list
is,
is
a
biggie.
E
So
I
think
everything
else
now
is
not
sort
of
related
so
much
to
how
a
participant
would
interact
with
the
system,
which
is
why
I
so
do
we
have
any.
We
don't
run
google
analytics
or
anything
else
on
the
data
tracker
or
mail
archive.
Do
we
so
do
we
have
any
usage
data
about
what
people
are
doing
on
this?
So
it
would
be
helpful
in
order
to
sort
of
decide
where
we
like
put
the
investment
for
these
things.
E
Okay,
I
think
it
would
be
good
to
have
some
idea
of
what
sort
of
the
the
most
common
usages
are,
so
that
we
can
sort
of
trade
off
whether
we
want
to-
and
you
know,
improve
some
of
those
versus
something
else.
Obviously,
it's
not
necessarily
going
to
help
us
with
like
deciding
on
new
functionality,
like
you
know,
zulet4
or
anything
else,
but
at
least
in
sort
of
in
terms
of
the.
What
do
we
do
about
the
stuff
that
we
already
offer,
but
we
want
to
offer
it
in
different
ways.
E
I
think
that
might
be
helpful
like,
for
example,
when
it
comes
to
html
there's
other
formats,
if
we
knew
him
from
ymca.org
right
click
rates
right.
Does
anybody
on
the
landing
page?
What
do
they
click
on,
or
does
it
and
then
even
very
coarse-grained
statistics
like
for
male
archive?
I
guess
you
don't
have
to
be
signed
in
so
we
don't.
It
would
be
useful
to
know
like
which
fraction
of
the
really
even
uses
it
right
and
if
they
use
it,
what
do
they
use
it
for?
E
C
E
We
use
it
yeah
so
I'll.
Give
you
an
example
like
the
bootstrap
file
stuff
right,
so
we
have
in
the
data
tracker.
It's
the
search
functionality
on
the
on
the
landing
page,
there's
also
a
search
thing
in
the
top
menu
bar
and
then
there's
the
pull-down,
where
you
can
search
for
like
all
kinds
of
complicated
queries
and-
and
it's
not
fully
clear
to
me
like.
What's
what
is
used
at
what
to
what
degree
right
so
is
it?
E
E
I
I
I
don't
know
if
it
would
be
useful
for
everybody
to
understand
the
details
here,
but
I
think
it
would
be
enough
to
know
that
we
have
some
data
and
if
I
have
a
question
like
this,
I
can
go
and
ask
like
you
guys,
and
you
can
tell
me
or
you
can
tell
me,
we
don't
have
that
data.
But
I
I
don't
know
if
everybody
needs
to
understand
what
is
there
and
how
to
query
it
and
all
that.
C
E
C
A
A
They
had
data
feeds
from
all
of
our
properties
that,
with
an
interface
on
top
of
it,
that
would
let
you
quickly
find
likely
relevant
stuff.
Get
you
into
the
right
application
to
find
more
details
and
then
using
these
things,
using
something
like
that
or
whether
you
had
it
or
not.
Putting
a
lot
of
effort
into
tuning
how
the
engines
are
interacting
with
us,
so
that
when
people
are
using
the
external
search
mechanisms,
they
land
on
more
relevant.
A
E
I
think
it's
good
topics,
I
don't
know
if
it's
one
workshop,
because
search
and
seo
are
two
different
things
right.
One
is
used
like
how
do
you
optimize
for
an
external
search
that
indexes
your
your
stuff
and
the
other
one
is.
How
do
you
search
provide
search
internally
to
our
applications
and
there's
not
obviously
to
me
like
a
whole
connection
between
us,
but
I
might
be
wrong.
A
We
do
want
to
move
to
a
world
where
we
have
better
reproducibility
of
the
things
that
we're
deploying.
We
have
better
insight
into
how
the
things
that
are
deployed
or
running
the
ability
to
scale
horizontally
when
we
need
to
scale
without
necessarily
having
to
have
a
lot
of
of
manual
intervention
in
this,
and
we
have
been
accruing
a
set
of
things
that
we
have
been
asking
ams
to
do.
A
That
needs
to
be
informed
by
a
better
vision
for
where
we
want
to
land,
and
we
need
to
have
a
clear
set
of
goals,
a
a
clear
pattern
that
we're
moving
forward
for
the
way
we
evolve,
our
our
our
infrastructure
services
over
over
the
next
couple
of
years,
and
we
really
need
to
develop
this
clear
picture.
As
early
as
we
can.
A
To
talk
about,
what's
worked
well
for
them,
what
technologies
that
we
might
want
to
use?
What
are
better
strategies
for
using
external
services
might
look
like
I'm
envisioning,
somebody
that
has
started
to
make
really
good
use
of
of
ansible
to
come
in
and
talk
about
what
the
challenges
are
when
you,
when,
when
you
you're
making
a
transformation
into
a
system,
that's
that's
using
ansible
as
a
primary
tool
for
its
automation.
A
E
C
So
if
I
could
add
just
so
that
people
haven't
read
the
the
the
notes
that
well
so
we,
this
is,
we've
put
ams
and
glenn,
or
you
know
through
through
that
effectively
on
notice
to
say
that
we
want
to
change
the
nature
of
the
contract
we
have
with
them
from
a
black
box
contract
to
a
contract
where
the
community
has
much
more
say
in
specifying
the
nature
of
this
of
the
service.
That's
provided
the
three
key
areas
that
we've
identified
there.
C
Basically,
the
virtualization
strategy,
the
build
strategy
and
the
monitoring
strategy
are
all
three
key
areas
where
there's
been
a
lot
of
feedback
from
people
or
are
either
from
the
community
or
from
internally
within
the
various
teams
about
people
who
integrate.
Who
interact
with
these
things
that
that's,
where
they'd
like
to
see
some
significant
changes.
So
this
is
something
that
we
some
of
this
direction
is
already
set.
To
be
blunt,
you
know
it.
We
are
going
to
move
towards
automated
proper,
build
using
build
languages
and
that
kind
of
stuff.
C
The
question
is,
you
know
how
which
ones?
How
does
that
do
we?
Do
we
end
up
with
everything
you
know
all
the
build
scripts
stored
in
github
that
that
sort
of
stuff
we
are
going
to
end
up
with
a
different
monitoring
solution?
The
question
is
you
know
what
standards
do
we
use?
How
do
we
do
that?
What
access
do
people
have
to
it,
those
sort
of
things
and
we
are
going
to
end
up
with
a
different
virtualization
strategy
and
the
question:
is
you
know
that?
A
A
A
A
A
D
A
C
F
Yeah,
I'm
I'm
pretty
happy
if
the
tools
team
can
do
their
work
so
whenever
such
a
workshop
becomes
an
opportunity
for
people
to
to
meddle
with
stuff
and
and
make
stuff
more
complicated,
that's
a
problem.
I
think
that
has
been
said
before
in
this
meeting.
So
I
think
we
have
to
be
a
little
bit
selective.
So
I'm
I
I
can
imagine
having
a
workshop
about
I.t
strategy,
but
it
should
be
pretty
selective
in.
F
F
C
Okay,
thank
you
so
to
robert,
maybe
for
some
of
these,
such
as
the
infrastructure
one.
We
could
have
a
project
team
and
open
project
meetings
that
the
anyone
from
the
community
can
join,
but
we
don't
need
to
go
through
with
a
specific
workshop.
In
order
to
do
that,
we
just
you
know,
started
as
a
project
and
we
obviously
tried
to
bring
in
those
people
with
this
expertise,
some
of
the
not
people,
those
sort
of
thing
so
that
they're
there,
but
otherwise
we
potentially
try
it
that
way.
F
C
A
A
H
Just
wanted
to
kind
of
keep
an
eye
on
what
you
guys
were
talking
about.
I've
voiced
my
things
I
would
like
to
see
on
the
mailing
list
a
few
times,
but
they
aren't
generally
things.
People
want
or
don't
seem
to
be
things.
People
want
so
like
archiving
of
the
meetings
in
in
separate
streams
that
can
be
recombined
and
things.
H
F
I
think
that's
a
pretty
pretty
interesting
input.
So
just
remember
that
I
wanted
to
say
that
I
do
much
of
my
work
by
simply
pulling
all
the
gigabytes
I
can
get
out
of
the
ietf
system
and
doing
things
locally
on
my
laptop,
which
kind
of
works
for
me.
But
maybe
it's
not
a
strategy
that
everyone
wants
to
go
after.
H
H
A
So
I
think
from
the
discussion
that
we've
had
we've
decided
that
we
would
take
the
infrastructure
services
conversation
through
a
different
tracking
workshops.
Then
we
go
find
a
a
team
to
work
this
and
start
working
it
iterative
on
on
a
separate
track
and
what
we're
doing,
with
with
the
workshops
in
general,.