Re: [netmod] YANG Mount = Alias Mount + Peer Mount (was RE: Motivations for Structuring Models)

Hi Eric,

we are dealing with two rather different problems:

1. A pull-type method for combining YANG schemas as a complement to
   "augment".

2. A proxy function that mediates access to data that are located
   elsewhere.

I believe the recent thread on structuring YANG models has been about #1
while both this draft and draft-clemm-netmod-mount-03 mainly address
#2. Each problem has its share of issues to solve but the issues don't
overlap, so I believe it would be useful to keep both problems
separate.

Lada

"Eric Voit (evoit)" <evoit@cisco.com> writes:

> There was a recent thread on structuring YANG models so that application developers might be able to reference alternative local hierarchies/tree structures for certain objects.  This thread motivated Alex, Sander, and I to rework the YANG Mount requirements draft.  v03 is posted at:
> http://datatracker.ietf.org/doc/draft-voit-netmod-peer-mount-requirements/
>
> This draft has been retitled to "Requirements for mounting of local and remote YANG subtrees".  This retitling was done because we have separated the thinking on what it takes to Mount objects from remote devices (Peer Mount) from what it takes to Mount within the same device (Alias Mount).
>
> We would be interested in your thoughts.   
>
> Eric
>
> -----Original Message-----
> From: Ladislav Lhotka, August 31, 2015 11:05 AM
>
> Randy Presuhn <randy_presuhn@mindspring.com> writes:
>
>> Hi -
>>
>> It is with no little amusement that I watch this thread struggling 
>> with questions that were solved fairly neatly a quarter century ago in 
>> GDMO/CMIP-land.  I'm *not* suggesting we go back there, but would like 
>> to offer an observation about modeling that might help.
>>
>> The organization of instance data in SNMP is a direct mirror of the 
>> "object" definitions.  Simple at first, but quickly becoming baroque 
>> as various minds of "multiplexing" are added to compensate for post 
>> hoc deficiencies in the index structures.
>>
>> Life is such that once a resource has been modeled, it will be 
>> used/re-used/embedded in systems in ways in which its designers 
>> couldn't be expected to imagine.  A consequence of this is that if 
>> instance naming is completely locked down when the management 
>> interface for a resource is first defined (as it is in SNMP) then all 
>> sorts of peculiar hacks will be needed to deal with, for example, 
>> virtual routers.  Unfortunately, an SNMP/SMI-like mindset is so 
>> pervasive that folks seem to overlook that there are other ways to 
>> deal with this situation.
>>
>> What GDMO did was to use a separate "NAME BINDING" construct to 
>> specify contexts in which instances might show up, allowing instances 
>> to be put in places that weren't even imagined when the original class 
>> definition was written.  Name bindings could be standardized, or be 
>> vendor or even product-specific, allowing the simplicity or complexity 
>> of a given system's instance tree to reflect the actual simplicity or 
>> complexity of that system, rather than requiring all systems to be 
>> structured for the worst case.
>
> How could this be expressed in YANG terms? (I tried to figure it out myself but I unfortunately couldn't make any sense of sec. 8.6 in CCITT Recommendation X.722).
>
> Thanks, Lada
>
>>
>> Yes, separating the specification of instance naming in large part 
>> from class definition does have implications for how one does access 
>> control, and how clients figure out how to ask a server to create 
>> something, but it's not a huge deal - it's just not like VACM, and a 
>> whole slew of hacky solutions and "wierd plumbing adapters" (to borrow 
>> from Jeff Case) just go away.  Strangely, it makes the job of the 
>> initial modeler and of the eventual user much easier.
>>
>> Randy
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C