Framework and Requirements for Layer 1 Virtual Private Networks
RFC 4847

Note: This ballot was opened for revision 05 and is now closed.

(Ross Callon) Yes

(Jari Arkko) No Objection

(Brian Carpenter) No Objection

(Lisa Dusseault) No Objection

(Lars Eggert) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Sam Hartman) (was Discuss) No Objection

Comment (2006-09-27)
No email
send info
I did not understand what the L1VPN working group was when it was
chartered.  As I begin to understand what it is about, I think L1VPN
may have been a very bad choice for a name.  I'd ask people to at
least think about whether calling the technology L1VPN will confuse
IETF participants enough that we should consider a change.  This is
very much just something I want people to think about.

(Russ Housley) (was Discuss) No Objection

Comment (2006-09-26)
No email
send info
  Sec 12.2 (authentication): There must be authentication as well as
  identification.  One cannot simply assert an identity; it must go
  with some proof that the asserted identity is appropriate.

  From Sean Turner's SecDir review:
  Sec 12.2 (confidentiality): s/retrieved/disclosed/

(Cullen Jennings) (was Discuss) No Objection

Comment (2006-09-12 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
It would be nice if there was a desciprtion of what a L1VPN was of why one might want one.

(David Kessens) No Objection

(Dan Romascanu) No Objection

Comment (2006-09-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
1. Section 11 - Manageability Considerations - 'In particular, MIB modules for GMPLS protocols and potential extensions MUST be supported.' It would have been useful to be more specific about the need for supplementary MIB modules or extentions of existing MIB modules - yes/no, if yes what managenent information they would carry. 

2. Section 12 - Security Considerations 

Confidentiality

     The information exchanged between the customer and the provider
     MUST NOT be retrieved by the third party.

better: 

     The information exchanged between the customer and the provider
     MUST NOT be observable by a third party.

o Access control

     Access to the information contained in the provider network MUST be
     restricted to the authorized entity.

It would be good to emphasize in the text that the information that is refered here, although contained in the provider network may be about customer network and customers as well. I hope that this is the intent, anyway. 

3. References

I find strange the fact that only RFC2119 is listed as a Normative Reference. True, this document targets Informational status, but it will become the requirements document to be used by other Standards track documents in l1vpn. As it is largely based on documents from ITU-T and GMPLS without which understanding the requirements would be impossible, I would rather see some of the documents included today in the Informational References clause moving to Normative

(Mark Townsley) (was Discuss) No Objection

Comment (2007-01-11)
No email
send info
These comments are for the updated version, -05

ASCII art in 7.1,  7.2, 7.3.3, 7.3.4 seems to have been goofed up a bit.

Section 12.2:  "identify authenticated."

 s/identify/identity

Magnus Westerlund No Objection