►
From YouTube: IETF-TOOLS-20220412-1800
Description
TOOLS meeting session at IETF
2022/04/12 1800
https://datatracker.ietf.org/meeting//proceedings/
B
A
C
A
D
E
G
D
G
A
A
A
We'll
skip
the
deployment
of
the
production
server
until
glenn
has
a
chance
to
join
for
moving
the
rest
of
the
services
off
of
tools.itf.org
and
redirecting
it.
We
did
set
up
a
temporary
bap
service
so
that
the
rpc
has
something
that
they
can
use
until
the
functionality
about
can
be
integrated
into
author
tools.
A
A
A
A
There
are
actions
in
those
repositories
that
go
feed
from
the
canonical
sources
and
make
both
relative
formatted
entities
and
bibx
web
xml
formatted
entities
that
just
live
in
those
repositories
and
the
web
service
feeds
from
those
caching
as
it
needs
to.
So
when
it
comes
up
from
scratch,
it
just
goes
and
gets
things
from
those
repositories.
A
A
Important
connotation
is
that
our
service
will
fundamentally,
at
this
point,
rely
on
github
so
as
part
of,
if
part
of
its
running
now,
if
we
ever
need
to
move
away
from
that,
it
would
just
be
a
matter
of
putting
those
things
in
a
get
repository
somewhere
and
changing.
What's
currently
in
those
github
actions
to
be
cron
running
somewhere.
So
there's
a
it's.
It's
not
a
a
difficult
thing
that
we're
being
locked
into,
but
I
wanted
everyone
to
be
aware
that
it
existed.
A
C
A
H
A
C
A
Again,
that's
great,
which
is
going
to
be
good
for
the
next
topic.
Yeah.
I
don't
see
glenn
still,
there's
a
question
about
whether
or
not
we're
doing
the
right
thing
with
our
api
design
at
author
tools
and
at
the
bib
xml
service.
We
designed
these
things
from
the
beginning
to
require
a
data
tracker
personal
api
key.
A
The
notion
behind
this
was
that
we
would
be
following
a
pattern
similar
to
what
cloudflare's
api
shield
follows
and
other
entities
that
are
are
protecting
apis,
that
you
have
a
an
allow
list.
You
know
basically,
a
a
somebody
comes
to
you
with
a
thing
that
says:
yes,
they
get
to
use
this,
and
the
api
key
was
what
we
were.
We
were
planning
to
use,
but
this
has
tension
with
the
apis
that
have
existed
in
the
past
at
places
like
xml
rfc.tools.itf.org
that
we're
just
free
to
use
by
anybody
anonymously.
A
To
get
what
we
would
want
out
of
it,
the
users
of
carson's
tool
would
have
to
go,
get
an
api
key
from
the
data
tracker
and
tell
the
tool
about
it
before
it
could
go.
Do
this
thing
and
carson
has
said
several
times
that
the
that
introduces
too
much
impedance
too
much
trouble
for
the
user,
and
he
doesn't
want
to
take
it
down
that
path.
A
One
of
the
things
that
alternatives
that
we
discussed
was
creating
a
key
just
for
the
application,
but
by
the
nature
of
the
application
that
key
would
be
accessible
to
anybody
that
bothered
to
look
at
which
point
we
shouldn't.
We
don't
have
any
advantage
for
having
keys
at
all,
because
random
robot
could
go
grab
that
key
and
start
doing.
H
A
So
the
question
is:
do
we
stay
on
the
path
that
we're
on
right
now
and
try
to
find
some
other
way
for
tools
like
kdrsc
to
get
the
kind
of
access
that
they
that
they
need,
or
do
we
back
off
of
the
position
that
we
want
this
positive
identification
kind
of
mechanic
and
just
open
the
apis
for
use
and
then
make
changes
later?
If
we
ever
actually
see
abuse
jay
go
ahead,
please.
D
Thanks,
isn't
the
impedance
not
in
having
a
key
and
getting
a
key,
but
in
the
process
by
which
one
gets
a
key,
you
know.
So
if
getting
a
key
is
trivial,
then
there
is
very
limited
impedance.
But
if
getting
a
key
is
complex
and
you
know
requires
multiple
email
round
trips,
all
that
kind
of
stuff,
then
it
is
then
that's
where
the
impedance
is.
A
D
C
Yeah
that
certainly
can
be
done
now
before
we
go
down
that
red
hole.
The
question
really
is:
do
we
need
this
api
key
right
now?
The
web
interface
for
author
tools
actually
uses
a
second
api
that
doesn't
need
an
api
key
and
of
course
I
can
simply
use
that
second
api
for
for
the
cardi
rc
access,
and
then
I
don't
need
an
api
key.
It's
not
apparently
not
a
published
api,
but
it's
not
hard
to
reverse
engineering,
and
I
did
it
so
do
we
really
need
that?
A
E
A
If
abuse
ever
appeared
by
requiring
these
api
keys,
is
there
a
fundamental
objection
to
just
falling
back
to
where
we
were
and
saying
you
know,
this
is
an
open
resource
that
anybody
can
use
we're
just
providing
free
compute
for
the
these
translation
services
in
the
in
the
case
of
author
tools
and
wait
and
deal
with
it.
If
it
turns
out
that
it
is,
you
know
something
that
gets
abused.
F
F
C
A
A
D
H
D
J
D
A
B
D
A
J
A
As
you've
seen
the
completed
projects,
the
svn
track,
migration
is
complete.
We
still
have
some
track
out
there
for
people
that
have
just
been
using
the
wikis
that
we
plan
to
have
a
crowd-sourced
migration
into
wikijs.
That's
waiting
for
us
to
finish
the
data
tracker
wikijs
integration,
which
is
behind
many
of
the
other
things
we're
going
to
be
talking
about
later,
in
the
call
I'm
bringing
it
up
here
so
that
we,
you
know,
know
that
it's
still
on
our
plan,
but
we
haven't
gotten
cycles
to
it.
Yet.
A
A
This
is
going
to
impact
the
people
that
have
automated
tooling
for
submission
to
the
draft
submission
api,
martin
thompson's
repositories
in
particular,
and
I
have
yet
to
reach
him.
But
I
need
to
coordinate
with
him
on
on
the
when
in
the
how
of
the
change
that
we
make
to
that
api,
so
that
these
submissions
can
succeed
when
the
processing
that
is
required
to
complete
them
is
longer
than
the
timeout
that
cloudflare
enforces
on
us.
A
I
have,
in
the
meantime
a
workaround
we
tested
this
with
john
yesterday.
If
you
just
hear
of
anybody
that
is
having
trouble
submitting
a
draft
because
it's
large
and
this
time
out
is
hitting
them.
The
answer
will
be
to
send
them
to
the
manual
submission
process,
and
I
will
teach
the
secretariat
a
way
to
go
around
the
proxies
to
to
do
these
submissions.
A
A
So
if
we
follow
through
with
what
I'm
hoping
we
can
do
later
this
week
or
early
next,
we
will
actually
shift
the
production
data
tracker
to
the
bootstrap
5
styling
and
then
everybody
will
be
shocked
and
will
get
rage
and
violence
because
of
the
surprise,
even
though
we've
tried
to
warn
people
about
this
for
a
while,
unless
anybody
has
concerns
we're
going
to
continue
down
this
push,
I
don't
know
if
we
should
signal
this
in
any
way.
At
the
moment
I
could
send
another
note
to
chairs.
A
I
E
The
domain
those
release
on
articles
this
week
and
the
big
change
was,
I
had
to
temporarily
remove,
go
sk2
because
that
tool
had
a
change
after
a
year
or
so,
and
that
change
break
lots
of
things,
and
I
don't
think
that
the
people
who's
developing
that
tool
is
going
to
move
forward
with
the
tool
they
are
suggesting.
Few
folks
and
some
of
those
folks
don't
use
that
tool
as
a
command
rather
than
a
module.
E
C
C
E
E
Under
the
hood
on
itf
servers,
we
can
look
into
automated
so
because
it's
not
going
to
be
a
big
change
to
update
cram
down
on
autotune
side.
So,
but
I
I'll
keep
right
now,
I'm
I
am
doing
manual
releases,
so
I
will
keep
an
eye
on
cram
down
for
changes
and
yeah
try
to
match
that
face,
at
least
with
the
version
updates.
C
E
A
A
A
A
A
Zdx
security
is
standing
by
waiting
for
us
to
complete
the
transition
to
the
new
server
before
they
start
in
on
testing
the
remaining
set
of
the
web
services
and
re-testing.
The
data
tracker
they're,
currently
on
we're
currently
on
their
schedule
for
mid-may
to
mid-june
and
they're
willing
to
adjust,
should
our
transition
to
the
new
server
need
to
take
longer
than
it's
currently
taking
I'm
going
to
skip
forward
to
the
rc
model.
A
Rc
editor
model
transition
based
on
conversations
I've
had
with
various
stakeholders
the
need
to
have
support
for
the
new
model
and
the
data
tracker
is
expected
to
come
in
sometime
around
mid-may.
So
we
are
waiting
to
make
those
changes
until
we
are
post
new
server
deployment
and
on
the
bootstrap
5
branch
as
well.
A
A
I
A
A
L
Yeah
I
didn't
want
to
get
in
the
way,
so
the
real
question
was
right:
now
you
guys
have
only
one
mx
record
for
ietf.org
and
I've
always
wondered
why?
But
you
know
you
might
consider
just
as
a
fallback
adding
an
mx
for
a
short
period
of
time
through
an
outsourced.
You
know,
agency,
there's,
certainly
plenty
that
could
do
it.
I'm
sure.
There's
probably
you
know
companies
within
the
ietf.
F
A
So
my
opening
volley
for
when
we
do
this,
assuming
that
our
testing
between
now
and
then
doesn't
show
a
reason
for
us
not
to
is
during
the
work
week
on
monday
morning,
pacific
time
april,
25th,
so
that
we
can
have
the
right
hands
available
to
assist
with
any
baubles.
If
there
are
bubbles
along
the
way.
A
A
I'm
hoping
that
as
we
go
through
the
next
steps
after
this
one,
that
this
will
be
our
last
multi-service
outage?
We
have
one
more
data
tracker
outage
that
is
going
to
be
big,
but
this
would
be
the
last
time
that
we
have.
You
know
the
issue
with
everything
going
away,
because
we're
we're
messing
with
the
infrastructure
under
it.
F
A
This
is
not
as
easy
to
do
with
the
data
tracker
most
of
the
data
tracker
users
are
logged
in,
and
we
have
cloud
for
necessarily
configured
to
not
cache
most
of
the
data
tracker
pages
for
anybody
that
is
logged
in
right,
so
they
wouldn't
have
anything
to
serve
to
those
people.
If
they
logged
out,
we
could
probably
configure
it
to
to
have
something
available
for
people
that
are
just
attempting
to
browse,
but
it's
a
it's.
It's
a
hit
or
miss
kind
of
experience.
A
So
if
people
are
on
board
with
this,
I
did
and
I
will
get
together
with
greg.
Oh
there,
you
are
sorry,
I
lost
your
image.
This
is
the
kind
of
message
that
maybe
we
should
send
out
super
visibly
with
the
a
you
know,
things
going
to
be
disrupted
and
we
should
probably
send
it
out
today,
because
that
is
less
than
two
weeks
from
now
today
or
tomorrow.
If
today
is
too
crazy,
but.
A
F
I
don't
understand
your
question,
so
we
are
doing
migration
right.
So
typically,
when
you
do
migration,
you
pull
down.
We
have
two
servers,
one
active
one
standby
or
whatever
you
put
the
standby.
You
migrate
this
and
then
you
switch
the
role
and
that's
if
you
have
good
synchronization,
that's
very
easy.
It
should
be
really
easy.
A
Yes,
we
we
essentially
had
that.
I
just
realized
that
I
had
intended
to
have
a
link
for
the
plan
that
glenn
had
put
together
available
for
you
to
to
see.
I
will
send
that
on
to
tools
development
shortly,
so
that
you
can
skim
through
what
what
we're
planning
to
do
but
yeah
we
have
ietfa
and
itfn
they're,
separate
machines,
and
the
basic
plan
is,
as
you
described.
There
will
be
a
point
where
some
services
on
atfa
are
stopped.
A
There
is
a
final
replication
step
from
itfa
to
iatfn.
Then
certain
services
like
making
the
mysql
database
master
on
ietfn
will
happen,
and
services
will
come
up
on
ietf
in
if
the
services
were
architected
a
little
bit
differently.
We
could
do
this
where
the
cut
over
time
was
instantaneous,
but
some
of
them
are
not,
and
the
dependencies
as
we
understand
them
on
the
male
processing
chain
in
particular,
are
such
that
we
need
to
have
the
male
q
quiescent.