> Can you explain how an off-line representation of the data model can be fast > or slow?
Marshalling can still be fast or slow. I'm not convinced that YANG, being focused on management, rather than protocol level interaction, doesn't have a lot of stuff that's not needed, and does have all the stuff that's needed -- nor do I understand what the overhead of carrying the stuff that's not needed is going to be. > You mean the YANG compiler takes too long to process a YANG file? > You mean the unspecified I2RS protocol will be too slow on the wire if it uses > XML or JSON encoding of YANG data structures? If I2RS on the wire uses all YANG structures and NETCONF, then it won't be I2RS -- it'll be YANG. That's okay if we look at the requirements and determine that YANG resolves all of them. In that case, fold the WG and be done -- it's a lot of extra work for no net gain. Again, however, I'm not convinced that YANG fulfills all the requirements at hand. > YANG is a data modeling language. > RESTCONF is a protocol. > Atomicity is a property of the protocol. Kindof. You can build a model that assumes atomic processing, and hence includes everything in the model to make certain atomic processing will work correctly. Or you can assume the data model will be used for just reading and writing discrete pieces of data, and then say, "we leave how to actually use the data up to someone else." YANG seems to do the latter, not the former. To put it a different way -- you can look at the problem of interacting with the RIB in two ways: - I want to be able to read stuff out of and push stuff into the RIB from time to time. - I want to interact with the RIB in parallel with other routing processes in near real time. I'm not convinced these are the same question. Can you prove they are? > It seems to me this WG needs to start asking the right questions about the > data modeling language requirements. E.g.: Data modeling is only half the problem -- part of the issue here is we've jumped right from a really large number of use cases to, "let's build data models," then to, "hey, these look a lot like YANG, so let's just use YANG." The interaction between the RIB and off box processes are important, too -- but we've apparently just left those behind in the rush to models. > You are asking about protocol requirements, not data modeling. Right! So let's go back to the protocol work, and once we have protocol and application level requirements, based on use cases, then we can ask, "hey does YANG have all the bits we need to make this work?" Right now, we don't know what the bits we need to make this work really are, so choosing a data model, or having some sort of competition between data models, doesn't make a lot of sense, to me. > IMO it would be near-sighted and extremely impractical to choose a language > that only supported description on RIB info. I fail to see what is so special > about RIB info that would warrant its own DML. So you'd argue that all the requirements in all the different use cases can be fulfilled with YANG? There is _nothing_ unique in _any_ of those use cases the YANG model doesn't support? Do the analysis and prove it. :-) Russ _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
