Re: [netmod] accessible tree for rpcs?

[Kent Watsen]

> That's what I meant.
> RPC input MUST be honored by the server or it is not implementing  
> correctly.
>
> Constraints on RPC output and notification output are for documentation 
> purposes.
> A client could try to evaluate them with its own copies of the server's 
> running and
> operational datastore contents, but I think the YANG definition says the 
> constraint
> is enforced on the server.
>
> Maybe NMDA could clarify this issue.

What would be the update?  Would you change the XPath context text in Section 
5.1
to not include the additional datastore contexts, or just add a clarification 
that any such
constraints are just conceptual and primarily for description purpose?  And, if 
the latter,
shouldn't it be a clarification on RFC 7950?

Kent

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] accessible tree for rpcs?

[Andy Bierman]

On Wed, Aug 2, 2017 at 8:20 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Aug 02, 2017 at 08:11:25AM -0700, Andy Bierman wrote:
> >
> > The server will NEVER use these constraints.  It does not run XPath
> > validation on its own output.
> >
> > The client can NEVER reliably use these constraints because they need to
> be
> > evaluated at the instant
> > the RPC or notification output is generated, and the client does not have
> > that snapshot
> > of the running or operational datastores.
> >
> > So just ignore these YANG details.  That's all real tools can do with
> them
> > anyway.
>
> I tend to agree when it comes to the output / notifications.  But
> things are less clear on the input - a server can reject the execution
> of an operation if a must constraint on the input is not satisfied.
>
> But yes, constraints on config false data, operations and
> notifications are likely much less useful than constraints on
> config true data.
>
>
That's what I meant.
RPC input MUST be honored by the server or it is not implementing 
correctly.

Constraints on RPC output and notification output are for documentation
purposes.
A client could try to evaluate them with its own copies of the server's
running and
operational datastore contents, but I think the YANG definition says the
constraint
is enforced on the server.

Maybe NMDA could clarify this issue.


/js
>


Andy



>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] accessible tree for rpcs?

[Juergen Schoenwaelder]

On Wed, Aug 02, 2017 at 08:11:25AM -0700, Andy Bierman wrote:
> 
> The server will NEVER use these constraints.  It does not run XPath
> validation on its own output.
>
> The client can NEVER reliably use these constraints because they need to be
> evaluated at the instant
> the RPC or notification output is generated, and the client does not have
> that snapshot
> of the running or operational datastores.
> 
> So just ignore these YANG details.  That's all real tools can do with them
> anyway.

I tend to agree when it comes to the output / notifications.  But
things are less clear on the input - a server can reject the execution
of an operation if a must constraint on the input is not satisfied.

But yes, constraints on config false data, operations and
notifications are likely much less useful than constraints on
config true data.

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] accessible tree for rpcs?

[Andy Bierman]

Hi Kent,


I objected to this expansion of XPath context when YANG 1.1 was being
developed.
Then I realized the YANG constraints are totally worthless so no reason to
do anything
about it.

The server will NEVER use these constraints.  It does not run XPath
validation on its own output.
The client can NEVER reliably use these constraints because they need to be
evaluated at the instant
the RPC or notification output is generated, and the client does not have
that snapshot
of the running or operational datastores.

So just ignore these YANG details.  That's all real tools can do with them
anyway.


Andy


On Wed, Aug 2, 2017 at 7:51 AM, Kent Watsen  wrote:

