Re: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09

[<[e-mail]>]

Hi Robert,

Thank you for your comments!

We have worked out your comments in the following way, see in line!

Please let us know if you are satisfied with these changes!
 


> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Robert Sparks
> Sent: donderdag 21 augustus 2014 22:44
> To: General Area Review Team; [e-mail]; [e-mail]; draft-ietf-
> [e-mail]
> Subject: [tsvwg] Gen-art LC review: draft-ietf-tsvwg-rsvp-pcn-09
>
> I am the assigned Gen-ART reviewer for this draft. For background on Gen-
> ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
> Document: draft-ietf-tsvwg-rsvp-pcn-09
> Reviewer: Robert Sparks
> Review Date: 21 Aug 2014
> IETF LC End Date: 26 Aug 2014
> IESG Telechat date: 2 Oct 2014
>
> Summary: Ready (with nits) for publication as Experimental.
>
> David's shepherd writeup points out that implementation and usage
> experience is desired before producing a proposed standard. Are there any
> points of concern about how this might behave (or misbehave) in a deployed
> network that such experience would inform? If so, it would be useful to call
> them out in the document.


Georgios: Added the following paragraph at the end of Section 1.1:

   This draft is intended to be published as Experimental in order to:
   
      o) validate industry interest by allowing implementation and 
         deployment

      o) gather operational experience, in particular around dynamic 
         interactions of RSVP signaling and PCN notification and 
         corresponding levels of performance.


>
> It would be nicer if the document argued why there are no new security
> considerations introduced by the new behavior defined in this draft, rather
> than tacitly asserting that there aren't any.

Georgios:
Added the following text in Section 5:

   In particular, the security considerations within the PCN domain come 
   from the Trust Assumption Section 6.3.1, of [RFC5559] i.e., that all 
   PCN-nodes are PCN-enabled and are trusted for truthful PCN-metering 
   and PCN-marking. 

   In the PCN domain environments addressed by this document, Generic 
   Aggregate Resource ReSerVation Protocol (RSVP)messages specified in 
   [RFC4860] are used for support of the PCN Controlled Load (CL) and 
   Single Marking (SM) edge behaviors over a Diffserv cloud using Pre-
   Congestion Notification. Similar, to [RFC4860], [RFC2747] and 
   [RFC3097] may be used to protect RSVP message integrity hop-
   by hop and provide node authentication as well as replay protection, 
   thereby protecting against corruption and spoofing of RSVP messages 
   and PCN feedback. 

   Based on these assumptions, it is considered that this document is 
   NOT introducing any additional security concerns/issues compared to 
   [RFC5559] and/or [RFC4860].

>
> The terminology section has lots of 2119 words in it. It's hard to tell when
> these have been copied from some other draft (and this is just restating
> them) vs when this draft is introducing a new requirement.
> Since a new requirement would likely be missed if it appeared only in a
> terminology section, would it be feasible to make sure anything new is well
> covered in section 3 or 4 and remove 2119 from these definitions altogether?

Georgios:
Removed all RFC 2119 words from the terminology section (Section 1.3)

>
> The rest of these comments are minor editorial nits:
>
> Section 1.2, paragraph 3: "Intserv over Diffserv can operate over a statically
> provisioned Diffserv region or RSVP aware." is missing a a word somewhere.

Georgios:
changed From:
Intserv over Diffserv can operate over a statically provisioned Diffserv region or a RSVP aware. 

INTO
Intserv over Diffserv can operate over a statically provisioned or a RSVP aware Diffserv region
>
> Section 1.2 paragraph 4: "By using multiple aggregate reservations for the
> same PHB allows enforcement of the different preemption priorities within
> the aggregation region." doesn't parse. Should the initial "By"
> be deleted?

Georgios:
Changed from:

By using multiple aggregate reservations for the same PHB, allows enforcement of the different preemption priorities within the aggregation region. 

INTO:
By using multiple aggregate reservations for the same PHB, it allows enforcement of the different preemption priorities within the aggregation region. 

>
> The definition for PCN-domain is very close to circular. Perhaps some words
> can be removed?

In Section 1.3, we have replaced PCN-domain with domain in the text, see below:
Channged from:
   PCN-domain:      a PCN-capable domain; a contiguous set of 
                    PCN-enabled nodes that perform Diffserv scheduling 
                    [RFC2474]; the complete set of PCN-nodes that in 
                    principle can, through PCN-marking packets, 
                    influence decisions about flow admission and 
                    termination within the PCN-domain; includes the PCN-
                    egress-nodes, which measure these PCN-marks, and the 
                    PCN-ingress-nodes.


INTO:
   PCN-domain:      a PCN-capable domain; a contiguous set of 
                    PCN-enabled nodes that perform Diffserv scheduling 
                    [RFC2474]; the complete set of PCN-nodes that in 
                    principle can, through PCN-marking packets, 
                    influence decisions about flow admission and 
                    termination within the domain; includes the PCN-
                    egress-nodes, which measure these PCN-marks, and the 
                    PCN-ingress-nodes.

=========

Best regards,
Georgios

>
>