Extensions to Generic Aggregate RSVP for IPv4 and IPv6 Reservations over Pre-Congestion Notification (PCN) Domains
draft-ietf-tsvwg-rsvp-pcn-11

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

(Spencer Dawkins) Yes

(Martin Stiemerling) Yes

(Jari Arkko) No Objection

(Adrian Farrel) No Objection

Comment (2014-09-28 for -10)
No email
send info
Thanks for putting this on the experimental track and for clarifying
what experimental feedback you want to see.

It might be worth adding to the explanation of the experiment something
about scoping. In particular, I think that the key issue is that you 
expect that every node along the path of the flow (i.e. the RSVP path)
from PCN-ingress-node to PCN-egress-node must be part of this experiment
(i.e. aware of the 248 class number) for the experiment to function. In
practice, this probably means that you want to conduct the experiment in
domains of nodes that are all aware of the experiment (or do funky stuff
with tunnels).

(Stephen Farrell) No Objection

Comment (2014-10-02 for -10)
No email
send info
- 2.13: I'm sorry, I don't get what methods from the
referenced RFCs you mean. Can you clarify?  I had a
(very) quick look at section 4 of 4860 and didn't see
anything at all about authentication or data
integrity. 

- Section 5: the first sentence is not.

- Section 5: RFC2747 specifics HMAC-MD5 right? That
is still ok for this purpose but it would be prudent
perhaps to move to HMAC-SHA256 today. Is there any
move to do something like that (in RSVP generally I
guess, not specific to PCN).

(Joel Jaeggli) No Objection

Comment (2014-10-01 for -10)
No email
send info
as experimental I do  not object.

Barry Leiba No Objection