RE: draft of a core protocol spec

>>        Use of these 
>>        features by IP and MPLS is beyond the scope of this 
>>        specification.  Their use will be specified in a later 
>>        document.
>>lb] We could at least define the mapping of DiffServe to the RPR service
>>classes 
>
>I imagine that this could lead to a long discussion (having watched 
>how long it took Diffserv to do something that was supposed to be 
>"simple"...). The purpose of this note is to define the basic, no 
>bells, no whistles, version of IPoRPR. The idea is that these are
>things that we can easily get consensus on. This would allow
>implementation and experimentation work to begin. Using the
>"advanced" features of 802.17 is something we intentionally put
>off until we recharter the working group to go into those areas
>(which should happen Q1 or Q2 of next year). It's been my experience
>in the IETF that keeping a very constrained charter keeps the 
>working group tightly focussed on the issues at hand and that
>means that the working group actually gets things done in a timely
>manner. 

If the reason to put this off is because this first version uses only classC, then fine. But as for the reason specified above, you should have very little worry. When I was designing the service classes for RPR, I modeled them after diffserv. There is an almost perfect mapping both ways between EF and classA, AF and classB, and BE and classC.

jl