High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)
draft-ietf-l2tpext-pwe3-hdlc-07

[Ballot comment]
Said it needed an applicability statement (fidelity to the link) as per the PWE3 charter. 
This one is very good and straight-shooting, other than some sketchy
words about existence of mechanims to get the underlying link to have QoS like a
non-pseudo HDLC.

[Ballot comment]
From Gen-ART review by Avri Doria

Section 3.1 page 5. It states that

  LCCE A should then exhibit a periodic retry mechanism. The period
  and maximum number of retries MUST be configurable.

Since a MUST is used to define the period and number of retries, it
seems confusing that the retry mechanism is not also required.  If this
is conditional on such a mechanism exisiting, but the mechanism is
option (MAY), it should say this.

[BC - presumably the "should" in the first quoted sentence should be
"SHOULD" and the second sentence should start "If so, ...".
Alternatively, the "should" should be "MUST". ]

[Ballot discuss]
The Security Considerations in draft-ietf-l2tpext-pwe3-atm-03.txt says:
  >
  > For generic security issues regarding PWs and ATMPWs, this document
  > will eventually refer to documents from the PWE3 WG.
  >
  Clearly, the ATMPW stuff is not applicable to this document, but this
  sentence makes me think that RFC 3931 does not contain all of the
  information about PW security that an implementor needs.

[Ballot comment]
Please pick one spelling:
    "Pseudowire" or "Pseudo-Wire"
    "HDLC PW" or "HDLCPW"

  In the 2nd paragraph of the Introduction:
    s/point to point/point-to-point/

  In section 3.1, the document says:
  >
  > Attribute Type 68, MUST be present in the ICRQ messages and MUST
  > include the HDLC PW Type of 0x0006 for HDLCPWs.
  >
  Please reword.  I suggest:
  >
  > Attribute Type 68 MUST be present in the ICRQ messages and MUST
  > include the PW Type of 0x0006 for HDLCPWs.

IANA Last Call Comments:
Upon approval of this document the IANA will register a L2TPv3 Pseudowire Type,
and 2 Result Code AVP Values in the following registry:
http://www.iana.org/assignments/l2tp-parameters

According to the registration rules these require an expert review.  This needs to be completed before these are registered.

IETF LC Comments:

Date: Fri, 20 May 2005 06:46:34 -0400
From: "W. Mark Townsley"
To: mark@mjlnet.com
Cc: cpignata@cisco.com, iesg@ietf.org
Subject: Re: draft-ietf-l2tpext-pwe3-hdlc-05.txt

Mark Lewis wrote:
> Hi Mark, Carlos,
> In section 4.1 of draft-ietf-l2tpext-pwe3-hdlc-05.txt, is it worth mentioning the following if an HDLC PW is used to transport HDLC-like traffic:
> 1. When used to transport PPP traffic, PPP negotiation (LCP, optionally authentication, and NCP) is performed between CE devices - PE devices do not participate in this negotiation.
> 2. When used to transport Frame Relay traffic, LMI takes place between CE devices - PE devices do not participate in LMI.
> 3. When used to transport X.25 (LAPB) traffic, PE devices do not function as either LAPB DCE or DTE devices.
>
> I know that this should be fairly obvious from the description in section 4.1, but I guess that sometimes it may be useful to explicity state the seemingly obvious! Could the above three statements be used as examples to emphasize the transparent nature of the HDLC PW to HDLC-like protocols such as PPP, FR, and X.25 (LAPB).

I can't see how explicitly identifying these 3 examples could hurt (and it would probably help).

> By the way, in the sentence 'Since all packets are passed in a largely transparent manner over the HDLC PW, any protocol which has HDLC-like framing may utilize the HDLC PW mode, including PPP, Frame-Relay, X.25, etc.', is it worth changing 'X.25' to  'X.25 (LAPB)'- this modification to emphasize the the HDLC PW is used to transport X.25 at layer-
> 2 (ie. not PLP, etc.). A very minor point, I know.

Not an X.25 expert, but if this is more correct or clear, I trust your judgement. Carlos, do you mind recording these as IETF LC comments and incorporating them in a new revision after the IETF LC has ended (and before Margaret puts the draft on the IESG telechat agenda).

> Anyway, just a couple of thoughts. And the draft looks very good to me.

Many thanks for the review, Mark.

- Mark

> Regards,
> Mark
>