Re: [netmod] WG Last Call resolutions incorporated in draft-ietf-tictoc-1588v2-yang-06

[Jiangyuanlong]

Hi Alex,

Sorry for a late reply as I spent the last week for an urgent business trip.
Please see my comments in line with [YJ]

Thanks,
Yuanlong

-Original Message-
From: Alex Campbell [mailto:alex.campb...@aviatnet.com] 
Sent: Monday, October 30, 2017 10:15 AM
To: Jiangyuanlong; tic...@ietf.org
Cc: Xian Liu; Xujinchun; netmod@ietf.org
Subject: Re: WG Last Call resolutions incorporated in 
draft-ietf-tictoc-1588v2-yang-06

Hi,
I've reviewed this latest draft and have some more comments.

1. I find the introduction to be unnecessarily wordy; it feels like it was 
written with a view of not missing any information out, rather than trying to 
keep it concise.
   For example, there is no need to elaborate on YANG data types here. It is 
also not here to sell YANG.

[YJ] Yes, we are trying to give some introductory information for an outsider 
who may not be familiar with PTP or YANG, and explain why a YANG for PTP is 
needed. The juicy part of this document is its YANG module, and people can skip 
all the other texts if they are familiar with PTP and YANG.
Besides, these texts have been contributed by multiple sources and undergone 
several rounds of reviews, thus I will wait for a clear message from the TICTOC 
chairs to introduce any big changes at this last call stage.


OLD:

   As a synchronization protocol, IEEE 1588-2008 [IEEE1588] is widely
   supported in the carrier networks, industrial networks, automotive
   networks, and many other applications. It can provide high
   precision time synchronization as fine as nano-seconds. The
   protocol depends on a Precision Time Protocol (PTP) engine to
   decide its own state automatically, and a PTP transportation layer
   to carry the PTP timing and various quality messages. The
   configuration parameters and state data sets of IEEE 1588-2008 are
   numerous.

   According to the concepts described in [RFC3444], IEEE 1588-2008
   itself provides an information model in its normative
   specifications for the data sets (in IEEE 1588-2008 clause 8). Some
   standardization organizations including the IETF have specified
   data models in MIBs (Management Information Bases) for IEEE 1588-
   2008 data sets (e.g. [RFC8173], [IEEE8021AS]). These MIBs are
   typically focused on retrieval of state data using the Simple
   Network Management Protocol (SNMP), furthermore, configuration of
   PTP data sets is not considered in [RFC8173].

   Some service providers and applications require that the management
   of the IEEE 1588-2008 synchronization network be flexible and more
   Internet-based (typically overlaid on their transport networks).
   Software Defined Network (SDN) is another driving factor, which
   demands an improved configuration capability of synchronization
   networks.

   YANG [RFC6020] is a data modeling language used to model
   configuration and state data manipulated by network management
   protocols like the Network Configuration Protocol (NETCONF)
   [RFC6241]. A small set of built-in data types are defined in
   [RFC6020], and a collection of common data types are further
   defined in [RFC6991]. Advantages of YANG include Internet based
   configuration capability, validation, rollback and so on. All of
   these characteristics make it attractive to become another
   candidate modeling language for IEEE 1588-2008.

NEW:

   IEEE 1588-2008 is a time protocol that provides high precision time
   synchronization as fine as nano-seconds.

   IEEE 1588-2008 itself provides an information model in its normative
   specifications for the data sets (IEEE 1588-2008 clause 8).
   Standard information models (e.g. [RFC8173], [IEEE8021AS]) have been
   previously defined as MIBs focused on the retrieval of state data using
   SNMP [RFC1157].

   YANG [RFC6020] is a data modeling language used to model configuration
   and state data manipulated by network management protocols like NETCONF
   [RFC6241].

2. Can we refer to the system as simply PTP rather than IEEE 1588(-2008)?
[YJ] Advice from IEEE 1588 is, we need to use "1588-2008" as much as possible 
to help clarify that the scope of this YANG is limited to the published 1588 
standard.


3. There is insufficient spacing here to separate the terms from their 
definitions:
OLD

   PTP dataset  Structured attributes of clocks (an OC, BC or TC) used
   for PTP protocol decisions and for providing values for PTP message
   fields, see Section 8 of [IEEE1588].

   PTP instance A PTP implementation in the device (i.e., an OC or BC)
   represented by a specific PTP dataset.

NEW

   PTP dataset
 Structured attributes of clocks (an OC, BC or TC) used
 for PTP protocol decisions and for providing values for PTP message
 fields, see Section 8 of [IEEE1588].

   PTP instance
 A PTP implementation in the device (i.e., an OC or BC)
 represented by a specific PTP dataset.
[YJ] OK.

4. There's a singular/plural mismatch here:

   module. Query and configuration of device wide or po

Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-14

[Kent Watsen]

This closes the Last Call on this document.  There is
clearly a lot of interest in the publication of an ACL
model, but there also seems to be significant concern
for how this model is structured.  It seems that we need
to spend some more time to ensure the current structure
is okay.  Based on the result of this discussion, we
will then judge if this Last Call was successful of not.

Thanks,
Kent // shepherd


--

All,

This starts a two-week working group last call on
draft-ietf-netmod-acl-model-14.

The working group last call ends on November 3.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Could the authors, explicitly CC-ed on this email, please
also confirm at this time that they are unaware of any 
IPR related to this draft.

Thank you,
Netmod Chairs


___
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=HCp9pNO1eASC7fBxrsD4hOUjTXHbKMuWC5C2h7-ym68&s=k7uRdiuP0Z8vvDa1hOLxdQJQt3MBpHv8gcuHg9hy-Lw&e=


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

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-08

[Kent Watsen]

This closes the schema-mount Last Call.  Looking at the 
responses, there is strong support for publication after
a variety of Last Call comments have been addressed, some
threads of which may still be ongoing.  The authors should
post an update addresses the Last Call comments followed
by a request for comments to review the update to ensure
their comments were addressed.  Once complete, the document
will then progress to the shepherd write-up phase.

Thanks,
Kent // shepherd

--

[changing subject line]

All,

Please use the just-posted -08 version instead.

In addition to changing the subject line, I also changed
the text below.  The end date remains unchanged.

Regards,
Kent // co-chair

--

All,

This starts a two-week working group last call on
draft-ietf-netmod-schema-mount-08.

The working group last call ends on November 3.
Please send your comments to the netmod mailing list.

Positive comments, e.g., "I've reviewed this document 
and believe it is ready for publication", are welcome!
This is useful and important, even from authors.

Could the authors, explicitly CC-ed on this email, 
please also confirm one more time that they are 
unaware of any IPR related to this draft.

Thank you,
Netmod Chairs





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

Re: [netmod] Action and RPC statements

[Lou Berger]

Humm. I don't think this is how Chris is envisioning it. We can talk more 
next week when he presents.


Lou


On November 6, 2017 12:31:18 PM Robert Wilton  wrote:




On 06/11/2017 17:24, Lou Berger wrote:


On 11/6/2017 12:17 PM, Juergen Schoenwaelder wrote:

What is default content of a list? Where is this coming from?

Whatever the vendor chooses in their code, and perhaps what gets defined
in future model definitions...

This is mixing up config and state:

The device's default module tags wouldn't be in , only in
, [ and perhaps .]

Only the clients configured modification to the module tags ends up in
.  This is merged with the system module tags, and then the
resultant set end up in .

Resetting the list to default is achieved by just deleting the list
entry in .  No special RPC is needed.

