Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-isis-mi-bis-02

From: Orit Levin <[email-masked]>
Date: Fri, 7 Apr 2017 03:26:44 +0000

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.
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.).
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.
4. In section 2 par 3, change "support" and "operates" to "MUST support" to use requirements language.
5. In section 2 par 2, change "may" to either "can" or "MAY" to clarify the intent.
6. In section 2.1 par 3, clarify whether IID #0 is ever being used on the wire. Explain the concept of the "standard interface" (see previous comment).
Reason: It seems to me that IID #0 MUST never be used on the wire. Please, correct me if I am wrong.
7. In section 2.1, rephrase "marks ... by including" to "MUST include" to use requirements language.
8. In section 2.4.1 par 2 second sentence, the sentence starting with "However" needs to be rewritten using standards language to explain its intent. 
9. In section 2.5, replace "exists" with "MUST be performed".
10. In section 2.5.1, replace "only operates" with "MUST only be performed".
11. In section 2.5.2, replace "This requires" with "It is REQUIRED".
12. In section 2.5.2 third sentence, after "inconsistent" insert "due to their configuration". Please, correct me if I am wrong.
13. In section 7 Security Considerations, discuss possible additional security considerations (or the lack of them) related to the introduction of "instances".
Reason: Beyond the normal IETF procedure, this is especially important because "multiple instances allow isolation of resources..." Can this isolation, if observed or interfered, be damaging beyond the previous "standard interface" situation.

Nits/editorial comments:
1. Compare (Diff) the current draft with the published RFC 6822. You will find that many of the editorial corrections got lost in the bis version. Omitted corrections throughout the document include "instance-specific", " topology (or topologies)", "Type-Length-Value" and others.
2. In Introduction par 4, either change the two "may" to capitals or replace with "can" to clarify the intent.
3. In Introduction par 5, add references to where in the document the two methods are described. Also, consider changing "defined" to "described".
4. In Introduction par 7, move the last paragraph before listing the examples and adjust the text accordingly, for clarity.
5. In section 2.3, replace "normal" with "usual".
6. In section 2.6.1 first sentence, replace "not to cause" to "to avoid".

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 8 Apr 2017 23:23:03 +0000

Orit -

Thanx for the review.
Responses inline.

> -----Original Message-----
> From: Orit Levin [mailto:[email-masked]]
> Sent: Thursday, April 06, 2017 8:27 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> 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.
> 

[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.

> 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

[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

---

From: Orit Levin <[email-masked]>
Date: Thu, 13 Apr 2017 23:59:00 +0000

Hi Les,
Sorry for the delay in response.
Your feedback was very helpful. Below is a refresh of my comments. I tried to make them more pointed and some are new.

General:
1) For implementers who are familiar with the history and the intent of this extension, the information in the draft is probably sufficient to serve as a check list for implementing a multi-instance IS-IS router. For all other readers, the document doesn't contain an overview of the new mode of operation, i.e. where the instances are not a configuration and an internal implementation choice only, but are exposed through the protocol to achieve the stated objective. Lacking such an overview, the reader needs to reverse-engineer the logic behind the documented guidance.
2) The draft talks about "extensions" in plural. Based on a single extension on the wire and the overall goal of the new mechanism, I would say that it is a single extension only.  How many protocol extensions does this document define? If they can be clearly separated, then it needs to be clarified throughout the document. Otherwise, the language throughout the document needs to be changed from "extensions" to "the extention".
3) Editorial: Please, compare (Diff) the current draft with the published RFC 6822. You will find that various RFC Editor corrections got lost in this bis document. Some repeating examples of the lost corrections are "instance-specific", " topology (or topologies)" and "Type-Length-Value".

My comments below are a result of a reverse-engineering exercise. Please, consider incorporating the suggested clarifications to improve the document readability. I might have misunderstood some of the parts; in such cases, please, provide an alternative text.

Abstract
1) Add clarification: "This document is not backwards compatible with RFC 6822."
2) Par. 2, replace the first two sentences with: "Configuration of multiple protocol instances within a router allow the isolation of resources associated with each instance. This document introduces a new mode of operation where the protocol instances are not a matter of configuration only, but are exposed through the new protocol extension to achieve the objective stated above."
3) Par. 3 uses both present and future time. Does it mean before and after the extension? Please, clarify by spelling out the intent and/or changing the grammar.

