►
From YouTube: IETF103-DISPATCH-20181105-0900
Description
DISPATCH meeting session at IETF103
2018/11/05 0900
https://datatracker.ietf.org/meeting/103/proceedings/
B
B
B
This
is
the
first
meeting.
This
is
the
note
well
statement.
You
need
to
understand
all
the
things
you're
agreeing
to.
If
you
get
up
and
speak
in
here
or
hang
out
in
here
in
general,
you
can
find
the
references
to
them
here
and
with
that
I
want
to
jump
into
a
little
bit
of
agenda
bash
before
we
hit
the
other
stuff.
So
we,
let's
see
get
over
to
the
agenda
here.
We
mistakenly
put
this
secret
token
URI
scheme
in
the
art
area
meeting
which
it
should
not
be.
B
It
should
be
at
the
dispatch
meeting,
so
we're
going
to
move
that
up
to
sort
of
up
to
the
front
with
the
HTTP
header
registration,
so
we'll
do
Mark's
two
drafts
first
and
then
move
on
to
the
the
other
part
of
the
agenda.
They
also
have
a
little
bit
of
open
mic
time
at
the
end
of
the
art
area.
Meeting
just
a
few
people
want
speak
to
any
other
agenda,
as
we
need
to
deal
with.
B
So
with
that
see,
if
there's
anything,
okay,
I
need
to
talk
about
deadlines,
so
this
is
our
proposed
deadlines
for
the
next
IETF
keep
in
mind.
We
do
these
deadlines
to
try
and
help
you
so
that
we
can,
you
know
better,
try
and
get
things
to
the
right
place
and
make
stuff
actually
happen
before
they're
submitted
at
the
very
last
minute.
B
We
have
two
mailing
lists:
one
for
dispatch;
okay,
that's
about
documents
need
to
go
somewhere
and
there's
also
the
art
area
lists.
It's
often
these
confused,
but
just
be
aware
that
there
are
the
two
mailing
lists.
So
with
that,
let
us
jump
into
one
of
marks
documents
which
one
do
you
want
to
do.
First,
mark,
let's
discuss
patterns.
B
D
D
So
right
now
we
record
our
header
fields
for
htdp
in
a
common
registry,
the
permanent
message,
header
field
names
registry.
We
also
have
a
provisional
message-
header
fields,
names
registry,
which
I
won't
talk
about
right
now,
but
in
that
registry
we
have
all
the
HTTP
headers
and
a
bunch
of
other
stuff
as
well,
and
that
was
defined
in
RFC
38,
64,
Graham,
kleine
drove
a
lot
of
that.
D
I
did
some
of
the
HTV
stuff
and
Jeff
Mogul
helped
out
as
well
way
back
in
2004
way
back,
and
so
in
that
registry
we've
got
HTTP
headers
we've
netnews,
which
is
n
MTP.
We've
got
mail
and
mime
I'm,
still
a
little
shady
about
the
distinction,
but
okay
and
we
do
not
have
SYP
SYP,
has
its
own
separate
message
head
of
registry
for
reasons
which
escaped
me
but
I'd
love
to
hear
about
so
I
raised
an
issue
in
the
HTV
working
group
a
while
back
we're
doing
the
HTTP
core
documents.
D
Revising
the
HTTP
core
specifications
yet
again
and
I
noticed
this,
and
it
had
been
bugging
me
for
a
while
that
the
HTTP
headers
were
mixed
up
in
this
other
registry,
which
had
a
couple
of
bad
effects
which
I'll
talk
about
in
a
minute.
So
I
raised
an
issue
and
we
discussed
it
in
Montreal,
and
the
feedback
in
the
room
was
yeah
probably
makes
sense
to
pull
this
out
into
a
separate
registry.
D
But
Alexi
pointed
out
that
we
needed
to
talk
to
a
greater
community
about
that,
because
that
registry
was
not
set
up
by
the
HTTP
working
group.
It
was
set
up
by
another
process
if
I
remember
correctly,
that
was
AD
sponsored,
but
I
could
be
misremembering.
Dispatch
didn't
exist
back
then,
but
dispatch
is
clearly
a
place
to
talk
about
this
now.
So
that's
why
I'm
here,
hello
and
so
I
put
together
a
strongman
draft
which
I
haven't
had
a
chance
to
submit.
D
Yet
this
is
not
what's
formally
being
proposed
in
the
HTTP
working
group,
and
it's
not
something
for
this
group
to
discuss,
but
it
does
talk
a
little
bit
about
the
motivation
for
why
we
want
to
pull
the
HTTP
headers
out
of
that
common
or
registry
into
their
own
registry
and
it's
beyond
things
like
just
making
it
easier
for
people
who
are
using
HTTP
to
look
through
this
huge
laundry
list
of
header
and
field
names
and
sort
out
which
one's
apply
to
HTTP.
There's.
Also
things
like
it's
it's
difficult
to
evolve
the
registration
process.
D
We
want
to
modernize
the
registration
process,
it's
a
lot
harder
to
coordinate
it
between
a
lot
of
different
communities
than
it
isn't
just
one
community
user
confusion
like
I
mentioned
the
extra
review
process.
That'd
be
nice
to
have
an
expert,
apply
the
HTTP
criteria
for
headers
and
all
the
considerations
that
we've
come
up
with,
which
are
quite
extensive
in
the
HP
documents
consistently
to
the
headers
and
to
make
sure
that
the
HP
community
is
a
perfectly
involved.
So
that's
my
motivation.
Alexi
asked
us
to
bring
it
to
dispatch.
E
So
I
was
actually
not
here
as
an
area
director
I'm
here
as
a
civil
war,
veteran
I
was
gonna.
Explain
you
asked
twice:
if
did
this
and
then
put
up
a
slide
that
I'm
looking
at
right
now
that
says
why
sip
did
this
and
yeah?
We
ran
through
the
same
analysis
and
I
think
you're
going
to
find
at
least
the
people
that
work
through.
All
that
agree
with
the
rationale
here
and
I
I
think
splitting
it
out
is
a
good
idea.
E
F
D
Not
my
problem,
we
would
leave
the
I
think.
The
idea
here
is
is
that
the
HTTP
header
registry
would
be
split
out,
and
the
current
registry
and
registration
procedures
for
the
other,
where
our
protocols
would
remain
the
same
if
those
communities
choose
to
revise
their
procedures
or
they
choose
to
get
together
and
revise
them
on
this,
that's
totally
up
to
them.
I.
F
G
Https
go
over
here.
This
is
Barry
liebe.
One
of
the
reasons
that
they
were,
let
that
they
were
put
together
in
the
first
place
was
to
make
sure
that
header
fields
that
had
similar
sense
were
commonly
defined,
but
they
kind
of
are.
But
do
you
have
any
sense
that
that
going
forward
as
the
registries
are
split,
we
would
try
to
keep
a
coordination
there
so
that
they
we
don't
wind
up
with
a
header
field
that
has
the
same
name
in
both
registries
but
a
vastly
different
function.
We
already
have
that
we.
D
D
No
one
in
practice,
no
one
goes
and
checks
to
make
sure
that
there's
not
a
conflicting
header
name
in
the
registry.
You
know
for
another
protocol
before
they
come
up
with
their
own.
It
just
doesn't
happen.
You
know.
No,
let
I
think
this
is
the
core
of
Alexie's
concern
is.
Is
that
he
likes
that
level
of
coordination?
I
think
we
can
certainly
come
up
with
tools
to
help.
You
have
a
common
view
of
all
the
registries
to
see
where
there's
overlap,
or
you
know
no.
G
E
H
E
H
Pete
Resnick
I
am
completely
okay
with
the
idea
of
doing
this
and
to
go
back
to
Barry's
point
about
keeping
coordination.
What
I
think
you're
doing
is
sort
of
reversing
the
priority.
The
the
current
registry
is
make
sure
they're
coordinated
and
then
we're
gonna
have
different
semantics
by
labeling
them
HTTP
or
something
else
we're
doing
it.
The
other
way
around
I
think
that's
fine,
but
I
do
think
at
some
point.
H
D
What
Alexa
and
I
have
talked
about
in
the
background
is
having
some
sort
of
alternate
view,
and
we
need
to
talk
to
Ann
about
this,
so
that
you
can
have
a
consolidated
view
of
all
the
registries
it.
But
my
observation
is:
is
the
audience
for
people
who
want
to
view
it?
Just
for
one
protocol
is
pretty
massive,
the
audience
of
people
who
want
to
view
the
consolidated
views
is
quite
small
and
most
were
in
this
room.
I
I
It
would
make
sense
to
simply
put
one
paragraph
in
HTTP
registry
registration
procedure
say
and
by
the
way
registry
and
the
common
headed
commentary.
If
you
need
to
cut
down
the
requirements
of
the
common
having
added
against
year
yeah,
someone
needs
to
be
able
to
fill
out
the
form.
Doesn't
that
would
be
no
big
deal
so
you're
saying
that
you
should
register
everything
twice
now
I'm
saying
that
part
of
the
procedure
of
register
registering
it
once
includes.
D
K
K
I
believe
you
and
the
other
thing
is
sort
of
a
meta
comment
and
Dave
Crocker
is
a
door
leaf
thing.
We
ran
into
a
similar
problem
that
the
you
are,
the
names
for
the
for
URI
record
resource
record
types
are
indirectly
defined
through
the
enum
services
registry.
You
know
and
and
the
URI
URI
expect
says:
well,
they
the
the
names
are
either
a
protocol
name
like
for
syrup
or
it's
a
service
name
from
enum
services.
K
You
know
and
we've
been
scratching
out,
you
know
and
it's
sort
of
and
since
neither
of
them
have
added
anything
in
the
past
decade.
The
overlap
problem
is
not
urgent,
but
I
think
this
is
now
the
fact
I,
but
that,
with
sort
of
the
same
week,
I'm
running
into
two
places
where
we
have
fewer
industries.
K
That
would
be
nice
just
to
coordinate,
to
the
extent
that
we
avoid
gratuitous
name
collisions
it's
like
I,
don't
want
to
necessarily
make
more
work
for
I
Anna,
since
they
will
cheerfully
do
whatever
we
ask
them
to
do,
including
you
know,
standing
on
their
heads
and
dancing,
but
I'm
going
to
do.
I'm
gonna
give
it
something
we
should
sort
of
think
about
in
general
about
having
coordinated
registries
because
it
comes
up
or
Newark
at
the
line
after
Johnson.
L
So
what
is
the
registration
look?
What
is
the
what,
if
we
have
the
term
the
rule
for
actually
this
expert
review
believe
so?
Yes,
so
the
VEX
pert
review
the
expert
view,
instructions
could
say,
make
sure
there
isn't
a
conflicting
header
and
one
of
the
other
things
or
at
least
figure
out.
Why
I
think
that's
reasonable
thing
for
expert
review,
because
the
expert
is
the
one
who
would
know
this?
Not
the
registered
person
would
do
the
registration
so.
D
L
Mean
I
think
the
expert
could
be
the
one
who
says
think
about
and
again
it's
not
must
not
it's.
The
expert
review
is
think
about
the
other
thing
to
push
back
against
the
the
registering
it
twice
thing:
we've
got
in
RTP
we've
got
a
dead
registry
of
RTP
payload
type
as
well
as
the
mime
types
registry
and
the
inferior
suppose
registering
things
twice,
but
nobody
does
so.
I
would
strongly
push
back
against
two
registries
because
they
will
get
out
of
sync
really
easily,
despite
I
Anna's
best
efforts.
B
So
I
have
not
actually
heard
a
single
person
speak
against
doing
this
idea.
I
think
that
we
can
dispatch
this
as
this
is
the
way
the
HTTP
group
should
proceed.
Any
objections
to
that
see
lots
of
thumbs
up.
Okay,
so
for
the
minutes,
we're
going
to
proceed
with
the
HTTP
should
check
out
at
the
roach
motel
and
do
whatever
it
is.
They
do.
D
D
So
I
have
a
draft
that
I
asked
to
be
dispatched.
This
is
just
me,
so
it
is
a
very
common
problem
out
there
and
there's
plenty
of
news
articles,
I
selected
a
fun
one
from
the
register
about
how
people
get
their
credentials
somehow
released
into
the
wild,
often
by
checking
them
into
a
repository
oops,
and
in
fact,
if
you
do
a
little
searching
around,
you
see
lots
of
evidence
of
people
who
have
realized
this
in
places
like
github
and
removing
their
authorization
tokens.
It's
actually
quite
a
widespread
problem.
D
There,
in
fact,
it
is
so
widespread
that
there
are
now
tools
that
people
have
come
up
with
to
find
tokens
and
repositories
and
remove
them
with
prejudice,
prejudice
and
indeed,
github
has
product
around
this,
and
this
is
really
interesting.
They
scan
for
tokens
in
repos
and
do
things
when
they
find
them
and
they've
identified
the
format's
of
several
common
tokens,
those
of
AWS
as
your
github
Google,
Cloud,
slack
and
stripe.
Of
course,
that's
not
the
only
people
on
the
planet
who
use
authentication
tokens
and
actually
before
that
announcement
came
out.
I
had
a
little.
D
I
said
what,
if
we
created
a
new
URI
scheme
for
access
tokens
and
then
github
refused
to
check
in
textual
content
that
contains
it
and
I
got
a
lot
of
interesting
responses
to
that
and
I
talked
to
a
few
people
in
history
and
they
said
hey,
we
actually
might
use
this
so
that
being
the
bar
for
hey,
let's
try
and
do
this
for
me.
I
brought
a
quick
draft
called
the
secret
token
your
eye
scheme.
It
is
very
simply
a
URI
scheme
that
I
did
some
sort
of
token
that
you
want
to
keep
secret.
D
It
has
a
very
permissive
syntax.
This
happens
to
the
user,
a
UUID.
There
are
plenty
of
other
things
you
can
stuff
into
it
and
that's
it.
That's
the
idea,
and
so
my
question
to
dispatch
is:
is
this
good
enough
to
try
I
think
this
sort
of
thing
is
in
the
class
that
it's
a
bit
chicken
and
egg
there's
interests
from
what
I've
seen
in
people
adopting
it?
D
I
talked
to
the
engineer
behind
the
github
token
scanning,
he
was
like
hi
I
hadn't,
seen
that
that
looks
interesting,
but
people
are
a
little
worried
of
actually
producing
and
using
or
scanning
for
tokens
in
this
format
until
it's
standardized
and
we
don't
want
to
standardize
it
without
any
evidence
of
use.
So
that's
the
chicken
in
the
egg
and.
D
G
G
B
Let's
just
take
a
second
to
go
back
that
for
John,
so
John
I
I
did
think
about
that
before
I
said
that
and
if
you
think
we
should,
we
will
review
these
these
minutes
on
the
list
as
always
and
and
go
over
that
decision.
But
my
thinking
was
that
where
this
decision
is
going
to
actually
be
made
is
in
the
draft
that
does
that
registry
and
that
draft
will
be
widely
reviewed.
B
All
we
were
really
doing
here
was
discussing
which
mailing
list
that
draft
was
going
to
be
discussed
on,
which
seems
more
of
an
administrative
level
thing
than
a
choice
of
think.
So
perhaps
we
made
the
wrong
choice
there
and
I'm
happy
to
correct
that.
Well,
we'll
go
we'll,
go
make
sure!
That's
that's
in
the
minutes
and
we
in
review
of
the
mailing
list,
but
that
that
was
what
was
going
through
my
head
when
I
said
those
words.
C
Being
able
to
search
for
things
easily
in
github
has
a
lot
of
value
and
I
work
at
I.
Can
some
of
you
know
that
we
just
rolled
the
root
KSK?
It
was
pointed
out
to
us
a
couple
months
before
the
role
that
there
were
a
bunch
of
a
bunch
of
repos
that
had
the
old
KSK
and
not
the
new,
what
KSK
in
them,
and
so
that
indicated-
oh,
maybe
they
didn't
know
to
update
and
we
mechanically
went
through
as
many
as
we
could
and
sent
issues.
C
You
know
like,
like
mechanically
sent
issues
to
a
lot
of
people.
Saying
don't
know
if
this
matters
or
whatever
we
got
a
lot
of
very
positive
response
back.
We
got
some
a
little
bit
of
negative
response.
We
got
a
lot
of
positive
response,
some
of
its
saying:
don't
worry
about
it!
No
one's
ever.
You
know
no
one
has
implemented,
but
some
people
going-
oh
wow,
you're
right.
C
So
something
like
this,
even
if
github
doesn't
prohibit
it,
but
just
being
able
to
mark
something
like
this,
so
that
white,
hats
or
grey
hats
can
find
it
our
our.
We
were
surprised.
We
thought
we
would
just
get
flamed
for
like
because
we
said
we
are
spamming.
This
issue,
you
know
like
no
human
typed,
this.
We
still
got
a
lot
of
very
positive
response
back
and
fixes.
M
Ten-Thirty,
this
seems
like
a
classic
case
where
making
it
provisional
and
upgrading
it.
If
we
see
see
use
would
be
exactly
in
line
with
the
way
that's
described
so
unless
you
feel
like
people
won't
take
it
up
because
they
don't
believe
in
Provisionals,
and
that's
certainly
not
my
experience.
I
would
say
that
would
be
the
way
to
go.
I.
A
B
E
B
I'm
gonna
make
our
proposal.
The
question
I'm
going
to
ask
in
a
minute
is
so
we
should
adjust
ad
sponsorship.
So
if
anybody
wants
to
say
that's
the
wrong
half
now
would
be
a
great
time
to
speak
to
that
and
we'll
let
Jonathan
go
to
speak
about
whatever
he
plan
to
see.
Yes,
so
I
was
gonna
ask
this
is.
L
A
sort
of
amusing
question
somebody
asked
in
the
jammer,
but
also
suppose
somebody
asked:
are
you
planning
to
have
this
draft
truck
checked
into
github?
You
know
more
generally
and
more
generally.
Presumably
your
code
for
scanning,
for
the
secret
token,
should
itself
be
checked
into
github.
So
is
there
a
way
to
say
this?
You
know
this
contains
the
string
secret
token,
because
I'm
documenting
how
your
name
your
secret
tokens,
but
it's
not
actually
a
token
so
that.
D
Sounds
like
a
user
experience
problem
which
we
don't
do
it
the
idea?
What
we'll
use
the
to
control
that
right,
I
think
I.
If
I
remember
correctly,
github,
doesn't
you
know
preclude
you
from
checking
it,
and
it
just
warns
you,
although
you
can
set
it
so
that
it
can
preclude
it,
I'm
sure
that
they've
thought
through
these
issues
and
have
adjusted
accordingly
I
hope
we
don't
need
to
deal
with
that
problem,
but
then
there's
encoding
we
could
just
encode
it
and
I
guess.
M
P
K
This
is,
this
is
a
topic
that
has
come
up
before
pretty
much.
Every
web
form
ever
written
accepts
an
email
address
and
it
is
pretty
common
to
verify
the
email
address
using
a
regular
expression
and
people
I
know
and
I
can
have
actually
hired
somebody
to
go
and
look
at
look
at
web
forms
and
like
the
electrical
extra
top
a
thousand
or
something
and
see
how
they
verify
and
the
email
addresses
and
pretty
much
without
exception.
They
use
some
random
regular
expression
that
some
guy
wrote.
We
didn't
actually
understand
that
understand,
mail,
syntax.
K
Sean
Leonard
and
some
other
people
sort
of
including
me
brought
up
some
actual
correct,
regular
expressions
for
for
the
match,
both
convince
key
email,
addresses
and
eai
email
addresses.
You
know,
which
are
actually
fairly
complicated
with
mail.
Syntax
is
complicated,
but
who
cares
you
know
you
just
plug
in
it?
So
our
goal
is
simple,
is
simply
to
first
get
them
reviewed
to
make
sure
they
actually
are
correct
and
then
publish
them
and
say
hey
instead
of
inventing
a
regular
expression.
Use
this
one
and
assuming
mark
is
still
in
the
room.
K
I'm
also
wondering
how
we
might
socialize
this
among
the
web
community,
where
it
actually
cares
we're
actually
matters
where
people
should
care.
You
know
so,
I
guess
I'm,
you
know,
I
mean
I.
Think
this
is,
you
know,
give
give
or
take
you
know
verifying
the
regular
Commission.
This
is
basically
done.
You
know
so
I'm
hoping
you
know,
I
hope
you
can
be
dispatched
directly
or
ad
sponsored
or
whatever
is
whatever
TV
is
well
I
know
you're
the
chair
yeah.
K
B
F
F
K
Agree
I
mean
I
personally,
I
wouldn't
be
opposed
to
having
you
know,
sort
of
a
cut-down
version.
That's
supposed
more
likely
more
likely
to
work.
You
know,
and
you
know,
with
Outlook
or
wherever
changes
I
think
even
a
lot
of
case
it
is.
Is
this
like?
It's
like
people
have
never
seen
a
plus
sign
and
an
address,
or
just
doesn't
accept
that
you
know
it's
it's
that
level
of
mistake
that
we're
trying
to
fix
yeah.
B
So
one
of
the
other
questions,
I
wonder
if
you
guys
thought
about
is
in
some
ways
a
an
RFC
is
like
the
least
useful
way
to
deliver
this
to
people
all
right.
I
agree:
we
sort
of
need
one
to
give
it
the
the
compound
of
that,
but
is
that
is
this?
Is
this
a
possibility
for
some
experimentation
with
tools
and
how
we
write
stuff
to
be
able
to
deliver
this
in
a
form,
that's
more
useful
for
developers
than
how
we
usually
give
stuff
to
I?
Don't.
K
Q
See
they're
hot
today
the
we've
had
a
few
other
graphs
come
by
where
the
nature
of
the
draft
is
here
is
an
implementation
that
we
believe
was
correct
of
how
to
do
a
certain
thing
to
meet
it
to
meet
the
standard
where
the
standard
is
something
else.
In
this
case,
a
standard
would
be
the
syntax
for
the
for
the
addresses
yeah
and
we
flip
those
to
the
ISE
I
I
don't
mean
that
to
mean
it's
not
valuable
or
anything
like
that.
It's
just
it's
been
more
of
a
well,
it's
not
really.
Q
K
You
are
absolutely
correct.
Like
the
week
you
know
these
addresses
are
spots,
that's
justified
at
a
B
in
a
B
and
F
and
when
they
suitably
brilliant,
compile
it,
which
you'll
be
able
to
translate
the
a
B
and
F
into
your
favorite.
Regular
expression.
Lactic
is
just
there.
Okay,
we
haven't,
and
a
B
and
F
is
I,
believe
the
a
BN
f
is
sufficiently
ambiguous
that
the
translation
is
kind
of
tricky.
E
O
E
O
And
so
tell
I
want
to
agree
with
John's
statement
that
you
know
the
the
relative
weight
that
being
an
RFC
carries,
makes
a
big
difference,
as
somebody
who
frequently
feels
like
he's
shouting
at
the
wind
for
wanting
to
use
addresses
with
plus
signs
in
them.
I
think
that
this
is
extremely
useful.
It's
not
the
only
approach
you
take,
but
it's
the
fallback
approach,
because
when
I
point
out
to
people
there
are
internet
standards
that
define
A+
is
being
perfectly
legitimate.
They're
like
okay.
O
But
how
do
I
code
that
and
if
they
want
to
use
regular
expressions
as
well,
you
know
show
an
IETF
sponsored
way
of.
This
is
how
you
go
about
and
do
it.
But
then
you
use
other
website
tools
to
you
know,
get
it
out
there
and
and
get
it
in
the
hold,
and
that
also
makes
me
wonder
why
not
you
know
why
did
it
have
to
be
part
of
a
working
group?
Why
not
just
maybe
sponsored
team
defensive
submission,
you
know
without
being
in
a
working
group,
I
don't
mean
I,
don't
just
make
it
clear.
R
R
K
I
F
K
L
L
K
P
B
P
E
Was
looking
to
see
if
this
actually
might
fit
an
extra
and
it
doesn't,
but
that
audience
is
also
present
in
that
room.
So
maybe
you
could
take
a
couple
of
minutes
to
mention
it.
There
I
mean
that's
supposed
to
be
about
mail
store,
is
not
about
forms
and
things,
but
that
audience
is.
There
is
what
I'm
getting
in.
P
B
About
this
is
a
proposed
step
path
forward.
The
people
who
comment
on
it.
Here's
a
straw-
man
is
eighty
sponsored,
but
when
the
when
the
ITF
last
call
is
done,
we
note
we
sinned.
We
make
sure
that
we
call
that
out
and
maybe
beforehand
call
it
out
in
every
working
group
that
defined
one
of
the
specs
that
these
regular.
That
drove
this
regular
expression
right,
though,
like
wherever
the
ABN
f,
was
defined
in
the
specification
that
nailed
these
things.
B
B
Okay,
so
will
propose
to
the
mailing
list
that
thickens
its
you
know
to
move
this
forward
as
ad
sponsored
as
forward.
Actually
we
don't
do
anything
on
that.
The
ad
just
does
it
so
I
think
we'll
take
that,
as
as
the
call,
if
that's
the
direction,
it's
gonna
go
unless
anyone
wants
to
speak
against
that.
E
B
E
It
goes
fine,
Adam
Roach,
so
the
web
RTC
documents,
the
last
ones
that
are
actually
dependencies
for
cluster
238,
have
all
been
publication.
Requested
I
have
my
area
directory
review
done
for
those
and
we're
waiting
for
some
relatively
small
updates
to
the
two
of
them
and
some
clarifications
and
a
third
one
that
we're
going
to
be
talking
about
in
WebRTC
in
the
RTC
web
working
group
on
Thursday.
E
G
E
Or
the
doing
the
ice
SDP
and
after
that,
the
whole
cluster
breaks
free.
So
we're
going
to
have
like
this
I
think
been
called
the
cluster
of
damocles
finally
drop
on
to
the
RFC
editor
sometime,
probably
this
quarter
or
first
quarter
of
next
year
and
there's
going
to
be
an
incredible
delay
and
publication
of
everything
else.
I
think
we're
in
have
like
20
consecutive
RFC
numbers
and
that's
I,
think
all
that
I
have
from
the
art
area.
That's
that's
kind
of
the
big
thing
going
on
right
now.
Q
C
C
It
rhymes
with
all
of
them.
If
you
were
at
the
first
woof,
would
walk
Boff.
You
would
know
that
we
already
made
that
joke.
So
if
you
were
at
the
first
boss,
which
was
a
year
two
years
ago,
we
we
basically
just
wanted
to
say
gee
working
groups
are
using
github.
What
does
that
mean
to
the
IETF?
And
there
is
lots
of
mic
line
and
such
like
that?
Q
C
Make
responsible
people
in
all
of
that?
So
that's
that's
part
of
what
the
boss
will
be
doing
this
week.
We
will
also
go,
go
back
and
revisit
the
issue
of
well.
What
should
working
groups
be
doing
or
not?
I
put
out
a
call
for
people
to,
because
we
have
plenty
of
open
mic
time
at
the
end,
to
say
what
their
working
group
is
doing
with
github.
That
is
interesting,
like
when
they've
noticed
that
other
people
aren't
doing
it
and
such
so
it'll
be
a
general
discussion.
Just
to
be
clear.
C
C
You
stepped
away
that
it's
Wednesday
at
150
right
so
yeah.
We
it's
so
funny
to
have
150,
be
immediately
after
lunch,
yeah,
so
yeah
please
come
by
and
if
you
and
we
have
a
mailing
list
already-
which
is
not
that
one
but
ask
me
afterwards,
but
we
we
want
to
help
working
groups
and
we're
not
sure
what
that
means
so
come
on
by.
E
K
K
Let
me
say
make
do
with
this
any
couldn't
a
coherent
sentence,
although
SPF
the
specification
of
SPF
says
nothing
about
how
it
works
in
the
presence
of
EI,
IMail,
D,
Kim
and
D
mark
sort
of
waved
our
hands,
don't
get
it
quite
right.
So
this
is
a
short
update
for
each
of
these.
Each
of
these
three
things
to
say,
if
you
are
doing
an
SPF
check
on
a
dependent,
ei
iMessage,
do
it
this
way
if
you
are
doing
D,
Kim,
signing
and
verification
on
ei
iMessages.
K
Do
it
this
way
and
if
you're
doing
what
D
mark
does
on
here,
I
messages.
Do
it
this
way
and
I've
actually
implemented
the
SPF
and
DKIM
things
there?
What
pretty
straightforward?
Is
it
basically
anywhere
that
you
can
have
a
normal
FDA
label?
You
can
now
also
have
a
you
label
and
it
clarifies
things
that,
like
in
the
SP
SPF
records
themselves
and
the
deccan
validation
records,
since
they
live
in
the
dns
and
can
be
used
to
validate
anything,
they
don't
actually
have
any
e
aí
stuff
in
them.
They
just
have
a
ski
in
them.
K
K
K
It's
barely
anything
informational,
so
whatever
you
have
to
do
to
be
able
to
document
you
know,
but
like
like
I
would
rather
not
split.
This
up
I
would
rather
just
have
one
thing
that
does
it
updates
all
three
of
them.
You
know
and
again-
and
this
is
not
intended
to
be
contentious-
it's
all
supposed
to
be
pretty
straight,
this
sort
of
writing
down.
Clearly
what
sort
of
the
obvious
way
to
do
this.
R
K
And
also
it
doesn't
update
arc
because
arc
is
new
enough
that
we
actually
manage
to
get
this
stuff
in.
This
is
the
first
time
around
right,
but
our
does
point
to
this
document
to
say
this
shows
you
how
to
do
it
right,
yeah
and
also
arc
the
arc.
The
arc
guys
depend
on
BPM.
So
it's
helpful
to
have
this.
This
is
exactly
oh
yeah.
E
G
This
is
Barrett
liebe
I
agree
that
it
would
be
nice
not
to
split
this
up.
The
only
thing
that
gives
me
a
little
pause
is
that
it
is
possible
that
the
D
mark
working
group
will
take
as
a
future
step
a
near
future
step
to
come
up
with
a
standards
track
version
of
D
mark,
presumably
that
standards
track
version
of
D
mark
would
incorporate
this
well.
It
would
be
newer
than
this
so
yeah
right
and
therefore
you'd
have
part
of
this.
It's
possible
that
the
standards
track
version
would
do
it
slightly
differently.
G
K
G
K
M
R
E
P
G
And
that's
that's
why
I
didn't
sit
down,
because
this
is
Barry
liebe.
That
was
my
next
statement
was
we
should
just
pick
this
up
in
Demark
and
I
say
that
as
a
current
chair
of
the
Demark
working
group,
fine
with
me
and
then
that
that
may
answers
the
dispatch
question
very
quickly,
even
though
we're
not
in
dispatch
now.
H
E
C
S
S
Things
like
MP
TCP
were
available
or
using
this
the
happy
eyeballs
approach
that
they
used
for
doing
things
like
racing
for
ipv4
and
ipv6.
So
the
goal
here
was
to
to
make
it
easier
for
applications
developers
to
take
advantage
of
capabilities
new
protocols
without
having
to
build
the
mechanism
in
to
binder
those
protocols
determine
if
they
were
going
to
work
failover
to
something
else.
If
it
didn't,
and
so
the
working
group
has
been
sort
of
chewing
away
at
this
for
several
years
now
and
we've
got
some
vendor
engagement.
S
Apples
actually
got
something,
that's
very
compatible
with
this
and
there's
an
architecture
and
the
abstract
API
is
starting
to
settle,
and
so
it's
kind
of
a
good
time
for
folks
who
have
an
applications
background
to
take
a
look
at
this
and
from
your
point
of
view,
because
the
transport
guys
are,
you
know,
we're
sort
of
bottoms
up.
Looking
at
this
problem
and
I
think
that
from
the
application
down,
you'll
probably
have
some
different
insights,
and
so
the
working
group
is
kind
of
heading
into
the
home
stages,
where
we're
starting
to
polish
up
the
documents.
S
And
so,
if
there's
any
like
major
course,
corrections
would
be
really
helpful
to
get
them
in
in
this
time
frame.
So
taps
meets
Wednesday
afternoon,
I
think
at
3:00
something,
and
so
you
can
just
tune
in
to
the
meeting,
but
I
actually
mostly
encourage
you
to
go.
Look
at
the
the
workgroup
documents,
there's
one
that
is
called
the
taps
interface
specification
and
and
see
if
the
abstractions
in
there
actually
kind
of
make
sense
from
an
application
perspective
so
and
send
comments
to
the
group.
Thank
you.