<adding list> I agree with the text below. The text is great but your Example 4 is a bit confusing to me. Hopefully you can help me out with that later or having it in the entire revision will probably clear that up for me (it is often hard to see clarity in the snippets).
I would change "the YANG models" to "the FPC YANG models" as we do not want to speak for all YANG models. -----Original Message----- From: Charlie Perkins [mailto:charles.perk...@earthlink.net] Sent: Sunday, January 21, 2018 11:11 PM To: Bertz, Lyle T [CTO] <lyle.t.be...@sprint.com> Cc: Marco Liebsch <marco.lieb...@neclab.eu>; Satoru Matsushima <satoru.matsush...@gmail.com>; Sri Gundavelli (sgundave) <sgund...@cisco.com>; Moses, Danny <danny.mo...@intel.com>; Weaver, Farni [CTO] <farni.wea...@sprint.com>; Matsushima Satoru <satoru.matsush...@g.softbank.co.jp> Subject: Indexed sets Hello folks, Here is some relevant text I developed to explain this concept. It was mostly present in the previous document I sent out last week. Below, I have some follow-up questions regarding the concept. > To encourage re-use, the YANG models define indexed sets of various > types of entities. To access such an model entity, other model > elements contain an attribute which is typically denoted as > "entity- > Id". When such an attribute is encountered, the referencing model > element will indicate how to supply any needed values so that the > entity model will be fully defined when used in any instance of the > referencing model element. For example: Figure 4 shows 2 entities: > > EntityA definition references entityB model elements. > > EntityB model elements are in a set indexed by entity-Id. > > Each EntityB model element has an Id which allows it to be uniquely > identified, and a Type which specifies its form, allowing for > creation of an instance by inserting entityB-Values as indicated. > . > . > | > +-[entityA] > | +-[entityB-Id] > | +-[entityB-Values] > . > . > | > +-[entityB] <Set> > | +-[entityB-Id] <L-Key> (M) > | +-[entityB-Type] > . > . > > Figure 4: Indexed sets of entities > > Indexed sets are specified for the following kinds of entities: > > Domains > DPNs > Policies > Descriptors > Actions > Interface Groups ============================================================== According to this, for example with "DPN", we would have a DPN-Id that allows one to locate the DPN (i.e., find what had been previously called a DPN-reference). With that in mind, I put in the following lines in the DPN structure: > | > +-[DPN] <Set> > | +-[DPN-Id] <G-Key>, <Name> (O) But this isn't really correct. As I read it, the structure would mean that there is a thing called a "DPN-Id Key", and another thing called a "DPN-ID Name". What we really want is a DPN-Key and a DPN-Name. That could be specified more simply as follows: > | > +-[DPN] <G-Key>, <Name> (O) <Set> > If we could use this to mean that there are attributes denoted "DPN-Key" and "DPN-Name", then we have a natural and understandable structure. These attributes would apply to the *elements* of the DPN Set, not the DPN-Set itself. In this case, I would rewrite the relevant parts of the document to replace instances of "DPN-Id" to instead use "DPN-Key". And similarly for other indexed sets. I hope you will agree, so that we can get to unambiguous language for describing this important concept without the currently existing redundancy. Somewhat less important, but still of interest: In the example above, there seems to be an implicitly described entity called a "DPN-Set" which is a set of DPNs. In the text, when we need to refer to the set of DPNs, I propose that we use exactly the naming convention that it is called "DPN-Set". That would be slightly but significantly different than "a set of DPNs", and if you approve, the nomenclaure "DPN Set" (i.e., lacking the '-') should probably not be used. Regards, Charlie P. ________________________________ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
