Subject: [CCAMP] RtgDir review: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Mon, 10 Dec 2018 10:35:19 +0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF
Last Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt
Reviewer: Matthew Bocci
Review Date: 9 December 2018
IETF LC End Date: Unknown
Intended Status: Standards Track

Summary:

I have some minor concerns about this document that I think should be resolved before
publication.

Comments:

The document is relatively concise, but I found that it could do with rewording in many
areas for clarity and to correct the English grammar. I have one issue that I found that I
consider major that I have listed below but that should be resolved as soon as possible. There are also some
minor issues related to the clarity of the specification that should be fixed before publication.

Major Issues:

Page 6, 3rd Paragraph: "When two LSPs request bandwidth with the same availability
   requirement, contention SHOULD/MUST be resolved by comparing the
   node IDs, .."

   Either it is a SHOULD or a MUST. The distinction between the two can make the
   difference between a document being acceptable or not to a WG and the IETF and can
   raise wider arguments about interoperability. Please resolve which of these you mean
    before proceeding.

Minor Issues:

Page 5, 1st Paragraph below figure 1: "The Availability TLV MUST come along with Ethernet
Bandwidth Profile TLV."

   I think you need to be more careful in the way this phrased. You are not saying that
   an Ethernet BW Profile TLV must always be accompanied by an Availability TLV, but rather that
   if you include an Availability TLV, the Ethernet BW Profile TLV must also be included.
   I suggest rephrasing this to "When the Availability TLV is included it MUST be present
   along with the Ethernet Bandwidth Profile TLV."

Page 3, 2nd Paragraph: I found the whole discussion here somewhat confusing. The text seems to mix
up service availability requirements (which are often specified in an SLA e.g. % of time a service is UP),
with the ability of a given service (voice/video/non-real-time data etc) to withstand fluctuations
in the bandwidth of the underlying transport. This could be fixed by always using the term 'bandwidth availability'
instead of just 'availability'.

Nits:

I found that the readability could be improved with some rewording of the text to improve
the English grammar and sentence structure. I would suggest reviewing with a native
English speaker to help with this.

Thanks,

Matthew

---

From: "Yemin (Amy)" <[email-masked]>
Date: Fri, 14 Dec 2018 06:03:15 +0000

Hi Matthew,

Thanks for your review comments.
Please see my reply inline below.

BR,
Amy
From: Bocci, Matthew (Nokia - GB) [mailto:[email-masked]]
Sent: Monday, December 10, 2018 6:35 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RtgDir review: draft-ietf-ccamp-rsvp-te-bandwidth-availability-11.txt

Hello,

Summary:

Comments:

[Amy] Sorry for the English grammar problems, I hope this could be improved with the help from RFC editors.

Major Issues:

   Either it is a SHOULD or a MUST. The distinction between the two can make the
   difference between a document being acceptable or not to a WG and the IETF and can
   raise wider arguments about interoperability. Please resolve which of these you mean
    before proceeding.
[Amy] Thanks for pointing it out. I fully agree that it should be clearly defined to avoid interoperability problem.
 I prefer to use MUST, to align with RFC3471.

Minor Issues:

[Amy] Will update the draft as you suggested.

[Amy] Will update the draft as you suggested.

Nits:

Thanks,

Matthew