Skip to main content

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

Yes

(Deborah Brungard)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Joel Jaeggli)
(Kathleen Moriarty)
(Spencer Dawkins)
(Stephen Farrell)
(Terry Manderson)

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

Deborah Brungard Former IESG member
Yes
Yes () Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection () Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection () Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection () Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (2016-11-01) Unknown
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 IESG member
No Objection
No Objection (2016-11-02) Unknown
Modifications are needed to resolve the comments raised in Paul's Gen-ART review.
Joel Jaeggli Former IESG member
No Objection
No Objection () Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection () Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2016-10-30) Unknown
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 IESG member
No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection () Unknown

                            
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2017-03-17) Unknown
Thanks for addressing my DISCUSS with the RFC Editor note.
Terry Manderson Former IESG member
No Objection
No Objection () Unknown