1. Introduction
1) Move par. 3 to become the opening paragraph (i.e., par.1 ) in the Introduction to improve its logical flow (also related to the next comment).
2) Par 4, sentence #2 says "This document defines an extension to IS-IS to allow non-zero instances...". My assumption is that the intent of this draft is to define a single extension, which will improve the routing operations in a number of ways. If this is the case, the quote needs to be replaced with "The MI-IS-IS extension, defined in this document, also allows so-called "non-zero instances"..." .
3) Par 4, sentences #4 and #5 are not sufficient to describe the new mode of operation introduced by this extension. Below is my attempt to describe it. Please, correct, if I got it wrong.
"IS-IS router instances that support this extension are preconfigured with unique non-zero Instance Identifiers (IIDs) giving them the name "non-zero instances". In addition, MI RTRs MAY (or SHOULD ?) implement the legacy (or so-called "standard") instance of the IS-IS router for backwards compatibility with legacy IS-IS routers. IID #0 is only used by MI-RTRs to convey information associated with such standard interface if implemented. See section 2.6 Interoperability Considerations for more details."
4) Par 4, replace the two "may" with "can" to clarify the intent.
5) Par 5, change "defined" to "described" since the examples are not normative.
5) Par 5, add references to the (sub)sections containing the description of the two methods.
6) Par 7, move the last paragraph before listing the two examples and adjust the text accordingly, to improve the logical flow.
7) In the end of the Introduction add a reference: "This RFC is not backwards compatible with RFC 6822. Differences between this document and RFC 6822 are described in Annex A." ... so that others don't skip it by mistake as I did earlier...

2. Elements of Procedure
1) It seems that this section (informational) and its subsections (normative) use present and future times and, at times,  the normative language inconsistently both within the sections and among the sub-sections. Please, explain the reasons and improve consistency accordingly. 
2) Par 1, clarify the scope by adding "within a routing domain" at the end of the first sentence.
3) Par 1, after the first sentence add a new sentence alone the following lines "Routers form adjacencies and exchange routing updates only if their IIDs correspond." This explains the basic premise of the whole mechanism.
4) Par 2, change "may" to "can" or "might" for consistency.

Section 2.1
1) Par 2, change "may" to "MAY".
2) Par 3, remove "supported by legacy systems" from the first sentence to avoid confusion. My understanding is that IID #0 is reserved  for use by MI-RTRs that also implement the standard instance and advertise it in IIH using IID-TLV.
3) Par 3, change "except where noted" to "except as noted in section 2.6.2 (?)".  This is an excellent place to explain the logic behind this MUST NOT statement or, at least, state the general circumstances where IID #0 is included in IID-TLV.
4) Par 9 (4th after the picture), change "as described later" to " as described in section 2.6.2 (?)".  
5) Par 13, change "recommended" to "RECOMMENDED".
6) Editorial: Par 13, change "particularf" to "particular".

Section 2.2
1) Add that MI-RTR MAY (or SHOULD) implement the standard instance as well and which packets are used to advertise it.
2) Rephrase "marks ... by including" to "MUST include" to use requirements language.

Section 2.3
Editorial: Replace "normal" with "usual".

Section 2.4.1 
1) Par 1. Replace "IID #0" with "standard instance".
2) Par 1. Replace "instances other than IID #0" with "non-zero instances".
3) Par 2 second sentence. What does it mean "normal expectations"? Is this a network configuration requirement? Please, clarify in the text.

Section 2.4.2 Improve language consistency 
1) Verbs are used inconsistently: some are used in present time, others in future time. 

Section 2.5, replace "exists" with "MUST be performed".
Section 2.5.1, replace "only operates" with "MUST only be performed".
Section 2.5.2, replace "This requires" with "It is REQUIRED".
Section 2.5.2 third sentence, after "inconsistent" insert "due to their configuration". (Please, correct me if I am wrong.)

Section 2.6.1 
1) Editorial: Par 1, first sentence, replace "not to cause" to "to avoid".
2) Par 2, remove "(IID #0)".
3) Par 2, replace "non-zero IID" with "non-zero instance".
4) Par 5 NOTE, replace "IID #0" with "standard instance".

Section 2.6.2 
Replace all four appearances of "IID #0" with "standard instance". 

Section 3.1
Replace the two "MAY" to "can". 

7 Security Considerations
Discuss possible additional security considerations (or the lack of them) related to the exposure of "instances" on the wire.
Reason: Beyond the normal IETF procedure, this is especially important because "multiple instances allow isolation of resources..." Can this isolation, if observed or interfered on the wire, be damaging beyond the previous "standard instance" situation.

Thanks,
Orit.
-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Saturday, April 8, 2017 4:23 PM
To: Orit Levin <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Gen-ART Last Call review of draft-ietf-isis-mi-bis-02

Orit -

Thanx for the review.
Responses inline.