Thanks,
Rob


Lou


/js

On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:

What's the standard way to reset a list to a default (based on
implementation)?

On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:

On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:

The tags draft has an RPC to 'reset to default state'.  I could see
wanting the reset to be persistent or not depending on actual usage...


In general, I think we love the usage of standard operations like
edit-config to manipulate configuration datastores and I think we
dislike custom operations that manipulate configuration datastores.

/js


___
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] Action and RPC statements

[Robert Wilton]

On 06/11/2017 17:24, Lou Berger wrote:


On 11/6/2017 12:17 PM, Juergen Schoenwaelder wrote:

What is default content of a list? Where is this coming from?

Whatever the vendor chooses in their code, and perhaps what gets defined
in future model definitions...

This is mixing up config and state:

The device's default module tags wouldn't be in , only in 
, [ and perhaps .]


Only the clients configured modification to the module tags ends up in 
.  This is merged with the system module tags, and then the 
resultant set end up in .


Resetting the list to default is achieved by just deleting the list 
entry in .  No special RPC is needed.


Thanks,
Rob


Lou


/js

On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:

What's the standard way to reset a list to a default (based on
implementation)?

On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:

On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:

The tags draft has an RPC to 'reset to default state'.  I could see
wanting the reset to be persistent or not depending on actual usage...


In general, I think we love the usage of standard operations like
edit-config to manipulate configuration datastores and I think we
dislike custom operations that manipulate configuration datastores.

/js


___
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] Action and RPC statements

[Lou Berger]

On 11/6/2017 12:17 PM, Juergen Schoenwaelder wrote:
> What is default content of a list? Where is this coming from?
Whatever the vendor chooses in their code, and perhaps what gets defined
in future model definitions...
Lou

> /js
>
> On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:
>> What's the standard way to reset a list to a default (based on
>> implementation)?
>>
>> On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
>>> On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
 The tags draft has an RPC to 'reset to default state'.  I could see
 wanting the reset to be persistent or not depending on actual usage...

>>> In general, I think we love the usage of standard operations like
>>> edit-config to manipulate configuration datastores and I think we
>>> dislike custom operations that manipulate configuration datastores.
>>>
>>> /js
>>>
>> ___
>> 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] Action and RPC statements

[Robert Wilton]

On 06/11/2017 17:02, Juergen Schoenwaelder wrote:

On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:

The tags draft has an RPC to 'reset to default state'.  I could see
wanting the reset to be persistent or not depending on actual usage...


In general, I think we love the usage of standard operations like
edit-config to manipulate configuration datastores and I think we
dislike custom operations that manipulate configuration datastores.

Yes.

I also dislike the idea of client managed persistent data that is not 
configuration.


E.g. I think that the subscriptions draft has this right:  It has 
configurable subscriptions, that are persistent; and rpc based dynamic 
subscriptions, that are not persistent.


If the tags draft defined RPCs to modify the module tags in a non 
persistent way then that would be OK with me (if this is actually 
useful), it is just that those actions/rpcs would end up only acting 
against the data in , and hence I think solution A would 
actually be sufficient for this case.


Thanks,
Rob




/js



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

Re: [netmod] Action and RPC statements

[Juergen Schoenwaelder]

What is default content of a list? Where is this coming from?

/js

On Mon, Nov 06, 2017 at 12:12:30PM -0500, Lou Berger wrote:
> 
> What's the standard way to reset a list to a default (based on
> implementation)?
> 
> On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
> > On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
> >> The tags draft has an RPC to 'reset to default state'.  I could see
> >> wanting the reset to be persistent or not depending on actual usage...
> >>
> > In general, I think we love the usage of standard operations like
> > edit-config to manipulate configuration datastores and I think we
> > dislike custom operations that manipulate configuration datastores.
> >
> > /js
> >
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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] Action and RPC statements

[Andy Bierman]

On Mon, Nov 6, 2017 at 5:19 AM, Martin Bjorklund  wrote:

> Hi,
>
> Trying to summarize this issue.
>
> The problem is which datastore is used to:
>
> 1a. evaluate action ancestor nodes
> 1b. evaluate action input/output parameter leafref,
> instance-identifier, must, when
> 2.  evaluate rpc input/output parameter leafref,
> instance-identifier, must, when
>
> (Note that the side effects of an action/rpc is not part of this
> issue)
>
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
>
> Possible solutions:
>
> A.  Always use  for 1 and 2.
>
> (This is what the current nmda draft says).
>
> B.  Let the client specify the datastore for 1, and use 
> for 2.
>
> (Note that this is trivial in RESTCONF (since the datastore is
> part of the URL), but would require a new parameter for NETCONF
> (or a new ).
>
> C.  Let the client specify the datastore for 1 and 2.
>
> This would require a new generic parameter for how RPCs are
> invoked in both NETCONF and RESTCONF.
>
> D.  Like B, but let the description of the "rpc" statement optionally
> override this.
>
>
> I prefer B and then D.
>
>
>

I prefer (A).

I do not see how this is transparent to non-NMDA clients that use actions
and/or rpcs.
The evaluation of config=true nodes change from  to .
This is a significant change that can break non-NMDA clients.

A non-NMDA client thinks the server is performing XPath evaluation according
to RFC 7950, sec. 6.4.1.


   o  If the XPath expression is defined in a substatement to an "input"
  statement in an "rpc" or "action" statement, the accessible tree
  is the RPC or action operation instance, all state data in the
  server, and the running configuration datastore.  The root node
  has top-level data nodes in all modules as children.
  Additionally, for an RPC, the root node also has the node
  representing the RPC operation being defined as a child.  The node
  representing the operation being defined has the operation's input
  parameters as children.

   o  If the XPath expression is defined in a substatement to an
  "output" statement in an "rpc" or "action" statement, the
  accessible tree is the RPC or action operation instance, all state
  data in the server, and the running configuration datastore.  The
  root node has top-level data nodes in all modules as children.
  Additionally, for an RPC, the root node also has the node
  representing the RPC operation being defined as a child.  The node
  representing the operation being defined has the operation's
  output parameters as children.



> /martin
>
>
>

Andy



>
>
> Andy Bierman  wrote:
> > On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
> >
> > > Sorry, if I wasn't clear.  I meant the  element would
> > > be directly under , so the system knows where to start
> > > looking for data.  Guessing is bad.
> > >
> > >
> > Totally agree guessing is bad.
> > Did you see the  proposal in a previous email?
> > That is exactly what I proposed, except I do not want to
> > overload  so the new template would be a different name.
> >
> > I realize the expanded name of the datastore element prevents it from
> > being confused with top-level YANG nodes, but the conformance
> > is more clear with a new name.
> >
> >
> >
> >
> > > Thanks,
> > >  Phil
> > >
> >
> > Andy
> >
> >
> > >
> > >
> > > Andy Bierman writes:
> > > >So a server will be required to guess the correct datastore until it
> > > >finds the right one that matches the action instance?
> > > >
> > > >   
> > > >   
> > > >  
> > > > 10
> > > > 
> > > >candidate
> > > > 
> > > >  
> > > >
> > > >
> > > >
> > > >The server will guess the datastore in some proprietary order and
> parse
> > > >instances of /top/ and /top/list1.  Then it finds the  action
> > > >and parses the input to get to the datastore and find out the real
> > > datastore
> > > >to use.  If the server guessed wrong, then it reparses the 
> > > against
> > > >the requested datastore.  Hopefully the schema trees match up.
> > > >
> > > >Will vendors do all the extra work required to support this sort of
> thing?
> > > >I doubt it.
> > > >
> > > >
> > > >Andy
> > > >
> > > >
> > > >
> > > >
> > > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
> wrote:
> > > >
> > > >> Robert Wilton writes:
> > > >> >ii) However, as far as I can see, it doesn't make sense for an
> action
> > > to
> > > >> >directly affect the contents of any configuration datastore, that
> > > should
> > > >> >be done via a purpose built rpc (like edit-config).
> > > >>
> > > >> An example action would be to retrieve the  fingerprint of an ssh
> > > >> key.  I might want to get the fingerprint of a key in 
> > > >> before I commit it.
> > > >>
> > > >> Or I could have an action that sets the SNMPv3 auth key to a ran

