Thanks Robert, but I think I like Benoit's edit more. Are you OK with it as well?
PS: I've moved this issue to the VERIFY state. Thanks, Kent On 9/21/15, 5:34 AM, "Robert Wilton" <rwil...@cisco.com> wrote: >Hi, > >I suggest changing the wording for A and adding D: > > 7. Ability for distinct modules to leverage a common model-structure > A. Scope is limited to providing a general model-structure only > B. Multiple domain-specific trees are okay > C. Multiple namespaces are okay > D. The model-structure may be used or extended by other >organizations. > >Justifications for (A): > - Limiting the scope to IETF-defined modules almost implies that >'ietf' would end up in the path (which would be wrong/unnecessary). > - Clients don't care which SDO defines the modules for the protocols >they use, they just want a coherent organization of modules. > - General structure only to limit the scope because trying to >precisely place every protocol/feature is likely to be fragile in the >face of future changes. > >Justifications for (D): > - To suggest and encourage other SDOs to use the same structure, but >cannot mandate what they do. > >Thanks, >Rob > > >On 18/09/2015 22:56, Kent Watsen wrote: >> Regarding https://github.com/netmod-wg/opstate-reqs/issues/7 >> >> >> Jonathan> Why does 7(A) limit the scope to IETF-defined modules of >> others are now defining YANG modules? >> >> Benoit> Good point. We need to provide guidance for the other SDOs. >> >> >> Current text says: >> >> 7. Ability for distinct modules to leverage a common >>model-structure >> A. Scope is limited to IETF-defined modules >> B. Multiple domain-specific trees are okay >> C. Multiple namespaces are okay >> >> >> >> Background: >> >> I pulled 7A from Andy's message here: >> >> >> https://mailarchive.ietf.org/arch/msg/netmod/I6clHE2665C40taRZHi0CKLD46U >> >> and put a stake in the ground so that, if nothing else, it could >> be discussed...and here we are! >> >> FWIW, I wrote 7A this way because I didn't see how it can be >> enforced outside of the IETF. But maybe that doesn't matter? >> Of course, we can have 6087bis guidance for other SDOs, but >> I didn't put that in the text. >> >> >> Thoughts on how the text should be updated? >> >> >> PS: Please Reply-All to the list rather than post comments to the GitHub >> issue tracker. >> >> >> Thanks, >> Kent >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod