Subject: [RTG-DIR] Routing Directorate review of draft-ietf-rtgwg-ni-model-02

From: "John G. Scudder" <[email-masked]>
Date: Fri, 28 Apr 2017 16:23:57 -0400

Hi All,
 
I have been selected to do a routing directorate aQA review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-ni-model/
 
The QA review is described (https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa) as:

"The WG Draft Quality Assurance process exists to provide cross-WG and expert review early in the IETF process after a WG has adopted a WG draft or while the WG is deciding to adopt a draft. Since a WG adopts a draft as a good starting point for the work, providing early excellent review of such drafts allows for good technical discussion and the ability to enhance the WG draft to solve identified issues. The earlier in the process that substantial issues (technical or editorial) are resolved, the more quickly and smoothly a WG draft is likely to proceed."
 
For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Document: draft-ietf-rtgwg-ni-model-02.txt 
Reviewer: John Scudder
Review Date: April 28, 2017

Summary: 

I found the document easy to follow, clear and almost painless to read, thank you.

Note that my level of Yang expertise is pretty low, so you should be looking elsewhere for a critique of anything other than the grossest Yang-specific aspects of the document. (I found the schema-mount example in section 3.2 particularly opaque.)

Comments and Questions:

1. There's a significant amount of duplication of explanatory and background text between this document and draft-ietf-rtgwg-lne-model-01. In reading it, I tried to consider whether it would be OK to cut out some of the text explaining what an LNE is, but on the whole I think it's better left in -- the document would have been more difficult to read without having that context in-line. However, it does lead to the question, is there some good reason the two documents are separate, instead of a single document? The duplication between them suggests there's at least some motivation to refactor them into one. (I realize there may be many reasons to keep them separate, including "seriously, John? The cost/benefit just isn't there", but I had to ask.)

2. The abstract is almost a copy of the abstract for draft-ietf-rtgwg-lne-model-01. Comments in #1 above notwithstanding, I do think brevity is the soul of wit when it comes to an abstract, so I suggest removing the LNE definition here, and just define the stuff *this* doc is about. (Similar suggestion applies to the companion doc's abstract.)

3. It seems to me the "TBD" for network-instance-policy represents a significant open issue and deserves to be included in your open issues list (section 1.1). Other TBDs sprinkled throughout don't seem to rise to this level, but of course do represent open issues.

4. Speaking of network instance policy, although since it's left TBD there's not much to be said, the examples you give (RTs, RDs, VNIs, VPLS neighbors) mostly don't seem like what I think of as "policy". I suppose it's one of the most overloaded terms in our industry, so maybe someone else does think of it that way, but this choice of terminology was a speed bump for my understanding of the doc.

5. The example given in section 3.2 doesn't seem to follow the same pattern as the one given in section 3. I'm too much of a Yang neophyte to know if there might be some Yang feature in play that makes this make sense, but on the face of it the example in section 3 seems to tell me I'm supposed to bind a network-instance-name to a specific instance of an interface (so, if:interfaces/if:interface), whereas what I see in 3.2 is a network-instance-name at the if:interfaces level -- which doesn't make a lot of intuitive sense, either.

Minor Issues and Nits:

6. I've edited various minor suggestions into a copy of draft-ietf-rtgwg-ni-model-02.txt and attached it, you can look at them using your diff tool of choice.

7. This sentence isn't quite right:

   Network instance policies are used to control how NI information is
   represented at the device level, VRF routing policies, and VRF/VSI
   identifiers.

Without knowing your intent I'm not able to offer you a rewrite. Possibly it would be enough to reorder the items in your list, to put the big compound one at the end, as in "Network instance policies are used to control VRF routing policies, VRF/VSI identifiers, and how NI information is represented at the device level"? 

8. This sentence no verb:

                      For layer 3,
                      this consistent with the routing-instance
                      definition in ietf-routing

Again, without knowing your intent I can't offer a rewrite. Maybe the verb "to be" is what you want?

---

From: Lou Berger <[email-masked]>
Date: Sat, 29 Apr 2017 10:44:31 -0400

Thanks for the review!  We'll address your (much appreciated!)  comments
as part of our next planned update which will also include:

- update to next rev of schema mount (which gates this works)

- more informational text / examples

Thanks,

Lou

On 4/28/2017 4:23 PM, John G. Scudder wrote:
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg