On Tue, Apr 22, 2014 at 8:19 AM, Jeffrey Haas <[email protected]> wrote:
> Joel, > > On Tue, Apr 22, 2014 at 10:28:13AM -0400, Joel Halpern Direct wrote: > > Since ForCES name space is per-lfb-class. So that the collision > > problem is mostly in the naming of the lfb classes. (Some care is > > needed in the naming of data types and such, but it is pretty easy > > to do that in a colission avoiding fashion. The harder problem, > > which applies equally to NetConf and ForCES, is to know when you can > > reuse an existing definition and when you need your own.) > > I'm still working my way through my FORCES reading. It would be very > helpful to see an example of this. > > Isn't "knowing when you can reuse an existing definition" just a tooling issue (e.g., searchable library of existing definitions)? YANG is designed to be as readable by humans as possible because usually humans need to understand the data model. > To offer an example from netconf that I commented upon at various WG > sessions, a RIB entry will tend to consist of things that are common across > implementations (prefix, nexthop[s], source protocol) and may be augmented > by either protocol-specific components (AS_PATH, communities for BGP; > metric > for IGP) or vendor-specific ones (weight, administrative distance, etc.) > > In YANG, this is mostly a matter of just decorating with additional XML > elements around the core objects. (I'm over-generalizing.) > > How does one do this in FORCES? > > > Note that the protocol on the wire does not use the names at all, > > but only the assigned identifiers. Which are registered precisely > > to avoid collision. > > One of my lesser concerns here is that code point registries provide > another > pivot for coordinating development work, in or out of IETF. Arguably, XML > token names have the same sort of issue to some extent, but tend not to be > "last code point +1". > Who assigns code points? IANA? IMO it is really useful to have distributed naming authority, so vendors do not need to register every data node as a new code point with IANA. The experience in NETCONF has been that human friendly identifiers like "/interfaces/interface/name" are far easier to work with than OIDs like 1.3.6.1.2.1.31.1.1.1.1 I think EXI encoding would be almost as efficient as a native binary encoding for NETCONF and HTTP compression should be about the same for RESTCONF. > -- Jeff > Andy
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