> 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.
> 
> 1. Add text explaining the reason (or reasons) for replacing the 
> original RFC
> 6822 from 2012.

> 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.).

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

> 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.

Section 2.1

Is clearly nonsensical.

Later in Section 2.1

???

   Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 14 Apr 2017 03:05:34 +0000

Orit -

It is obvious you spent a lot of time on this review - and I do want to be respectful of that.
However, there is a larger context here which I think has a significant bearing on handling of many of your comments.

RFC 6822 was published over 4 years ago. Multiple interoperable implementations exist. The bis version makes some modest - but significant changes. However, we deliberately strived to keep the bis version as consistent as possible with RFC 6822 in order to minimize the possibility that aspects of the specification which had NOT been changed would be reinterpreted simply because the wording had changed. So, in cases where you suggest (below) that a different wording is desirable I am very reluctant to make such changes because of the above concern.
If I do not indicate any response to a particular comment you can interpret as meaning:

"Unnecessary changes relative to RFC 6822 are not desirable."

Inline.

> Sent: Thursday, April 13, 2017 4:59 PM
> To: Les Ginsberg (ginsberg); [email-masked]
> Your feedback was very helpful. Below is a refresh of my comments. I tried
> to make them more pointed and some are new.
> 
> 1) For implementers who are familiar with the history and the intent of this
> extension, the information in the draft is probably sufficient to serve as a
> check list for implementing a multi-instance IS-IS router. For all other readers,
> the document doesn't contain an overview of the new mode of operation,
> i.e. where the instances are not a configuration and an internal
> implementation choice only, but are exposed through the protocol to
> achieve the stated objective. Lacking such an overview, the reader needs to
> reverse-engineer the logic behind the documented guidance.

[Les:] I am not sure I understand your concern. You seem to be suggesting that readers won't know when to use MI and when to simply create multiple non-MI instances of the protocol.
The short answer to that is that it is not the purpose of this document to make that decision. We have provided some new functionality - it is up to the user to decide when it is appropriate to use the new functionality and when it is not. We have provided some guidance in Sections 3 and 4 - but this is non-normative - as it should be.
But your use of "reverse-engineer" confuses me, so likely I do not understand your point.

As regards new vs old readers, the new version of the document provides as much (or as little) guidance as RFC 6822 - so I do not see why new readers would have any more issues than new readers of RFC 6822 had 4 years ago.

> 2) The draft talks about "extensions" in plural. Based on a single extension on
> the wire and the overall goal of the new mechanism, I would say that it is a
> single extension only.  How many protocol extensions does this document
> define? If they can be clearly separated, then it needs to be clarified
> throughout the document. Otherwise, the language throughout the
> document needs to be changed from "extensions" to "the extention".

[Les:] There are multiple changes in protocol behavior described - hence the term extensions is correct.

> 3) Editorial: Please, compare (Diff) the current draft with the published RFC
> 6822. You will find that various RFC Editor corrections got lost in this bis
> document. Some repeating examples of the lost corrections are "instance-
> specific", " topology (or topologies)" and "Type-Length-Value".

[Les:] Noted - thanx.

> My comments below are a result of a reverse-engineering exercise. Please,
> consider incorporating the suggested clarifications to improve the document
> readability. I might have misunderstood some of the parts; in such cases,
> please, provide an alternative text.
> 
> Abstract

[Les:] This statement is made explicitly in the Appendix - and I believe that is where it belongs for reasons I have previously stated.

> 2) Par. 2, replace the first two sentences with: "Configuration of multiple
> protocol instances within a router allow the isolation of resources associated
> with each instance. This document introduces a new mode of operation
> where the protocol instances are not a matter of configuration only, but are
> exposed through the new protocol extension to achieve the objective stated
> above."
> 3) Par. 3 uses both present and future time. Does it mean before and after
> the extension? Please, clarify by spelling out the intent and/or changing the
> grammar.
> 
[Les:] The sentence will in any case be changed when the document becomes an RFC - not worth discussing.

