RE: draft of a core protocol spec
[email protected] Mon, 18 Nov 2002 10:39:15 -0800
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C28F31.CB91A534 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I completely agree with Glenn (on this topic :-). =20 jl -----Original Message----- From: Glenn Parsons [mailto:[email protected]] Sent: Sunday, November 17, 2002 11:20 AM To: [email protected] Cc: 'Frank Kastenholz' Subject: RE: [IPORPR] draft of a core protocol spec Frank,=20 You have confirmed my concern.=20 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.=20 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.=20 Cheers,=20 Glenn.=20 ----------=20 From: Frank Kastenholz=20 Sent: Monday, November 11, 2002 3:59 PM=20 To: Parsons, Glenn [CAR:6L81:EXCH]; [email protected]=20 Subject: RE: [IPORPR] draft of a core protocol spec=20 At 05:36 PM 11/10/2002 -0500, Glenn Parsons wrote:=20 >Frank,=20 >=20 >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). >=20 >As such, I would recommend that all of the RPR pedagogy (all of section = 3 and most of 4) be deleted.=20 Glenn=20 Thanks for your comments=20 In no way should this draft be considered to attempt to replace=20 or supplant the 802.17 work. Section 3 is meant to be just enough=20 of an overview of the technology so that people reading the spec=20 by itself (such as the IESG will be doing when they review it) will=20 be able to understand the rest of it. I would be more than happy=20 to put some stronger text at the front saying that the section is=20 just a brief, highlevel, description of the aspects of 802.17 that=20 are relevant to the work that IPoRPR is doing, and/or move it to=20 an appendix. But I do feel that having some "RPR pedagogy" is=20 both useful and necessary.=20 As to section 4 -- that section's goal is to describe various=20 common things that one needs to do to do IP/MPLS over 802.17.=20 Things like what values to put in the Ether-type field, where=20 the payload is to begin, and so on. Some of the things in=20 here that I thought were 'adjustable' (like the TTL) turn out=20 not to be and those would get moved into section 3. Also,=20 some things may seem to be too obvious (e.g. that the=20 IP header immediately follows the 802.17 header, or that the=20 packet type is "data") but one thing that I've learned=20 over the last 20+ years of doing TCP/IP development is that=20 more often than we would like, the engineers writing the=20 code need to be told these simple things.=20 Again, thanks for taking the time and brain-cycles to read=20 and comment on the document.=20 Frank Kastenholz=20 ------_=_NextPart_001_01C28F31.CB91A534 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <TITLE>RE: [IPORPR] draft of a core protocol spec</TITLE> <META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D748523818-18112002><FONT face=3DArial color=3D#008080 = size=3D2>I=20 completely agree with Glenn (on this topic :-).</FONT></SPAN></DIV> <DIV><SPAN class=3D748523818-18112002><FONT face=3DArial color=3D#008080 = size=3D2></FONT></SPAN> </DIV> <DIV><SPAN class=3D748523818-18112002><FONT face=3DArial color=3D#008080 = size=3D2>jl</FONT></SPAN></DIV> <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> Glenn Parsons=20 [mailto:[email protected]]<BR><B>Sent:</B> Sunday, November = 17, 2002=20 11:20 AM<BR><B>To:</B> [email protected]<BR><B>Cc:</B> 'Frank=20 Kastenholz'<BR><B>Subject:</B> RE: [IPORPR] draft of a core protocol=20 spec<BR><BR></FONT></DIV> <P><FONT face=3DArial color=3D#0000ff size=3D2>Frank,</FONT> </P> <P><FONT face=3DArial color=3D#0000ff size=3D2>You have confirmed my = concern.</FONT>=20 </P> <P><FONT face=3DArial color=3D#0000ff size=3D2>In my short experience = (~10 yrs) I=20 notice that designers read the least number of docs before = implementing. =20 That is, if there any description of RPR in this document (beyond a = short=20 abstract), I submit that it would be taken by some to be the 'de facto'=20 definition of RPR.</FONT></P> <P><FONT face=3DArial color=3D#0000ff size=3D2>I would prefer to avoid = that=20 situation.</FONT> </P> <P><FONT face=3DArial color=3D#0000ff size=3D2>As you may be aware, IEEE = 802.17 will=20 be forwarding a copy of the WG ballot version of RPR (similar to an ID = in IETF=20 WG last call) to the IESG (for MIB review) and will also copy this = WG. As=20 a result, I do not see any issue with not being able to access the=20 document.</FONT></P> <P><FONT face=3DArial color=3D#0000ff size=3D2>As a result, my comment = stands that=20 this document should contain no RPR descriptive text beyond a simple=20 abstract.</FONT> </P> <P><FONT face=3DArial color=3D#0000ff size=3D2>Cheers,</FONT> <BR><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Glenn.</FONT> </P> <UL> <P><FONT face=3DArial size=3D2>----------</FONT> <BR><B><FONT = face=3DArial=20 size=3D2>From:</FONT></B> <FONT face=3DArial size=3D2>Frank = Kastenholz</FONT>=20 <BR><B><FONT face=3DArial size=3D2>Sent:</FONT></B> <FONT = face=3DArial=20 size=3D2>Monday, November 11, 2002 3:59 PM</FONT> <BR><B><FONT = face=3DArial=20 size=3D2>To:</FONT></B> <FONT face=3DArial = size=3D2>Parsons,=20 Glenn [CAR:6L81:EXCH]; [email protected]</FONT> <BR><B><FONT = face=3DArial=20 size=3D2>Subject:</FONT></B> = <FONT=20 face=3DArial size=3D2>RE: [IPORPR] draft of a core protocol = spec</FONT> </P> <P><FONT face=3DMonaco size=3D2>At 05:36 PM 11/10/2002 -0500, Glenn = Parsons=20 wrote:</FONT> </P> <P><FONT face=3DMonaco size=3D2>>Frank, </FONT><BR><FONT = face=3DMonaco=20 size=3D2>></FONT> <BR><FONT face=3DMonaco size=3D2>>You have = noted the various=20 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=20 for the RPR MIB, I believe that the specification for RPR should be=20 definitively in IEEE 802.17. That is, your proposed document (or = any=20 IETF document) should not include any details of RPR that could be = construed=20 as being a definition. Even if a subset of the RPR definition = looks the=20 same, I would suggest that it may be interpreted differently. = That is=20 something we want to avoid. This document should only describe = the=20 payload format when it is IP, the details of RPR are irrelevant (since = it is a=20 broadcast media).</FONT></P> <P><FONT face=3DMonaco size=3D2>></FONT> <BR><FONT face=3DMonaco = size=3D2>>As=20 such, I would recommend that all of the RPR pedagogy (all of section 3 = and=20 most of 4) be deleted. </FONT></P> <P><FONT face=3DMonaco size=3D2>Glenn</FONT> <BR><FONT face=3DMonaco = size=3D2>Thanks=20 for your comments</FONT> </P> <P><FONT face=3DMonaco size=3D2>In no way should this draft be = considered to=20 attempt to replace</FONT> <BR><FONT face=3DMonaco size=3D2>or supplant = the 802.17=20 work. Section 3 is meant to be just enough</FONT> <BR><FONT = face=3DMonaco=20 size=3D2>of an overview of the technology so that people reading the = spec</FONT>=20 <BR><FONT face=3DMonaco size=3D2>by itself (such as the IESG will be = doing when=20 they review it) will</FONT> <BR><FONT face=3DMonaco size=3D2>be able = to understand=20 the rest of it. I would be more than happy</FONT> <BR><FONT = face=3DMonaco=20 size=3D2>to put some stronger text at the front saying that the = section=20 is</FONT> <BR><FONT face=3DMonaco size=3D2>just a brief, highlevel, = description of=20 the aspects of 802.17 that</FONT> <BR><FONT face=3DMonaco size=3D2>are = relevant to=20 the work that IPoRPR is doing, and/or move it to</FONT> <BR><FONT = face=3DMonaco=20 size=3D2>an appendix. But I do feel that having some "RPR pedagogy" = is</FONT>=20 <BR><FONT face=3DMonaco size=3D2>both useful and necessary.</FONT> = </P> <P><FONT face=3DMonaco size=3D2>As to section 4 -- that section's goal = is to=20 describe various </FONT><BR><FONT face=3DMonaco size=3D2>common things = that one=20 needs to do to do IP/MPLS over 802.17.</FONT> <BR><FONT face=3DMonaco=20 size=3D2>Things like what values to put in the Ether-type field, = where</FONT>=20 <BR><FONT face=3DMonaco size=3D2>the payload is to begin, and so on. = Some of the=20 things in </FONT><BR><FONT face=3DMonaco size=3D2>here that I thought = were=20 'adjustable' (like the TTL) turn out</FONT> <BR><FONT face=3DMonaco = size=3D2>not=20 to be and those would get moved into section 3. Also,</FONT> <BR><FONT = face=3DMonaco size=3D2>some things may seem to be too obvious (e.g. = that=20 the</FONT> <BR><FONT face=3DMonaco size=3D2>IP header immediately = follows the=20 802.17 header, or that the</FONT> <BR><FONT face=3DMonaco = size=3D2>packet type is=20 "data") but one thing that I've learned</FONT> <BR><FONT face=3DMonaco = size=3D2>over the last 20+ years of doing TCP/IP development is = that</FONT>=20 <BR><FONT face=3DMonaco size=3D2>more often than we would like, the = engineers=20 writing the</FONT> <BR><FONT face=3DMonaco size=3D2>code need to be = told these=20 simple things.</FONT> </P> <P><FONT face=3DMonaco size=3D2>Again, thanks for taking the time and = brain-cycles=20 to read</FONT> <BR><FONT face=3DMonaco size=3D2>and comment on the=20 document.</FONT> </P> <P><FONT face=3DMonaco size=3D2>Frank Kastenholz</FONT> = </P><BR></UL></BODY></HTML> ------_=_NextPart_001_01C28F31.CB91A534--