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

[Robert Sparks <[e-mail]>]

Thanks Georgios - these are improvements.

RjS

On 9/14/14 3:58 AM, [e-mail] wrote:
> 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
>
>>