On Sat, Apr 19, 2014 at 11:06 AM, Russ White <[email protected]> wrote: > > > 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. > >
Perhaps we agree on 1 thing -- this is all speculation without a protocol definition. You are confusing the protocol properties and data model properties with the data modeling language properties. If you don't like the sentence, you don't blame the alphabet. YANG is just the schema for describing valid instances of conceptual data. The protocol operations and server implementation performance depend on how YANG is used. I am still unclear on this "E is for Engineering, so we don't mention tools" thing. That sounds like computer science , not engineering. Engineers need to worry about the practical implementation of the design. The ability to leverage existing technology is extremely relevant to software engineering. > :-) > > Russ > > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
