Re: draft of a core protocol spec
"A.Herrera" <[email protected]> Mon, 11 Nov 2002 09:51:48 -0500
| Newsgroups | gmane.ietf.iporpr |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C28967.F3A7EA60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [IPORPR] draft of a core protocol specHi Glenn, I find a few references to RPR specifications to be quite helpful when trying to describe IP functions that can run over it. However, I share your concern of two different=20 sources, no matter how similar, to potentially confuse.=20 Can't we somehow keep the reference in IPORPR=20 drafts by specifying in bold and unmistakable=20 blurb that -- 'This section does not, in any=20 official or definitive way, present the actual=20 802.17 specification. For an accurate representation=20 of the specification, please refer to the most=20 current IEEE documentation.' Albert =20 ----- Original Message -----=20 From: Glenn Parsons=20 To: [email protected]=20 Sent: Sunday, November 10, 2002 5:36 PM Subject: RE: [IPORPR] draft of a core protocol spec Frank,=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). As such, I would recommend that all of the RPR pedagogy (all of = section 3 and most of 4) be deleted.=20 Cheers,=20 Glenn.=20 ------=_NextPart_000_0005_01C28967.F3A7EA60 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><TITLE>RE: [IPORPR] draft of a core protocol spec</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#d8d0c8> <DIV><FONT size=3D2>Hi Glenn,</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>I find a few references to RPR specifications to=20 be</FONT></DIV> <DIV><FONT size=3D2>quite helpful when trying to describe IP=20 functions</FONT></DIV> <DIV><FONT size=3D2>that can run over it.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>However, I share your concern of two different = </FONT></DIV> <DIV><FONT size=3D2>sources, no matter how similar, to = potentially</FONT></DIV> <DIV><FONT size=3D2>confuse. </FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Can't we somehow keep the reference in </FONT><FONT=20 size=3D2>IPORPR </FONT></DIV> <DIV><FONT size=3D2>drafts by specifying in bold and </FONT><FONT=20 size=3D2>unmistakable </FONT></DIV> <DIV><FONT size=3D2>blurb that -- </FONT><FONT size=3D2>'This section = does not, in=20 any </FONT></DIV> <DIV><FONT size=3D2>official or </FONT><FONT size=3D2>definitive = </FONT><FONT=20 size=3D2>way, present the actual </FONT></DIV> <DIV><FONT size=3D2>802.17 specification. For an </FONT><FONT = size=3D2>accurate=20 representation </FONT></DIV> <DIV><FONT size=3D2>of the specification, please </FONT><FONT = size=3D2>refer to=20 the most </FONT></DIV> <DIV><FONT size=3D2>current IEEE documentation.'</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Albert</FONT><FONT = size=3D2> </FONT></DIV> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; = BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A [email protected]=20 href=3D"mailto:[email protected]">Glenn Parsons</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A [email protected]=20 href=3D"mailto:[email protected]">[email protected]</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Sunday, November 10, 2002 = 5:36=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [IPORPR] draft of = a core=20 protocol spec</DIV> <DIV><BR></DIV> <P><FONT face=3DArial color=3D#0000ff size=3D2>Frank,</FONT> </P> <P><FONT face=3DArial color=3D#0000ff size=3D2>You have noted the = various minor=20 corrections to the details on RPR that you have included in this = draft. =20 However, I have a more fundamental concern. As we are doing for = the RPR=20 MIB, I believe that the specification for RPR should be definitively = in IEEE=20 802.17. That is, your proposed document (or any IETF document) = should=20 not include any details of RPR that could be construed as being a=20 definition. Even if a subset of the RPR definition looks the = same, I=20 would suggest that it may be interpreted differently. That is = something=20 we want to avoid. This document should only describe the payload = format=20 when it is IP, the details of RPR are irrelevant (since it is a = broadcast=20 media).</FONT></P> <P><FONT face=3DArial color=3D#0000ff size=3D2>As such, I would = recommend that all=20 of the RPR pedagogy (all of section 3 and most of 4) be = deleted.</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></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0005_01C28967.F3A7EA60--