Re: [netmod] Action and RPC statements

[Lou Berger]

What's the standard way to reset a list to a default (based on
implementation)?

On 11/6/2017 12:02 PM, Juergen Schoenwaelder wrote:
> On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
>> The tags draft has an RPC to 'reset to default state'.  I could see
>> wanting the reset to be persistent or not depending on actual usage...
>>
> In general, I think we love the usage of standard operations like
> edit-config to manipulate configuration datastores and I think we
> dislike custom operations that manipulate configuration datastores.
>
> /js
>

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

[netmod] Reset tags RPC [was Re: Action and RPC statements]

[Robert Wilton]

Renaming this sub thread to avoid confusing the main discussion.


On 06/11/2017 16:48, Lou Berger wrote:

On 11/06/2017 11:41 AM, Robert Wilton wrote:


On 06/11/2017 15:51, Lou Berger wrote:


On November 6, 2017 10:21:19 AM Robert Wilton  wrote:


Hi Lou,

All of proposed solutions (A through D) allow the action or the RPC to
perform whatever behaviour that it wants.

This issue is only about which datastore is used to evaluate and check
that the parameters for the action/rpc are valid.  E.g. if the
parameters use when, must, leaf-ref, or instance-identifier.

So, to take option "A" for example: "A.  Always use  for 1
and 2."

One can still define a RPC that modifies another datastore ("edit-data"
in the NETCONF NMDA  draft is one such example).  But to check whether
the edit-data request can be performed, any input parameter constraints
would be evaluated against .  However, given that the input
parameters to edit-data don't contain any when, must, leaf-ref, or
instance-identifier statements then it makes absolutely no functional
difference which the datastore the parameters are evaluated in, since
the result will always be the same regardless.  But perhaps it just
feels a little odd that they are conceptually evaluated against
operational, even though the RPC only even affects one of the editable
configurable datastores.



Yes, which is why I've been assuming we'd end up with c.

But I think that to do C properly also requires a new optional statement
in YANG to indicate where the Action/RPC parameters are evaluated (with
the default being  if the new statement isn't specified).

Most RPCs/Action statements seem to naturally apply to .

For the RPCs/Action statements that don't naturally apply to
, it seems that it mostly doesn't matter where the
parameters are evaluated.

At the moment, the set of remaining RPCs/Actions (don't apply to
 but do care about parameter evaluation) seems quite small:
  (i) RFC7517, if it defined a YANG model for the  RPC
  (ii) A partial datastore diff from a subtree in  to
 might be another - it would want an instance-identifier
path to the subtree in .
  (iii) Perhaps I2RS and dynamic datastores may also throw up some new
examples.

The tags draft has an RPC to 'reset to default state'.  I could see
wanting the reset to be persistent or not depending on actual usage...

OK, I don't understand why this RPC is needed at all.

If the tags are managed through config (which I think that they are), 
then calling the "reset to default state" RPC should be equivalent to a 
normal list entry delete for that module anyway.


Why do you need two methods to achieve the same thing?  Or does this RPC 
do something slightly different?


Personally, I think that it would be better if the only way of editing 
configuration is through an  RPC.


A couple of other nits on the tags draft:
 - the tree diagram in 6.1 doesn't cover the config, perhaps it is out 
of date.
 - I would put list module-tags into a container (e.g. to make it 
easier to delete, or replace, all tag information).
 - do the configured tags replace the devices list or merge with them 
(perhaps this could be clarified)?  If merge, then presumably you also 
need a way to delete existing entries.  E.g. perhaps "grouping 
module-tags" also needs a separate leaf-list of tags to delete (really 
hide) from the implementation?


Thanks,
Rob




Lou

Thanks,
Rob



.



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

Re: [netmod] Action and RPC statements

[Juergen Schoenwaelder]

On Mon, Nov 06, 2017 at 11:48:23AM -0500, Lou Berger wrote:
> 
> The tags draft has an RPC to 'reset to default state'.  I could see
> wanting the reset to be persistent or not depending on actual usage...
>

In general, I think we love the usage of standard operations like
edit-config to manipulate configuration datastores and I think we
dislike custom operations that manipulate configuration datastores.

/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] Action and RPC statements

[Lou Berger]

