Document: draft-ietf-isis-wg-multi-topology-11.txt
Reviewer: Miguel Garcia <miguel.an.garcia@nokia.com>
Review Date: 2006-10-24
IESG Telechat Date: 2006-10-26
Summary: This draft is basically ready for publication, but has nits 
that should be fixed before publication.

Comments:

- Abstract: the draft fails to mention that "New TLVs are created to 
support Multi-Topology ISIS" or something like that. I think it is 
important that the abstract indicates whether there are new extensions 
or not.

- Abstract: I don't like that the abstract mentions the words "optional" 
and "used today by many ISPs". The former because everything is optional 
in this life until you use it. The later because it misleads me, since I 
don't know if the draft is a BCP or a standard track. Whether this 
extensions is used today or not and by many or fewer ISP is completely 
irrelevant for the draft.

- I found hard to read the draft, mainly due to two issues:

a) The draft is written with a poor English grammar. There are quite a 
few missing articles, lack subject-verb agreement, etc. I recommend the 
authors to get a native English speaker and do an editorial review to 
improve readability.

b) Acronyms are never expanded. The RFC Editor requires to expand an 
acronym the first time it is used (except for well-known acronyms such 
as TCP, IP, etc.). The draft rarely expands any acronym, so it becomes 
hard to understand the terms unless the reader is familiar with the 
technology. So I would recommend to expand the first appearance of an 
acronym. Due to the large number of acronyms in this draft, the authors 
may also consider to add an "Abbreviations"  or "Definitions" section.

- The draft mentions the word "draft" twice in the abstract (and I think 
elsewhere too). When proceeding as an RFC, this draft will no longer be 
a draft. So I suggest to replace "draft" by "document".

- Double quotes are strange and non-standard throughout the document. 
Example: ``standard'' which should be "standard".

- Section 8 says:

"The implementation and configuration MUST make sure the IP packets are 
only traversed through the nodes and links intended for the topologies 
and applications".

Unfortunately I don't know how to digest the normative MUST. Which 
actions do I need to take on the implementation to implement the MUST? I 
think the "MUST" is not applicable to the configuration, at least, 
standard track RFCs do no impose normative statements to the 
configuration. So I think this isn't a "MUST", unless the authors can 
spell out some implementable actions to support and test the compliance 
with such MUST.

- Section 2, second paragraph, the text reads:

"In the case of adjacency contains multiple MTs on an interface, and if 
there exists overlapping IP address space among the topologies, 
additional mechanism MAY be used to resolve the topology identity of
the incoming IP packets on the interface."

I don't understand what those "additional mechanisms" are. I guess an 
example would help (e.g., add "such as  .... "). I have also concerns 
with the usage of "MAY". I am not sure if this is a "MAY" or a "can".

- I run idnits, and it returned the following nits:

   Miscellaneous warnings:
   - The copyright year in the RFC 3978 Section 5.4 Copyright Line does 
not match the current year

   Experimental warnings:
   - Unused Reference: 'ISO10589' is defined on line 489, but not referenced
   - Unused Reference: 'RFC1195' is defined on line 494, but not referenced

   This last two nits are not correct though. On Section 1 the draft 
refers to both references, but with a strange way to refer to them. The 
draft says:

   "Maintaining multiple MTs for ISIS [ISO10589 , RFC1195] in ...."

and should probably say:

   "Maintaining multiple MTs for ISIS [ISO10589] [RFC1195] in ..."