Eric, Thanks for the feedback, comments inline below.
> On Jun 5, 2015, at 8:17 AM, Osborne, Eric <[email protected]> wrote: > > General comments: the doc is pretty straightforward in many of its aims but > parts of it are confusing. Certain sections need some copyediting and an > infusion of 'the'. It also barely touches on the idea of config models vs > state data and ops, and this distinction is (I think) pretty lost at some > points. Do Standard models include config, state and ops? Or are Standard > models just some subset? Do they *have* to be a subset? Adding more > discussion around the interplay of [standard, standard extension, > proprietary, vendor] * [config, state, ops] would be interesting. > > Specific comments: > > 1) > --- > o Based on the level of abstraction in the model > > o Based on the applicability of the model > > The two categories are covered in the next two sections. > > 2. First Dimension: YANG Data Model Layering > ..... > 3. Second Dimension: Model Type > ----- > > The section titles should match the bulleted list. Maybe the first dimension > should be 'Model Abstraction Levels' and the second should be 'Model > Applicability’? Since the content of section 2 is all around “layering”, I did the following: <t>This document presents a set of concepts and terms to form a useful taxonomy for consistent classification of YANG models in two dimensions: <list style="symbols"> <t>The layering of models based on their abstraction levels</t> <t>The type of model based on the nature and intent of the content</t> > 2) > Figure 1 lists both 'BGP' and 'Routing'. I'm guessing from context that > 'Routing' really means 'RIB' or something, and I know there's been a lot of > discussion I've been very vigorously disregarding, but maybe 'Routing' in > this doc should read 'RIB' so as to not let the reader think it's shorthand > for 'Routing Protocol'? Or if you intend for 'Routing' to mean 'Routing > Protocol', then shouldn't BGP be subordinate to it? Good catch, switched the labels to "MPLS", "BGP", "IPv4 & IPv6" and “Ethernet" > > 3) > -- > > As an example, the Network Service model included in > http://datatracker.ietf.org/doc/draft-l3vpn-service-yang/ provides an > --- > > Fix the reference to [I-D-l3vpn-service-yang] or whatever the right format is. Fixed, thanks. Will submit a pull-request based on the above. Again; thanks! > > 4) > Section 3 gets a little tricky. It seems to imply that the service models > are built after the vendor models are built, and that the service models can > only be built out of the pieces provided by vendor models. While this makes > sense on its face (you can't use a component to build a service if that > component doesn't exist), it reads like SDOs are beholden to the vendors > exposing the right bits before the SDOs can do anything. Surely there's > going to be some give and take here, where SDOs (or customers! ahem..) isssue > standard service models and the vendors need to come up with config models to > support them? It's also not clear exactly what turf 'vendor config models' > is grabbing. If we have a standard ACL model, for example, do I also need a > vendor ACL config model? > > > 5) > I'm not sure what value the discussion around routing protocol config (p. 8+) > provides. Does this schism of protocol vs vrf centricity apply to state and > ops too? Is it specific to config? It's called out here but there's no > conclusion, it just says "here's a thing". Why is this thing more important > than all the other things that could be mentioned? Also, you may want to > remove CLI from the discussion of centricity; it's clear that this is an > IOS-vs-JunOS section. If you're going to show both models, use YANG or > pseudo-YANG to describe both. > > > 6) > I don't get section 3.5. Why is it there? Just as a placeholder to say > "this might happen"? Shouldn't any discussion of vendor models either > a) stay away from telling vendors what to do, or > b) encourage vendors to get off of proprietary models ASAP once there's > a standard one? > That's sort of what "while waiting..." means, but I think this section either > should be much bigger or not be there. > > > 7) > I don't like the last paragraph of section 5. What is it saying? That the > IETF can take the Linux kernel and write a standard model for it? > I guess maybe it's trying to say "IETF must be the place where all models are > blessed if they're about IETF technology"? > Is the RIB IETF technology? What about an ACL? > Does the IETF not recognize other sources of models for IP-and-SDN stuff? > > > > > eric _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
