►
From YouTube: IETF93-DIME-20150722-1300
Description
DIME meeting session at IETF93
2015/07/22 1300
A
A
A
A
We
still
had
the
group
signaling
entertaining
us,
I,
don't
know
for
how
long
and
then
the
also
the
intent
in
secular,
Greek
ones
document.
So
that
is
a
quad
recently
revised
addressing
the
comments
from
Steve.
So
thank
you
and
it's
in
those
days
that
T
it's
waiting
for
the
proto
right
up
and
then
do
the
submitted
to
the
NIH
three.
A
A
B
This
just
stood
down
and
quick
point
on
the
Asian
overload
and
great
control
I
just
like
to
solicit
comments,
not
it
okay.
We
did
this
not
on
the
agenda
because
there
been
no
changes
since
the
last
meeting,
but
we
need
we
need
review
of
those
documents
so
that
they
can
move
forward
right
and
I'd
like
to
think
I
got
it
under
percent
right
and
the
way.
A
A
B
C
B
So
the
I
believe
we
have
consensus
on
having
supporting
a
period
of
here
mechanism
for
load
where
diameter
server
would
communicate
its
load
to
its
peer
being
an
ancient
our
client.
It's
our
multiple
agents
in
the
chain.
An
agent
would
do
the
same
or
a
nature
could
do
that
to
the
client
as
well,
and
so
that
aspect
of
it
I
think
we
have
consensus.
I
haven't
heard
anybody
pushing
back
on
that
for
quite
a
while.
The
AVP
definition
for
this
is
TBD.
B
B
In
the
load
report
itself,
and
then
the
receiver
of
that
load
report
can
determine
whether
it
really
is
its
peer
or
not.
And
if
it's
not
it's
pure
than
that,
that
load
report
presumably
transited
through
an
on
supporting
agent
and
and
that
receiver
of
the
load
report
can
ignore
it
or
should
ignore
it,
because
it's
not
applying
to
its
peer.
B
Proposal
is
the
frequency
of
sending
load.
Information
is
an
implementation
decision
person.
The
element
to
ascending
load
information
is
giving
a
suggestion
to
the
to
its
peer
on
how
much
traffic
or
how
busy
it
is.
How
important
that
element
that
is
sending
it
considers
that
load
information,
whether
it
sends
never
request
whether
it
sends
it
when
the
load
information
changes
by
some
amount
or
or
sends
it
periodically
every
10
seconds
every
second,
whatever
that
might
be.
B
You
know
an
input
into
a
routing
table
with
some
kind
of
balance,
some
kind
of
waiting
on
each
of
the
piers
that
can
receive
a
request
and
use
that
then,
as
a
load
distribution
as
part
of
a
load
distribution
algorithm.
Okay,
next
slide.
So
the
open
question
is
whether
we
also
support
the
concept
of
server
load
and,
more
accurately,
I
should
say,
endpoint
load,
because
obviously,
requests
can
go
one
way
or
the
other,
but
in
general
it's
probably
going
to
be
servers
who
wear.
This
is
more
important.
B
So
I
is
art
that
this
is
required
to
be
supported
or
as
a
use
case.
That
should
be
supported
because
there
are
deployments
in
the
in
the
world
today.
I
can
I
can
name
greater
than
three
that
won't
name
them
for
confidentiality
reasons,
but
I
can
name
greater
than
three
they're.
Probably
I
suspect
that
there
are
greater
than
that.
I
mean
it's
it's
it's
often
on
the
size
of
network
consideration
where,
where
that's,
where
its
consideration
go,.
C
B
Couldn't
say
that,
but
you
could
yeah
specifically,
so
the
there
are
cases
where
we're
very
large
diameter
networks
are
partitioned,
for
instance,
where
a
set
of
HS
SSR
are
handling
a
subset
of
the
users.
It
could
be
a
case
where
I'm
a
policy
side
of
the
world
where
that's
partitioned
based
on
geography.
Possibly
there
are
other
cases
where
it
may
not
be
a
partition
network,
but
there
is
a
node
other
than
the
previous
hop
to
the
server
that
is
doing
server
selection.
B
B
Don't
think
that
there's
a
lot
of
value
in
arguing,
arguing
that
I
think,
in
my
view,
the
base
Beck
is
inconsistent
and
what
in
in
whether
or
not
more
than
realm
can
be
used
by
some
of
the
other
than
the
previous
hot
for
routing
purposes.
I.
Think
if
you
read
parts
of
the
spec,
it's
pretty
clear
that
if
that
cannot
be
handled
in
some
smart
parts,
it
implies
that
it
can
that
that's
just
kind
of
where
the
draft
is.
What
I'd
like
to
propose.
B
Is
that,
because
we
have
real
world
needs
for
this,
that
we
that
we
in
the
load
wrap
itself.
We
could
separate
this
out
if
we
want,
if
we
felt
like
we
needed
to
have
a
bit
Sun
on
the
base
back
I
think
that's
probably
not
necessary.
What
I
would
suggest
that
we
have
a
section
in
the
in
the
load
draft
that
talks
about
this
specific
scenario
where
we
have.
D
D
Think
you
play
it
may
be
so,
for
instance,
we
have
the
case
where
so
in
your
in
your
proposal.
Also
initial
probability
will
based
on
the
fact
that
the
presence
of
the
destination
post
in
the
request
may
impact
the
routing
decision
correctly.
That
is
not
so
clear,
but
I
think
it
is
something
that
could
be.
D
That
could
be
indicated
in
a
separate
section
saying
that
when
you
are
using
this,
because
actually
it
would
mean
that
it
could
be
application
specific,
for
instance,
or
in
a
specific
context,
it
does
not
apply
that
any
node
they
emit
super
means
that
if
any
node
in
the
middle
doesn't
support
a
basic
stuff
doesn't
support
this.
It
would
not.
It
may
not
work
the.
D
D
For
instantaneously
gpp,
spec
or
whatever,
is
it
something
that
need
to
dis
on
the
dies?
It's
something
not
so
really
that
at
this
time,
because
we
can
decide
if,
if
we,
if
we
did
this
after
that,
but
I
think
that,
having
having
information,
saying
that,
if
you
are
using
this
for
any
purposes,
that
is
not
strictly
diameter
base,
the
related
I
think
it's
something
valuable
to
to
indicating
draft.
But.
D
D
B
E
A
E
B
E
B
B
So
next
slide
so
I'm
the
AVP
design
I
mean
this
is
a
fairly
simple,
fairly
straightforward
mechanism,
since
we
don't
have
a
negotiation
mechanism,
it's
the
someone
who
is
sending
load
sends
it
no
matter
what
and
then
somebody
who
can
receive
it
processes
that
it's
a
it's
a
hint
not
and
not
a
person.
There's
no
prescriptive,
behavior
tied
to
it.
So
it's
so
we
decided
earlier
not
to
have
a
capability
negotiation
like
we
have
with
overload.
If
we
run
into
things
that
make
it
look
like
we
need
it,
then
we
can
obviously
change
that
decision.
B
So
it
looks
something
like
like
this,
where
you
have
a
grouped
abp
called,
maybe
load
or
we
come
up
with
other
names.
If
we
want
to
that,
has
a
value
and
the
identity
of
the
note
itself.
Now
we
potentially,
we
could
also
add
a
sequence
number
if
we
felt
that
was
important
as
well
make
it
to
handle
the
case
where
requests
are,
where
load
reports
come
in
out
of
sequence,
just
to
make
sure
you're
not
getting
the
wrong
information.
B
C
Load
balance
to
avoid
overload
right
and,
and
so
there's
there's
room
for
a
little
bit
of
error
there
right
if
you're
off
a
little
bit
versus
if
you're
already
in
overload,
you
know
considering
the
nature
of
you,
know,
surges
and
spikes
right
being
a
little
off
could
mean
you're,
killing
the
network
and
so
I
think
that
would
probably
be
over
killing
kidding
it
simpler
for
the
load.
What
other
sequence
would
probably
be
better
designer
and.
E
E
B
D
B
B
If
we
support
it,
I
would
envision
as
something
like
don't
have
the
text
in
a
slide,
but
the
way
that
it
would
operate
would
be
something
like
servers
which
would
still
just
generate
a
single
load
report,
and
then,
if
there
is
an
agent
there,
it
would
propagate
that
load
report,
maybe
modify
it
to
be
a
server
load
report
and
then
generate
a
load
report
for
itself
as
well
or
the
other
way
to
do.
It
is
that
the
server
generates
to
load
reports
that
have
basically,
they
have
the
same
information
just
to
two
different
types.
B
We
could
do
it
either
way
the.
If
we
want
to
make
it
easier
on
the
endpoints,
then
we
could
certainly
have
the
agents
that
know
there
is
a
need
for
propagation
of
of
that
server
report
generate
this.
The
server
report
are
the
endpoint
report
at
that
point,
because
they're
there
are
networks
where
that
that
would
never
be
used.
If
you
have
a
client
talking
directly
to
an
eighth
to
a
server
without
an
agent
there,
the
server
is
generating
to
reports
for
the
same
with
the
same
information.
For
no
reason.
B
So
that's
that's
one
approach
to
do
it.
We
could
do
it
either
way.
As
far
as
a
VPS
are
concerned,
two
options
when
we
have
a
load
type
abp
as
part
of
the
grouped
load
AVP
with
which
indicates
whether
it's
a
pure
report
or
a
employed
record,
or
we
could
have
a
completely
separate
set
of
ABP's
I
new
groups
AVP
some
called
something
like
servers,
load
or
end
point
load.
That
has
the
same
information
in
it.
The
same
two
sub
baby
peas
in
it
that
we
talked
about
earlier
I.
F
Perhaps,
on
these
two
possibilities
I
would
have
a
trend
toward
the
second
one,
so
new
group
AVP
and
maybe
for
two
reasons.
First,
in
some
networks
they
may
only
to
use
the
pier
selection
sort,
may
decide
not
to
user
satisfaction,
so
for
them
it
would
be
a
dilute.
They
don't
need
to
look
at
the
road
Titan
or
to
waste
beer.
F
E
B
B
B
That
is
the
pier
and
you
have
that
report
coming
from
the
end
point,
you
need
to
have
a
way
of
differentiating
those
two
and
maybe
that's
the
point
you're
making
one
way
to
do
that
is
to
include
a
low
type
of
AVP
and
just
indicate
that
this
is
either
a
type
of
pier
or
type
of
endpoint.
The
other
way
to
do
it
is
is
a
a
new
group
day.
Bp
want
to
have
to
group
day
be
peace,
one
called
peer
load
and
the
other
called
server
load.
Our
end
point
load,
yeah,
I'm,.
E
E
Bring
that
last
meeting
the
complicated
network
pictures
you
had
with
regard
to
housing
couple
of
servers
which,
which
are
proxying
at
least
a
VPS
and
I,
know
that
we
have
in
sipped
the
history
in
for
header
like
something
like
that,
which
is
a
very
complicated
mechanism.
The
problem
is
I,
don't
want
to
have
it
over
complicated
red
stuff
afloat
with
regard
to
indicating
how
it
should
decide
on
routing
mechanisms.
That's
that's
my
point.
What
I
would
like
to
make?
B
And
this
is,
as
far
as
choosing
the
next
hop
that's
just
giving
you
additional
information
they
can
use
to
choose
that
nyx
hop
can
either
be
information
based
on
the
host
or
bit
web
based
on
the
pier
are
can
be.
If
that
note
is
doing
server
selection,
it
can
be
information
based
on
the
server
load.
Yes,
but
I
think
it
should
be
very
straight.
Whichever
way
we
go,
it
should
be
very
straightforward.
D
All
right,
yes,
yeah
I
had
one
question:
that's
for
the
second
one
or
just
even
the
second
type,
whatever
the
final
format
that
we
will
select
for
the
AVP,
but
for
the
save
load
case,
do
we
need
to
have
something
else
than
the
because
it
would
not
be
from
a
period
would
be
from
a
note
such
that
is
not
appear,
so
you
have
multiple.
So
you
don't
know
exactly
when
you
will
receive
this
information
and
how
you
would
be
refresh.
D
So
you
may
assume
that
just
this
ever
bleep,
this
sparxy
will
be
in
the
path
of
any
requests
and
so
on,
but
actually
it
will
depend
on
the
implementation
that
you
would
have
so
I
was
wondering
if
we,
if
we
need
to
have
something
about
the
freshness
of
the
information
received.
That
is
not
the
same
force
appear
because
with
the
piece
you
have
a
direct
connection,
so
you
will
receive
always
something
yeah.
D
Least,
it
wasn't
open
question
to
the
ante
de,
because
we
had
this
discussion
also
last
time
and
to
ensure
that
the
information
will
be
ticking
to
a
combat,
for
it
could
be
implementation-specific
anyway,
sure
better.
You
may
assume
that
it's
not
the
same
level
as
a
reformation
in
as
an
information
received
from
the
pier,
because
from
the
pier
you
will
always
exchange
something,
or
the
connection
is
closed
from
the
server
you
don't
know
when
you
will
receive
a
new,
a
new
new
information,
yeah.
B
D
B
B
Okay!
Next
slide,
there
are
some
security
considerations
that
we
need
to
to
think
about.
This
is
the
this
load
mechanism,
if
you're
thinking
about
the
way
of
using
it
in
nefariously,
and
if
you
wanted
for
some
reason
to
take
all
of
the
traffic
yourself
or
I'm,
try
to
influence
things
to
get
more
traffic
sent
to
you
if
your
server
is
getting
paid
on
a
per
transaction
basis
and
your
competitors
server
is
getting
paid
on
the
per
transaction
basis.
You
might
want
to
use
this
as
a
way
of
getting
more
traffic
sent
to
you.
B
Are
you
conceivably
could
use
it
to
cause
all
the
traffic
to
be
sent
or
more
traffic
to
be
sent
to
your
competitors
server
as
a
way
of
making
it
look
bad
or
something
I
mean
these
are
kind
of
strange
scenarios
to
talk
about,
but
but
something
to
consider,
and
then
there's
also
a
consideration
that
that
these
these
load
reports
could
be
used
to
infer
network
topology
information.
So
it's
probably
something
that
you
don't
want
to
transit
domain
boundaries.
B
So
no
no
answers
to
what
to
do
about
these,
but
just
something
that
we
need
to
be
thinking
about
as
we
progress
the
draft
and
if
people
think
of
other
security
considerations
that
need
to
be
factored
into
the
design
of
the
draft.
Please
put
them
on
the
list.
We
need
to
get
the
list
activity
going
a
little
higher
here
next
slide.
B
Okay,
so
do
we
have
a
decision
on
the
server
load
or
the
end
point
load,
separate
section
talking
about
if
you're,
if
you're,
in
a
scenario
where
this
is,
is
needed,
the
this
structure
of
AVP
would
be
used.
Some
of
the
considerations
may
be
about
frequency
of
sending
that
the
this
endpoint
information,
whether
it's
sent
by
the
server
itself
or
the
agent
in
front
of
the
server
all
that
would
be
in
that
separate
section.
We
have
a
section
on
Pierce
up
the
section
on
end
point:
everybody,
okay,
with
that
yeah.
D
C
B
In
general
yeah,
I
think
it's
it's
it's
really
more
about.
If
you
have
the
need
to
insert
destination
host
into
the
request
them,
you
can
use
this
information
to
determine
what
destination
host
certain
the
request.
Obviously
you're.
In
most
cases,
you're
probably
doing
it
to
influence
routing
by
subsequent
nodes,
but
you're,
just
inserting
it
and
how
it's
used
later
is
is
up
to
the
application
and.
A
A
D
B
Yes,
so
I
think
we're
saying
the
same
thing:
you'll
make
sure
that
I
get
the
text
wrong,
I'm
sure
yeah,
good
okay,
so
the
next
step,
then,
is
to
flesh
out
the
the
mechanism
parts
of
the
draft.
That
should
be
pretty
straightforward
to
do
work
with
jean-jacques
on
that
to
get
ready,
Pratt
hope,
hopefully
by
Yokohama.
I
would
I
would
be
surprised
we
didn't
have
it
by
by
Yokohama,
okay,
that's
it
and.
D
D
I
think
it
is
a
general
comment
for
the
document,
so
we
we
said
that
at
the
last
meeting
we
need
to
have
people
involved
in
order
to
progress
the
work,
because
you
can
see
that
now
from
the
iesg.
We
have
feedback
to
say
that
we
need
to
have
a
discussion
and
so
on
and
to
ensure
that
the
as
the
p228
at
the
project,
the
output
of
the
working
group,
is
a
fair
project
than
direct.
So
we
need
we
need
the
contribution.
Maybe.
D
B
B
A
You
can
be
somewhere
around
and
it
so
for
the
dog.
I,
don't
have
any
slight
waste
for
that,
but
the
couple
of
things
so
so
the
document
itself
is
now
in
light,
applause
go
so
there
was
one
week
kind
of
sanity
period
before
that
which
was
caused
by
the
unusual
situation
that
yet
the
knowledge
supply
increases.
Coaches
were
both
on
the
Tokyo
and
Seoul.
A
The
ad
Stephen,
and
a
couple
of
other
guys
just
wanted
to
make
sure
that
they
are
no
no
issues
about
data
and
the
process
had
been
done
in
a
proper
way
and
the
actually
the
as
we
did
also
is
that
he
and
we
could
show
that
the
and
the
whole
process
has
been
documented.
It
is
ok,
actually
so
in
a
sense
that
they
started
using
issue
tracker
from
the
beginning
and
every
everything
can
be
traced
down
to
the
constant
process.
Ali
and
the
actual
a
discussion
has
been
massive.
A
B
Development
on
that
point,
I
know
Stephen
had
given
some
input
prior
to
the
ITF.
Last
call
that
we
need
to
comment
on
you
know
I'll
take
care
of
that
after
I
Jeff
last
call
finishes.
If
we
get
anything
else
obviously
will
reflect
that,
and
there
were
a
couple
of
comments
that
came
between
meetings
that
that
might
require
some
tweaks
in
vacuity
are.
A
D
Anyway,
if
if
there
is
a
real
concern
about
the
texts,
chrome
text
and
I
need
for
improvement,
this
need
to
be
done
now
during
the
hf
last
call.
It
cannot
be
done
after
that,
because
after
the
final,
so
the
end
of
the
period
of
the
last
call
the
we
will,
we
can
modify
the
document,
but
only
for
you
can
edit
or
your
stuff
and
so
on,
but
it
would
be
a
ready
for
publication
after
that.
D
A
One
thing
that
I
would
like
to
bring
up
that
avoid
kind
of
opening,
even
if
you
had
some
issues
that
that
required
a
lot
of
discussion,
so
I
would
I
winkle
it's
not
to
reopen
those
that
we
treats
conscience
or
even
if
that
was
rough
yeah.
So,
but
if
there
are
Terry
issues
like
problems
and
non-working
stuff
dose
of
course
need
to
be
addressed
right.
So,
yes,
after
for
all
the
document
is
in
a
fine
process.
So
I
would
assume
that
if
everything
goes
okay,
we
may
they'll
have
autopsy
number
in
two
months.
B
F
B
So
these
are
some
of
the
use
cases
that,
in
discussions
I
had
with
various
people
were,
were
brought
forward.
The
first
responder
emergency
call
related.
There
may
be
differentiated
services
cases
where
you
give
a
better
promise
better
service
to
one
customer
over
another,
and
you
could
use
this
to
implement
that
potentially
and
then
also
their
application
specific
priorities,
potentially
where
for
the
same
request,
you
might
want
that
request
handled
differently.
Based
on
the
context
that
that
request
is
happening
where
the
example
that
was
given
to
me
was
the
ol.
C
And
actually,
another
example
would
be
for
government
priority
services
as
well
as
right
for
the
first
responders,
where
they're
using
the
HPA,
the
high
priority
access
capability
and
so
you're,
making
sushi
ating
pain
in
order
to
get
high
priority
access
from
the
ue
to
the
adobe
right
to
the
MMA.
If
you
don't
have
the
same
level
of
priority
than
getting
from
the
mme
to
the
HSS
and
then
so
and
so
on,
so
does
not
yeah.
B
Doesn't
help
yeah
yeah
breaks
down
all
the
good
work
done
in
the
earlier
parts
of
the
process,
yeah,
okay,
so
next
slide,
so
the
IRA
fresh,
the
draft,
its
that's
now
is
0-1
and
it
actually
contains
a
fairly
complete
proposal
for
mechanism.
It's
pretty
straightforward.
It
defines
an
AVP
for
carrying
transaction
priority.
We
talked
about
whether
it
should
apply
to
a
transaction
or
a
message.
B
We
decided
as
a
group
in
the
in
this
room
in
dallas
this
same
type
of
room
in
Dallas
at
least
that
transaction
made
the
most
sense,
so
the
same
priority
would
apply
to
two
requests
and
answers.
Obviously
that
was
early
discussion.
So
if
we
change
that
decision,
we
certainly
can
we
decided
to
go
with
five
priorities
levels.
B
B
Presumably
you
would
have
a
queue
of
something
like
a
queue
of
messages
at
each
priority
and
decide
on
routing
of
those
requests
are
throttling
of
those
requests
based
on
that
Q.
The
Q
with
requests
it
sits
in.
It
could
also
be
used
by
the
target
of
the
request
by
a
server
or
client
from
make
for
making
resource
decisions
it
might
you
might
receive
an
HSS
taking
a
higher
priority
request
and
processing
it
before
it
would
process
a
lower
priority
request
next
slide.
B
Presumably,
applications
would
would
set
parameters
around
when
to
use
priority
0
priority
one
priority
to
the
usage
of
the
priority
by
agents,
and
then
servers
would
be
up
to
individual
implementations,
but
probably
with
some
some
guide
text
with
guidelines
around
how
you
might
want
to
use
it,
applications
could
specify
descriptive.
Behavior
must
level
prior
most
level
requirements
on
how
to
use
the
priority
stuff.
This
draft
does
presume,
presumably,
would
not
leave
that
to
applications
and
then,
where
applications
don't
specify
a
specific
behavior,
then
its
implementation,
specific
fairly
obvious.
B
B
You
could
foresee
the
message
priority
being
used
to
to
try
to
get
higher
higher
preferential
treatment
for
your
client
over
somebody
else's
over
some
other
client.
So
if
somebody
comes
in
there
and
starts
marketing
everything
as
priority
for
that
kind
of
defeats,
the
service
are
the
defeats.
The
purpose
of
the
whole
mechanism,
so
I,
don't
have
an
answer
to
how
we
handle
that.
But
that's
that's
one
consideration
the
there
may
be
scenarios
where
it
makes
sense
for
agents
to
insert
the
priority.
B
For
instance,
if
you
got
it,
if
you've
got
clients
that
do
not
get
support,
the
capability
and
agents
can
you
may
well
then
have
have
the
agents
inserted
new
as
a
proxy
for
the
for
the
clients
has
the
same
potential
for
abuse
and
I?
Don't
know
if
if
there
are
scenarios
here
that
says
because
of
this
potential
for
abuse,
you
want
to
sign
the
ABP's
or
make
sure
you
really
know
who
originated
the
AVP.
So
you
can
act
on
it
made
act
differently
on
a
plant
inserted
AVP
versus
an
agent
inserted,
a
beefy,
possibly
I.
B
B
The
GX
application
defining
things
defining
things
in
a
slightly
different
way
than
the
RX
application
and
causing
some
kind
of
strange
interactions
them
and
the
one
case
where
I
can
see
where
this
might
be,
where
some
guidelines
might
be
put
in.
There
would
be
that
last
use
case
where
we
have
within
an
application.
The
same
request
type
having
different
priorities.
Well,
maybe
that
differentiation
would
be
using
priorities,
one
and
two,
and
if
you're,
if
you're
doing
the
emergency,
responder
type
priorities,
use
priorities.
B
C
You
know,
ABC,
but
not
XYZ,
ok,
and
so,
therefore,
if
I
received
from
XYZ
I
will
strip
it.
In
addition,
with
respect
to
the
values,
the
same
concept,
you
know
with
our
pH,
where
you
have
a
default
value
arm
when
you
don't
know
the
actual
priority
of
that
communication
per
se.
But
you
know
it's
priority
communication,
you
know,
you
know
would
be
left
up
to
local
policy,
and
so
we
don't
really
need
to
get
into
details
with
that
up
here.
I
think
yeah.
B
I
was
was
never
suggesting
any
less
level
wording
here,
but
maybe
some
but
some
guidelines
again.
The
really
the
concern
is
that
the
s6,
a
application
team,
might
take
on
a
different
philosophy
than
the
PCC
application
team,
and
it
could
well
be
that
this
for
the
same
scenario,
emergency
responder
being
the
case
PCC
guys
to
find
priority
to
as
being
the
case
in
the
Essex
a
to
define
priority
for,
and
it
just
doesn't
mix
it
all
together.
C
Okay,
so
Martin
dolly
yes,
that's
true,
and
but
okay,
you
know,
for
instance,
you
know
within
ATT.
We've
had
this
discussion
because
of
the
fact
that
we
realize
that
there
may
be
coexistence
of
mission-critical.
You
know
the
responders,
you
know
on
the
same
frequency
band
and
within
the
same
you
know
you
know
a
core
network
as
the
government
priority
in
Soho,
each
carrier
is
going
to
create
guidelines
arm
in
the
US.
C
We
have
a
guideline
stock
and
you
know
being
defined
within
Addis,
which
is
the
the
the
standards
for
North,
America
and
so
other
nations,
because
with
respect
to
both
those
topics,
Public
Safety
and
government
priority
services
that
would
be
making
use
of
this.
It's
really
a
national
issue,
there's
not
really
a
rule
per
se.
That's
going
to
be
one
size
fits
all
globally.
So.
B
F
There's
not
like
a
totem,
yes,
the
it's
about
the
between
applications.
If
it
leads
out
to
ensure
on
Monday
and
homogeneity,
the
use
of
the
service
priorities
not
to
favor
one
application
against
another
I
I
do
think
that
it's
an
operator,
local
policy
so
that
he
can
configure
yes
rarities
in
the
different
applications.
We
are
yes
this
this
way
to
do
it.
I
don't
know
but
nettle
s,
dispersion
of
immunity
is
a
bit
there
and
also
it's
also
between
operators.
F
So
if
you
receive
a
priority
from
an
external
network
when
it
comes
in
your
network
now
to
touch
you
have
to
map
in
the
echa,
the
priorities
form
external
penalties
to
your
own
priorities
in
the
network.
Man,
so
I
think
there
and
also
this,
but
simply
were
coming
back
to
some
implementation
aspects.
F
Another
remark:
it's
about
the
number
of
levels
because
the
priority
concept:
it's
not
the
first
time
there
are
privacy
levels,
defining
many
specifications
and
children,
five
I
have
no
I,
am
NOT
an
alternative,
but
perhaps
we
have
to
recheck
about
what
is
used
in
other
places
to
see
if
this
number
is
considered
rather
rather
consistent.
This
is
enough
not
to
be
and
the
other
question,
but
not
in
the
resolution.
What
is
the
hierarchy?