Framework and Requirements for Layer 1 Virtual Private Networks
RFC 4847

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

Lars Eggert No Objection

(Ross Callon; former steering group member) Yes

Yes ( for -)
No email
send info

(Bill Fenner; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Brian Carpenter; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Cullen Jennings; former steering group member) (was Discuss) No Objection

No Objection (2006-09-12 for -)
No email
send info
It would be nice if there was a desciprtion of what a L1VPN was of why one might want one.

(Dan Romascanu; former steering group member) No Objection

No Objection (2006-09-10 for -)
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

(David Kessens; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Jari Arkko; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Lisa Dusseault; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Magnus Westerlund; former steering group member) No Objection

No Objection ( for -)
No email
send info

(Mark Townsley; former steering group member) (was Discuss) No Objection

No Objection (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

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (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/

(Sam Hartman; former steering group member) (was Discuss) No Objection

No Objection (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.

(Ted Hardie; former steering group member) No Objection

No Objection ( for -)
No email
send info