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'? 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? 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. 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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
