Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
>Then you probably already know what the solution is going to be. I don't. It’s not that I know the exact solution. It’s that I see this approach offering good options for graceful migration to an opstate compliant solution (for which I’m on the design team alias), without incurring any modelling cost, other than there being an additional module. I additionally see this approach as more flexible in that, as you said, it would allow one module to be updated without disturbing the other. > Anyway, if the consensus was to split config and state data into separate > modules, we would have to tell all module developers who build upon the core > routing model to split their augments into config and state parts as well, > because otherwise the change to ietf-routing would be useless. Yes, indeed, this would be the primary consequence. >Lada Kent ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New revision of draft-wu-opsawg-service-model-explained
> > Apparently Section 6.4 refers to MEF 55. I wonder why the > > specification MEF 55 is > > not referenced. Also, I believe the terminology in Section 6.4 may > > have to be reviewed. For instance, MEF apparently uses the term > > reference points ("Management Interface Reference Point") instead of > > "interface" in MEF 55. > Thanks for the pointer. It is hard to search all of the MEF documents (public > and private) to find a figure. > I will add the reference and clear up the language. MEF 55 is public: https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_55.pdf Michael ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New revision of draft-wu-opsawg-service-model-explained
Hi Michael, Thanks for the helpful email. > In general, I believe that distinguishing between different terms for "service > model" is useful. > > Actually, I would suggest to align the terminology in draft-ietf-l3sm-l3vpn-service- > model accordingly, e.g., by using the term "Customer Service Model" in the L3SM > WG. For instance, the title of draft-ietf-l3sm-l3vpn-service-model-12 "YANG Data > Model for L3VPN service delivery" is quite inconsistent with the use of the term > "service delivery" in draft-wu-opsawg-service-model-explained. It would be > good to avoid confusion. Yes. Although we added text to draft-wu-opsawg-service-model-explained to explain the terminology mapping, I think you're right that it would be even better to avoid the need. So that is an issue to take to L3SM (or the IETF last call of draft-ietf-l3sm-l3vpn-service-model) > Despite the discussion in https://www.ietf.org/mail- > archive/web/opsawg/current/msg04486.html, the draft still contains the wording > "all of the parameters". I continue to believe that a wording such as "the > parameters" would be more consistent with the rest of the document talking > about operator-specific augmentations etc. My bad dropping that email. I'll go back and respond on that thread. > The document, in particular in Section 6.1, could better distinguish between the > terms "module" and "model", if an alignment with draft-ietf-netmod-yang- > model-classification is the objective. One example where the terminology is not > entirely consistent is the sentence "add an additional example of a Network > Service YANG model as shown in Figure 4". That figure actually shows modules. Nice point. Does anyone have a reference for the definition of model and module in the YANG context (or I can search :-) > Apparently Section 6.4 refers to MEF 55. I wonder why the specification MEF 55 is > not referenced. Also, I believe the terminology in Section 6.4 may have to be > reviewed. For instance, MEF apparently uses the term reference points > ("Management Interface Reference Point") instead of "interface" in MEF 55. Thanks for the pointer. It is hard to search all of the MEF documents (public and private) to find a figure. I will add the reference and clear up the language. > Editorial nit: s/to/two/ in "The service model may divided into to categories" Ack Cheers, Adrian ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] New revision of draft-wu-opsawg-service-model-explained
Hi all, In general, I believe that distinguishing between different terms for "service model" is useful. Actually, I would suggest to align the terminology in draft-ietf-l3sm-l3vpn-service-model accordingly, e.g., by using the term "Customer Service Model" in the L3SM WG. For instance, the title of draft-ietf-l3sm-l3vpn-service-model-12 "YANG Data Model for L3VPN service delivery" is quite inconsistent with the use of the term "service delivery" in draft-wu-opsawg-service-model-explained. It would be good to avoid confusion. Despite the discussion in https://www.ietf.org/mail-archive/web/opsawg/current/msg04486.html, the draft still contains the wording "all of the parameters". I continue to believe that a wording such as "the parameters" would be more consistent with the rest of the document talking about operator-specific augmentations etc. The document, in particular in Section 6.1, could better distinguish between the terms "module" and "model", if an alignment with draft-ietf-netmod-yang-model-classification is the objective. One example where the terminology is not entirely consistent is the sentence "add an additional example of a Network Service YANG model as shown in Figure 4". That figure actually shows modules. Apparently Section 6.4 refers to MEF 55. I wonder why the specification MEF 55 is not referenced. Also, I believe the terminology in Section 6.4 may have to be reviewed. For instance, MEF apparently uses the term reference points ("Management Interface Reference Point") instead of "interface" in MEF 55. Editorial nit: s/to/two/ in "The service model may divided into to categories" Michael -Original Message- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, September 07, 2016 11:44 AM To: ops...@ietf.org Cc: draft-wu-opsawg-service-model-explai...@ietf.org; netmod@ietf.org Subject: [netmod] New revision of draft-wu-opsawg-service-model-explained Hi, [Copying NETMOD, but suggest all discussions are held on OPSAWG list] We updated our document to (hopefully) make some stuff clearer... - We are not trying to piss on draft-ietf-netmod-yang-model-classification! Actually, that is an important reference, but its approach is slightly different. We have beefed up our discussion of the relationship with that draft. Our belief is that the two drafts are complementary and that our work should not delay the completion of the NETMOD draft. - The distinction between a "service model" and a "service model" (sic) has become unclear. We have introduced the terms "customer service model" and "service delivery model", explained what these are, and shown mappings of other work to these terms. We would propose, if these terms are clear and acceptable, that new work adopt these terms, but we do not suggest that it is necessary to go and change existing mature work. - There was some discussion around "what do you mean by a service?" We have tried to tidy our text about this, but could probably use help. As always, comments, rotten fruit, and constructive input would be welcome. Cheers, Adrian (for the authors) -- Support an author and your imagination. Tales from the Wood - Eighteen new fairy tales. More Tales from the Wood - Eighteen more new fairy tales. https://www.feedaread.com/profiles/8604/ http://www.amazon.co.uk/Tales-Wood-Adrian-Farrel/dp/1786100924 Or buy from me direct. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Service Models Explained > > Abstract: >The IETF has produced a considerable number of data models in the >YANG modelling language. The majority of these are used to model >devices and they allow access for configuration and to read >operational status. > >A small number of YANG models are used to model services (for >example, the Layer Three Virtual Private Network Service Model >produced by the L3SM working group). > >This document briefly sets out the scope of and purpose of an IETF >service model, and it shows where a service model might fit into a >Software Defined Networking architecture or deployment. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-wu-opsawg-service-model-explained/ ___ 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
Re: [netmod] Circular dependency in 'when'
> -Original Message- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav > Lhotka > Sent: Wednesday, September 7, 2016 8:22 PM > To: Vladimir Vassilev > Cc: netmod@ietf.org > Subject: Re: [netmod] Circular dependency in 'when' > > > > On 07 Sep 2016, at 19:44, Vladimir Vassilev > wrote: > > > > On 09/07/2016 02:18 PM, Martin Bjorklund wrote: > >> Hi, > >> > >> Your example is not circular, and it is legal. However, the 'when' > >> expression refers to the node in which the when expression is defined. > >> Note that this expression will always evaluates to 'false' (see the > >> third bullet in 7.21.5 in RFC 7950). > > This is true for YANG 1.1 due to that 3rd bullet in 7.21.5. > > > > However it should be noted that in YANG 1.0 nothing says the data node > for which the "when" statement is defined will be replaced with dummy > node > without a value so that this expression always evaluates to 'false'. In > YANG 1.0 the expression can evaluate to 'true' when a+b=100. > > Using "when" expressions that refer to the context node or its descendants > could easily lead to deadlocks in YANG 1.0, so this part was underspecifed > and ill-defined. The new 1.1 procedure for evaluating "when" expressions > is thus a bug fix. Although it is somewhat tricky and sometimes (as in > your example) counter-intuitive at first sight, it leads to unambiguous > and stable results. > > >> > >> Take a step back and consider what the 'when' statement means - it is > >> used to indicate if the node can be present or not. As such, it > >> doesn't make any sense to refer to the node itself in the xpath > >> expression. > > > >> In your case, you probably want to use a 'must' expression. This is > >> evaluated once the node is present, in order to enforce some > >> constraint. > >> > > I agree. I think the conclusion can be generalized to: there is no point > in using "when" expressions directly depending on the value of the data > node for which the "when" statement is defined or its children when the > parent is not 'augment', 'uses', 'case' or 'choice' statement in YANG 1.1 > because the 'when' statement will always evaluate to 'false' and the data > node will never exist. > > Not necessarily. The following expression is always true: > > leaf foo { > when "."; > ... > } > > > > > Would be helpful if model validation tools could issue at least warning > in such cases. > > This is rather difficult to detect in general. XPath is a complicated > beast. We've implemented partial evaluation of XPath expressions that operates on an "accessible tree skeleton" (schema of the accessible tree as defined by modules in scope). For the example given by Vladimir, our compiler would complain with: WARNING; test@2016-09-07:8; when: XPath construct '.' (at 2) references the initial context node or one of its descendants in a when expression since it is referring to the "leaf" for which the "when" statement is defined and this was discouraged by one of the 6087bis drafts. It would detect this (and other issues) no matter how "obfuscated" the expression is. Implementing it was mostly problematic due to poorly defined accessible trees or initial context nodes in some cases (YANG 1). Jernej > > Lada > > > > > Vladimir > >> > >> /martin > >> > >> > >> Vladimir Vassilev wrote: > >>> Hi, > >>> > >>> Is there any practical value of 'when' statements with circular > >>> dependency to the value of the parent (in case it is a leaf) or any > >>> children of the parent? > >>> > >>> container circular-dependency-when { > >>> leaf a { > >>> when "(. + ../b) = 100"; > >>> type uint16 { > >>> range "0 .. 100"; > >>> } > >>> } > >>> leaf b { > >>> type uint16 { > >>> range "0 .. 100"; > >>> } > >>> } > >>> } > >>> > >>> > > > > ___ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > ___ > 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