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:tsvwg-bounces@xxxxxxxx] On Behalf Of Robert Sparks
Sent: donderdag 21 augustus 2014 22:44
To: General Area Review Team; ietf@xxxxxxxx; tsvwg@xxxxxxxx; draft-ietf-
tsvwg-rsvp-pcn.all@xxxxxxxxxxxxxx
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