RE: draft of a core protocol spec

At 05:36 PM 11/10/2002 -0500, Glenn Parsons wrote:

>Frank, 
>
>You have noted the various minor corrections to the details on RPR that you have included in this draft.  However, I have a more fundamental concern.  As we are doing for the RPR MIB, I believe that the specification for RPR should be definitively in IEEE 802.17.  That is, your proposed document (or any IETF document) should not include any details of RPR that could be construed as being a definition.  Even if a subset of the RPR definition looks the same, I would suggest that it may be interpreted differently.  That is something we want to avoid.  This document should only describe the payload format when it is IP, the details of RPR are irrelevant (since it is a broadcast media).
>
>As such, I would recommend that all of the RPR pedagogy (all of section 3 and most of 4) be deleted. 

Glenn
Thanks for your comments

In no way should this draft be considered to attempt to replace
or supplant the 802.17 work. Section 3 is meant to be just enough
of an overview of the technology so that people reading the spec
by itself (such as the IESG will be doing when they review it) will
be able to understand the rest of it. I would be more than happy
to put some stronger text at the front saying that the section is
just a brief, highlevel, description of the aspects of 802.17 that
are relevant to the work that IPoRPR is doing, and/or move it to
an appendix. But I do feel that having some "RPR pedagogy" is
both useful and necessary.

As to section 4 -- that section's goal is to describe various 
common things that one needs to do to do IP/MPLS over 802.17.
Things like what values to put in the Ether-type field, where
the payload is to begin, and so on. Some of the things in 
here that I thought were 'adjustable' (like the TTL) turn out
not to be and those would get moved into section 3. Also,
some things may seem to be too obvious (e.g. that the
IP header immediately follows the 802.17 header, or that the
packet type is "data") but one thing that I've learned
over the last 20+ years of doing TCP/IP development is that
more often than we would like, the engineers writing the
code need to be told these simple things.

Again, thanks for taking the time and brain-cycles to read
and comment on the document.

Frank Kastenholz