On 11/06/2017 11:41 AM, Robert Wilton wrote:
> 
> 
> On 06/11/2017 15:51, Lou Berger wrote:
>>
>>
>> On November 6, 2017 10:21:19 AM Robert Wilton  wrote:
>>
>>> Hi Lou,
>>>
>>> All of proposed solutions (A through D) allow the action or the RPC to
>>> perform whatever behaviour that it wants.
>>>
>>> This issue is only about which datastore is used to evaluate and check
>>> that the parameters for the action/rpc are valid.  E.g. if the
>>> parameters use when, must, leaf-ref, or instance-identifier.
>>>
>>> So, to take option "A" for example: "A.  Always use  for 1
>>> and 2."
>>>
>>> One can still define a RPC that modifies another datastore ("edit-data"
>>> in the NETCONF NMDA  draft is one such example).  But to check whether
>>> the edit-data request can be performed, any input parameter constraints
>>> would be evaluated against .  However, given that the input
>>> parameters to edit-data don't contain any when, must, leaf-ref, or
>>> instance-identifier statements then it makes absolutely no functional
>>> difference which the datastore the parameters are evaluated in, since
>>> the result will always be the same regardless.  But perhaps it just
>>> feels a little odd that they are conceptually evaluated against
>>> operational, even though the RPC only even affects one of the editable
>>> configurable datastores.
>>>
>>
>>
>> Yes, which is why I've been assuming we'd end up with c.
> 
> But I think that to do C properly also requires a new optional statement
> in YANG to indicate where the Action/RPC parameters are evaluated (with
> the default being  if the new statement isn't specified).
> 
> Most RPCs/Action statements seem to naturally apply to .
> 
> For the RPCs/Action statements that don't naturally apply to
> , it seems that it mostly doesn't matter where the
> parameters are evaluated.
> 
> At the moment, the set of remaining RPCs/Actions (don't apply to
>  but do care about parameter evaluation) seems quite small:
>  (i) RFC7517, if it defined a YANG model for the  RPC
>  (ii) A partial datastore diff from a subtree in  to
>  might be another - it would want an instance-identifier
> path to the subtree in .
>  (iii) Perhaps I2RS and dynamic datastores may also throw up some new
> examples.

The tags draft has an RPC to 'reset to default state'.  I could see
wanting the reset to be persistent or not depending on actual usage...

Lou
> 
> Thanks,
> Rob
> 
> 

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

Re: [netmod] Action and RPC statements

[Robert Wilton]

On 06/11/2017 15:51, Lou Berger wrote:



On November 6, 2017 10:21:19 AM Robert Wilton  wrote:


Hi Lou,

All of proposed solutions (A through D) allow the action or the RPC to
perform whatever behaviour that it wants.

This issue is only about which datastore is used to evaluate and check
that the parameters for the action/rpc are valid.  E.g. if the
parameters use when, must, leaf-ref, or instance-identifier.

So, to take option "A" for example: "A.  Always use  for 1
and 2."

One can still define a RPC that modifies another datastore ("edit-data"
in the NETCONF NMDA  draft is one such example).  But to check whether
the edit-data request can be performed, any input parameter constraints
would be evaluated against .  However, given that the input
parameters to edit-data don't contain any when, must, leaf-ref, or
instance-identifier statements then it makes absolutely no functional
difference which the datastore the parameters are evaluated in, since
the result will always be the same regardless.  But perhaps it just
feels a little odd that they are conceptually evaluated against
operational, even though the RPC only even affects one of the editable
configurable datastores.




Yes, which is why I've been assuming we'd end up with c.


But I think that to do C properly also requires a new optional statement 
in YANG to indicate where the Action/RPC parameters are evaluated (with 
the default being  if the new statement isn't specified).


Most RPCs/Action statements seem to naturally apply to .

For the RPCs/Action statements that don't naturally apply to 
, it seems that it mostly doesn't matter where the 
parameters are evaluated.


At the moment, the set of remaining RPCs/Actions (don't apply to 
 but do care about parameter evaluation) seems quite small:

 (i) RFC7517, if it defined a YANG model for the  RPC
 (ii) A partial datastore diff from a subtree in  to 
 might be another - it would want an instance-identifier 
path to the subtree in .
 (iii) Perhaps I2RS and dynamic datastores may also throw up some new 
examples.


Thanks,
Rob

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

Re: [netmod] Action and RPC statements

[Lou Berger]

On November 6, 2017 10:21:19 AM Robert Wilton  wrote:


Hi Lou,

All of proposed solutions (A through D) allow the action or the RPC to
perform whatever behaviour that it wants.

This issue is only about which datastore is used to evaluate and check
that the parameters for the action/rpc are valid.  E.g. if the
parameters use when, must, leaf-ref, or instance-identifier.

So, to take option "A" for example: "A.  Always use  for 1
and 2."

One can still define a RPC that modifies another datastore ("edit-data"
in the NETCONF NMDA  draft is one such example).  But to check whether
the edit-data request can be performed, any input parameter constraints
would be evaluated against .  However, given that the input
parameters to edit-data don't contain any when, must, leaf-ref, or
instance-identifier statements then it makes absolutely no functional
difference which the datastore the parameters are evaluated in, since
the result will always be the same regardless.  But perhaps it just
feels a little odd that they are conceptually evaluated against
operational, even though the RPC only even affects one of the editable
configurable datastores.




Yes, which is why I've been assuming we'd end up with c.

Thanks,

Lou

Thanks,
Rob


On 06/11/2017 15:03, Lou Berger wrote:

So i guess this comes down to D listed below.  While i was expecting
C, i think D is probably workable. How would you envision the override
would be expressed?

Lou


On November 6, 2017 9:49:49 AM Martin Bjorklund  wrote:


Lou Berger  wrote:

Martin,

If I have an RPC or action that changes state, how would the
persistence of that state be indicated with an NMBA data stores.  I
expected it to be related to the data store, but I read your mail
below as saying otherwise


The side effects of executing an rpc or action is described in the
rpc/action itself.  This is not a problem.  For example, see the
definition of .  So with NMDA, this continues to work
like before.


/martin





Thanks,
Lou


On November 6, 2017 8:20:12 AM Martin Bjorklund 
wrote:

> Hi,
>
> Trying to summarize this issue.
>
> The problem is which datastore is used to:
>
> 1a. evaluate action ancestor nodes
> 1b. evaluate action input/output parameter leafref,
> instance-identifier, must, when
> 2.  evaluate rpc input/output parameter leafref,
> instance-identifier, must, when
>
> (Note that the side effects of an action/rpc is not part of this
> issue)
>
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
>
> Possible solutions:
>
> A.  Always use  for 1 and 2.
>
> (This is what the current nmda draft says).
>
> B.  Let the client specify the datastore for 1, and use 
> for 2.
>
> (Note that this is trivial in RESTCONF (since the datastore is
> part of the URL), but would require a new parameter for NETCONF
> (or a new ).
>
> C.  Let the client specify the datastore for 1 and 2.
>
> This would require a new generic parameter for how RPCs are
> invoked in both NETCONF and RESTCONF.
>
> D.  Like B, but let the description of the "rpc" statement optionally
> override this.
>
>
> I prefer B and then D.
>
>
> /martin
>
>
>
>
> Andy Bierman  wrote:
>> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer 
wrote:
>>
>> > Sorry, if I wasn't clear.  I meant the  element would
>> > be directly under , so the system knows where to start
>> > looking for data.  Guessing is bad.
>> >
>> >
>> Totally agree guessing is bad.
>> Did you see the  proposal in a previous email?
>> That is exactly what I proposed, except I do not want to
>> overload  so the new template would be a different name.
>>
>> I realize the expanded name of the datastore element prevents it
from
>> being confused with top-level YANG nodes, but the conformance
>> is more clear with a new name.
>>
>>
>>
>>
>> > Thanks,
>> >  Phil
>> >
>>
>> Andy
>>
>>
>> >
>> >
>> > Andy Bierman writes:
>> > >So a server will be required to guess the correct datastore
until it
>> > >finds the right one that matches the action instance?
>> > >
>> > >   
>> > >   
>> > >  
>> > > 10
>> > > 
>> > > candidate
>> > > 
>> > >  
>> > >    
>> > >    
>> > >
>> > >The server will guess the datastore in some proprietary order and
>> > >parse
>> > >instances of /top/ and /top/list1.  Then it finds the
 action
>> > >and parses the input to get to the datastore and find out the
real
>> > datastore
>> > >to use.  If the server guessed wrong, then it reparses the

>> > against
>> > >the requested datastore.  Hopefully the schema trees match up.
>> > >
>> > >Will vendors do all the extra work required to support this
sort of
>> > >thing?
>> > >I doubt it.
>> > >
>> > >
>> > >Andy
>> > >
>> > >
>> > >
>> > >
>> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
>> > >wrote:
>> > >
>> > >> Robert Wilton writes:
>> > >> >ii) However, as far as I can see, it doesn't make sense for
an action
>> > 

Re: [netmod] Action and RPC statements

[Robert Wilton]

Hi Lou,

All of proposed solutions (A through D) allow the action or the RPC to 
perform whatever behaviour that it wants.


This issue is only about which datastore is used to evaluate and check 
that the parameters for the action/rpc are valid.  E.g. if the 
parameters use when, must, leaf-ref, or instance-identifier.


So, to take option "A" for example: "A.  Always use  for 1 
and 2."


One can still define a RPC that modifies another datastore ("edit-data" 
in the NETCONF NMDA  draft is one such example).  But to check whether 
the edit-data request can be performed, any input parameter constraints 
would be evaluated against .  However, given that the input 
parameters to edit-data don't contain any when, must, leaf-ref, or 
instance-identifier statements then it makes absolutely no functional 
difference which the datastore the parameters are evaluated in, since 
the result will always be the same regardless.  But perhaps it just 
feels a little odd that they are conceptually evaluated against 
operational, even though the RPC only even affects one of the editable 
configurable datastores.


Thanks,
Rob


On 06/11/2017 15:03, Lou Berger wrote:
So i guess this comes down to D listed below.  While i was expecting 
C, i think D is probably workable. How would you envision the override 
would be expressed?


Lou


On November 6, 2017 9:49:49 AM Martin Bjorklund  wrote:


Lou Berger  wrote:

Martin,

If I have an RPC or action that changes state, how would the
persistence of that state be indicated with an NMBA data stores.  I
expected it to be related to the data store, but I read your mail
below as saying otherwise


The side effects of executing an rpc or action is described in the
rpc/action itself.  This is not a problem.  For example, see the
definition of .  So with NMDA, this continues to work
like before.


/martin





Thanks,
Lou


On November 6, 2017 8:20:12 AM Martin Bjorklund 
wrote:

> Hi,
>
> Trying to summarize this issue.
>
> The problem is which datastore is used to:
>
> 1a. evaluate action ancestor nodes
> 1b. evaluate action input/output parameter leafref,
> instance-identifier, must, when
> 2.  evaluate rpc input/output parameter leafref,
> instance-identifier, must, when
>
> (Note that the side effects of an action/rpc is not part of this
> issue)
>
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
>
> Possible solutions:
>
> A.  Always use  for 1 and 2.
>
> (This is what the current nmda draft says).
>
> B.  Let the client specify the datastore for 1, and use 
> for 2.
>
> (Note that this is trivial in RESTCONF (since the datastore is
> part of the URL), but would require a new parameter for NETCONF
> (or a new ).
>
> C.  Let the client specify the datastore for 1 and 2.
>
> This would require a new generic parameter for how RPCs are
> invoked in both NETCONF and RESTCONF.
>
> D.  Like B, but let the description of the "rpc" statement optionally
> override this.
>
>
> I prefer B and then D.
>
>
> /martin
>
>
>
>
> Andy Bierman  wrote:
>> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  
wrote:

>>
>> > Sorry, if I wasn't clear.  I meant the  element would
>> > be directly under , so the system knows where to start
>> > looking for data.  Guessing is bad.
>> >
>> >
>> Totally agree guessing is bad.
>> Did you see the  proposal in a previous email?
>> That is exactly what I proposed, except I do not want to
>> overload  so the new template would be a different name.
>>
>> I realize the expanded name of the datastore element prevents it 
from

>> being confused with top-level YANG nodes, but the conformance
>> is more clear with a new name.
>>
>>
>>
>>
>> > Thanks,
>> >  Phil
>> >
>>
>> Andy
>>
>>
>> >
>> >
>> > Andy Bierman writes:
>> > >So a server will be required to guess the correct datastore 
until it

>> > >finds the right one that matches the action instance?
>> > >
>> > >   
>> > >   
>> > >  
>> > > 10
>> > > 
>> > > candidate
>> > > 
>> > >  
>> > >    
>> > >    
>> > >
>> > >The server will guess the datastore in some proprietary order and
>> > >parse
>> > >instances of /top/ and /top/list1.  Then it finds the 
 action
>> > >and parses the input to get to the datastore and find out the 
real

>> > datastore
>> > >to use.  If the server guessed wrong, then it reparses the 


>> > against
>> > >the requested datastore.  Hopefully the schema trees match up.
>> > >
>> > >Will vendors do all the extra work required to support this 
sort of

>> > >thing?
>> > >I doubt it.
>> > >
>> > >
>> > >Andy
>> > >
>> > >
>> > >
>> > >
>> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
>> > >wrote:
>> > >
>> > >> Robert Wilton writes:
>> > >> >ii) However, as far as I can see, it doesn't make sense for 
an action

>> > to
>> > >> >directly affect the contents of any configuration 
datastore, that

>> > should
>> > >

Re: [netmod] Action and RPC statements

[Lou Berger]

So i guess this comes down to D listed below.  While i was expecting C, i 
think D is probably workable. How would you envision the override would be 
expressed?


Lou


On November 6, 2017 9:49:49 AM Martin Bjorklund  wrote:


Lou Berger  wrote:

Martin,

If I have an RPC or action that changes state, how would the
persistence of that state be indicated with an NMBA data stores.  I
expected it to be related to the data store, but I read your mail
below as saying otherwise


The side effects of executing an rpc or action is described in the
rpc/action itself.  This is not a problem.  For example, see the
definition of .  So with NMDA, this continues to work
like before.


/martin





Thanks,
Lou


On November 6, 2017 8:20:12 AM Martin Bjorklund 
wrote:

> Hi,
>
> Trying to summarize this issue.
>
> The problem is which datastore is used to:
>
> 1a. evaluate action ancestor nodes
> 1b. evaluate action input/output parameter leafref,
> instance-identifier, must, when
> 2.  evaluate rpc input/output parameter leafref,
> instance-identifier, must, when
>
> (Note that the side effects of an action/rpc is not part of this
> issue)
>
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
>
> Possible solutions:
>
> A.  Always use  for 1 and 2.
>
> (This is what the current nmda draft says).
>
> B.  Let the client specify the datastore for 1, and use 
> for 2.
>
> (Note that this is trivial in RESTCONF (since the datastore is
> part of the URL), but would require a new parameter for NETCONF
> (or a new ).
>
> C.  Let the client specify the datastore for 1 and 2.
>
> This would require a new generic parameter for how RPCs are
> invoked in both NETCONF and RESTCONF.
>
> D.  Like B, but let the description of the "rpc" statement optionally
> override this.
>
>
> I prefer B and then D.
>
>
> /martin
>
>
>
>
> Andy Bierman  wrote:
>> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
>>
>> > Sorry, if I wasn't clear.  I meant the  element would
>> > be directly under , so the system knows where to start
>> > looking for data.  Guessing is bad.
>> >
>> >
>> Totally agree guessing is bad.
>> Did you see the  proposal in a previous email?
>> That is exactly what I proposed, except I do not want to
>> overload  so the new template would be a different name.
>>
>> I realize the expanded name of the datastore element prevents it from
>> being confused with top-level YANG nodes, but the conformance
>> is more clear with a new name.
>>
>>
>>
>>
>> > Thanks,
>> >  Phil
>> >
>>
>> Andy
>>
>>
>> >
>> >
>> > Andy Bierman writes:
>> > >So a server will be required to guess the correct datastore until it
>> > >finds the right one that matches the action instance?
>> > >
>> > >   
>> > >   
>> > >  
>> > > 10
>> > > 
>> > >candidate
>> > > 
>> > >  
>> > >
>> > >
>> > >
>> > >The server will guess the datastore in some proprietary order and
>> > >parse
>> > >instances of /top/ and /top/list1.  Then it finds the  action
>> > >and parses the input to get to the datastore and find out the real
>> > datastore
>> > >to use.  If the server guessed wrong, then it reparses the 
>> > against
>> > >the requested datastore.  Hopefully the schema trees match up.
>> > >
>> > >Will vendors do all the extra work required to support this sort of
>> > >thing?
>> > >I doubt it.
>> > >
>> > >
>> > >Andy
>> > >
>> > >
>> > >
>> > >
>> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
>> > >wrote:
>> > >
>> > >> Robert Wilton writes:
>> > >> >ii) However, as far as I can see, it doesn't make sense for an action
>> > to
>> > >> >directly affect the contents of any configuration datastore, that
>> > should
>> > >> >be done via a purpose built rpc (like edit-config).
>> > >>
>> > >> An example action would be to retrieve the  fingerprint of an ssh
>> > >> key.  I might want to get the fingerprint of a key in 
>> > >> before I commit it.
>> > >>
>> > >> Or I could have an action that sets the SNMPv3 auth key to a random
>> > >> value, and I want to invoke that action against .
>> > >>
>> > >> Seems like  might also be an interesting place to target
>> > >> actions, but I can't think of a good example.
>> > >>
>> > >> There are always scenarios where something is useful, and the problem
>> > >> with ruling it out is that it becomes needed at some later point.
>> > >> We've a habit of ruling out things and later wishing we had them.
>> > >>
>> > >> Is the easy fix to just put a datastore leaf under rpc/action and
>> > >> have it default to operational?  Any specific RPC can define its
>> > >> own datastore leaf of hard-code the database in the description
>> > >> (explicitly or implicitly ), but the  RPC only
>> > >> gets this if we make a new parameter for it.
>> > >>
>> > >> Thanks,
>> > >>  Phil
>> > >>
>> > >
>> > >--001a11411b0ad2d58d055cee96cb
>> > >Content-Ty

Re: [netmod] Action and RPC statements

[Martin Bjorklund]

Lou Berger  wrote:
> Martin,
> 
> If I have an RPC or action that changes state, how would the
> persistence of that state be indicated with an NMBA data stores.  I
> expected it to be related to the data store, but I read your mail
> below as saying otherwise

The side effects of executing an rpc or action is described in the
rpc/action itself.  This is not a problem.  For example, see the
definition of .  So with NMDA, this continues to work
like before.


/martin




> Thanks,
> Lou
> 
> 
> On November 6, 2017 8:20:12 AM Martin Bjorklund 
> wrote:
> 
> > Hi,
> >
> > Trying to summarize this issue.
> >
> > The problem is which datastore is used to:
> >
> > 1a. evaluate action ancestor nodes
> > 1b. evaluate action input/output parameter leafref,
> > instance-identifier, must, when
> > 2.  evaluate rpc input/output parameter leafref,
> > instance-identifier, must, when
> >
> > (Note that the side effects of an action/rpc is not part of this
> > issue)
> >
> > I think it would be very weird if 1a and 1b were treated differently,
> > so I just label them as 1 below.
> >
> > Possible solutions:
> >
> > A.  Always use  for 1 and 2.
> >
> > (This is what the current nmda draft says).
> >
> > B.  Let the client specify the datastore for 1, and use 
> > for 2.
> >
> > (Note that this is trivial in RESTCONF (since the datastore is
> > part of the URL), but would require a new parameter for NETCONF
> > (or a new ).
> >
> > C.  Let the client specify the datastore for 1 and 2.
> >
> > This would require a new generic parameter for how RPCs are
> > invoked in both NETCONF and RESTCONF.
> >
> > D.  Like B, but let the description of the "rpc" statement optionally
> > override this.
> >
> >
> > I prefer B and then D.
> >
> >
> > /martin
> >
> >
> >
> >
> > Andy Bierman  wrote:
> >> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
> >>
> >> > Sorry, if I wasn't clear.  I meant the  element would
> >> > be directly under , so the system knows where to start
> >> > looking for data.  Guessing is bad.
> >> >
> >> >
> >> Totally agree guessing is bad.
> >> Did you see the  proposal in a previous email?
> >> That is exactly what I proposed, except I do not want to
> >> overload  so the new template would be a different name.
> >>
> >> I realize the expanded name of the datastore element prevents it from
> >> being confused with top-level YANG nodes, but the conformance
> >> is more clear with a new name.
> >>
> >>
> >>
> >>
> >> > Thanks,
> >> >  Phil
> >> >
> >>
> >> Andy
> >>
> >>
> >> >
> >> >
> >> > Andy Bierman writes:
> >> > >So a server will be required to guess the correct datastore until it
> >> > >finds the right one that matches the action instance?
> >> > >
> >> > >   
> >> > >   
> >> > >  
> >> > > 10
> >> > > 
> >> > >candidate
> >> > > 
> >> > >  
> >> > >
> >> > >
> >> > >
> >> > >The server will guess the datastore in some proprietary order and
> >> > >parse
> >> > >instances of /top/ and /top/list1.  Then it finds the  action
> >> > >and parses the input to get to the datastore and find out the real
> >> > datastore
> >> > >to use.  If the server guessed wrong, then it reparses the 
> >> > against
> >> > >the requested datastore.  Hopefully the schema trees match up.
> >> > >
> >> > >Will vendors do all the extra work required to support this sort of
> >> > >thing?
> >> > >I doubt it.
> >> > >
> >> > >
> >> > >Andy
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer 
> >> > >wrote:
> >> > >
> >> > >> Robert Wilton writes:
> >> > >> >ii) However, as far as I can see, it doesn't make sense for an action
> >> > to
> >> > >> >directly affect the contents of any configuration datastore, that
> >> > should
> >> > >> >be done via a purpose built rpc (like edit-config).
> >> > >>
> >> > >> An example action would be to retrieve the  fingerprint of an ssh
> >> > >> key.  I might want to get the fingerprint of a key in 
> >> > >> before I commit it.
> >> > >>
> >> > >> Or I could have an action that sets the SNMPv3 auth key to a random
> >> > >> value, and I want to invoke that action against .
> >> > >>
> >> > >> Seems like  might also be an interesting place to target
> >> > >> actions, but I can't think of a good example.
> >> > >>
> >> > >> There are always scenarios where something is useful, and the problem
> >> > >> with ruling it out is that it becomes needed at some later point.
> >> > >> We've a habit of ruling out things and later wishing we had them.
> >> > >>
> >> > >> Is the easy fix to just put a datastore leaf under rpc/action and
> >> > >> have it default to operational?  Any specific RPC can define its
> >> > >> own datastore leaf of hard-code the database in the description
> >> > >> (explicitly or implicitly ), but the  RPC only
> >> > >> gets this if we make a new parameter for it.
> >> > >>
> >> > >> Thanks,
> >

Re: [netmod] draft-clacla-netmod-yang-model-update-00.txt : Re: [RTG-DIR] handling module incompatibility => handling module transition

[Rob Shakir]

I agree that semantic versioning is only part of the solution. In
OpenConfig versioning we have the concept of release bundles that have a
semver, these contain modules that are known to work together - and are the
base for compliance descriptions. The individual modules semver has been
useful to mark where there are backwards incompatible changes in an
individual module.

On top of release bundles, we also have feature bundles which describe a
particular implementation's requirements for the modules. A feature bundle
is a description of paths within a release bundle.

We're continuing to gain experience with how well this works, but certainly
I don't see the need for the bundles alleviating the need for the semantic
versions for modules.

r.

On Fri, 3 Nov 2017 at 11:05 Andy Bierman  wrote:

> On Fri, Nov 3, 2017 at 10:48 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> My take here is that structured version numbers do only partially
>> solve the problem. Andy's work years ago on packages offers in my view
>> a superior foundation for a solution. Once we can bundle modules that
>> are designed and known to work together into meaningful packages, then
>> it may be possible to relax some of the strict RFC 7950 update
>> rules.
>>
>> Once the NETMOD WG gets the work on NMDA "completed", I believe "YANG
>> packages" are a worthwhile target to work on. There is a need to get
>> more structure into the module space, not just additional structured
>> version numbers.
>>
>>
> I agree ;-)
>
> It is nice to have a way to know current implementations will probably
> break if they upgrade to the new version. It is even nicer if the APIs
> are stable and don't break existing code.
>
> It is not encouraging that the IETF cannot produce stable YANG modules
> published in RFCs.  We expect I-Ds to ignore the YANG update rules,
> but not RFC versions.
>
> Since the semantic versioning is only per-module, it is not usefull for
> determining if module foo will work with module bar.  If it is OK
> to break backward-compatibility then it will become increasingly
> difficult to just use the latest version of a module. Real interoperability
> at the granularity of modules will become more difficult. YANG packages
> can dramatically reduce the number of API permutations.
>
>
> /js
>>
>
>
> Andy
>
>
>>
>> On Fri, Nov 03, 2017 at 06:30:52PM +0100, Benoit Claise wrote:
>> > Dear all,
>> >
>> > Let me present this draft
>> > https://datatracker.ietf.org/doc/draft-clacla-netmod-yang-model-update/
>> >
>> > New YANG Module Update Procedure
>> > draft-clacla-netmod-yang-model-update-01
>> >
>> > Abstract
>> >
>> >This document specifies a new YANG module update procedure in case of
>> >non backward-compatible changes, as an alternative proposal to the
>> >YANG 1.1 specifications.  This document updates RFC 7950.
>> >
>> >
>> > Problem statement:
>> > Changing a YANG module name each time there is a non backward compatible
>> > change (as RFC7950 requires) adds a lot of complexity to automation,
>> from an
>> > import and service composition point of view.
>> >
>> > Solution:
>> > We need a different mechanism. The solution in the draft is based on the
>> > semantic versioning YANG extension: it was proposed openconfig in the
>> past
>> > and is currently used by the openconfig YANG modules
>> >
>> > Note: there might other solutions, such as new YANG keywords, but at
>> this
>> > point in time, it's important to recognize that we need to change the
>> way we
>> > produce YANG modules at the IETF. Let's discuss on the list and during
>> the
>> > NETMOD meeting.
>> >
>> > Regards, Benoit.
>> > > On 10/12/2017 3:30 PM, Benoit Claise wrote:
>> > > > Hi Lou,
>> > > > >
>> > > > > So circling back to the original question: what do we do about
>> > > > > the non backward-compatible module being defined in rfc8049bis?
>> > > > >
>> > > > > While being sympathetic to many of the comments made below as
>> > > > > well as the "do over" concept, I find the comments about
>> > > > > adhering to the rules of 7950 compelling - which leads to
>> > > > > renaming the module in the bis to ietf-l3vpn-svc-2.
>> > > > >
>> > > > > It would be good to ensure that this is the consensus of the
>> > > > > group before asking the authors make this change.
>> > > > >
>> > > > Since this draft is AD sponsored, I'll evaluate the consensus on
>> > > > RFC8049bis.
>> > > > Moving to ietf-l3vpn-svc-2 is the easy path not to break backward
>> > > > compatibility. However, since ietf-l3vpn-svc is unimplementable (it
>> > > > has broken XPATH expressions, so a compliant implementation is
>> > > > impossible), so technically, ietf-l3vpn-svc does not even exist.
>> > > See my message on this topic, as the IETF LC follow up.
>> > >
>> https://www.ietf.org/mail-archive/web/ietf-announce/current/maillist.html
>> > > If a follow up is required, I propose that we use a single public
>> email
>> > > 

Re: [netmod] Action and RPC statements

[Juergen Schoenwaelder]

On Mon, Nov 06, 2017 at 02:19:24PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Trying to summarize this issue.
> 
> The problem is which datastore is used to:
> 
> 1a. evaluate action ancestor nodes
> 1b. evaluate action input/output parameter leafref,
> instance-identifier, must, when
> 2.  evaluate rpc input/output parameter leafref,
> instance-identifier, must, when
> 
> (Note that the side effects of an action/rpc is not part of this
> issue)
> 
> I think it would be very weird if 1a and 1b were treated differently,
> so I just label them as 1 below.
> 
> Possible solutions:
> 
> A.  Always use  for 1 and 2.
> 
> (This is what the current nmda draft says).
> 
> B.  Let the client specify the datastore for 1, and use 
> for 2.
> 
> (Note that this is trivial in RESTCONF (since the datastore is
> part of the URL), but would require a new parameter for NETCONF
> (or a new ).
> 
> C.  Let the client specify the datastore for 1 and 2.
> 
> This would require a new generic parameter for how RPCs are
> invoked in both NETCONF and RESTCONF.
> 
> D.  Like B, but let the description of the "rpc" statement optionally
> override this.
> 
> 
> I prefer B and then D.
>

I prefer A for now and I believe any of the other options may be
considered in the future (when we can provide proper support of YANG
and the protocols). I also believe that A covers a large number of
real-world use cases.

/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] Action and RPC statements

[Lou Berger]

Martin,

If I have an RPC or action that changes state, how would the persistence of 
that state be indicated with an NMBA data stores.  I expected it to be 
related to the data store, but I read your mail below as saying otherwise

Thanks,
Lou


On November 6, 2017 8:20:12 AM Martin Bjorklund  wrote:


Hi,

Trying to summarize this issue.

The problem is which datastore is used to:

1a. evaluate action ancestor nodes
1b. evaluate action input/output parameter leafref,
instance-identifier, must, when
2.  evaluate rpc input/output parameter leafref,
instance-identifier, must, when

(Note that the side effects of an action/rpc is not part of this
issue)

I think it would be very weird if 1a and 1b were treated differently,
so I just label them as 1 below.

Possible solutions:

A.  Always use  for 1 and 2.

(This is what the current nmda draft says).

B.  Let the client specify the datastore for 1, and use 
for 2.

(Note that this is trivial in RESTCONF (since the datastore is
part of the URL), but would require a new parameter for NETCONF
(or a new ).

C.  Let the client specify the datastore for 1 and 2.

This would require a new generic parameter for how RPCs are
invoked in both NETCONF and RESTCONF.

D.  Like B, but let the description of the "rpc" statement optionally
override this.


I prefer B and then D.


/martin




Andy Bierman  wrote:

On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:

> Sorry, if I wasn't clear.  I meant the  element would
> be directly under , so the system knows where to start
> looking for data.  Guessing is bad.
>
>
Totally agree guessing is bad.
Did you see the  proposal in a previous email?
That is exactly what I proposed, except I do not want to
overload  so the new template would be a different name.

I realize the expanded name of the datastore element prevents it from
being confused with top-level YANG nodes, but the conformance
is more clear with a new name.




> Thanks,
>  Phil
>

Andy


>
>
> Andy Bierman writes:
> >So a server will be required to guess the correct datastore until it
> >finds the right one that matches the action instance?
> >
> >   
> >   
> >  
> > 10
> > 
> >candidate
> > 
> >  
> >
> >
> >
> >The server will guess the datastore in some proprietary order and parse
> >instances of /top/ and /top/list1.  Then it finds the  action
> >and parses the input to get to the datastore and find out the real
> datastore
> >to use.  If the server guessed wrong, then it reparses the 
> against
> >the requested datastore.  Hopefully the schema trees match up.
> >
> >Will vendors do all the extra work required to support this sort of thing?
> >I doubt it.
> >
> >
> >Andy
> >
> >
> >
> >
> >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer  wrote:
> >
> >> Robert Wilton writes:
> >> >ii) However, as far as I can see, it doesn't make sense for an action
> to
> >> >directly affect the contents of any configuration datastore, that
> should
> >> >be done via a purpose built rpc (like edit-config).
> >>
> >> An example action would be to retrieve the  fingerprint of an ssh
> >> key.  I might want to get the fingerprint of a key in 
> >> before I commit it.
> >>
> >> Or I could have an action that sets the SNMPv3 auth key to a random
> >> value, and I want to invoke that action against .
> >>
> >> Seems like  might also be an interesting place to target
> >> actions, but I can't think of a good example.
> >>
> >> There are always scenarios where something is useful, and the problem
> >> with ruling it out is that it becomes needed at some later point.
> >> We've a habit of ruling out things and later wishing we had them.
> >>
> >> Is the easy fix to just put a datastore leaf under rpc/action and
> >> have it default to operational?  Any specific RPC can define its
> >> own datastore leaf of hard-code the database in the description
> >> (explicitly or implicitly ), but the  RPC only
> >> gets this if we make a new parameter for it.
> >>
> >> Thanks,
> >>  Phil
> >>
> >
> >--001a11411b0ad2d58d055cee96cb
> >Content-Type: text/html; charset="UTF-8"
> >Content-Transfer-Encoding: quoted-printable
> >
> >Hi,So a server will be required to
> gue=
> >ss the correct datastore until itfinds the right one that
> matche=
> >s the action instance?=C2=A0
> =C2=A0=
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
> =C2=A0 =
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> >=C2=A0 =C2=A0 =C2=A010=C2=A0 =C2=A0
> =C2=
> >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0
> =C2=
> >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate<
> /datas=
> >tore>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> =C2=A0 >test>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> <=
> >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
>  >ction>The server will guess the datastore
> in s=
> >ome proprietary order and parsein

Re: [netmod] Action and RPC statements

[Martin Bjorklund]

Hi,

Trying to summarize this issue.

The problem is which datastore is used to:

1a. evaluate action ancestor nodes
1b. evaluate action input/output parameter leafref,
instance-identifier, must, when
2.  evaluate rpc input/output parameter leafref,
instance-identifier, must, when

(Note that the side effects of an action/rpc is not part of this
issue)

I think it would be very weird if 1a and 1b were treated differently,
so I just label them as 1 below.

Possible solutions:

A.  Always use  for 1 and 2.

(This is what the current nmda draft says).

B.  Let the client specify the datastore for 1, and use 
for 2.

(Note that this is trivial in RESTCONF (since the datastore is
part of the URL), but would require a new parameter for NETCONF
(or a new ).

C.  Let the client specify the datastore for 1 and 2.

This would require a new generic parameter for how RPCs are
invoked in both NETCONF and RESTCONF.

D.  Like B, but let the description of the "rpc" statement optionally
override this.


I prefer B and then D.


/martin




Andy Bierman  wrote:
> On Thu, Nov 2, 2017 at 2:16 PM, Phil Shafer  wrote:
> 
> > Sorry, if I wasn't clear.  I meant the  element would
> > be directly under , so the system knows where to start
> > looking for data.  Guessing is bad.
> >
> >
> Totally agree guessing is bad.
> Did you see the  proposal in a previous email?
> That is exactly what I proposed, except I do not want to
> overload  so the new template would be a different name.
> 
> I realize the expanded name of the datastore element prevents it from
> being confused with top-level YANG nodes, but the conformance
> is more clear with a new name.
> 
> 
> 
> 
> > Thanks,
> >  Phil
> >
> 
> Andy
> 
> 
> >
> >
> > Andy Bierman writes:
> > >So a server will be required to guess the correct datastore until it
> > >finds the right one that matches the action instance?
> > >
> > >   
> > >   
> > >  
> > > 10
> > > 
> > >candidate
> > > 
> > >  
> > >
> > >
> > >
> > >The server will guess the datastore in some proprietary order and parse
> > >instances of /top/ and /top/list1.  Then it finds the  action
> > >and parses the input to get to the datastore and find out the real
> > datastore
> > >to use.  If the server guessed wrong, then it reparses the 
> > against
> > >the requested datastore.  Hopefully the schema trees match up.
> > >
> > >Will vendors do all the extra work required to support this sort of thing?
> > >I doubt it.
> > >
> > >
> > >Andy
> > >
> > >
> > >
> > >
> > >On Tue, Oct 31, 2017 at 11:36 PM, Phil Shafer  wrote:
> > >
> > >> Robert Wilton writes:
> > >> >ii) However, as far as I can see, it doesn't make sense for an action
> > to
> > >> >directly affect the contents of any configuration datastore, that
> > should
> > >> >be done via a purpose built rpc (like edit-config).
> > >>
> > >> An example action would be to retrieve the  fingerprint of an ssh
> > >> key.  I might want to get the fingerprint of a key in 
> > >> before I commit it.
> > >>
> > >> Or I could have an action that sets the SNMPv3 auth key to a random
> > >> value, and I want to invoke that action against .
> > >>
> > >> Seems like  might also be an interesting place to target
> > >> actions, but I can't think of a good example.
> > >>
> > >> There are always scenarios where something is useful, and the problem
> > >> with ruling it out is that it becomes needed at some later point.
> > >> We've a habit of ruling out things and later wishing we had them.
> > >>
> > >> Is the easy fix to just put a datastore leaf under rpc/action and
> > >> have it default to operational?  Any specific RPC can define its
> > >> own datastore leaf of hard-code the database in the description
> > >> (explicitly or implicitly ), but the  RPC only
> > >> gets this if we make a new parameter for it.
> > >>
> > >> Thanks,
> > >>  Phil
> > >>
> > >
> > >--001a11411b0ad2d58d055cee96cb
> > >Content-Type: text/html; charset="UTF-8"
> > >Content-Transfer-Encoding: quoted-printable
> > >
> > >Hi,So a server will be required to
> > gue=
> > >ss the correct datastore until itfinds the right one that
> > matche=
> > >s the action instance?=C2=A0
> > =C2=A0=
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
> > =C2=A0 =
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
> > >=C2=A0 =C2=A0 =C2=A010=C2=A0 =C2=A0
> > =C2=
> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0
> > =C2=
> > >=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 candidate<
> > /datas=
> > >tore>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > =C2=A0 > >test>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> > <=
> > >div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
> >  > >ction>The server will guess the datastore
> > in s=
> > >ome proprietary order and parseinstances of /top/ and
> > /top/list1=
> > >.=C2=A0 Then it fin

Re: [netmod] WG Last Call: draft-ietf-netmod-schema-mount-07

[Ladislav Lhotka]

On Sat, 2017-11-04 at 15:03 -0400, Christian Hopps wrote:
> I've reviewed this draft (-08), and I think it's ready for publication.
> 
> A nit, the text:
> 
> Page 4 item 3: "The mounted schema is defined by instance data that is
> part of the mounted data model."

So would it be better to say "... is defined by a new instance of YANG library
that is a part of the mounted data model."?

Thanks, Lada

> 
> Seems pretty complex if all it's trying to say is "It is what it is".
> 
> Thanks,
> Chris.
> 
> 
> Kent Watsen  writes:
> 
> > All,
> > 
> > This starts a two-week working group last call on
> > draft-ietf-netmod-schema-mount-07.
> > 
> > The working group last call ends on November 3.
> > Please send your comments to the netmod mailing list.
> > 
> > Positive comments, e.g., "I've reviewed this document
> > and believe it is ready for publication", are welcome!
> > This is useful and important, even from authors.
> > 
> > Could the authors, explicitly CC-ed on this email,
> > please also confirm one more time that they are
> > unaware of any IPR related to this draft.
> > 
> > Thank you,
> > Netmod Chairs
> > 
> > 
> > ___
> > 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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