> Hi Alex,
>
> > Why would it not make sense?
>
> Firstly, it seems outside the norm.  At least, I'm unaware of any other
> IDL that allows for such linkage.  Second, I'm trying to understand the
> value.  For instance, how does it benefit the module designer, the server
> developer, the client developer?  (more on this below)
>
> While not in the subject, my question extends to notifications as well.
> Section 6.4.1 says that the accessible tree is "the notification instance,
> all state data in the server, and the running configuration datastore".
> Notifications are particularly interesting given their one-way
> communication property.  In this regard, notifications are a bit like
>  in that the server will/should send truth, regardless what
> the validation might allow.
>
>
> > Is your question about the datastores proposal?
>
> I wasn't thinking about it originally, but you raise a good point. Looking
> at revised-datastores, we see that the XPath context rules are revised in
> S5.1.  It seems like that  is no longer included (better), but the
> concern raised in this thread persists.  Just thinking about  no
> longer being included, this seems to break backwards compatibility.  For
> RPC's, neither NETCONF nor RESTCONF provide a mechanism to address a
> datastore.  And for actions, NETCONF again doesn't address a datastore,
> though RESTCONF does.  What this means is that a legacy server also
> supporting NMDA is unable to differentiate between if it should use old or
> new behavior.  Maybe it's a mute point, in that  is a subset
> of , but there is a semantic difference between something
> configured versus applied.
>
> BTW, the restconf-nmda draft currently doesn't say anything about action
> statements, but it seems that it should restrict them to just 
> under the {+restconf}/ds/ resource.  We wouldn't want to support, for
> instance, {+restconf}/ds/ietf-datastores:candidate/foobar/restart.
>
>
>
> > Usually an action will refer to some object that is defined as
> configuration
> > and/or state, and may depend on the particular properties of that object.
> > Here is a YANG fragment showing one possible application:
> >
> >list ospf-instance {
> >config true;
> >leaf id {type string;}
> >leaf supports-graceful-restart {type boolean;}
> >   }
> >
> >rpc ospf-graceful-restart {
> >input {
> >leaf instance-id {type leafref {path "/ospf-instance/id";}}
> >must 
> > "/ospf-instance[id=current()/instance-id]/supports-graceful-restart
> = 'true'" {
> >error-message "Instance does not support graceful
> restart";
> >}
> >}
> >}
> >
> > As another application, a "mute transmitter" command might only apply to
> > digital radio interfaces.
>
> About this example, my first thought is that RPC input is probably the
> most defensible example - RPC output or notification examples make even
> less sense.  With this example, the YANG is doing two things: 1) asserting
> that the instance exists and 2) asserting that the instance supports
> graceful restarts.  So:
>
>   From a module designer perspective:
> - it is more exact than a description statement (but just mildly so),
> and
>   note that the 'leaf' and 'must' statements should have 'description'
>   statements too
>
>   From a server developer perspective:
> - it moves a little more of the validation into the input-parsing
> logic,
>   but I'm sure that the server would throw an error anyway if the
>   instance didn't exist or if it didn't support graceful restart.
>
>   From a client developer perspective:
> - again, the leafref/must statements are more exact than description
>   statements, but I don't believe that there is any expectation that
>   a client would perform validation prior to sending the RPC.  Of
>   course it could if it had a copy of the server's datastores (e.g.
>   peer mount), but that doesn't guarantee anything unless the client
>   is also going to use locking (which doesn't exist in RESTCONF)
>   around the syncing of the server's data and the execution RPC.
>
>
> We can do similar exercises with RPC output and notifications, but my
> position is that we'll find even less value.  Again, these provisions seem
> like a lot of comp

Re: [netmod] accessible tree for rpcs?

[Kent Watsen]

Hi Alex,

> Why would it not make sense? 

Firstly, it seems outside the norm.  At least, I'm unaware of any other IDL 
that allows for such linkage.  Second, I'm trying to understand the value.  For 
instance, how does it benefit the module designer, the server developer, the 
client developer?  (more on this below)

While not in the subject, my question extends to notifications as well.  
Section 6.4.1 says that the accessible tree is "the notification instance, all 
state data in the server, and the running configuration datastore".  
Notifications are particularly interesting given their one-way communication 
property.  In this regard, notifications are a bit like  in that 
the server will/should send truth, regardless what the validation might allow.


> Is your question about the datastores proposal?

I wasn't thinking about it originally, but you raise a good point. Looking at 
revised-datastores, we see that the XPath context rules are revised in S5.1.  
It seems like that  is no longer included (better), but the concern 
raised in this thread persists.  Just thinking about  no longer being 
included, this seems to break backwards compatibility.  For RPC's, neither 
NETCONF nor RESTCONF provide a mechanism to address a datastore.  And for 
actions, NETCONF again doesn't address a datastore, though RESTCONF does.  What 
this means is that a legacy server also supporting NMDA is unable to 
differentiate between if it should use old or new behavior.  Maybe it's a mute 
point, in that  is a subset of , but there is a semantic 
difference between something configured versus applied.

BTW, the restconf-nmda draft currently doesn't say anything about action 
statements, but it seems that it should restrict them to just  
under the {+restconf}/ds/ resource.  We wouldn't want to support, for instance, 
{+restconf}/ds/ietf-datastores:candidate/foobar/restart.  



> Usually an action will refer to some object that is defined as configuration
> and/or state, and may depend on the particular properties of that object.
> Here is a YANG fragment showing one possible application:
>
>list ospf-instance {
>config true;
>leaf id {type string;}
>leaf supports-graceful-restart {type boolean;}
>   }
>
>rpc ospf-graceful-restart {
>input {
>leaf instance-id {type leafref {path "/ospf-instance/id";}}
>must 
> "/ospf-instance[id=current()/instance-id]/supports-graceful-restart = 'true'" 
> {
>error-message "Instance does not support graceful restart";
>}
>}
>}
>
> As another application, a "mute transmitter" command might only apply to
> digital radio interfaces.

About this example, my first thought is that RPC input is probably the most 
defensible example - RPC output or notification examples make even less sense.  
With this example, the YANG is doing two things: 1) asserting that the instance 
exists and 2) asserting that the instance supports graceful restarts.  So:

  From a module designer perspective:
