Skip to main content

Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
draft-kumaki-murai-l3vpn-rsvp-te-09

Yes

(Stewart Bryant)

No Objection

(Benoît Claise)
(Gonzalo Camarillo)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Wesley Eddy)

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

Adrian Farrel Former IESG member
(was No Objection) Yes
Yes (2012-12-13 for -08) Unknown
I believe that Martin's Discuss has been addressed, and I am happy to move to a "Yes" ballot
Stewart Bryant Former IESG member
Yes
Yes (for -07) Unknown

                            
Barry Leiba Former IESG member
(was Discuss) No Objection
No Objection (2012-12-13 for -08) Unknown
I'm moving this to a comment, leaving it on the record but not blocking progress at this point.

I see no evidence that there was substantive discussion of this document anywhere, and I don't see that it belongs in the IETF Stream, with any claim to IETF consensus.

The shepherd writeup mentions consideration by the l3vpn WG, but it appears not to have been substantively discussed there.  The IETF 77 minutes show a discussion of what working group it belongs in, but no discussion of the substance of the document.  With a little digging, one finds that it has a predecessor document, draft-kumaki-murai-ccamp-rsvp-te-l3vpn, which was proposed to the ccamp WG, but there's no evidence that it was discussed there either.

The only two substantive comments I can find are these:
 
1. From Ben Niven-Jenkins on the l3vpn list:
http://www.ietf.org/mail-archive/web/l3vpn/current/msg02706.html
In that post, Ben made some comments that were never responded to.

2. During IETF Last Call, on the IETF discussion list, Lou Berger had a brief exchange with an author (two messages from each), starting here:
http://www.ietf.org/mail-archive/web/ietf/current/msg75348.html

It's not clear that this resulted in a resolution of Lou's concern.

And that's all.  I think that's light even for an Experimental document.

Given that both ccamp and l3vpn have looked at this and said that they don't want it (but apparently think it's not harmful), and that exactly two people other than the authors have made any comments at all about the substance of the document, I don't think it's reasonable to say that there's IETF consensus on it.

I do think it would have been reasonable to have sent this over to the Independent Stream Editor.
Benoît Claise Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Brian Haberman Former IESG member
(was Discuss) No Objection
No Objection (2012-12-13 for -08) Unknown
Thanks for addressing my DISCUSS point.
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Martin Stiemerling Former IESG member
(was Discuss) No Objection
No Objection (2012-12-13 for -08) Unknown
Thanks for addressing my DISCUSS -- cleared. 

Comments:
This draft is going for experimental and I would like to know what the test for a successful or not successful outcome of this is. Especially since the drafts says that this should enable experimental research. 

I would further add a more explicit clarification that this is only to be used within an operator. This is mentioned in several places, e.g., in Section 3.1.1 "The object  MUST NOT be included in any RSVP-TE message that is sent outside of  the provider's backbone." However, a particular section discussing this would be better. This section could also discuss possible impacts if the above rules is not followed.
Pete Resnick Former IESG member
No Objection
No Objection (2012-12-11 for -07) Unknown
(For the IESG; no author action necessary.)

My "No Objection" position notwithstanding, I strongly agree with Barry's DISCUSS comments and would like to hear more about this. Even if we pass this document on for publication, I think the issue of almost entirely unsupported AD-sponsored documents needs to be dealt with. It is certainly within an AD's discretion to personally support the publication of a document he/she feels is important, but I would expect an extensive writeup of why the AD is using that privilege for a document that's gotten virtually no discussion.
Ralph Droms Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -07) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2012-12-12 for -07) Unknown
Updated after discussions with Adrian.  This is about control plane stuff so my concerns don't apply.

This might be cleared up by addressing PHB's secdir review comment too, but I thought I'd throw this in:

Are there two different mechanisms defined in RFC 2747 and 3097?  I thought 3097 updates 2747 to just clarify which values to use because of a double assignment.  Wouldn't be clearer if you said:

 To ensure the integrity of an RSVP request, the RSVP Authentication
 mechanisms defined in [RFC2747], update by [RFC3097], SHOULD be used.
Stephen Farrell Former IESG member
No Objection
No Objection (2012-12-12 for -07) Unknown
- The authors responded to the secdir review [1] saying they
planned to modify the security considerations section, but I
didn't see any further response and don't see associated
changes in the security considerations.

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03538.html

- This cites RFC 4364 which calls for use of TCP-MD5 for
control plane security. [2] Given that this is an
experimental document, would it not be resaonable for it at
least mention that RFC 5925 obsoleted TCP-MD5?

   [2] http://tools.ietf.org/html/rfc4364#section-13.2
Wesley Eddy Former IESG member
No Objection
No Objection (for -07) Unknown