►
From YouTube: IETF94-ECRIT-20151104-0900.webm
Description
ECRIT meeting session at IETF94
2015/11/04 0900
A
B
A
B
He's
here
fabulous
alright,
so
that's
let's
get
started.
This
is
e
crib,
you
might
think
I'm
a
chair,
but
actually
I'm,
just
standing
in,
because
both
chairs
weren't
able
to
make
the
meeting
I'm
brian
rosen
I'm
sitting
in
yes,
so
both
mark
and
Roger
weren't
able
to
be
with
us
and
so
I
will
I
will
try
to
do
my
best,
even
though
I'm
presenting
so
we'll
we'll
be
alright
note.
Well,
it's
Wednesday
you've
seen
this
before
and
I
certainly
hope.
You
know
what
it
means.
B
B
B
B
Here's
our
document
status,
two
of
the
documents
are,
are
already
adopted
and
there's
a
third
that
I'm
going
to
ask
to
be
adopted
and
we
need
reviewers
on
the
most
well
will
do
working
loop
last
call
was
submitted
for
car
crash
and
II
call
and
in
to
land
on
the
19th.
So
if
you
haven't
had
an
opportunity
review,
you
should
be
reviewing
because
we're
in
working-class
go
on
both
of
those
documents.
Oh
and
I'm.
Sorry,
1019,
hello,
1019,
it's
over.
It's
we're
going
to
submit
right
and
so
you'll.
B
C
B
We
we
don't
have
any
more
milestone,
so
we'll
have
to
go
and
and
work
on
that
I
though
the
we
have
milestones
for
the
data
only
and
emergency
call
I'm
sorry,
the
e
call
car
crash
things
are
there,
so
they
were
up
we're
proposing
to
update
those
to
march,
and
all
of
those
documents
are
well
well
along
the
path
that
really
just
need
reviews
and
we
can
get
them
done.
We
can
beat
this
pretty
easily,
but
they
have
slipped
and
the
one
was
done.
B
B
A
C
These
documents
have
been
around
for
a
while
this
particular
one
is
describing
how
next
generation
automatic
crash
notification
from
vehicles
is
are
implemented
using
IETF
protocols
few
idf's
ago,
based
on
a
suggestion
from
Keith.
This
was
made
actually
an
extension
or
dependency
of
on
e
call,
so
it
uses
the
same
call
setup
mechanism
as
he
call,
but
because
this
is
not
for
ecall
but
for
generalized
automatic
crash
notifications
such
as
in
North
America.
It
replaces
the
mandatory
call
has
a
mandatory
MS
D,
which
is
nique
all
specific
data
set.
C
This
document
uses
the
Nina
aapko
beds
as
mandatory,
but,
of
course,
permits
other
data
sets
if
those
are
needed
by
different
regions.
So
that's
the
only
technical
dif
down
there
and
then
the
rest
of
the
differences
between
this
documented.
This
one
talks
more
about
I
could
see
but
yeah.
It
describes
the
models
that
are
in
use
now
and
how
those
models
migrate.
B
B
C
Okay,
so
next
slide
right,
so
the
the
most
significant
change
to
the
to
the
draft
that
happened
since
the
last
ITF,
which
happened
before
working
group
last
call,
was
that
we
added
an
example
of
a
veg
data
structure
in
there,
and
we
validated
that
example
against
the
bed
schema.
So
the
working
group
last
call
is
expired
on
this
I
believe
this
document
is
ready
for
IETF
last
call.
B
B
Although
we've
had
a
couple
people,
we've
got
quite
a
few
people
who
have
read
it
commented
on
and
we've
taken
care
of
it
and
those
people
usually
are
easy
to
get
to
speak
up
with.
They
didn't
like
that.
The
change
so
I'm
not
too
worried
about
that,
but
another
reviewer
to
really
would
be
great
if
we
could
get
it
and
both
of
them
they're
very
similar
documents.
If
you've
read
one
you've,
pretty
much
read
the
other,
which
was
by
design,
but
any
other
comments.
B
A
B
Yeah
is
there
anyone
here
who
could
possibly
look
at
these
both
of
these
documents
and
take
and
and
say
yes,
I
think
they're,
okay
and
that's
all
really
want
to
have
at
this
point
will
get
the
chairs
the
chairs
will
hunt
somebody
up
I'll.
Do
it
myself
if
I
need
to,
but
yes
you
you,
we
need
to
have
that.
A
A
C
Okay
and
now
on
to
the
e
call
document
this
document,
it's
very
similar
to
the
last
one,
the
difference
being
that
this
one
is
actually
sets
out
the
technical
basis
for
call
setup,
that's
used
by
the
other
one.
This
call
this
document
does
not
discuss
anything
about
North
American
deployments,
but
it
does
talk
a
little
briefly
about
the
pan-european
eCall
service.
C
C
B
C
B
B
B
An
interesting
problem
that
I'm
cheering
but
I'm
since
I'm
not
chairing
the
meeting,
but
since
I'm,
not
the
actual
chair
I,
can't
actually
deal
with
the
materials
they
had
to
deal
with
the
material,
so
some
slides
didn't
get
it
yet
updated.
But
that's
alright!
All
right
hang
on
one.
Second,
it
was
data
only
all
right,
I'm
gonna
do
it
from
here,
because
I'm
running
this
and
slides.
B
So
date
only
provides
a
way
to
take
a
cat
message,
which
is
the
generic
con
alerting
protocol
that
is
used
in
a
variety
of
emergency
circumstances
that
has
it's
an
XML
data
structure
that
that
that's
used
to
announce
emergency
items.
It's
used,
for
example,
in
the
the
text
messaging
thing
where
you
get
a
warning
cell
broadcast
mechanisms
in
the
US
they
use
cap
to
send
the
message
from
the
original
originator
to
the
system
that
distributes
the
messages
out
through
the
cell
system.
B
B
We,
we
did
have
a
working
group
last
call
it
ended.
We
had
no
objections,
but
we
didn't
have
enough
reviews.
So,
when
I'm
asking
for
here
I'm
begging,
please
review
it,
I
will
I
will
get
a
reviewer
for
from
from
nina
from
it,
but
they're,
not
regular,
workgroup
members,
and
that's
not
a
really
good
thing.
We
could.
They
use
people
who
are
in
the
work
group
or
with
the
ITF
know
what
a
good
document
looks
like
to
to
take
a
look
at
it.
B
C
B
A
A
B
B
That
does
not
is
not
part
of
a
city,
but
the
city
is
growing
and
an
ex
is
a
part
of
the
county
into
the
boundary
of
the
city,
so
the
city
gets
bigger,
the
county
and
and
so
that
typically
changes
the
routing
of
calls,
because
the
city's
typically
have
their
own
piece
apps
in
their
own
routing,
their
own
police,
fire
and
EMS
services.
So
all
the
routing
in
the
lost
server
changes
when
that
annexation
occurs.
The
annexation
typically
occurs
midnight
on
some
day.
B
You
know
January,
first
or
something
like
that
that
that
annexation
occurs
and
any
any
routes
that
were
were
in
the
in
the
in
the
system
need
to
change.
So
the
lost
servers
data
needs
to
change,
and
you
would
like
it
to
change
exactly
at
the
time
that
the
annexation
occurred,
because
what
the
the
emergency
authorities
want
is
that
immediately
before
it
goes
to
the
old
routing
and
immediately
after
it
goes
the
new
routing
calls
received
from
that
area
that
gets
a
next.
You
want
to
be
able
to
change
the
health
of
routing
change.
B
B
You
now
do
and
what
used
to
be
invalid
is
now
valid
and
the
the
again
before
you
typically
know
that
before
the
house
is
allowed
to
be
used
and
there's
routing
changes
that
have
to
get
done
with
all
these
things
but
anyways,
so
there
isn't
a
way
to
to
handle
that
kind
of
problem.
So
the
the
other
thing
that
occurs
on
the
actually
has
two
mechanisms
in.
It
is
more
useful
for
that.
B
That
second
case,
where
you
get
a
new
house,
which
is
that,
if
you
have
a
list
and
the
list
is
done,
validation
and
something
changes
that
affects
that
validation,
you
have
no
way
of
telling
it
that
that
happens.
The
only
way
that
exists
in
the
current
law
system
is
what's
called
periodic
revalidation.
So
every
once
in
a
while,
you
go
and
revalidate
the
data
in
your
database.
B
We've
done
a
bunch
of
work
on
this
because
we're
deploying
these
systems
now
and
the
validation,
the
REE,
the
periodic
revalidation
load,
swamps
every
other
use
of
the
law
server
by
orders
of
magnitude.
It's
crazy,
but
it's
the
only
mechanism
we
have.
There
is
no
push
mechanism
that
says
what
was
valid
is
no
longer
valid,
so
the
the
draft
proposes
ways
to
fix
this,
there's
a
new
element
and
fine
service,
which
is
a
URI
that
you
save
with
location
that
you
validate.
B
So
when
you
do
a
query
and
you
ask
for
validation,
you're
allowed
to
send
a
URI
in
and
the
server
will
save
that
URI
optionally,
it's
up
to
it,
whether
it
saves
that
your
eye
and
if
it
becomes
invalid,
it
sends
you
a
message
at
that.
You
or
I
saying
this
location
has
become
invalid.
You
should
go,
do
something
about
it
boom
and
then
there's
this
date.
B
This
as
update
that
you
can
use
in
the
query
so
that
you
can
say
I
know
that
there's
a
change
coming
I
want
to
be
able
to
have
a
new
location
in
my
my
list.
That
will
is
valid
as
of
the
date
of
that
plan
change.
So
you
can
say
tell
me
if
this
would
be
valid
at
this
date
and-
and
you
can
do
that
so
before
the
plan
change
occurs.
B
So
the
the
implementers
who
built
these
things
things
really
want
this
change
and
there's
been
a
sub-list
traffic
that
was
generated
by
the
guys
who
are
doing
this
implementation
to
say.
I've
looked
at
this
I
really
want
this,
and
that
means
it
read
the
document
they
really
understand
what's
in
there
and
they
really
want
it
for
their
implementations,
so
I'm
asking
that
this
one
be
adopted
and
that
we
review
it
and
get
it
out.
B
It's
I
think
it's
pretty
it's
a
pretty
simple
mechanism
really
all
it
does
is
add
a
couple
of
parameters
in
the
in
the
inputs
and
and
and
and
then
there's
an
error
that,
if
you,
if
it
didn't
save
your
your
you
are
I'll,
tell
you
that
it
didn't
save
your
URI
and
and
that's
all
there
is
to
it.
I
mean
it
doesn't
really
change
the
protocol
in
any
way.
B
Significantly
just
adds
a
couple
of
parameters
to
the
input
and
gives
the
server
some
work
to
do
and
saving
the
the
URI
and
it's
up
to
it
whether
it
saves
it,
it
can
happen
it
can
save
it
can
limit
how
many
your
eyes
it
saves
for
a
given
location.
It
can
limit
how
many
your
eyes
it
saves
for
a
given
client.
Who
knows
it
doesn't
matter.
It's
all
policy.
B
B
A
C
A
A
B
B
A
B
C
A
A
A
A
C
A
B
B
All
right
so
this.
What
this
does?
This
draft
allows
you
to
return
location
information
in
the
fine
service
response.
That's
what
it
does
it
lets
you
put
location
in
the
response,
so
you
put
in
a
query
with
location
information
in
it
and
you
get
some
some
location
information
back.
There
are
two
circumstances
in
which
you
would
use
this.
B
So
a
really
interesting
example
of
this
is,
if
you,
if
you
send
in
a
street,
address
without
a
city
name,
but
there's
only
one
instance
of
that
street
name
in
the
whole
state
or
the
whole
province.
We
actually
know
what
it
is
and
we
really
could
route
based
on
that.
But
we
really
don't
want
you
to
store
in
your
list
a
location
without
a
city
without
a
municipality
there.
There
are
more
technical
reasons
why
this
is
is
useful
to
have
information
like
the
county
name
when
you
didn't
supply
it.
B
If
the
county
is
used
for
routing
and
again,
the
circumstances
is
that
we
know,
because,
based
on
the
municipality
in
the
street,
address
where
you
are,
but
you
haven't
specified
what
the
county
name
is.
It
sits
there
in
another.
Another
example
is
that
we
have
in
the
in
the
pit.
If
which
means
in
the
location,
information
we
have
the
postal,
a
community
name
and
in
many
countries
that
that
that
the
the
name
that's
in
the
post
address
is
not
the
actual
municipality
and
the
emergency
systems
tend
to
use
the
actual
municipality
names.
B
And
if
so,
if
you
send
in
a
postal
address
and
its
unique,
we
can
say
all
right,
but
you
really
want
to
have
the
real
community
name,
the
the
real
city
name,
the
Miss,
appalling
name
again.
This
occurs
a
lot
in
the
US
and
it
occurs
somewhat
less
frequently
in
in
Canada.
So
we
would
like
to
be
able
to
say
well,
okay,
we
know
where
you
are,
but
please
put
this
information
in
the
list
in
the
record
and
the
record
in
the
list.
B
So
when
it
comes
back
in
the
emergency
call,
we
have
all
the
data,
the
other
circumstance
in
which
we
use
it
is
where
you
don't
have
a
unique
location.
You
you
give
us
information
and
it's
not
unique,
and
in
this
case
we
use
it
to
send
information.
That
was
a
did.
You
mean
so
it's
a
what
you
sent
was
invalid,
but
/.
B
You
meant
this,
and
here
is
one
or
maybe
more
than
one
valid
sets
of
location
information
that
it
might
be,
and
then
that's
used
as
a
prompt
to
the
user
when
they
entered
an
incorrect
address
that
perhaps
you
met
this
address
I
and
both
of
those
are
useful
because
you
don't
you
you
you,
we
were
trying
to
make
sure
that
and
many
as
many
cases
as
possible.
The
list
has
as
much
valid
information
as
we
can
so
when
the
membrane
that
validation
occurs
before
an
emergency
call
right.
So
we're
trying
to
get
this
to
happen.
B
B
And
this
one
is
already
ITF,
so
we're
really
just
looking
for
people
we're
begging
for
people
to
review
it.
We
will
have
some
Neenah
folks
review
it
again:
they're
not
regular
participants,
but
at
least
they
can.
They
can
tell
you
that
they've
looked
at
it
and
they're
the
folks
they're
going
to
implement
it,
but
I
again,
I'd
really
like
to
get
some
reviews
and
get
people
to
take
a
look
and
see
if
it's
all
right,
it's
it's
a
little
bit
more
of
a
protocol
change
than
the
prior
one.
B
The
prior
one
is
a
pretty
simple
change
to
the
mechanism.
This.
This
is
a
little
more
heavyweight
you're,
getting
a
full
set
of
location
information
in
the
response
that
is
currently
only
in
the
request.
It's
exactly
the
same.
It's
the
same
structures,
but
it
occurs
in
the
response
instead
of
the
request,
but
it
doesn't
change
the
protocol
in
any
substantial
amount.
It
just
gives
you
this
big
hunk
of
data
and
optional.
You
can
always
ignore
it
right
in
the
anybody
can
ignore
the
data.
B
A
B
B
It's
it
is
a
little
disheartening
to
have
this.
The
work
of
this
working
group
is
being
implemented.
We're
actually
deploying
this
stuff.
There
are
multiple
actual
deployments,
it's
not
being
deployed.
It
is
deployed,
it's
being
used
to
route
emergency
calls
every
day
in
a
couple
of
states
now
and
the
people
who
are
implementing
it.
Unfortunately,
don't
aren't
in
the
ITF
world
right
and
they
depend
on
me
and
and
and
Randy
and
a
few
of
a
few
others
of
us
Roger
Roger,
to
bring
the
work
here
to
get
it
done.
B
But
then
we
can't
get
any
kind
of
finishing
of
people
who
are
actually
deploying
this
stuff
and
saying
it's
great.
We
really
like
it,
but
we
need
these
little
things
and
it's
it's
a
it's
tough
to
to
deal
with
when
we're.
When
it's
going
to
be
it's
a
successful
protocol,
it's
really
amazing.
There's
there
are
at
least
ten
interoperable
implementations
of
loss
that
I'm
aware
of
when.
B
C
A
Randall,
gallon
site,
I
think
somebody
who
has
actually
implemented
from
the
draft
yeah,
particularly
in
interoperable
implementations,
would
be
an
ideal
person
to
send
a
note,
saying,
I've
implemented
this.
That's
all
they
have
to
say
is
I've
implemented
this.
This
is
good.
That's
yeah,
two
lines.
One
line
of
thing.
C
A
C
A
A
C
A
Cuff
but
I
tend
to
think
that
in
the
IETF
we
spend
not
nearly
enough
time
documenting
our
successes,
like
their
focus.
So
much
failure,
and
and
like
the
proportion
of
like
focus
on
failure
to
success,
is
completely
insane
right.
So
I
wonder
if
you
know
we
could
channel
some
of
that.
You
know
get
some
of
them
to
talk
about
their
implementation
experience
and,
and
you
guys
to
contribute
and
just
like
write
it
down.
You
know
what
I
mean
I,
don't
know
it's
I,
don't
know
exactly
what
the
format
would
be
meals.
This
is
like.
A
Ietf
journal
or
something,
but
you
know
like
like
document
how
it
went
and
I
mean
this:
it's
a
number
of
emergency
calls
using
it
I
our
amazing
PR
right
like
yeah,
you,
never
you,
you
can
never
exploit
anything
more
than
an
emergency.
So
what
like
I,
don't
know
just
just
something
to
think
about,
and
we
sure
we
can
chat
offline.
Let's,
let's
do
that
beam
because
I
I.