To:
Cc:
Subject:
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 https://wiki.ietf.org/en/group/rtg/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-spring-bfd-12
Reviewer: Loa Andersson
Review Date: date
IETF LC End Date: 2024-12-13
Intended Status: Experimental
Summary:
Choose from this list...
Comments:
Major Issues:
Minor Issues:
Nits:
SR-MPLS is not a wellknow abbreviation, so it need to expanded at first use. If it is used both in the Abstract and the document text I think it should be expanded twice. The Abstract is treated as something stand-alone.
Grammar concerns:
I have a couple of comments that are grammatical in nature. Please take care with these comments. English is not my mother tongue, but I'm happy if you read and consider (even if you decide not to take what I suggest).
MPLS Data Plane
In the Abstract you talk about the MPLS Data Plane and say:
Inm the 2nd sentence "It can be realized in the Multiprotocol Label Switching (MPLS) network without changing the data plane."
I have the feeling that "without changing the data plane" can be understood that the entire data plane is swapped, maybe:
s/without changing the data plane/without any changes to the data
plane/
Expected to
The second sentence in the Abstract says:
"Bidirectional Forwarding Detection (BFD) is expected to monitor a segment list..."
I have the feeling that "expectations" leave quite a bit of
uncertainty. What about:
s/(BFD) is expected to/(BFD) is used to/
To: rtg-ads@ietf.org
Cc: rtg-dir@ietf.org; draft-ietf-pce-p2mp-reqs.all@ietf.org; pce@ietf.org; last-call@ietf.org
Subject: RtgDir Last Call review: draft-ietf-pce-p2mp-reqs-03
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. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see https://wiki.ietf.org/en/group/rtg/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-pcep-p2mp-reqs-03
Reviewer: Albert N. Other
Review Date: 25 January 2010
IETF LC End Date: 27 January 2010
Intended Status: Informational
Summary:
I have some minor concerns about this document that I think should be resolved before publication.
Comments:
This document is clearly written and easy to understand. The requirements are numbered, which is helpful. I would have preferred to see more figures, but this is a matter of style.
This is the first PCE document I have reviewed, so I went back and read some of the previous RFCs. It may mean that my review is not sufficiently in-depth.
Major Issues:
No major issues found.
Minor Issues:
Section 2.1.10 : requirement R11
I found the term "reoptimization" confusing. It begs the question of whether the objective is to find an optimum path for the LSP or to place the LSP for the optimum use of the network. Indeed, "optimum" may, itself, be open to interpretation. Can you include some clarification of these terms, possibly by reference to other documents if they have already been defined in the PCE context?
Nits:
Section 2
s/seciton/section/
Back to the Routing Area Directorate wiki
The content of this page was last updated on 2021-07-22. It was migrated from the old Trac wiki on 2022-12-20.
All contributions to this wiki are covered by the IETF Note Well | Powered by Wiki.js