> 1. Introduction
> 1) Move par. 3 to become the opening paragraph (i.e., par.1 ) in the
> Introduction to improve its logical flow (also related to the next comment).
> 2) Par 4, sentence #2 says "This document defines an extension to IS-IS to
> allow non-zero instances...". My assumption is that the intent of this draft is
> to define a single extension, which will improve the routing operations in a
> number of ways. If this is the case, the quote needs to be replaced with "The
> MI-IS-IS extension, defined in this document, also allows so-called "non-zero
> instances"..." .
> 3) Par 4, sentences #4 and #5 are not sufficient to describe the new mode of
> operation introduced by this extension. Below is my attempt to describe it.
> Please, correct, if I got it wrong.
> "IS-IS router instances that support this extension are preconfigured with
> unique non-zero Instance Identifiers (IIDs) giving them the name "non-zero
> instances". In addition, MI RTRs MAY (or SHOULD ?) implement the legacy (or
> so-called "standard") instance of the IS-IS router for backwards compatibility
> with legacy IS-IS routers. IID #0 is only used by MI-RTRs to convey
> information associated with such standard interface if implemented. See
> section 2.6 Interoperability Considerations for more details."
> 6) Par 7, move the last paragraph before listing the two examples and adjust
> the text accordingly, to improve the logical flow.
> 7) In the end of the Introduction add a reference: "This RFC is not backwards
> compatible with RFC 6822. Differences between this document and RFC 6822
> are described in Annex A." ... so that others don't skip it by mistake as I did
> earlier...
> 
 [Les:] Reading of the Appendix is optional - the new version is usable without any need to refer to RFC 6822 - and that is its primary purpose.

> 2. Elements of Procedure
> 1) It seems that this section (informational) and its subsections (normative)
> use present and future times and, at times,  the normative language
> inconsistently both within the sections and among the sub-sections. Please,
> explain the reasons and improve consistency accordingly.
> 3) Par 1, after the first sentence add a new sentence alone the following lines
> "Routers form adjacencies and exchange routing updates only if their IIDs
> correspond." This explains the basic premise of the whole mechanism.
> 2) Par 3, remove "supported by legacy systems" from the first sentence to
> avoid confusion. My understanding is that IID #0 is reserved  for use by MI-
> RTRs that also implement the standard instance and advertise it in IIH using
> IID-TLV.
> 3) Par 3, change "except where noted" to "except as noted in section 2.6.2
> (?)".  This is an excellent place to explain the logic behind this MUST NOT
> statement or, at least, state the general circumstances where IID #0 is
> included in IID-TLV.
[Les:] #6 - Agreed.

> Section 2.2
> 1) Add that MI-RTR MAY (or SHOULD) implement the standard instance as
> well and which packets are used to advertise it.
> 3) Par 2 second sentence. What does it mean "normal expectations"? Is this a
> network configuration requirement? Please, clarify in the text.
> 
> Section 2.5.2 third sentence, after "inconsistent" insert "due to their
> configuration". (Please, correct me if I am wrong.)
> 
> Section 2.6.1
> Discuss possible additional security considerations (or the lack of them)
> related to the exposure of "instances" on the wire.
> Reason: Beyond the normal IETF procedure, this is especially important
> because "multiple instances allow isolation of resources..." Can this isolation,
> if observed or interfered on the wire, be damaging beyond the previous
> "standard instance" situation.
> 

[Les:] There are no security concerns associated with the use of multiple instances.
Security reviews of the document have been satisfied w the current contents.

   Les

> [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.
> 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.
> 
> 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.
> 
> 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".
> 
> [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.
> 
> ???
> 
> 
> [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.
>

---

From: Orit Levin <[email-masked]>
Date: Mon, 17 Apr 2017 23:00:13 +0000

Dear Les,

I see that you "agreed" to correct two typos only.
I disagree with your reasons for not making the document more readable and complete. Note that "more complete" doesn't necessarily mean "more prescriptive". It means removing ambiguities that will continue hurting interoperability of new and existing implementations. 
Since your guiding principle is "don't rock the boat / don't describe what to do - only what NOT to do", I see no point in arguing point-by-point. 
I know that different Areas have different standards for their documents, so I leave it to your community.

Thanks,
Orit.

-----Original Message-----
From: Les Ginsberg (ginsberg) [mailto:[email-masked]] 
Sent: Thursday, April 13, 2017 8:06 PM
To: Orit Levin <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: Gen-ART Last Call review of draft-ietf-isis-mi-bis-02

Orit -

Inline.

> Your feedback was very helpful. Below is a refresh of my comments. I 
> tried to make them more pointed and some are new.
> 
> 1) For implementers who are familiar with the history and the intent 
> of this extension, the information in the draft is probably sufficient 
> to serve as a check list for implementing a multi-instance IS-IS 
> router. For all other readers, the document doesn't contain an 
> overview of the new mode of operation, i.e. where the instances are 
> not a configuration and an internal implementation choice only, but 
> are exposed through the protocol to achieve the stated objective. 
> Lacking such an overview, the reader needs to reverse-engineer the logic behind the documented guidance.

> 2) The draft talks about "extensions" in plural. Based on a single 
> extension on the wire and the overall goal of the new mechanism, I 
> would say that it is a single extension only.  How many protocol 
> extensions does this document define? If they can be clearly 
> separated, then it needs to be clarified throughout the document. 
> Otherwise, the language throughout the document needs to be changed from "extensions" to "the extention".

> 3) Editorial: Please, compare (Diff) the current draft with the 
> published RFC 6822. You will find that various RFC Editor corrections 
> got lost in this bis document. Some repeating examples of the lost 
> corrections are "instance- specific", " topology (or topologies)" and "Type-Length-Value".

