Support for Resource Reservation Protocol Traffic Engineering (RSVP-TE) in Layer 3 Virtual Private Networks (L3VPNs)
RFC 6882

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

(Stewart Bryant) Yes

(Adrian Farrel) (was No Objection) Yes

Comment (2012-12-13 for -08)
No email
send info
I believe that Martin's Discuss has been addressed, and I am happy to move to a "Yes" ballot

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Stephen Farrell) No Objection

Comment (2012-12-12 for -07)
No email
send info
- 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

(Brian Haberman) (was Discuss) No Objection

Comment (2012-12-13 for -08)
No email
send info
Thanks for addressing my DISCUSS point.

(Russ Housley) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2012-12-13 for -08)
No email
send info
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.

(Pete Resnick) No Objection

Comment (2012-12-11 for -07)
No email
send info
(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.

(Robert Sparks) No Objection

(Martin Stiemerling) (was Discuss) No Objection

Comment (2012-12-13 for -08)
No email
send info
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.

(Sean Turner) (was Discuss) No Objection

Comment (2012-12-12 for -07)
No email
send info
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.