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:
> 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?
>
>
>
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to