Keyed IPv6 Tunnel
draft-ietf-l2tpext-keyed-ipv6-tunnel-07

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

Alvaro Retana No Objection

(Deborah Brungard; former steering group member) Yes

Yes ()
No email
send info

(Alia Atlas; former steering group member) No Objection

No Objection ()
No email
send info

(Alissa Cooper; former steering group member) No Objection

No Objection ()
No email
send info

(Ben Campbell; former steering group member) No Objection

No Objection (2016-11-01)
No email
send info
I have just a few minor comments:

- 1, 2nd paragraph: The first sentence is convoluterd; can it be simplified?

-- "upon receipt on each tunnel": on receipt of packets?

-6: Please expand OAM, MEP, and MIP on first mention.

-11.2: RFCs 1981, 4623, 4720, 5085. 5883, and 5885 are all cited in the context of 2119 language. They should probably be normative references. (In my opinion, even citations for optional features need normative references if they are needed to fully understand the features.)

(Jari Arkko; former steering group member) No Objection

No Objection (2016-11-02)
No email
send info
Modifications are needed to resolve the comments raised in Paul's Gen-ART review.

(Joel Jaeggli; former steering group member) No Objection

No Objection ()
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ()
No email
send info

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection (2016-10-30)
No email
send info
Two questions:

1) I assume this was in depth discussed in the wg but the given reasoning for the following MUST does still not justify a MUST for me:
"All packets MUST carry the 64-bit L2TPv3 cookie field."
I would assume that there are possible deployment scenarios e.g. within a single domain where other existing protection mechanisms might be sufficient already that you don't really need the cookie...?

2) Further this is not normative language and i wonder if it should be:
"However, for compatibility with existing RFC3931 implementations, the packets need to be sent with Session ID."
Again I assume that this could be a SHOULD because if you know that you don't have devices that (only) implement RFC3931, you could probably even neglect the session id...?

(Spencer Dawkins; former steering group member) No Objection

No Objection ()
No email
send info

(Stephen Farrell; former steering group member) No Objection

No Objection ()
No email
send info

(Suresh Krishnan; former steering group member) (was Discuss) No Objection

No Objection (2017-03-17)
No email
send info
Thanks for addressing my DISCUSS with the RFC Editor note.

(Terry Manderson; former steering group member) No Objection

No Objection ()
No email
send info