Asynchronous Transfer Mode (ATM) over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
RFC 4454

[Ballot discuss]
This needs an ATM-specific "faithfulness" statement, per
the charter, describing the way that an ATM service is
sometimes not provided with fidelity over the PSN.
This same statement can also appear in the MPLS-based
document in the later appearance of that.

I'm concerned especially with future uses, not
necessarily AAL5, though I think that there could
be problems with behavior even with the services
defined in this document.

The section can be called Applicability Statement.

[Ballot discuss]
This needs an ATM-specific "faithfulness" statement, per
the charter, describing the way that an ATM service is
sometimes not provided with fidelity over the PSN.
This same statement can also appear in the MPLS-based
document in the later appearance of that.

I'm concerned especially with future uses, not
necessarily AAL5, though I think that there could
be problems with behavior even with the services
defined in this document.

The section can be called Applicability Statement.

[Ballot comment]
This document is right: it is incomprehensible without a deeper
understanding of the L2TP spec than I have.  While I'm not going to
block it on that point, I cannot evaluate well enough to enter a no
objection vote.

[Ballot comment]
Gen-ART review comments from Mary Barnes:

Detailed Comments:
-------------------

Security Considerations section is inadequate.  It mentions that other
pwe3 documents would address the security considerations, but there are
no specific references, nor even a basic description of the threats
associated with the scenarios under which this protocol is used.
(similar comment as raised by Ted and Russ).

Editorial nits:
------------------

- Abstract. First sentence is grammatically incorrect.  I would suggest
adding either "defines", "specifies" or
"describes" prior to "how" in that sentence.

- General. First use of acronyms should be expanded, even though they're
listed in the glossary (e.g. SLI in section 1, etc.).

- Section 3. Second/last sentence. Would read better by changing from:
"  This includes what will happen when an ATM Circuit
  (e.g. AAL5 PVC) is created, deleted or changes state when circuit is
  in alarm."
to:
"This includes what will happen when an ATM Circuit
  (e.g. AAL5 PVC) is created, deleted or changes state when circuit
state is

  in alarm.

[At least I think the statement is referring to the circuit being in a
stat of ALARM.]

[Ballot comment]
The 2nd paragraph of the Introduction begins:
  >
  > Any ATM specific AVPs or other L2TP constructs for ATM pseudo-wire
  > (ATMPW) support will be defined here as well.
  >
  s/will be/are/

[Ballot discuss]
The Security Considerations say:
  >
  > For generic security issues regarding PWs and ATMPWs, this document
  > will eventually refer to documents from the PWE3 WG.
  >
  The references need to be included now.  This does not provide a
  way to locate them and determine if they are sufficient.

[Ballot discuss]
The document says:

9. Security Considerations

  For generic security issues regarding PWs and ATMPWs, this document
  will eventually refer to documents from the PWE3 WG.

Did a pointer get dropped here?

IANA Last Call Comments:
Upon approval of this document the IANA will
assign 4 Pseudowire Types, 1 L2-Specific Sublayer Type, 3 Control Message Attribute Value Pairs (AVPs), and 1 Result Code AVP Value in the existing registry at http://www.iana.org/assignments/l2tp-parameters

Some of the above registrations require expert reivew.  This needs to take place before they can be registered.

The IANA will set up a new registry for ATM Alarm Status AVP Values
including Circuit Status Reason values for the SLI message and for the
general ATM Alarm failures

The IANA will set-up a new registry for ATM-Specific Sublayer bits

Sent message to chairs requested submission questionnaire and review:

To: Ron da Silva , Ignacio Goyret
From: Margaret Wasserman
Subject: Three L2TPEXT Documents
Cc: Mark Townsley , Thomas Narten

Hi Ron and Ignacio,

Mark Townsley recently transferred responsibility for three L2TP documents to me, because he is a co-author.  These are:

draft-ietf-l2tpext-pwe3-atm
draft-ietf-l2tpext-pwe3-fr
draft-ietf-l2tpext-pwe3-hdlc

These documents are in kind of a funny state -- Mark was an author, the sole WG chair and is now the responsible AD for the WG.  I will process the documents, but I do not have enough expertise in the technology to make an expert assessment of their quality or completeness.  I also have not been on the L2TPEXT mailing list, and I don't know what the contentious issues (if any) were regarding these documents.

So, I will need some help from you guys before I will be ready to send these documents to the IESG for review (I have already sent them to IETF LC).

(1) Could you please fill out a submissions questionnaire for each of these documents, as described in:

http://www.ietf.org/internet-drafts/draft-ietf-proto-wgchair-doc-shepherding-05.txt

Please do a careful job, as I do not know the WG history and I am counting on you to determine that the process was followed properly.

(2)  Also, could at least one of you please review each of these documents in detail to make sure that they are ready for RFC publication?  Although they were submitted by Mark, they will end-up being work output from your WG, and I would like to know that you think they are suitable (clear, complete and correct).  Send me a note when you complete your review.  If you uncover any issues, we will deal with them during LC.

I have also cc:ed Thomas Narten, as he may have some context or opinion about these documents, as they were originally submitted to him.

Thanks!!

Margaret