[Les:] Noted - thanx.

> My comments below are a result of a reverse-engineering exercise. 
> Please, consider incorporating the suggested clarifications to improve 
> the document readability. I might have misunderstood some of the 
> parts; in such cases, please, provide an alternative text.
> 
> Abstract

> 2) Par. 2, replace the first two sentences with: "Configuration of 
> multiple protocol instances within a router allow the isolation of 
> resources associated with each instance. This document introduces a 
> new mode of operation where the protocol instances are not a matter of 
> configuration only, but are exposed through the new protocol extension 
> to achieve the objective stated above."
> 3) Par. 3 uses both present and future time. Does it mean before and 
> after the extension? Please, clarify by spelling out the intent and/or 
> changing the grammar.
> 

> 2) Par 4, sentence #2 says "This document defines an extension to 
> IS-IS to allow non-zero instances...". My assumption is that the 
> intent of this draft is to define a single extension, which will 
> improve the routing operations in a number of ways. If this is the 
> case, the quote needs to be replaced with "The MI-IS-IS extension, 
> defined in this document, also allows so-called "non-zero instances"..." .
> 3) Par 4, sentences #4 and #5 are not sufficient to describe the new 
> mode of operation introduced by this extension. Below is my attempt to describe it.
> "IS-IS router instances that support this extension are preconfigured 
> with unique non-zero Instance Identifiers (IIDs) giving them the name 
> "non-zero instances". In addition, MI RTRs MAY (or SHOULD ?) implement 
> the legacy (or so-called "standard") instance of the IS-IS router for 
> backwards compatibility with legacy IS-IS routers. IID #0 is only used 
> by MI-RTRs to convey information associated with such standard 
> interface if implemented. See section 2.6 Interoperability Considerations for more details."
> 6) Par 7, move the last paragraph before listing the two examples and 
> adjust the text accordingly, to improve the logical flow.
> 7) In the end of the Introduction add a reference: "This RFC is not 
> backwards compatible with RFC 6822. Differences between this document 
> and RFC 6822 are described in Annex A." ... so that others don't skip 
> it by mistake as I did earlier...
> 

> 2. Elements of Procedure
> 1) It seems that this section (informational) and its subsections 
> (normative) use present and future times and, at times,  the normative 
> language inconsistently both within the sections and among the 
> sub-sections. Please, explain the reasons and improve consistency accordingly.
> 3) Par 1, after the first sentence add a new sentence alone the 
> following lines "Routers form adjacencies and exchange routing updates 
> only if their IIDs correspond." This explains the basic premise of the whole mechanism.
> 2) Par 3, remove "supported by legacy systems" from the first sentence 
> to avoid confusion. My understanding is that IID #0 is reserved  for 
> use by MI- RTRs that also implement the standard instance and 
> advertise it in IIH using IID-TLV.
> 3) Par 3, change "except where noted" to "except as noted in section 
> 2.6.2 (?)".  This is an excellent place to explain the logic behind 
> this MUST NOT statement or, at least, state the general circumstances 
> where IID #0 is included in IID-TLV.
[Les:] #6 - Agreed.

> 3) Par 2 second sentence. What does it mean "normal expectations"? Is 
> this a network configuration requirement? Please, clarify in the text.
> 
> Section 2.5.2 third sentence, after "inconsistent" insert "due to 
> their configuration". (Please, correct me if I am wrong.)
> 
> Section 2.6.1
> Discuss possible additional security considerations (or the lack of 
> them) related to the exposure of "instances" on the wire.
> because "multiple instances allow isolation of resources..." Can this 
> isolation, if observed or interfered on the wire, be damaging beyond 
> the previous "standard instance" situation.
> 

   Les

> [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.
> 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.
> 
> > support for instances vs. other already existing concepts also 
> > listed in the Abstract (i.e., circuits, adjacencies,  topologies, etc.).
> 
> 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.
> 
> >refer to the  same thing - the implementation of the original 
> >protocol without the concept  of instances. Please, correct me if I am wrong.
> 
> 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".
> 
> [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.
> 
> ???
> 
> 
> #0 is discussed. I do not understand how a reader would conclude that 
> IID #0 is never sent on the wire.
>