Hi Jeff, Apologies, on travel mode - so some latency involved.
On Tue, Apr 22, 2014 at 11:08 AM, Jeffrey Haas <[email protected]> wrote: > I can definitely see such a case, although the more likely paradigm is > injecting a large number of RIB entries that may have some BGP properties, > such as communities or inputs to various BGP-like policy mechanisms. > It will be useful to come up with some hand-wavy numbers; at minimal for implementations to check if they are within expected ranges. > I have created stubs in the wiki for such comparisons. Would you mind > starting the work for FORCES? > > http://wiki.tools.ietf.org/wg/i2rs/trac/wiki > > You will require a datatracker login. If you run into issues with editing, > please unicast me. This is the first time I'll have done more than editing > it myself. > > If someone is willing to start stubbing in similar items for Netconf/Yang, > that would be helpful. > I will update the ForCES bits at the next opportunity i get. Useful again to have a matrix of I2RS requirements vs what a model/protocol offers. While the presentations at the meeting attempted to follow that, it was not "standard" requirements. >> On compute: >> I would expect json to perform better than XML when sending to a browser. > > While I think that detail is true, I suspect a browser is not the first > order consumer of the information. > > My general experience with such things is that JSON does fine when you want > to pass around JavaScript native data, but that you lose some of the > semantic layering in turning things into JavaScript. My personal preference > would be that if we provide JSON layers that they effectively be at the far > end of the pipe (UI facing) rather than the native object in-protocol. > > Obviously such details are discussion points and the above is simply my > opinion and experience. > it does make sense; note what i said earlier are arguements the pro-json camp uses against xml. Mostly they deal with a browser as an endpoint. Having said that there will always be an impedence mismatch of some form between a representation and the native format; i just claim it is less so with binary than it is with any form of ascii. > > While certainly not a constraint on the working group, I tend to remember > that we want I2RS to be as pervasive as possible. This means that anything > we can make work well on older platforms means it's more likely to be > supported across a wide range of devices. This has impact, for example, on > crypto load. > Nod. > [Several other good points that should be in the wiki entry elided.] > > I think I made this observation at the last IETF session: Even for simple > compression, XML tends to compress *very* nicely with small dictionaries. > Since HTTP compression is well deployed, I suspect this isn't quite as big a > deal as it could be. Of course, that presumes we're layering on top of > something HTTP-like. > Yes, http compression is pretty ubiquitous - so something like restconf could take advantage of that. > It's pretty common to either tap before or after the transport APIs for > debugging. I think the distintion is that in something text-like you can > tap and do thinks potentially simpler than if you have to look at binary > PDUs. That requires tapping one level back before the binary marshalling > layer. Obviously that is doable as well, but simply moves the point of > complexity one layer up/down. > So I am sensing development debugging then? The arguement i have heard is that operators debug by capturing on the wire packets and that ascii was easier to follow. > To offer a somewhat BGP network operations example, those who use the MRT > file format (RFC 6396) typically have programs that convert from/to that > format in human-readable form. Some users may use binary API to interact > with the files but the majority of operators I've interacted with that use > it tend to simply transform it to ASCII and Do Something Clever using their > favorite scripting language. > Ok, understood. > I've left a stub in the wiki for helping to derive or map requirements. I will be picking requirements as i find them (architecture doc etc) and filling up the ForCES responses. cheers, jamal _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
