Subject: [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-uni-nni-02

From: Julien Meuric <[email-masked]>
Date: Wed, 22 Dec 2010 17:03:27 +0100

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 
http://www.ietf.org/iesg/directorate/routing.html

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-mpls-tp-uni-nni-02.txt
Reviewer: Julien Meuric
Review Date: 2010-12-22
IETF LC End Date: 2010-12-23
Intended Status: Informational

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

*Comments:*
This document focuses on a specific topic within a limited scope. 
Nevertheless, it is a patch to RFC 5921 and thus requires reading some 
parts of the latter (sections 3.4.2 and 3.4.3 mainly), which is 
detrimental to its readability if considered alone.

*Major Issues:*
No major issues found.

*Minor Issues:*
- It is not obvious why P nodes are not mentioned when tackling the NNI. 
It requires to look for an answer in RFC 5921, which lies in the last 
paragraph of section 3.4.2. It may be worth considering introducing that 
paragraph in this document (in section 1 for instance).
- Linked to the above, the exact scope of the document is defined a bit 
late: the fact that UNI and NNI are "Transport Service Interfaces" is 
not stated before section 1.1, while one would expect to be aware of 
this information from the abstract and introduction.
- The phrase "Transport Service Instance" is only mentioned in section 
3: defining it in section 1.2 may improve the readability; "TSI" is only 
used in drawings: is it necessary to use the acronym, especially in this 
context where the phrase "Transport Service Interface" is also used?
- The term "attachment circuit" is mentioned in section 2, but it does 
not appear on figures, nor is defined in the I-D. Definition and/or 
illustration would be welcome.
- The acronyms UNI-C and UNI-N are used for the first time in section 
1.1, without expansion/definition and before the terminology section. 
They should either be removed from there, or be expanded/defined at 
first use.
- The acronym UNI-N is defined in section 1.2 but not actually expanded, 
thus leading to wonder why "-N". I agree that "PE side" is more 
meaningful than "network", but adding expansion while keeping definition 
may be considered.
- Figure 1: it looks like "Native service control" is defined as native 
service control and/or GMPLS, where I understand that GMPLS can be an 
option even if not native. Would not it be clearer to write "Service 
control" and keep current definition (native and/or GMPLS)?

*Nits:*
Abstract
s/subjet/subject/
-----
Section 1.2
s/PE Side/PE side/
-----
Section 2 & 3
- either:
     s/User-Network/User-to-Network/ in section 2
     + s/NNI is illustrated/Network-to-Network Interface (NNI) is 
illustrated/ in section 3
- or: s/User-Network Interface (UNI)/UNI/ in section 2
-----

Regards and merry Christmas,

Julien