►
From YouTube: SIDROPS WG Interim Meeting, 2020-10-01
Description
SIDROPS WG Interim Meeting, 2020-10-01
A
Okay,
cool
all
right
so
for
the
people
that
are
already
here,
it's
it's
start
time
of
meeting
10
o'clock,
my
time,
something
horribly
late
for
natalie
and
horribly
early
for
the
k
years
of
the
world
and
super
bad
for
anybody
in
asia
packet.
I'm
sorry
about
that.
But
this
is
the
spider
ops
interim
meeting
from
october
1st
I'm
going
to
do
all
the
presenting
there'll,
be
some
question
discussion
time
at
the
end,
there's
an
uncomfortable
part
in
the
middle
and
k.
Ura
is
going
to
take
some
notes.
A
If
you
have
questions,
there's
a
chat
in
the
webex.
Please
use
that
to
signal
that
you
have
a
question
and
I'll
be
happy
to
entertain
questions
or
comments
during
my
uncomfortable
speaking
part.
So
the
note
well,
the
slides
are
posted,
so
these
are
too
small.
My
recommendation
is:
go
to
the
agenda
or
go
to
the
meetings
thing
download
the
meeting
materials
and
just
follow
along.
A
B
A
Don't
really
have
any
administrivia,
we
don't
really
have
any
agenda
bashing.
We're
gonna
go
right
to
the
uncomfortable
part
about
discussions
during
the
on
the
mailing
list
and
during
the
meetings
I
think
it
seems
like
we
need
a
reminder.
Everyone
needs
a
reminder
once
in
a
while.
I
had
one
to
myself
yesterday
that
the
people
involved
in
this
work
in
this
conversation
they're
been
doing
this
for
a
long
time
with
the
sole
purpose
to
improve
the
security
of
the
internet.
We're
not
here
trying
to
advantage
ourselves
or
disadvantage
others.
A
Our
whole
point
is
to
make
the
internet
better
safer
at
the
least,
and
because
of
that,
we
need
to
continually
remind
ourselves
when
we're
reading
somebody's
email
or
listening
to
them.
Talk
that
they're
they're,
not
the
problem.
The
problem
is
the
technical
problem
and
we
need
to
focus
on
the
technical
problems,
not
on
the
personalities
and
and
and
the
people,
and
we
need
to
be
able
to
step
back
from
the
peoples
and
say:
okay,
I
understand
there's
a
technical
problem.
A
Whenever
discussions
get
into
you
sort
of
sniping
at
people
or
or
assuming
that
people
are
trying
to
do
the
wrong
thing,
I
think
we
all
end
up.
You
know
rat
holding
on
that
part
of
the
problem
and
not
on
the
technical
part
of
the
problem
or
discussion,
and
we
should
keep
that
in
mind
as
people
in
discussion
that
we
need
to
not
rat
hole
in
the
wrong
thing.
We
have
a
lot
of
other
things.
We
need
to
discuss
mostly
technical
details
and
operations,
things.
Why
don't
we
stick
to
that?
Please.
A
I
also
understand
that
at
times
the
ietf
process
can
be
very
long,
very
slow
or
at
least
seemed
that
way,
and
you
know
I
there's
some
good
parts,
it's
the
bad
parts
of
that.
It's
bad,
that
it
takes
us
a
long
time
to
get
anything
done.
It's
good
that
we
spend
a
lot
of
time
discussing
and
finding
corner
cases
that
we
can
either
choose
to
deal
with
or
choose
to
accept
in
the
design.
So.
A
Second,
to
last
point
about:
please
please,
please,
your
working
mate
working
group
mates
are
here
to
improve
the
internet,
not
to
break
the
internet
or
break
the
process
or
break
you
or
or
cause
problems,
and
and
there
will
be
problems
with
all
the
things
we
run
in
ops.
We
run
into
and
find
problems
and
that's
our
job
to
find
those
raise
those
and
get
those
fixed,
in
particular
insider
ops.
It's
today
in
today's
space,
it's
you
know,
operating
at
scale.
A
A
A
A
We've
agreed
that
like
because
of
this
rigorous
because
of
this
rigor
that
there
are
some
people
who
are
gonna
fall
off
the
map
for
a
little
while
and
that's
okay,
they
fall
off,
they
fall
off
back
to
unknown.
Ideally,
there
are
some
cases.
I
think
one
of
tim's
points
in
his
email
that
I
skimmed
was.
A
There
are
some
places
where,
if
you're
a
subtended
ca
that,
if
you
fall
off
the
map,
you
don't
go
to
unknown.
You
go
to
invalid
and
that's
also
sad,
but
I
think
that's
something
that
we
have
to
be
willing
to
accept
or
we're
gonna
have
to
find
another
discussion
about
how
to
fix
that,
but
at
least
for
right
now.
That's
that's
sort
of
the
point.
There's
also
some
conversation
about
rolling
out
new
features
in
the
existing
ca
tree,
which
dr
kent
and
martin
and
I
think
tim
spent
much
time
discussing.
A
It
sounded
like
we
sort
of
want
to
acknowledge
in
the
biz
document.
Maybe
this
is
a
point
of
contention
as
well.
We
may
want
to
acknowledge
that,
like
it's
going
to
be
a
little
bit,
ticklish,
adding
something
new
and
or
we
should
add
something
new
by
by
you-
know
a
basic
process
like
x
or
pass
that
off
to
the
new
person
and
say
you're,
implementing
something
new
going
to
figure
out
how
to
fit
it
into
this
box.
I
don't
right
now.
I
don't
care
what
the
answer
to
that
is.
A
We
should
discuss
that
on
the
mailing
list,
a
little
bit
in
a
separate
thread
about
you
know.
How
should
we
deal
with
this
one
particular
topic
and
the
final
thing
I
think,
there's
some
push
in
the
original
design
work.
There
was
some
push
to
kind
of
like
make
sure
we
keep
everybody
in
this
game
as
we
go,
which
is
almost
in
my
mind.
Almost
like
microsoft
with
you
know,
mike
with
ms-dos
like.
Oh,
we
got
to
keep
massage
running
just
got
to
make
sure
all
these
things
are
still
compatible
backward
compatible
forever.
A
No,
I
think,
from
an
operations
perspective,
some
of
the
conversation
has
been,
people
need
to
upgrade
their
software
and
if
they
don't
they're,
going
to
get
left
behind
and
that's
fine
they're
not
as
secure
they're,
not
as
capable
they're
not
up
to
the
current
set
of
specific
specifications,
and
it's
something
that
we
have
to
agree
as
a
group
that
we're
willing
to
drop
the
hammer
on.
We
have
to
say
you
know
you
you're
gonna
have
a
year
to
get
yourself
updated.
A
A
Okay,
so
I
think
to
move
forward
there's
at
least
three
things
we
should
wish.
I
didn't
put
on
the
slide
and
I'm
sorry
for
that.
There's
three
things
we
should
discuss
in
separate
threads.
One
is
the
discussion
about
rigor
and
what
impact
that
may
have
there's
a
discussion
about.
You
know
how
do
we
add
new
features
to
the
rpki
if
we
have
to
and
the
third
one
is
agreement
that
we're
okay
with
dropping
people
who
don't
keep
their
software
updated
after
some
reasonable
period
of
time.
A
I
think
it
also
means
that
we're
putting
some
pressure
on
the
repository
and
maybe
the
ca
folks
and
by
consequence,
the
the
developers
of
software
to
provide
software
that
will
produce
this
rigorous
output,
and
it
may
not
be
the
case
today
that
that
happens,
but
it
should
be
our
goal
from
the
document
and
from
the
working
groups.
Thought
process
here
to
generate
a
more
rigorous
output
at
the
publication
point,
because
all
the
collectors
are
going
to
require
that
if
we
get
on
this
path,
I
guess
so.
A
I
I
think
I
have
two
questions
at
the
end
here,
which
maybe
steve
and
his
crew
came
all
over
for
a
bit,
and
the
working
group
should
well
over
the
first
one.
You
know
how
far
do
we
think
we
are
from
the
draft
being
finalized
enough
to
send
to
work
group
last
call
and
then
push
forward,
and
the
second
thing
is:
I
understand
that
the
editors
are
kind
of
doing
this
on
their
free
time,
while
they're
not
taking
pictures
of
birds
and
whatnot.
D
Not
you
know,
providing
the
usual
kind
of
backward
compatibility
that
I
agree
with.
You
doesn't
go
on
forever.
We
have
to
set
time
frames
for
it,
and
so,
if
you
feel
it's
critical
to
have
that
included
in
this
document,
then
there
needs
to
be
a
concrete
proposal,
not
just
suggestions
of
oh,
it
needs
to
be
available
because
I
think
there's
a
lot
of
discussion
about
how
that's
going
to
be
done
in
our
typical
incremental
and
mostly
backward
compatible
fashion.
D
I
will
observe
that
I
think
we
have
a
current
gap
in
making
this
work
properly,
because
the
ghostbusters
record
is
not
a
mandatory
object
and,
frankly,
I
think
it
should
be
mandatory,
because
if
we're
going
to
say
that
when
you
find
a
problem
during
a
fetch-
and
you
alert
an
operator
and
the
operator
is
expected
to
try
and
contact
the
people
responsible
to
get
them
to
fix
it.
Because
they've
discovered
there's
a
problem,
then
there
needs
to
be
a
ghostbusters
record
available
so
that
they
know
how
to
contact
the
folks
to
get
fixed.
D
So
I
think
this
has
been
an
oversight
on
our
part
and
we
should
take
some
action
to
make
ghostbusters
a
mandatory
publication
point
object
in
the
future
in
terms
of
my
commitment
to
continuing
to
edit
it.
Unfortunately,
due
to
the
pandemic,
my
bird
photography
options
have
been
flown
away.
Shall
we
say
for
the
entirety
of
this
year.
D
I'm
now
up
to
four
months
worth
of
cancelled
trips,
and
I
have
a
telecom
tomorrow
with
the
folks
at
lindblad
about
the
five-week
epic
antarctic
trip
which
they're
redoing,
because
they
think
that
new
zealand
won't
like
us.
At
the
end
and
won't
let
us
get
off
the
ship,
but
I
plan
to
make
up
for
that
next
year.
D
A
Okay,
so
I
I
think
before
the
next
person
jumps
in,
if
there's
a
next
person
just
so
I'm
I'm
clear,
I
agree
that
there
isn't
a
concrete
upgrade
plan
where
our
addition
to
new
objects
plan
and
that
you're
proposing
that
we
need
to
either
decide
to
not
work
on
that
for
this
draft
or
we
need
to
have
somebody
propose
a
concrete
plan
that
we
could
agree
or
disagree
and
alter
that.
That
seems
fine
to
me.
A
Okay-
and
I
agree,
the
ghostbust
buster's
record
is
an
interesting
oversight
that
we
made
and
it
seems
useful,
I'm
in
the
general
sense,
adding
mandatory
things
to
the
to
the
publication
point
seems
fine
to
me
right
now,
like
it
from
the
from
the
perspective
of
this
draft
like
if
there's
something
we
should
add,
we
should.
We
should
certainly
do
that
and
if
there's
a
good
reason
to
do
it,
it
seems
like
it's
a
no-brainer,
so
that
seems
fine
and
documenting.
A
There
is
some
mention,
at
least
in
the
slide
deck
that
I
have
about.
You
know
we
need
to
mention
what
we
we
know
the
side
effects
of
this
are
going
to
be,
and
I
think
that
was
one
of
the
points
that
both
tim
and
martin
brought
up
was
that
you
know
hey,
you
guys,
know:
you're
gonna
break
some
people
here,
right,
yeah,
yeah,
that's
the
point.
A
We
know
we're
gonna
break
some
people
and
the
last
point
about
continuing
on
so
essentially,
maybe
until
december
you're
happy
to
to
truck
on,
but
but
at
december
we
need
to
either
be
done
or
hand
off
to
a
third
person,
and
that's
that's
fine.
I'm
just
making
sure
that
we're
that
that's
what
you're
saying.
A
C
D
C
So
maybe
we
can
follow
up
on
that
and
and
focus
on.
You
know
the
textbook,
because
all
in
all,
I
think,
there's
been
a
lot
of
discussion
on
this,
but
I
honestly
believe
that
in
the
end,
everybody
has
the
goal
of
making
everything
better,
just
as
you
said
quit.
So
I
think
if
we
keep
the
focus
on
that,
we
can
actually
move
things
forward.
A
Okay,
so
I
I
think
that
sounds
terrific.
By
the
way,
I
think,
can
we
either
I'll
I'll
start
a
new
thread
for
the
new.
You
know
how
to
introduce
a
new
type
into
the
process
and
a
new
thread
for
the
repercussions,
discussion
or
tim
or
steve-
could
do
that
too.
I
don't
really
care,
but
I'll
do
something
at
the
end
of
today.
If
there
isn't
something
end
of
my
day,
which
is
going
to
be
six
hours
from
now
or
eight
hours
from
now.
D
A
Okay,
so
I
mean
it
sounds
like
we
should
take
his
two
examples
and
and
put
those
into
the
discussion,
separate
discussion
and
say:
okay.
Well,
you
know
here's
some
examples
of
repercussions
and
where
do
these
cause
the
problem,
or
where
did
this
problem
come
from
like?
Is
this
because
we're
processing
the
manifest
when
we
toss
stuff
out
or
is
this
because
somebody
upstream
got
tossed
out
and
now
my
now,
my
subordinate
ca
is
lost
in
the
system?
A
E
I
couldn't
hear
you
you
started
talking
for
unmuted
anyway,
thanks
warren
kumari.
I
just
want
to
mention
that
if
we
do
do
anything
which
looks
like
a
breaking
change,
it's
not
just
us
that
needs
to
know.
We
should
make
sure
that
we,
you
know,
get
the
word
out
on
various
mailing
lists,
etc,
so
that
people
aren't
surprised.
It
would
be
sad
if
you
know
we're
not
surprised,
but
various
people
who
using
this
are
and
that's
a
fairly
obvious.
A
B
A
Well,
my
my
assumption
was
that
the
whole
discussion
about
new
objects
is
in
the
future.
Somebody
may
dream
up
a
new
thing:
how
are
they
going
to
jam
that
into
the
box?
So
we
already
know
what
aspa
is
kind
of
shapely.
We
we
sort
of
understand
a
little
bit
about
reap
there's.
Also
george
michelson
had
a
discussion
about.
I
forget
the
name
of
his
object,
but
the
separate
thing
that's
not
necessarily
dependent
upon
the
rpki
itself
just
uses
the
tas.
B
I
mean
to
ask
it's
not
necessary
that,
though
the
actual
details
that
the
technical
details
of
those
objects
have
to
be
finalized
before
this
draft
gets
published.
It
is
I'm
assuming
that
it
is
just
that
there
is
a
general
framework
that
is
built
into
document
which
enables
the
creation
of
these
new
articles
that
you
just
mentioned,
or
maybe
future
proposed
new
ones.
Am.
A
A
C
Can
I
please
plus
q,
but
so
I
want
to
comment
a
bit
on
the
invalidation
and
and
with
regards
to
new
object
types
section.
6.7
says
bill
fetches,
an
rp
does
not
require
a
current,
develop
manifest
or
does
not
acquire
current
valid
instances
of
all
of
the
objects
enumerated
in
the
current,
develop,
manifest,
etc.
Then
it's
a
field
fetched,
so
that
implies
that
all
the
objects
there
have
to
be
valid
and
validatable,
and
that's
why
new
object
types
would
create
an
issue
here.
C
Well,
then
they
would
create
something
that
has
resources
that
are
not
yet
known,
so
that
object
would
be
invalid,
so
you
have
one
invalid
object.
Therefore,
the
whole
thing
is
invalid,
and
so
hopefully
that
clarifies
a
bit
where
I'm
coming
from
here
and
what
I
meant
by
if
you
would
loosen
this
well
with
regards
to
new
object
types,
you
could
consider
whether
object
types
are
actually
orthogonal
to
the
thing
that
we
care
about
or
not.
C
We
can
have
that
discussion
later
again
and
it
probably
we
should,
but
hopefully
that
makes
it
a
bit
more
clear.
The
resource
transfers
unfortunately,
are
a
bit
of
a
hairy
problem.
I
would
like
to
pursue
updates
to
the
6492
protocol
so
that
a
child
ca
at
least
can
understand
before
a
resource
is
removed,
that
they
should
clean
up
in
an
automated
way
and,
similarly
that
they
can
understand
when
new
resources
will
be
safe
to
use.