Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)

[Kent Watsen]

>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

[Scharf, Michael (Nokia - DE)]

> > 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

[Adrian Farrel]

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

[Scharf, Michael (Nokia - DE)]

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'

[Jernej Tuljak]

> -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