On Tue, Sep 22, 2015 at 11:39 AM, Dean Bogdanovic <ivand...@gmail.com> wrote:
> Andy, > > Mobile operators are sharing infrastructure more and more. They are even > now considering sharing spectrum. Today there are already use cases where > Radio Access Network (RAN) is shared between multiple operators and they > are interested in sharing core resources as well. I can see multiple > NETCONF servers running on Mobile Switching Center (MSC), server per each > virtual instance for tenant. > > That's all fine but it does not alter my opinion at all that platforms that do not need this feature should not be impacted by it. If that means that YANG will "fork" into a solution for big routers and a different solution for not-a-routers, then that's fine. The market can decide better than the IETF anyway. Dean > Andy > > On Sep 22, 2015, at 9:38 AM, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Tue, Sep 22, 2015 at 3:00 AM, Robert Wilton <rwil...@cisco.com> wrote: > >> Hi Andy, >> >> Please can you clarify. Is your concern specifically with requirement 7? >> Or the full set of requirements in draft-chairs-netmod-opstate-reqs-00 >> <https://datatracker.ietf.org/doc/draft-chairs-netmod-opstate-reqs/>? >> >> > > My concern is the impact on implementations that do not contain virtual > servers > or do not even contain routers. If the scope of a solution is only > routers, then > it does not matter how router-centric the solution. But if the scope is > every > device that uses YANG, then it does matter. > > To be quite specific: > - most devices do not require long time intervals to apply > configuration so any solution > to identify intended vs. applied config is a waste of resources > > - most devices do not contain virtual servers so placing the data models > in a framework > for virtualization is a waste of resources > > A good engineering solution would only use engineering resources, device > resources, > and/or network resources on platforms that actually have these problems. > It's the difference between MAY leverage a common model-structure and > MUST leverage > a common model-structure. (Something IETFers should understand). > > If the solution really is MAY, then I have no concerns, but I know YANG > does > not actually support that, and it probably never will. Relocatable YANG > would > be rather complicated, so that is not an option at this time. > > > Thanks, >> Rob >> > > > Andy > > >> >> >> On 21/09/2015 20:28, Andy Bierman wrote: >> >> Hi, >> >> I do not think the issue of scope is being considered very carefully. >> >> IMO the solutions being proposed are extremely router-centric. >> (e.g., most NETCONF servers DO NOT have any virtual servers within them). >> >> The larger the scope, the more concern I have that >> the IETF will be pushing expensive solutions on platforms >> that don't have any of the "problems" in the first place. >> >> >> Andy >> >> >> >> On Mon, Sep 21, 2015 at 12:09 PM, Kent Watsen <kwat...@juniper.net> >> wrote: >> >>> >>> 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> >>> 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 >>> >> >> >> > _______________________________________________ > 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
