liason & the 5 priorities

>   If there is an existing group that can extend a protocol or
>   mechanism, IEPREP will generate only a requirements document for
>   those groups to evaluate. If there is not an existing group that can
>   extend a protocol or mechanism, IEPREP will prepare requirements and
>   discuss the extension of that protocol/mechanism or
>   protocols/mechanisms within IEPREP.
>
> This is a promise to liason with anybody and everbody that intends to
> work in this area and to step back and let that other group do the
> protocol work.  The IESG favors (with good reason) WG charters that
> propose to do work rather than WG charters that propose to sit back
> and watch the ITU do work in that area.  A good example (and closely
> related to this sort of work) where the result coming from the ITU was
> not at all useful is the ITU QoS requirements work in the mid to late
> 1990s.  This may be looking too much like more of the same.

I don't believe the intention was for IEPREP to rubber stamp work  
from other groups, and we can fix the passage to stress that IEPREP  
would discuss and consider efforts from other groups.   I think there  
is a bit more strength in having an existing set defined by another  
group (and stronger if deployed), then in having a new set specified  
from scratch.  Others may disagree.  But again, strength shouldn't  
correlate to automatic acceptance.

> As long as the number of priority/preemption classes remains too open
> ended, the mapping onto DSCP and Diffserv-TE remains uncertain.  For
> example, there has to be a strong technical justification for five
> priority classes, not just "because ITU specified five" before there
> is much of a chance for a set of new DSCP values to be assigned as
> anything other than experimental.

yes, a good point.  one thing to take note of is that there are  
several installed deployments of the "five" specified by ITU (and  
other groups).  one example can be found in land mobile radio used by  
first responders and specified by APCO on their Project 16 and  
Project 25 efforts.  Another is the MLPP work from ITU and deployed  
in systems like Autovon by DoD, NATO, and some others.  There is also  
the "five" found in cellular networks in the UK and in WPS in the US.

In looking at these deployments, one will notice that the five are  
pretty much in the form of role-based priorities, where the priority  
is assigned based on the role of the user (executive leader,  
battalion chief, etc).  Where older historic systems like Autodin  
rely on content-based prioritization is based on the importance of  
the content of the data being sent regardless of the role of the  
user.  Its easier to implement role-based instead of content-based  
prioritization.

There are some other examples, but a question arises of whether its  
productive to have 5 pushed down into a one-to-one mapping at the IP  
layer in the form of DSCPs given the limited number of bits to work  
with.  One expired draft advocated this direct mapping, while  
RFC-4542 makes an argument for a different approach.  In either case,  
the headache is compounded if other organizations raise the number  
from 5 to 7, 9, 15(?).

-ken