►
From YouTube: IETF98-DISPATCH-20170327-0900
Description
DISPATCH meeting session at IETF98
2017/03/27 0900
B
C
F
H
H
J
H
Please
note
it
very
likes
to
say
no
the
note
well
well.
This
establishes
obligations
around
reporting
intellectual
property
may
have
regarding
the
material
that
will
be
discussed
in
this
meeting
or
you
have
the
right
to
remain
silent.
Anything
you
say:
can
you
be
used
by
the
can
and
will
be
used
by
the
I
ATF,
and
you
should
consult
with
your
IP?
Are
people
before
proceeding
here.
K
L
So
these
are
our
u-bolt
that
lies.
You
know,
oh
sorry,
so
what
we,
what
we've
done
just
to
remind
people,
what
the
official
off
deadline
is
it
used
to
be?
We
tried
to
track
that
and
have
our
stuff
in
before
that,
but
they
kept
moving
it
up.
So
we're
not
quite
aligned
with
that.
So
you
have
to
think
about.
If
you
might
want
to
official
ball
talk
to
us
early
and
then
jun
12
is
to
let
the
chairs
know
you've
got
something
coming
in.
H
We
both
have
been
announced
to
the
list,
yet
we
will
be
posting
them
shortly.
Just
so,
you
understand
why
how
we
use
the
deadlines,
if
you
make
the
deadlines
and
you're
in
line
with
what
we
need,
you
basically
go
to
the
front
of
the
line
for
the
list
for
again
time.
If
you
miss
them,
you
end
up
at
the
end
in
any
other
business.
If
we
can
fit
you
in
and
please
start
your
drafts
when
you
submit
them
at
their
for
consideration
at
the
spring
group
with
the
draft
app
is
slightly
longer
should
be
draft.
H
Your
last
name
dispatching
than
the
rest
of
the
way
and
material.
That's
for
general
area.
Discussion,
not
specific
to
this
working
group
or
that
will
be
processed
to
this
working
group,
should
go
on
a
general
art
list
and
anything
it
is
for
us.
So
should
we
on
the
dispatch
list,
that's
how
we're
hoping
to
make
these
two
lists
separately.
Sometimes
it's
been
some
confusion
about
whether
apps
discuss
became,
which
one
and
so
forth
so
80s.
This
is
your
for
time.
Anything
because
I
see
I
only
see
been
in
alleppey.
I
H
B
Yeah,
I
think
really
quick,
think
that
been
mentioned
to
me
published
mention.
We
just
created
art
art
directorate,
which
has
three
a
DS
I
and
no
members.
So
we
have
all
the
documents
in
the
world
through
view
and
nobody'd
review
them.
Okay,
here's
so
I
think
the
plan
is
initially
for
a
DS
to
play
with
the
interface
and
see
how
it
works
and
try
to
request
documents
and
vote.
We
can
start
talking
to
to
recruit
people
as
well
and
I.
B
E
B
B
Okay,
thank
you.
What
what's
happening
to
a
pure
so
I
think
we're
going
to
close
it.
Unban
was
separately
talking
about
the
rice,
I
Directorate,
which
is
not
being
used,
so
our
art
is
going
to
be
the
joint
thing.
But
if
you
have
opinions
email
to
our
dash
AG's
at
ITA
blow
talk
I,
don't
think
we
have
decided
exactly
how
this
is
going
to
work,
but
I
think
a
single
Directorate
makes
sense.
H
There
are
various
nods
around
the
room,
outstanding
apps,
OGG
items.
This
is
the
former
applications
area,
general
working
group.
All
of
its
final
documents
have
been
made
it
all
the
way
to
RFC
status,
so
that
lexi,
I
believe,
is
planning
to
close
that
working
group.
Any
moment
now
might
as
well
just
stay
at.
B
The
mic
understand
titania
yeah,
it's
actually
the
last
oh
c'mon
got
published
on
my
birthday,
so
I
should
have
closed
the
chip
back
then.
So
there
is
nothing
left
so
and
we
have
a
quieted
impressive
list
of
like
I.
Think
almost
like
20
documents
will
publish
to
be
here
so
yeah
I'll,
just
cry
graph
them
in
our
nice.
Nice
short
email
saying.
Thank
you.
Everybody
and.
N
A
H
H
O
In
pink
box,
as
some
of
you
might
be
aware,
we
have
serve
a
tradition
here,
of
thanking
outgoing
area
directors
in
the
right
area
and
now
the
arc
area
with
sort
of
celebrating
with
gifts
along
a
theme.
The
theme
we've
arrived
at
this
year
is
music
and
so
to
kick
that
off.
I've
have
this
classic
Miles
Davis,
album
kind
of
blue.
This
is
presented
on.
P
Yeah
so
so
over
in
the
codec
working
group,
we
we
really
thought
the
idea
of
music
was
a
great
one
and
and
vinyl
was
an
excellent
choice.
But
what
Richard
rightly
pointed
out
Alyssa
might
need
a
record
player
to
play
her
records
because
probably
didn't
already
have
one
and
and
so
so
we
thought
you
know,
we
could
give
some
recommendations
of
reddit
audio
file
approved
record
players,
but
but
somehow
that
just
didn't
seem
good
enough.
It
didn't
seem
to
really
represent
true
leveraging
of
the
work
we
do
here
at
art.
P
Q
S
G
T
T
T
We
definitely
have
the
most
fun
and
the
best
jokes
and
I
hope
and
I
am
confident
that
that
tradition
will
continue,
but
also
that
means
I've
had
a
ton
of
fun
with
all
of
you,
as
as
our
area,
director
and
I
expect
that
to
continue
not
going
anywhere
really.
Oh,
the
other
thing
I
will
say
is
that
I
think
a
lot
of
the
sort
of
innovation
around
how
we
do
things
in
the
IETF
and
how
we
keep
current
and
bring
in
new
people.
T
I
think
a
lot
of
the
new
ideas
that
have
permeated
throughout
the
entire
ITF
have
started
in
our
area,
so
I
will
still
be
looking
back
to
all
of
you
to
keep
coming
up
with
those
ideas
and
how
we
can
make
the
ITF
better,
and
you
guys
know
where
to
find
me
if
you
want
to
help
with
that
or
complain
about
anything.
So
thanks
a
lot
really
appreciate
it.
R
R
H
Other
working
groups
that
aren't
meeting
this
week
like
to
say
anything
or
in
our
case
I
know
it's
like
we're
meeting,
but
the
list
is
not
coming
to
set
course.
So
we
do
have.
We
also
have
something
to
present
to
her.
This
is
joy.
Division's
love
will
tear
us
apart.
I
wanted
to
find
something
with
you
know,
a
neat
vinyl
color,
and
this
is
actually
clear.
So.
U
Hi
John
Peterson
I've
been
sent
on
behalf
of
the
modern
working
group.
Do
you
provide
a
contribution
for
modern
for
a
change?
This
is
like
a
career.
That's
come
yes,
those
are,
you
know,
modern
know
what
I'm
talking
about.
So
this
is
at
record
by
band
called
slint.
Both
Tom,
McGarry
and
I
are
big
fans
of
kind
of
indie
rock
stuff.
Since
is
some
good
indie
rock.
H
All
right,
okay,
we'll
go
back.
One
just
mention
that
we
have
everything
that
was
a
dispatch
working
group
item
from
last
time
has
been
hunted
and
I
early
to
sit
for,
so
we
have
nothing
currently
pending
for
dispatch.
We
hope
that
agrees
with
what
your
understanding
so
we're
going
to
emboss
this
this
meeting
compared
to
previous
ones.
There
are
only
four
I
invited
the
chairs
to
those
boss
to
come
in
mention
the
priests
35
comment
on
what
you're
doing
and
when
you're
doing
it.
H
H
T
So
I
asked
from
people
who
don't
know
is
the
ITF
administrative
support
activity?
It's
the
word
we
use
to
describe
how
we
administer
the
IETF
and
the
way
we
do
it
now
was
established
about
more
than
10
years
ago.
So
we've
been
starting
a
community
discussion
about
changes.
We
might
want
to
make
challenges
we're
facing
as
an
organization
from
an
administrative
and
funding
perspective.
So
we're
having
a
discussion
on
Wednesday
afternoon
about
some
of
those
things
we
had.
T
H
I
Hi
burn
gondwana.
You
can
turn
the
mic
up.
Yeah
I'd
like
to
that
yeah
Jay
map
is
mostly
an
attempt
to
create
an
email
protocol.
That
means
that
people
don't
spend
the
first
six
months
of
developing
a
new
client
and
trying
to
understand
30
different
standards
and
discovering
that
this
random
support
for
them
and
then
give
up.
That's
pretty
much
it.
What
do
you
love.
K
Joe
Hildebrand,
so
yeah
we're
doing
a
sea
border
working
group.
That's
doing
three
things
number
one
moving
the
seaboard
spec
along
towards
proposed
standard,
fix
a
couple
of
myths
that
sort
of
thing
number
two
talking
about
the
possibility
of
standardizing
some
extra
features:
extra
tags,
that
sort
of
thing
number
three
and
the
part
that
may
be
more
interesting
to
folks
in
this
room-
is
looking
at
standardizing
a
definition.
K
J
We
just
finish
last
call
hopeless
coatings
at
home
working
all,
which
is
a
draft
IDF
Constantine
Hildy,
which
is
itself
an
implementation
of
a
chief
of
ta21,
which
is
used
to
discover
the
path
and
tu
for
protocol
would
do
not
have
a
mechanism
to
discover
path
empty
next
slide.
So
what
do
we
need?
So
this
is:
can
order
of
that
unpacked
a
lot
from
be
a
lot
of
people
in
art,
so
we
need
guidance
to
find
what
is
the
best
way
to
collect
identifiers
for
ftp
tcp
vachetta.
J
Y
Advice
I
mean
I
seems
like
a
much
more
natural
protocol,
for
you
know,
sort
of
as
an
extra
you
know,
since
the
purpose
of
the
ice
cognitive
of
the
ice
is
to
figure
out
transport
characteristics,
I
would
say
if
you're
using
is
it
for
natural,
but
I
could
certainly
see
use
cases.
You
know
when
you're
doing
RTP
without
ice,
but
it
seems
less
compelling
and
at
which
point,
if
you're
doing
that,
you
might
want
to
think
about
which
it
gets
a
lot
harder.
Of
course,
some
of
the
multicast
cases
of
RTP.
J
X
So
someone
Thompson
I'm,
I'm
kind
of
with
Jonathan
only
on
the
ice
suggestion.
Frankly,
I.
Don't
think
that
the
multicast
scenarios
are
going
to
be
tractable
in
any
particular
way.
If
you
want
to
go
off
and
solve
that
problem,
it's
probably
a
number
of
research
projects
required
before
that
happens.
I
see
a
lot
of
RTP
usage
now
is,
is
tied
to
ice
and
fixing
the
problem.
There
is
both
simpler
and
easier,
so
I
would
suggest
just
sticking
to
that.
Okay,
Erica.
Z
Scorer
on
+1
to
that
also
it's
worth
observing
that
in
many
cases
their
other
protocol
co-located
with
RTP
over
ice
and
those
have
their
own
p,
MTU
discovery
problem
so
be
sevilla,
be
d,
GLS,
NSE,
TB
and
being
able
to
simply
inform
them
of
the
PMT.
You
rather
Hannah
do
independent
p.m.
to
discover
a
bureaucratic
well.
J
Z
Saying
that
if
you
could
simply
tell
it,
what
is
PMT
was
that
would
make
life
easier,
I
mean
PMT
the
new
discovery
kind
of
sucks,
so
the
few
times
you
have
to
do
it
I'm
you
either
you
have
to
burn
actual
packets,
which
you
want
to
send,
or
you
have
to
burn
them
with
by
sending
bogus
packets.
So
let's
do
that
once
rather
than
rather
than
end
times
and
I'm,
also
kind
of
curious
how
we're
gonna
do
it
with
how
it's
gonna
interact
with
bumble.
Z
J
Yes,
so
we,
when
we
fought
about
this
about
ice
thing,
is
that
we
don't
need
it
for
DTLS,
because
dtls
is
using
its
only
father,
Jean
shows
at
the
beginning
and
that
this
is
srgb.
So
we
don't
have
to
do
path
discovery
for
the
application
data,
because
there
is
no
application
data
and
then
we
don't
need
it
for
SC
TPP,
because
I
ctp
has
its
own.
J
X
Yeah,
sometimes
an
echo
sort
of
reminded
me
of
a
reason
why
you
absolutely
probably
don't
want
to
do
it
in
the
RTP
layer.
Is
it
you
are
running
out
for
ice?
You
lose
visibility
of
what
path
you're
operating
over
or
as
ice,
actually
understands
the
path
and,
if
you're
doing
path,
MTU
detection
over
ice
and
ice.
Doesn't
this
ice
by
Bill
anything
or
if
it
chooses
nominates
a
different
pair,
then
you're,
actually
on
a
different
path
and
the
information
that
you've
learned
on
the
first
path
is
carried
across
under
the
second
path.
X
Which
is
what
which
is
part
of
the
breeze?
Why
the
highlight
hi
layer
protocols
like
sctp,
actually
implement
the
interior
discovery
themselves,
because
they
actually
understand
that
the
existence?
The
past
they're
operating
over
in
the
case,
where
you're
running
srtp
over
over
ice
ice
really
needs
to
be
the
place
where
you
doing
this.
AA
H
Y
John
Lennox
I
mean
if
there
are
compelling
use
cases
for
RTP
without
ice,
then
we
can
look
at
this,
but
so
far
I
haven't
really
heard
any
I
said
I.
Think
most
you
know
in
the
modern
world,
I'd
say
most
of
the
articulate
Isis
either
VoIP,
which
isn't
likely
to
implement
something
new
like
this.
At
this
point,
especially
because
audio
doesn't
really
attempt
to
you
issues
or
else
like
IPTV,
which
it's
in
the
multicast
areas,
all
right.
AB
H
H
I
AC
AA
W
AB
W
That
they
do
and
it's
the
most
liquid,
but
of
that
yes-
and
it's
used
in
a
lot
of
other
places,
it's
kind
of
one
of
those
foundational
specs
that
doesn't
get
a
lot
of
attention,
but
it
it
helps
build
some
structure
and
other
stuff,
and
and
so
when
we
did
this
spec,
it
was
something
that
I
did
in
my
spare
time
and
it
was
80
sponsored
because
way
back
when
that
was
kind
of
how
things
were
done.
Alexi.
Were
you
the
idea
that
sponsored
it
but
Bevin?
I
really
forget
who
it
was.
W
It
is
it's
possible
yeah,
but
so
it
went
out
there
and
it
got
adopted
by
these
communities
and
was
good
and
it
SAT
there
for
a
while
and
in
the
meantime
you
know
once
it
became
you
sorry,
it
was
Alexia.
Thank
you,
Thank
You
laxing,
so
that
makes
the
more
recent
sations
a
little
more
ironic
than
okay.
W
This
is
a
short
link
to
that
issues
list.
If,
if
you
want
to
go
and
have
a
look
at
the
issues,
there
I'll
summarize
the
high
points
in
just
a
moment,
but
we
had
a
long
set
of
discussions
about
them
and
got
to
a
place
where
everyone
was
pretty
happy
or
at
least
from
what
I
could
see.
And
so
the
document
has
settled
down.
There
aren't
any
open
issues
on
it
currently
and
we
think
it's
it's
pretty
ready
to
go.
W
I
do
have
some
discussions
that
I
want
to
have
with
ayanna
about
how
the
interaction
with
them
works.
But
that's
about
all
that's
left.
So
next
slide.
There's
a
lot
of
little
stuff
and
as
abyss
document
this
is
entirely
you
know,
appropriate
I
think
we
did
things
like
clarifying
terminology,
cutting
down
the
introduction
and
making
more
human
readable,
updating
all
the
references
incorporating
all
the
errata
most
of
those
from
julie,
and
I
think
hi
Julian.
W
We
remove
the
registration
template
since
they've
served
their
purpose
and
they
took
up
a
lot
of
space
in
the
document,
updated
the
EA
BNF.
Thank
you
again
Julian
and
we
added
a
non-normative
algorithm
for
parsing
link
headers
in
the
style
of
the
what
working
group,
because
that's
what
the
cool
kids
do
today
and
we
define
these
concepts
of
an
application
of
linking
and
a
serialization
of
linking
more
carefully.
W
These
are
kind
of
the
ways
that
you
might
express
a
link
in
C
realisations,
as
well
as
things
that
use
links
the
applications
and
what
constraints
or
guidelines
we
give
to
those
things
next
slide
a
little
bit
bigger
of
an
issue
that
actually,
at
one
point
I
think
was
a
bit
controversial.
Folks
in
the
Semantic
Web
world,
wanted
a
lot
more
rigor
around
how
to
create
a
uri
for
a
registered
link
relation.
So
we
have
a
registry
of
lincra
link
relations
in
just
a
short
token.
W
You
know
for
neck
or
home,
or
what's
of
these
things
that
we
use
as
a
shorthand,
but
the
actual
extension
syntax
for
link
relations
is
a
folio
I,
so
it's
grounded
in
a
namespace,
and
so
these
folks
wanted
a
way
to
express
those
shorts
registered
relations.
As
you
are
eyes
which
the
spec
didn't
do
terribly
well,
it
kind
of
waved
the
tens
about
it,
and
so
we
had
a
long
back
and
forth
about
how
best
to
do
that
and
we
think
we've
come
up
to
a
place
where
we
have
a
reasonable
approach
to
that.
W
That
makes
everyone
not
unhappy,
and
so
in
discussions
that
I
had
with
lexie.
In
the
background
about
doing
this.
This
document
this
was
one
of
the
concerns-
was
that,
if
that
blows
up,
that
might
require
a
working
group
to
sort
it
out,
but
it's
not
blowing
up
anymore.
So
next
slide
the
other
big
thing
that
that's
kind
of
happening.
The
background
of
this
draft,
which,
which
you
don't
really
get
a
good
sense
of
from
reading
it
is,
is
that
we
personally
want
to
try
and
experiment
with
how
we
run
the
registry.
W
In
that
you
know,
the
registry
right
now
is
quite
clunky
and
how
its
run
and
it's
not
very
friendly
to
end
users
who
aren't
familiar
with
IETF
process,
and
this
is
a
kind
of
recurring
theme
in
in
what
we
do
here.
We
have
certain
numbers
of
registries
whose
audience
is
not
just
protocol
folks
at
the
ITF,
it's
a
much
much
wider
audience
of
developers
and
they
need
to
interact
with
these
registries
in
a
more
friendly
fashion,
and
so
there's
been
some
thinking
put
into.
How
can
we
do
that,
and
how
can
we
establish
those
procedures?
W
I
think
the
insight
that
that
I'm,
currently
operating
under,
which
which
may
or
may
not
be
disabused,
is
that
we
don't
need
to
document
all
of
those
procedures
in
the
RFC.
What's
important
is
we
document
the
relationship
between
the
registry
and
the
experts
and
iono
to
make
sure
that
they
can
evolve
a
structure
that
works,
but
that's
one
of
the
discussions
that
I
think
still
needs
to
happen
a
little
bit
more
publicly,
at
least
in
this
community?
Is
there
a
next
slide,
I'm,
not
sure,
there's
next
line?
Okay
thanks!
W
W
H
I
mean
I,
don't
think
it
quite
happens
in
dispatch.
It
could
be
discussed
on
that
list
or
whatever,
but
it
seems
that
you
have
two
very
different
levels
of
things
here
that
maybe
you
should
tease
apart
a
little
bit
more
talk
about
more
because
one
of
them
is
a
fairly
straightforward.
Update
is
to
a
draft.
Another
way
is
finding
a
way
that
is
a
problem.
Lots
of
people
had
to
have
a
better
registry
system,
and
you
clearly
have
some
ideas
for
that
which
are
not
in
this
draft.
C
W
And
it's
always
been
kind
of
sidetracked.
In
other
discussions
we
had
the
happy
I
Anna
work.
We've
had
other
discussions
on
the
side.
It's
something
I'm,
very
interested
in
I'm,
happy
to
talk
about
with
folks,
but
I
need
a
venue
where
it's
going
to
be
able
to
be
focused
upon,
and
we
come
to
a
conclusion
and
I.
Y
W
And
and
what
I
really
want
to
do
is
give
the
experts
of
the
registry
and
full
disclosure
I
am
one
of
the
experts
of
that
registry,
the
ability
to
experiment
with
how
they
allow
registrations
to
happen,
because
I
think
trying
to
write
it
down
in
RFC
and
then
execute.
That
is
a
recipe
for
disaster.
I.
Think.
E
Do
for
to
be
clear,
I
wasn't
suggesting
anything
related
to
this
document
right
there.
What,
if
so,
first
of
all
I
think
this
document
should
be
ad
sponsored
I,
don't
think
we
need
a
working
look
for
it
and
if
we
want
to
pursue
generalizing
some
changes
to
registry
stuff
I
think
we
need
to
have
a
ball
for
that,
and
maybe,
after
some
experience
with
this,
we
can
do
that.
Well,.
W
H
W
I,
just
don't
so,
have
you
read
the
iana
considerations
section
of
this
document?
Okay,
I
mean
if
we
can
come
to
a
place
where
we
can
get
this
document
out
and
it
has
enough
flexibility
net
where
we
can
at
least
do
some
of
this
experimentation
and
not
have
to
rewrite
it
in
six
months
or
a
year.
I
think
that
would
be
good
I.
L
AD
Roy
fielding
Adobe
first
I,
I
we
use
links
heavily
in
our
upcoming
api's,
so
it's
that's
good
public
aps,
so
I
certainly
hope
that
it
moves
towards
more
standardization.
The
other
thing
I
wanted
to
note
is
that
I'm
starting
work
on
a
specification
of
hypertext
references,
which
has
a
lot
of
overlap.
W
C
W
B
H
B
H
X
AE
Ok,
my
name
is
Colin
Gasca
from
deutsche
telekom,
and
I
propose
an
addition
to
the
reason.
Heather
and
first
I
would
like
to
say
that
the
term
location
used
here
within
this
raft
has
nothing
to
do
with
the
location
use
for
emergency,
calling
that
I
get
a
couple
of
comments
back
from
people
to
point
that
out.
AE
That's
another
RFC
which
we
did,
but
what
at
least
a
draft
disliking
is
that
we
have
a
location
within
the
eyes
of
network
where
this
call
was
released,
and
this
is
the
aim
of
the
draft
to
at
this
location.
If
you
go
to
the
next
slide,
it
shows
at
least
the
nice
telephone
network,
the
old
ones
which
we
have
it's
not
like
the
SIP
approach
and
to
end.
AE
For
example,
we
have
different
kinds
of
user
busy
where
they
use
itself
says
I'm
busy
and
user
agent
or
lisa
telephone,
reject
the
call
and
says
use
a
busy
or
we
have
it
also
within
the
network
itself,
so
that
the
network
says
okay,
I
have
no
lines
to
the
users,
so
the
user
is
busy,
and
that
is
where
we
send
the
location
with
the
use
of
busy
eyes,
of
course,
next
slide.
So
why
why
we
do
use
or
why
we
do
need
it.
AE
We
have
yes
mobile
networks
providing
IMS
which
is
based
on
sip,
and
we
have
still
gsm
networks,
PSN
networks
that
are
using
the
I
sub
coding,
and
with
regard
to
that,
we
need
the
seamless
interoperability
between
networks,
and
we
have
seen
that
we
have
problems
providing
services
where
we
have
to
react
on
a
user
pc,
for
example,
the
couple
of
scenarios
and
which
is
important
to
map
a
location,
and
that
cannot
be
done
with
existing
sip.
Well,
you
sleep
responses
which
we
try
to
do.
AE
We
have
already
examples
where
we
did
it
with
other
eyes,
of
course,
but
busy
keeps
us
busy,
at
least
with
only
two
coding.
So
so
we
have
the
pcanywhere
and
the
normal
busy
with
and
sit,
and
that's
why
we
would
like
to
introduce
addition
to
the
coding.
So
it's
a
small
ad
on
within
the
reason
header
so,
and
that
is
the
proposal.
Thank
you.
AF
AE
I
want
to
know
how
to
dispatch
it.
So
I've
got
a
couple
of
comments
on
the
dispatch
list
already,
so
I
will
incorporate
them,
at
least
mainly.
It
was
the
use
of
the
wording
location.
So
I
will
change
this
to
something
like
I
supplication
or
something
like
that.
So
the
question
is:
if
this
other
could
be
anywhere
dispatched
or
if
this
can
be
fights,
amla
e
d
sponsored
activity.
U
Okay,
John
Peterson.
Sorry,
my
voice
is
really
going
out
today,
yeah,
so
there
seem
to
occasionally
come
up
more
reason:
code,
ish
kinds
of
things
that
people
want
to
do.
So
it's
not
that
I
can't
imagine
where
being
a
bucket
of
like
reason,
cause
code,
I
person
this
from
stirrer
I
know,
there's
some
work
that
people
are
doing
in
Addis
Mary.
I
H
Perspective
and
I'm
speaking
as
the
support
chair
for
the
next
forty
some
odd
hours,
this
seems
to
fit
in
zip
cores
new
charter.
Just
fine,
so
but
I
think
that
it
would
be
a
reasonable
sort
of
thing
to
take
on
there.
I
haven't
looked
at
the
technical
content,
the
document
I
know
he
has
some
thoughts.
There
is
going
to
share
in
a
moment,
but
I
think
it's
perfectly
good
than
you.
AG
This
Pete
Resnick,
so
not
being
a
sick
person.
I
just
got
whacked
on
the
nose,
rather
appropriately
on
the
IETF
list
during
last
call
for
the
666
document
and
told
that
headers
don't
go
back
through
proxies
in
error
codes,
don't
necessarily
go
back
through
and
that's
why
you
had
to
use
666
and
you
couldn't
put
the
this
is
spam
and
a
header
because
it
wasn't
going
to
make
it
back
to
where
you
want
it
to
get
it.
Isn't
this
the
same
thing?
AE
AG
AH
Christer
homework,
basically
what
you
say
it
is
correct,
but
at
least
from
my
implementation
on
and
product
experience.
The
reason
hitter
do
go
back
in
general.
What
the
comment
that
was
made
at
hitters:
don't
go
back.
Yeah
I
totally
agree
with
that,
but
I
would
almost
say
that
de
facto
standard,
even
though
it's
not
really
specified
in
anywhere.
Is
that
the
reason
how
to
do
tend
to
go
back,
but
that
I
mean
II
fighters
have
either
you
know
experience,
but
that's.
At
least
you
know
my
experience.
H
So
this
seems
I
mean
it
seemed
someone
within
the
scope
of
sick
or
if
we
decide
that
we're
getting
enough
of
this
work
in
sick
or
that
it
makes
sense
to
split
off
something
to
deal
with
that
type
of
stuff.
I'm
sure
that
that
could
be
addressed
at
that
point
in
time.
I
is
you
want
to
speak
about
this
doing
something
with
other
than
sending
it
to
succour
I
guess.
H
H
J
M
I'm
talking
very
briefly
about
what
I
think
is
a
tiny
change
to
D
care.
How
many
people
here
know
how
beacon
works?
Most
of
you,
okay,
good,
so
I
have
for
the
rest
of
you.
I
have
a
next
slide.
Please
next
slide!
Here
we
go
here's.
What
dekum
does
it
takes?
It
takes
a
mail
message:
it
hashes
it
all
up.
It
signs
the
hashes
with
a
private
key.
It
then
adds
a
header
to
the
message
with
the
sign
with
the
signature.
Then,
when
a
recipient
gets
the
message,
they
can
look
up.
M
M
It
really
is
a
very
small
registry
of
hash
algorithms
and
signature.
Algorithm
hash
algorithm
was
a
sha-1
which
is
deprecated
and
nobody
uses
anymore
and
shot
to
256,
which
we
all
use.
The
only
signature
algorithm
currently
is
our
essay,
and
it's
plain
ordinary
RSA
and
in
the
signature
itself
there
is
a
tag
that
says
what
hash
algorithm
and
what
signing
algorithm
you
used.
So
it
like
a
equals,
make
shot
to
shot,
256
RSA
and
then
in
the
key.
M
The
key
does
not
identify
yeah
the
key
says
what
signing
algorithm
is
used
and
a
little
used
optional
field
about
what
hashes
you're
allowed
to
use.
So
both
the
signature,
both
the
signature
and
the
key,
allow
you
two
are
designed
to
allow
new
out
on
this
to
be
added
next,
please
here's!
The
problem,
the
spec
currently
says
spec
is
really
all
the
spec
says,
you're
supposed
to
be
able
to
use
five,
but
bit
RSA
keys,
but
nobody
does
that
anymore.
M
I
hope
the
signers
must
use
at
least
1k
keys,
and
we
are
thinking
that
1k
keys
are
ok
now,
but
they're
getting
a
little
long
in
the
tooth.
So
we
want
to
expand
to
too
cakey.
Well,
that's
fine!
We
could
just
mean
normally,
you
would
say,
I'll
just
make
the
key
longer
and
I'll
put
the
stomach.
I'll
put
the
signing
key
in
the
DNS
and
everything
will
be
cool.
However,
it
turns
out
that
doesn't
work,
because
a
1k
key
is
almost
256
bytes.
We
store
them
in
txt
records.
M
We
should
not
have
this
problem.
Only
a
would
write
software
that
had
this
problem,
but
the
world
is
full
of
people
who
write
software
like
that,
and
then
ain't
going
to
change.
So
I
have
to
promote
to
proposed
solutions.
First
is
new:
improved
signing,
algorithm,
elliptic,
curve,
keys
or
tiny
code
as
well
debug
blah
blah
blah.
So
for
that
all
we
do
is
we
would.
We
would
update
the
deccan
spec
to
say.
Ok
now,
instead
of
in
addition
to
RSA
signatures,
you
can
do
you
can
do
ed
DSA
signatures
and.
M
An
alternative
proposal
which
which
eric
suggested
is
do
what
we
do
in
other
other
context
and
actually
put
the
signing
key
in
into
the
signature.
So
I'll
put
the
verification
key
into
the
signature,
just
put
a
hash
of
the
fixed
size,
hash
of
the
of
the
verifying
verification
key
into
the
dns,
the
hashes
of
a
limited
size.
So
you
know
so
we
could
do
it.
Okay,
and
this
would
then
a
lot
this
is.
We
then
get
rid
of
the
practical
limit
on
the
on
the
on
the
key
size?
M
Well,
if
at
the
cost
of
adding
a
new
header
field,
but
but
sorry
at
the
hot
cost,
adding
a
new
tag
to
the
D
Kim's
signature,
which
is
also
it
is
already
defined,
have
to
be
to
allow
more
tags
to
be
added.
We
could
do
either
or
both
I
think
I
have
one
more
slide,
yeah.
So
for
transition
issues,
we
need
to
figure
out
how
to
do
old
and
new
signatures.
M
The
current
specs
says
for
says
you
can
only
have
a
single
key
record
for
each
selector,
which
is
fruit
and
we
could
relax
act
and
say
we
could
have.
You
know
two
key
records,
one
for
the
old
key
and
one
for
the
one
for
the
old
signing
our
algorithm
one
for
the
new
signing
algorithm
during
the
transition.
Verifiers
are
supposed
to
ignore
signatures.
They
don't
understand.
That's
I
hope
that
works.
That
is
a
code
path
that
has
not
been
well
tested.
M
So
we
need
to
go
back
and
test
it
and
see
how
much
this
is
going
to
break
and
the
reason
this
is
slightly
urgent
is
there's.
This
thing
called
arc,
which
is
a
mutant
version
of
D
Kim
that
is
being
invented
to
help
deal
with
the
the
DMark
mailing
list.
Issues
that
I'm
not
even
going
to
go
into
here
but
but
but
arc
is
the
magic
bullet
arc
is
based
on
d,
kim,
to
the
extent
that
we
could
get
d
Kim
updated.
M
S
It
figured
back
up
on
some
ID,
please
I,
think
Brett's,
who
are
you
I'm,
sorry,
Russ,
housley
I,
think
that
supporting
things
like
ed
255
19
is
a
good
plan.
However,
it
does
not
have
the
same
API
as
any
other
signature
out.
It
does
not,
for
example,
have
a
hash
algorithm.
It
is
implied
by
using
ed
2519
how
the
hash
will
be
constructed.
I
know
this
having
just
worked
through
how
to
use
the
CMS,
so
your
API
is
not
as
plug-and-play
as
this
presentation
implies.
AI
AI
M
AI
AJ
Duke
Crocker,
so
we
have
a
tendency
in
the
ITF
to
think
of
doing
transitions
as
an
integrated
step,
and
we
end
up
building
cruft
into
the
transition
process.
To
do
that
and
the
from
this
the
view
that
I've
developed
is
the
way
to
do
a
transition
is
first
specify
where
you
want
to
be
and
make
it
be
as
clean
as
possible
and
have
it
be
completely
separate
from
any
of
the
transition
steps.
AJ
AJ
And
that's
where
I
landed
on
is
we
have
a
construct
for
giving
multiple
signatures
in
a
message?
Do
multiple
signatures?
It's
already
there
in
fact
that
one
of
those
in
the
new
style
and
one
of
them
is
in
the
old
style,
is
completely
transparent
to
the
meta
structure
and
it's
much
simpler,
ok
and
and
therefore
your
transition
isn't
a
transition
in
the
technology.
It's
a
transition
in
some
operational
practice,
which
looks
a
whole
lot
like
some
other
transitions.
We
already
support,
get.
AJ
But
if
it
doesn't
do
that,
we
have
bigger
problems
with
that
implementation
anyhow,
because
we
already
have
transitions
that
it
has
to
support.
This
is
just
in
the
macro.
This
is
the
same
as
all
of
those.
The
the
other
thing
that
Russ's
comment
triggered
in
my
thinking
is,
it
sure,
would
be
nice
to
move
this
stuff
into
our
registry,
so
we
don't
have
to
go
around
changing
specs.
We
just
did
change
registry
entries,
and
that
requires
that
there
be
some
regularization
to
how
the
registry
entry
is
and
I'm
not
sure
how
to
do
that.
AJ
M
D
Kim
is
actually
a
merger
of
two
different
specifications,
one
of
which
stored
the
public
key
and
dns
and
the
other
which
stored
a
hash
of
the
public
key
and
EMS,
and
we
made
a
decision
when
we
merge
them
to
put
the
public
key
in
dns
in
order
to
cut
down
on
the
message
header
size,
because
some
large
email
provider
noted
that
it
would
take
some
non-trivial
number
of
additional
disk
drives
in
order
to
store
all
of
those
public
keys
that
were
redundant
lee
in
all
of
those
messages.
So
that's
how
we
got
here.
D
D
Remember
it
was
probably
12
or
so
yeah
I
think
yeah
right,
but
that
was
when
the
decision
was
made.
In
any
case,
I
will
note
that
publishing
the
the
hash
of
the
public
key
and
DNS
in
this
particular
application,
I
believe
has
some
IP
are
associated
with
it,
and
so
that
might
be
something
else
so
that
you
might
want
to
consider.
Z
Eric
risk
rola,
basically
plus
one
of
a
phb,
said
I
think
that
what's
most
flexible,
its
most
flexible
to
have
the
hash,
the
DNS,
but
it's
fun.
We
should
be
doing
some
modern
algorithm
as
well.
I'm
seems
like
we
now
conversion
Edie's
and
they
were
other
so
I'm.
Finally,
that
that,
or
also
be
fine
with
PG
56
ecdsa.
The
point
Russ
made
earlier,
of
course,
right
about
the
hashes
on
my
senses.
Z
The
communities
actually
rapidly
converging
towards
the
notion
that
every
curve
should
we
use
exactly
one
and
only
one
hash,
so
I
think
if
we're
actually,
if
we
decide
to
do
you
know
something
other
than
you
do
find
her
a
nine
it
should
be.
Like
you
know,
p
256
reach
out
to
36
makes
a
match
like
we're
doing
now.
No,
it's
an
RSA
thing,
not
really
an
easy
thing.
I
mean.
M
O
You
know
some
support
for
what
whether
it
makes
sense
the
supports
within
this
curves,
and
it's
like
using
PG
56,
which
I
sha-256
only
because
there
are
a
lot
of
signers
out
there
right
now
and
in
you
know,
you
can't
buy
a
signer
right
now
that
does
ed
2551,
not
as
far
as
I
know,
people
probably
correct
you
on
that,
but
the
market,
the
support
for
that
in
the
market.
Right
now
is
not
great.
So
if
you
want
to
promote
deployment,
you
might
consider
having
some
support
for.
M
H
X
So
none
thompson.
The
only
reason
I
got
up
was
that
there
is
a
working
group
that
is
doing
precisely
this
work
and
they're
over
in
the
second
area.
Have
all
the
people
who
understand
all
of
the
issues
that
brass
and
eka
and
Richard
have
talked
about
the
actual
interface
to
2d
kim
is
connor
trio?
Oh
sorry,
I
was
about
to
say
a
cuddle.
X
I
was
going
to
say
the
interface
dude
Hakeem
is
actually
pretty
trivial,
because
the
design
correctly
anticipated
the
need
to
change
these
things.
They
don't
require
a
huge
level
of
knowledge
about
how
Deacon
works
in
order
to
define
new
signature
algorithms,
if
you're
willing
to
go
over
and
participate
on
their
mailing
list,
which
might
be
out
for
the
time
that
it
takes
to
write
the
draft
have
a
couple
of
hours
of
discussion
and
and
get
it
through
publication,
which
is
what
what's
happened
with
their
current
set
of
drugs.
AI
AI
AI
AI
H
I
mean
it
seems,
I
had
look
at
that
charter
head
time.
It
seemed
to
me
there's
two
different
issues
here:
there's
one
about
how
to
select
curves
and
how
to
do
the
crypto
and
there's
another
thing:
that's
really
about
the
whole
d
Kim
architecture.
What
you're
talking
about
an
architectural
change
that
has
nothing
to
do
with
crypto,
that's
about
where
you
store
these
things
and
the
pointers
to
them.
Do
you
want
to
separate
those
at
all
or.
N
All
right
student
are
also
going
idea.
This
one
behind
will
probably
disagree
with
me,
but
and
the
so
I
need
to
cut
up
into
this
church
or
would
fit
curdle
very
well,
I.
Think
the
changes
to
the
significant
signature
message-
header
fields
in
if
you
wanted
to
reach
our
decoder,
which
you
might
have
to
do
to
include
that,
then
that
would
be
okay
as
long
as
it's
not
mail.
People
actually
pay
some
attention,
but
you
would
need
male
people
paying
attention.
In
fact,
that's.
Z
Erihskroy,
yes,
I
rise
to
support.
My
former
colleague,
III
I
was
originally
thinking
that
this
is
a
kernel
thing
based
on
Martin's
comments,
but
I
think
based
on
the
point,
Colin
just
made
I
think
probably
better
to
have
a
small,
focused
working
group
than
to
do
that.
Then
the
pun
it
to
curdle
on
clean
I
mean
I
I,
don't
oppose
they
get
to
Colonel.
People
want
to
do
that,
but
I
think
that
if
I
were
voting
as
opposed
to
has
opposed
judging
consensus,
I
would
vote
other
way.
B
J
H
H
B
F
F
H
Yes,
I
didn't
say
that
very
clearly
and
I
apologize,
so
this
patch
has
not
fully
dispatched
this
yet,
but
our
proposal
is
that
they
write
that
we're
going
the
direction
we're
going
on
dispatching.
It
is
with
a
mini
working
group
right,
a
charter
for
the
mini
working
group.
If
we
can
get
consensus
on
that
many
working
group
along
with
the
area
directors,
obviously,
then
it
will
be
dispatched
into
that.
That
seems
highly
likely.
That
could
happen
quickly.