- it is more exact than a description statement (but just mildly so), and
  note that the 'leaf' and 'must' statements should have 'description' 
  statements too

  From a server developer perspective:
- it moves a little more of the validation into the input-parsing logic,
  but I'm sure that the server would throw an error anyway if the
  instance didn't exist or if it didn't support graceful restart.

  From a client developer perspective:
- again, the leafref/must statements are more exact than description
  statements, but I don't believe that there is any expectation that
  a client would perform validation prior to sending the RPC.  Of
  course it could if it had a copy of the server's datastores (e.g.
  peer mount), but that doesn't guarantee anything unless the client
  is also going to use locking (which doesn't exist in RESTCONF)
  around the syncing of the server's data and the execution RPC.


We can do similar exercises with RPC output and notifications, but my position 
is that we'll find even less value.  Again, these provisions seem like a lot of 
complexity for little gain...

Kent  // contributor




___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained

[Carl Moberg (camoberg)]

Adrian,

> On Aug 2, 2017, at 12:28 PM, Adrian Farrel  wrote:
> 
> Hi Carl,
> 
>>  - The term “Network Service Model” in RFC 8199 is intended to cover both
>>"Customer Service Model” as well as “Service Delivery Model” as defined
>>in draft-ietf-opsawg-service-model-explained. At the time of the first
>>revision of what was
>> draft-bogdanovic-netmod-yang-model-classification
>>we discussed further splitting "Network Service Model” into smaller
>>components, but decided against it since we did not see a consensus on
>>what that split would look like. I believe the authors here is
>>suggesting such a further split.
> 
> I think that an "issue" with RFC 8199 is that is appears to imply that the 
> "Network Service Module" (sic) it defines is used on a specific interface 
> rather than simply being the classification of "all modules used north of 
> this point". This our draft is doing slightly more than partitioning the 
> classification. The last couple of rounds of edits to what became 8199 were 
> working with Dean to slightly soften thee language used to make this more 
> consistent.

 Right, and the reason why we took the "all modules used north of this point” 
is that we have not seen any sign of convergence around abstractions into 
smaller components. In short: implementations of “YANG for services” is 
currently all over the map.

> But see below...
> 
>>There is one specific passage in this draft that I would suggest could
>>use rephrasing if the authors agree to the above:
>> 
>> """
>>   As previously noted, [I-D.ietf-netmod-yang-model-classification]
>>   provides a classification of YANG data models.  It introduces the
>>   term "Network Service YANG Module" to identify the type of model used
>>   to "describe the configuration, state data, operations and
>>   notifications of abstract representations of services implemented on
>>   one or multiple network elements."  These are service delivery models
>>   as described in this document, that is, they are the models used on
>>   the interface between the Service Orchestrator or OSS/BSS and the
>>   Network Orchestrator as shown in Figure 3.
>> """
> 
> You suggest this could be rephrased, but don't suggest how:-)
> I just checked 8199 and I see that the quote we have is still accurate.
> 
> I am wondering what it is specifically about this text that worries you. 
> Again, this may come back to the use of a module on a functional interface. I 
> read 8199 as saying that the "Network Service YANG Modules are used by the 
> OSS/BSS in talking to the network elements (o perhaps Controllers?) to 
> configure the network to deliver the service. Am I wrong?
> 
> If I'm right in my reading we are not "splitting" the classification, but 
> introducing a new class that lives further north (where the atmosphere is 
> thinner and the temperature colder)

 I think at the core of the feedback (and sorry that it took two rounds of 
email to make it shorter :-) is that in 8199 the Service Orchestrator is 
assumed to be an integral part of OSS/BSS. More below.

>> - And this gets to my second point of feedback. Figure 4. in the draft
>>   seems to suggest that the "Service Orchestrator" is an entity separate
>>   from the "Operations and Business Support Systems (OSS/BSS)".
> 
> I want to jump into this paragraph at once just to say "no, no, no!"
> This figure (like most I draw in ASCII these days) displays functional 
> components not physical entities.
> How you choose to implement is entirely up to you.
> It seems likely (to me) that the interface between customer and operator is 
> externally exposed (but not necessarily realised using RESTconf).

 This is perhaps also at the core of the feedback. I have never seen an 
implementation/architecture with a functionally distinct Service Orchestrator 
(outside of OSS/BSS) exposed directly to customers. There is usually at least 
something like an order manager (as part of the OSS/BSS) between the customer 
and the service orchestrator. Even in the instances of self-service portals 
(which are naturally located very close to the network) there is at least some 
notion of pricing and billing involved.

> It does not seem obvious to me that the Service Orchestrator and the OSS/BSS 
> are separate blobs, except to note that the OSS/BSS deployed today does not 
> support the Customer Service YANG Modules and so the extent to which it 
> provides "service orchestration" is limited.

 Well, a common pattern is to have the order manager put in orders for 
technical service activation from a service orchestrator. The uptake of YANG 
seems to be mostly in the interface between the order manager (an integral part 
of OSS/BSS) and the service orchestrator.

> I might also claim that an OSS/BSS possibly operates on a single network 
> where the orchestration of a service *might* involve the coordination of more 
> than one network.

 Hmm, since the actual business is accounted for in the OS

Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained

[Adrian Farrel]

Hi Carl,

>   - The term “Network Service Model” in RFC 8199 is intended to cover both
> "Customer Service Model” as well as “Service Delivery Model” as defined
> in draft-ietf-opsawg-service-model-explained. At the time of the first
> revision of what was
> draft-bogdanovic-netmod-yang-model-classification
> we discussed further splitting "Network Service Model” into smaller
> components, but decided against it since we did not see a consensus on
> what that split would look like. I believe the authors here is
> suggesting such a further split.

I think that an "issue" with RFC 8199 is that is appears to imply that the 
"Network Service Module" (sic) it defines is used on a specific interface 
rather than simply being the classification of "all modules used north of this 
point". This our draft is doing slightly more than partitioning the 
classification. The last couple of rounds of edits to what became 8199 were 
working with Dean to slightly soften thee language used to make this more 
consistent.

But see below...

> There is one specific passage in this draft that I would suggest could
> use rephrasing if the authors agree to the above:
>
> """
>As previously noted, [I-D.ietf-netmod-yang-model-classification]
>provides a classification of YANG data models.  It introduces the
>term "Network Service YANG Module" to identify the type of model used
>to "describe the configuration, state data, operations and
>notifications of abstract representations of services implemented on
>one or multiple network elements."  These are service delivery models
>as described in this document, that is, they are the models used on
>the interface between the Service Orchestrator or OSS/BSS and the
>Network Orchestrator as shown in Figure 3.
> """

You suggest this could be rephrased, but don't suggest how:-)
I just checked 8199 and I see that the quote we have is still accurate.

I am wondering what it is specifically about this text that worries you. Again, 
this may come back to the use of a module on a functional interface. I read 
8199 as saying that the "Network Service YANG Modules are used by the OSS/BSS 
in talking to the network elements (o perhaps Controllers?) to configure the 
network to deliver the service. Am I wrong?

If I'm right in my reading we are not "splitting" the classification, but 
introducing a new class that lives further north (where the atmosphere is 
thinner and the temperature colder)

>  - And this gets to my second point of feedback. Figure 4. in the draft
>seems to suggest that the "Service Orchestrator" is an entity separate
>from the "Operations and Business Support Systems (OSS/BSS)".

I want to jump into this paragraph at once just to say "no, no, no!"
This figure (like most I draw in ASCII these days) displays functional 
components not physical entities.
How you choose to implement is entirely up to you.
It seems likely (to me) that the interface between customer and operator is 
externally exposed (but not necessarily realised using RESTconf).
It does not seem obvious to me that the Service Orchestrator and the OSS/BSS 
are separate blobs, except to note that the OSS/BSS deployed today does not 
support the Customer Service YANG Modules and so the extent to which it 
provides "service orchestration" is limited.
I might also claim that an OSS/BSS possibly operates on a single network where 
the orchestration of a service *might* involve the coordination of more than 
one network.

> And also that
>Customers (as defined) in Section 2 interface directly with that entity.
>This is a very unusual construct, in the sense that:
> o The common taxonomomy from e.g. TMForum would classify a service
>   orchestrator as a part of the OSS/BSS stack, since...
> o The successful activation of a service includes many parts of the
>   OSS/BSS-stack including operational readiness (are there physical
>   ports available), billing management (is the customer allowed to 
>   perform e.g. this resource expansion), and assurance (changed
>   services require new assurance parameters). This makes it hard
>   to separate out a Customer interface to service orchestration
>   only, separate from the OSS/BSS stack.

I am not (overly) familiar with the TMF work, however, your text "TMForum would 
classify a service orchestrator as a part of the OSS/BSS stack" suggests the 
acceptance of service orchestration as "a thing". If you were writing code, you 
*might* write a separate module (even library) to handle service orchestration, 
and maintain that as a separate module from billing management, etc. That does 
not make them completely separate, but does result in them showing as separate 
functional components in the "OSS/BSS stack."

>  This an informational draft and as such is for general information, and
> not  necessarily intended to represent community consensus or
> recommendation,