ietf
[Top] [All Lists]

RE: Gen-ART Last Call review of draft-ietf-isis-mi-bis-02

2017-04-08 18:23:22
Orit -

Thanx for the review.
Responses inline.

-----Original Message-----
From: Orit Levin [mailto:oritl(_at_)microsoft(_dot_)com]
Sent: Thursday, April 06, 2017 8:27 PM
To: gen-art(_at_)ietf(_dot_)org
Cc: ietf(_at_)ietf(_dot_)org; 
draft-ietf-isis-mi-bis(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Subject: Gen-ART Last Call review of draft-ietf-isis-mi-bis-02

I am the assigned Gen-ART reviewer for this draft. The General Area Review
Team (Gen-ART) reviews all IETF documents being processed by the IESG for
the IETF Chair.  Please treat these comments just like any other last call
comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-isis-mi-bis-02
Reviewer: Orit Levin
Review Date: 2017-04-06
IETF LC End Date: 2017-04-07
IESG Telechat date: 2017-04-13

Summary: This draft is "ready with issues" for publication.

Major issues: None.

Minor issues:

1. Add text explaining the reason (or reasons) for replacing the original RFC
6822 from 2012.
Reason: It is a "bis" draft and there is no mention about it in the text.

[Les:] Note that the latest revision of the draft correctly identifies the 
draft as obsoleting RFC 6822. Previous versions had incorrectly identified this 
as an update to RFC 6822.
This is then the new Standard for the IS-IS MI support.

There are two classes of future readers of this document:

a)Readers who are unfamiliar with RFC 6822. For them what changed between RFC 
6822 and this document is irrelevant. 

b)Readers who are familiar with RFC 6822. For them it is useful to know what 
changed - which is described in Appendix A.

In order not to distract readers of type "a" - as well as to provide an 
"uninterrupted" description of the normative behavior I believe placement of 
the change description in an Appendix improves the readability of the document.

Does this make sense to you?

2. In Abstract, state clearly that this standard introduces the support for
instances vs. other already existing concepts also listed in the Abstract 
(i.e.,
circuits, adjacencies,  topologies, etc.).

[Les:] The Abstract currently says:

"This draft describes a mechanism that allows a single router to share
   one or more circuits among multiple Intermediate System To
   Intermediate System (IS-IS) routing protocol instances."

Previous to this extension, a router could have multiple instances of the IS-IS 
protocol, but multiple instance could not be run over the same interface. 
So we are not introducing "instances", but we are introducing the ability to 
enable multiple instances on the same interface.

Reason: The wording is not clear about what is the new feature vs. what are
the new benefits vs. what was the original baseline 

3. Throughout the
document, use "standard instance" instead of "IID = 0" or "IID #0".
Reason: Expressions "standard instance", "IID = 0" and "IID #0" are used
interchangeably throughout the document. It seems that they all refer to the
same thing - the implementation of the original protocol without the concept
of instances. Please, correct me if I am wrong.

[Les:]  I don't think this is possible without seriously compromising the 
document. For example:

Section 2.1

" IID #0 is reserved for the standard instance supported by legacy
   systems. "

Changing this to  " Standard instance is reserved for the standard instance ..."

Is clearly nonsensical.

Later in Section 2.1

"When the IID = 0, the list of supported ITIDs MUST NOT be present."

What is being discussed here is what is the correct behavior when an MI-capable 
router sends a PDU associated IID #0 and includes the new IID TLV. 
Replacing this with "When the standard instance..." loses the important point 
that the value of the IID in the IID TLV in this case is "0".

Hope this helps clarify things.

4. In section 2 par 3, change "support" and "operates" to "MUST support" to
use requirements language.

[Les:] I am on the fence as regards this change. Section 2 is an introduction 
to the following sub-sections - which define the normative behavior. But the 
introduction itself is not defining normative behavior - it is providing a 
context in which the protocol extensions defined in the following sub-sections 
can be understood. 

I am more inclined to change the "MAY" used later in the same paragraph you 
mention to "may" so it is consistent with the rest of this section.

???


5. In section 2 par 2, change "may" to either "can" or "MAY" to clarify the
intent.

[Les:] Did you mean Section 2.1 para 2?
If so I agree to the change.

6. In section 2.1 par 3, clarify whether IID #0 is ever being used on the 
wire.

[Les:] There are numerous places in the document where the legal use of IID  #0 
is discussed. I do not understand how a reader would conclude that IID #0 is 
never sent on the wire.

Explain the concept of the "standard interface" (see previous comment)

[Les:] There is no mention of "standard interface" - did you mean "standard 
instance"?

If so, Section 1 paragraph 4 states:

"Legacy routers support the standard
   or zero instance of the protocol."

   Les


<Prev in Thread] Current Thread [Next in Thread>