Subject: Fwd: RFC 3518

From: Fred Baker <[email-masked]>
Date: Mon, 28 Apr 2003 09:44:19 -0700

We received this note this morning. I didn't see any note from him during 
the development of the draft, working group last call, or IETF last call. 
What does the working group want to do with the comments?

>From: "Alfred H\Nnes" <[email-masked]>
>Subject: RFC 3518
>To: [email-masked]
>Date: Mon, 28 Apr 03 15:25:44 MESZ
>Cc: [email-masked], [email-masked], [email-masked]
>
>Hello,
>
>I'd like to report to you some issues I found when reading the new
>PPP-BCP RFC 3518 :
>
>
>(1) On [Page 1], the last paragraph of the 'Abstract' section
>     does not correctly represent the situation before RFC 3518.
>
>     At the similar place in RFC 2878, there was written:
>
>     "This document obsoletes RFC 1638, which was based on the IEEE
>     802.1D-1993 MAC Bridge[3]. This document extends that specification
>     by including the IEEE 802.1D-1998 MAC Bridge[8] and IEEE 802.1Q
>     Virtual LAN (VLAN)[9] standards. ..."
>
>     Therefore, the sentence found in RFC 3518 :
>
>     "This document obsoletes RFC 2878, which was based on the IEEE
>     802.1D-1993 MAC Bridge. This document extends that specification ..."
>     ^^^^^^^^^^^
>
>     seems inappropriate and should better state:
>
>     "This document obsoletes RFC 2878, which was based on the IEEE
>     802.1D-1998 MAC Bridge[8] and IEEE 802.1Q Virtual LAN (VLAN)[9]
>     standards. This document extends that specification ..."
>
>     (The unchanged reference tags are still correct.)
>
>     But, since RFC 3518 does not add any new IEEE 802 related
>     functionality (the additions are purely PPP-BCP performance
>     clues), it even would suffice to state:
>
>     "This document obsoletes RFC 2878. It extends that specification ..."
>
>
>(2) The frame format descriptions in section 4.2. and section 4.3. still
>     lack of textual descriptions for
>
>     - the "SNAP-encoded TPID" field (802.4/... tagged frame format), and
>
>     - the "Length/Type" field (both 802.3 frame formats).
>
>       {N.B.:
>        "Type" would usually mean an Ethernet frame; but that would be
>        inappropriate if the headline "802.3 Frame format" is taken
>        literally.
>        It is not clear from the text whether it is intended to admit
>        Ethernet frames too in section 4.2. (Existing implementations
>        obviously do!) Because these frames do not contain any 802.2 LLC
>        (+ eventually SNAP) header, in this case the "LLC data" field
>        should better be named "LLC / Ethernet data" in 4.2 on page 13.
>        I've never seen Ethernet-like frame-content in IEEE 802 Tagged
>        Frames; do such frames really exist?? -- if not, "Lenght/Type"
>        should be corrected to just read "Length" in 4.3 on page 17.
>       }
>
>(3) The pseudo code given in Appendix B for the Transmitter side still
>     sets the ZeroCompressionFlag in the case of a packet of minimal
>     length that does _not_ contain any padding bytes, i. e. in the
>     case where the 'while' loop bodies are never executed because
>       TrailingOctet (PDU) != 0   on first try.
>
>     This behaviour indeed does not cause real harm, but it introduces
>     inefficiency into the Transmitter code and unnecessarily causes
>     additional code to be executed on the Receiver side as well;
>     therefore it would be better to not "specify" this behaviour.
>     (N.B.: It is not clear from the text whether Appendix B should
>     be considered normative or not.)
>
>Best regards,
>   Alfred Hönes.
>
>--
>
>+------------------------+--------------------------------------------+
>| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
>| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
>| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
>+------------------------+--------------------------------------------+

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 29 Apr 2003 13:11:24 -0400

Fred,

I guess he took the term "Request for Comments" at face value! :-)  Not 
everyone can follow the work in progress ...

If the authors/editors of the RFC, with the concurrence of the WG, see 
value in the comments, then you may want to turn around a revised RFC with 
just these changes.  While I'm not a BCP expert, the comments generally 
seem useful.

Cheers,
Andy

--------

---

From: Tawei Liao <[email-masked]>
Date: Tue, 29 Apr 2003 11:37:40 -0700 (PDT)

My take on the comments raised:

(1)  The abstract section

Alfred's wording is better.  We can list this as Errata on the RFC.
Don't see a need to crank out a new one just to correct the abstract.

(2)  Frame Format description

I disagree with the need to go into great detail on the meaning of
type/length or TPID fields.  The IEEE documents best describe what
the fields mean.  And their text is canon.

The use of "Length/Type" nomenclature is also used throughout the
IEEE 802.3 document.  I just checked 802.3-2002 and "Length/Type"
appears in figure 3-1 page 31 and again in section 3.2.6 and so on.

It is beyond the scope of this RFC to spell out what each and every
field of 802.3/4/5 PDU is and what it does.

(3)  On the pseudo-code

This appendix has been in existence since RFC1638 published in June
1994.  In the 8 years since, has anyone ever complained about this?
Changing this now will cause more confusion.

-tawei

---

From: Karl Fox <[email-masked]>
Date: Tue, 29 Apr 2003 17:53:47 -0400

If others agree with Tawei's comments, I'd recommend taking no action.

Karl

---

From: Mitsuru Higashiyama <[email-masked]>
Date: Wed, 30 Apr 2003 09:49:53 +0900

I support Tawei's comment.

Thanks,
Mitsuru

Tawei Liao wrote:

>>>>  Alfred H?nes.