RE: draft of a core protocol spec
"Glenn Parsons" <[email protected]> Sun, 17 Nov 2002 14:20:14 -0500
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <[email protected]> |
This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C28E6E.5AE36938 Content-Type: text/plain; charset="iso-8859-1" Frank, You have confirmed my concern. In my short experience (~10 yrs) I notice that designers read the least number of docs before implementing. That is, if there any description of RPR in this document (beyond a short abstract), I submit that it would be taken by some to be the 'de facto' definition of RPR. I would prefer to avoid that situation. As you may be aware, IEEE 802.17 will be forwarding a copy of the WG ballot version of RPR (similar to an ID in IETF WG last call) to the IESG (for MIB review) and will also copy this WG. As a result, I do not see any issue with not being able to access the document. As a result, my comment stands that this document should contain no RPR descriptive text beyond a simple abstract. Cheers, Glenn. > ---------- > From: Frank Kastenholz > Sent: Monday, November 11, 2002 3:59 PM > To: Parsons, Glenn [CAR:6L81:EXCH]; [email protected] > Subject: RE: [IPORPR] 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 > > ------_=_NextPart_001_01C28E6E.5AE36938 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 5.5.2655.35"> <TITLE>RE: [IPORPR] draft of a core protocol spec</TITLE> </HEAD> <BODY> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Frank,</FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">You have confirmed = my concern.</FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">In my short = experience (~10 yrs) I notice that designers read the least number of = docs before implementing. That is, if there any description of = RPR in this document (beyond a short abstract), I submit that it would = be taken by some to be the 'de facto' definition of RPR.</FONT></P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">I would prefer to = avoid that situation.</FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As you may be aware, = IEEE 802.17 will be forwarding a copy of the WG ballot version of RPR = (similar to an ID in IETF WG last call) to the IESG (for MIB review) = and will also copy this WG. As a result, I do not see any issue = with not being able to access the document.</FONT></P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">As a result, my = comment stands that this document should contain no RPR descriptive = text beyond a simple abstract.</FONT> </P> <P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Cheers,</FONT> <BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Arial">Glenn.</FONT> </P> <UL> <P><FONT SIZE=3D2 FACE=3D"Arial">----------</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">From:</FONT></B> <FONT = SIZE=3D2 FACE=3D"Arial">Frank Kastenholz</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">Sent:</FONT></B> <FONT = SIZE=3D2 FACE=3D"Arial">Monday, November 11, 2002 3:59 PM</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">To:</FONT></B> = <FONT SIZE=3D2 FACE=3D"Arial">Parsons, Glenn [CAR:6L81:EXCH]; = [email protected]</FONT> <BR><B><FONT SIZE=3D2 FACE=3D"Arial">Subject:</FONT></B> = <FONT SIZE=3D2 FACE=3D"Arial">RE: = [IPORPR] draft of a core protocol spec</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Monaco">At 05:36 PM 11/10/2002 -0500, Glenn = Parsons wrote:</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Monaco">>Frank, </FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">></FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">>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).</FONT></P> <P><FONT SIZE=3D2 FACE=3D"Monaco">></FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">>As such, I would recommend that = all of the RPR pedagogy (all of section 3 and most of 4) be deleted. = </FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Monaco">Glenn</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">Thanks for your comments</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Monaco">In no way should this draft be = considered to attempt to replace</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">or supplant the 802.17 work. Section = 3 is meant to be just enough</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">of an overview of the technology so = that people reading the spec</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">by itself (such as the IESG will be = doing when they review it) will</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">be able to understand the rest of = it. I would be more than happy</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">to put some stronger text at the = front saying that the section is</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">just a brief, highlevel, description = of the aspects of 802.17 that</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">are relevant to the work that IPoRPR = is doing, and/or move it to</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">an appendix. But I do feel that = having some "RPR pedagogy" is</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">both useful and necessary.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Monaco">As to section 4 -- that section's = goal is to describe various </FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">common things that one needs to do = to do IP/MPLS over 802.17.</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">Things like what values to put in = the Ether-type field, where</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">the payload is to begin, and so on. = Some of the things in </FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">here that I thought were = 'adjustable' (like the TTL) turn out</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">not to be and those would get moved = into section 3. Also,</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">some things may seem to be too = obvious (e.g. that the</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">IP header immediately follows the = 802.17 header, or that the</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">packet type is "data") but = one thing that I've learned</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">over the last 20+ years of doing = TCP/IP development is that</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">more often than we would like, the = engineers writing the</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">code need to be told these simple = things.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Monaco">Again, thanks for taking the time and = brain-cycles to read</FONT> <BR><FONT SIZE=3D2 FACE=3D"Monaco">and comment on the document.</FONT> </P> <P><FONT SIZE=3D2 FACE=3D"Monaco">Frank Kastenholz</FONT> </P> <BR> </UL> </BODY> </HTML> ------_=_NextPart_001_01C28E6E.5AE36938--