[netmod] Fwd: Reminder: Survey on planning for possible online IETF meetings

[Kent Watsen]

NETMOD WG,

Please fill out this survey.

Thanks!

> Begin forwarded message:
> 
> From: Alissa Cooper 
> Subject: Fwd: Reminder: Survey on planning for possible online IETF meetings
> Date: May 5, 2020 at 7:48:03 AM EDT
> To: IETF WG Chairs 
> 
> Please circulate this to your working group lists. The survey data will be 
> very important as we plan future IETF meetings.
> 
> Thanks,
> Alissa
> 
>> Begin forwarded message:
>> 
>> From: IETF Executive Director > >
>> Subject: Reminder: Survey on planning for possible online IETF meetings
>> Date: May 4, 2020 at 3:03:35 AM EDT
>> To: "IETF Announcement List" > >
>> Reply-To: ietf108plann...@ietf.org 
>> 
>> This is a reminder that we need the IETF community to help us plan for the 
>> possibility that one or more upcoming IETF meetings in 2020 and possibly 
>> 2021 may not be able to go ahead in person.  You can help us with this by 
>> filling out the following survey: 
>> 
>>  https://www.surveymonkey.com/r/5328FFJ 
>> 
>> 
>> So far we have 114 responses and we would ideally like 500 or more.
>> 
>> The survey contains the following pages and will take 15-20 minutes to 
>> complete:
>> 
>> 1. Welcome
>> 2. Online IETF 107 and the subsequent virtual interims
>> 3. Replacing a cancelled in-person meeting
>> 4. Online meeting format and timezone
>> 5. Replicating humming
>> 6. Replicating the hallway environment
>> 7. Fees
>> 8. Thanks and anything else
>> 
>> We run the survey in anonymous mode which means that we only see data that 
>> you explicitly provide.
>> 
>> Thank you in advance for your help.
>> 
>> -- 
>> Alissa Cooper, IETF Chair
>> Jay Daley, IETF Executive Director
>> Colin Perkins, IRTF Chair
>> 
>> ___
>> IETF-Announce mailing list
>> ietf-annou...@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 

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

Re: [netmod] RFC 8349 action input augment

[tom petch]

From: Martin Björklund 
Sent: 05 May 2020 12:39
Cc: lho...@nic.cz; netmod@ietf.org

tom petch  wrote:
> RFC8349 specifies an action with no input and says that modules that
> use this MUST augment the input with a leaf and that the leaf must
> be named destination-address.
>
> Is there any way that YANG can enforce either constraint?

This may look correct:

  action activate-route {
input {
  must '*[local-name(.) = "destination-address"]';
}
...
  }


 but unfortunatly we have a CLR in the definition of "input":

   input-stmt  = input-keyword optsep
 "{" stmtsep
 ;; these stmts can appear in any order
 *must-stmt
 *(typedef-stmt / grouping-stmt)
 HERE--->1*data-def-stmt
 "}" stmtsep


We require "input" to have at least one data-def-stmt, which doens't
make any sense, since we allow an action/rpc to not define "input" at
all.


Thanks for that.  I thought there was a reason but did not think to look there.

As you may have guessed, I just looked at a YANG module which broke the rules, 
added  a leaf but of the wrong name.

Tom Petch



/martin


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

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

[netmod] Module-name + revision-label identifies a YANG module version

[Balázs Lengyel]

Hello,

I added a new issue about draft-ietf-netmod-yang-module-versioning at
https://github.com/netmod-wg/yang-ver-dt/issues/58.

A specific revision-label identifies a specific version (variant) of the
module. If two files contain YANG modules with the same module name and the
same revision-label in their latest revision statement, then the two modules
MUST be the same (except for possible white space at the end of each line.)

This requirement should be stated in the draft.

Regards Balazs

 

-- 

Balazs LengyelSenior Specialist
Ericsson Hungary Ltd. 

Mobile: +36-70-330-7909  email: balazs.leng...@ericsson.com

 



smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] RFC 8349 action input augment

[Martin Björklund]

tom petch  wrote:
> RFC8349 specifies an action with no input and says that modules that
> use this MUST augment the input with a leaf and that the leaf must
> be named destination-address.
> 
> Is there any way that YANG can enforce either constraint?

This may look correct:

  action activate-route {
input {
  must '*[local-name(.) = "destination-address"]';
}
...
  }


 but unfortunatly we have a CLR in the definition of "input":

   input-stmt  = input-keyword optsep
 "{" stmtsep
 ;; these stmts can appear in any order
 *must-stmt
 *(typedef-stmt / grouping-stmt)
 HERE--->1*data-def-stmt
 "}" stmtsep


We require "input" to have at least one data-def-stmt, which doens't
make any sense, since we allow an action/rpc to not define "input" at
all.




/martin


> 
> Tom Petch
> 
> 
> ___
> 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] YANG action not allowed at root?

[Juergen Schoenwaelder]

On Tue, May 05, 2020 at 12:06:34PM +0200, Per Hedeland wrote:
> On 2020-05-05 11:55, Juergen Schoenwaelder wrote:
> > On Tue, May 05, 2020 at 11:45:41AM +0200, Per Hedeland wrote:
> >> On 2020-05-05 11:00, Martin Björklund wrote:
> >>> Hi,
> >>>
> >>> If we were to redo YANG, I would prefer to have a single statement
> >>> "operation", either on the top-level, or tied to a node.
> >>
> >> So, no rpc statement, and thereby no possibility to extend NETCONF
> >> with new RPCs? (Or to be precise, YANG would extend NETCONF with
> >> exactly one RPC, called "operation"?)
> >>
> >
> > OLD
> >
> >   rpc foo {}
> >   list something { action bar {} }
> >
> > NEW
> >
> >   operation foo {}
> >   list something { operation bar {} }
> 
> Yes, that much is obvious, my question was really about the NETCONF
> encoding.
> 
> > Syntactic sugar if you will.
> 
> So you're saying that the NETCONF encoding of "operation foo" at the
> top level would be an RPC called "foo", while the NETCONF encoding of
> "operation foo" elsewhere would be an RPC called "action"?
>

Yes. Unless you want to change the protocol (or the protocols) as
well, which would involve another WG (or even WGs). Perhaps this is
what will happen if we were to start this.

But ideally, we would use a YANG next activity to get the interface
between YANG, the encodings of YANG defined data, and the protocols
better worked out (since we now know that we have several of them to
take care of and we I think we learned where we could have made things
simpler).

/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] YANG action not allowed at root?

[Martin Björklund]

"Rob Wilton (rwilton)"  wrote:
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Martin Björklund
> > Sent: 05 May 2020 11:30
> > To: p...@hedeland.org
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] YANG action not allowed at root?
> > 
> > Per Hedeland  wrote:
> > > On 2020-05-05 11:55, Juergen Schoenwaelder wrote:
> > > > On Tue, May 05, 2020 at 11:45:41AM +0200, Per Hedeland wrote:
> > > >> On 2020-05-05 11:00, Martin Björklund wrote:
> > > >>> Hi,
> > > >>>
> > > >>> If we were to redo YANG, I would prefer to have a single statement
> > > >>> "operation", either on the top-level, or tied to a node.
> > > >>
> > > >> So, no rpc statement, and thereby no possibility to extend NETCONF
> > > >> with new RPCs? (Or to be precise, YANG would extend NETCONF with
> > > >> exactly one RPC, called "operation"?)
> > > >>
> > > >
> > > > OLD
> > > >
> > > >   rpc foo {}
> > > >   list something { action bar {} }
> > > >
> > > > NEW
> > > >
> > > >   operation foo {}
> > > >   list something { operation bar {} }
> > >
> > > Yes, that much is obvious, my question was really about the NETCONF
> > > encoding.
> > >
> > > > Syntactic sugar if you will.
> > >
> > > So you're saying that the NETCONF encoding of "operation foo" at the
> > > top level would be an RPC called "foo"
> > 
> > Yes.
> > 
> > > while the NETCONF encoding of
> > > "operation foo" elsewhere would be an RPC called "action"?
> > 
> > Yes; or called something else.
> [RW] 
> 
> What is your reasoning for not wanting to unify the encoding?

I don't want to change the protocol.

> E.g. always treat the encoding like action, but with the  node 
> removed.

This would violate RFC 6241 which says:

   The name of the RPC is an element directly inside the
element, and any parameters are encoded inside this element.



/martin


> 
> Regards,
> Rob
> 
> [As an individual contributor]
> 
> > 
> > 
> > /martin
> > 
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod

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

[netmod] RFC 8349 action input augment

[tom petch]

RFC8349 specifies an action with no input and says that modules that use this 
MUST augment the input with a leaf and that the leaf must be named 
destination-address.

Is there any way that YANG can enforce either constraint?

Tom Petch


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

Re: [netmod] YANG action not allowed at root?

[Rob Wilton (rwilton)]

> -Original Message-
> From: netmod  On Behalf Of Martin Björklund
> Sent: 05 May 2020 11:30
> To: p...@hedeland.org
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG action not allowed at root?
> 
> Per Hedeland  wrote:
> > On 2020-05-05 11:55, Juergen Schoenwaelder wrote:
> > > On Tue, May 05, 2020 at 11:45:41AM +0200, Per Hedeland wrote:
> > >> On 2020-05-05 11:00, Martin Björklund wrote:
> > >>> Hi,
> > >>>
> > >>> If we were to redo YANG, I would prefer to have a single statement
> > >>> "operation", either on the top-level, or tied to a node.
> > >>
> > >> So, no rpc statement, and thereby no possibility to extend NETCONF
> > >> with new RPCs? (Or to be precise, YANG would extend NETCONF with
> > >> exactly one RPC, called "operation"?)
> > >>
> > >
> > > OLD
> > >
> > >   rpc foo {}
> > >   list something { action bar {} }
> > >
> > > NEW
> > >
> > >   operation foo {}
> > >   list something { operation bar {} }
> >
> > Yes, that much is obvious, my question was really about the NETCONF
> > encoding.
> >
> > > Syntactic sugar if you will.
> >
> > So you're saying that the NETCONF encoding of "operation foo" at the
> > top level would be an RPC called "foo"
> 
> Yes.
> 
> > while the NETCONF encoding of
> > "operation foo" elsewhere would be an RPC called "action"?
> 
> Yes; or called something else.
[RW] 

What is your reasoning for not wanting to unify the encoding?

E.g. always treat the encoding like action, but with the  node removed.

Regards,
Rob

[As an individual contributor]

> 
> 
> /martin
> 
> ___
> 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] YANG action not allowed at root?

[Martin Björklund]

"Rob Wilton (rwilton)"  wrote:
> [As an individual contributor]
> 
> Is this something that we should try and improve in a future revision
> of YANG?
> 
> E.g., deprecating either rpc or action, and allow the other one to be
> specified more flexibly?  Looking at the encodings it might make more
> sense to make rpc more generic and deprecate action.

No.


/martin



> 
> Regards,
> Rob
> 
> 
> > -Original Message-
> > From: netmod  On Behalf Of Juergen
> > Schoenwaelder
> > Sent: 05 May 2020 10:18
> > To: Martin Björklund 
> > Cc: netmod@ietf.org
> > Subject: Re: [netmod] YANG action not allowed at root?
> > 
> > On Tue, May 05, 2020 at 11:00:11AM +0200, Martin Björklund wrote:
> > > Hi,
> > >
> > > If we were to redo YANG, I would prefer to have a single statement
> > > "operation", either on the top-level, or tied to a node.
> > >
> > 
> > +1
> > 
> > /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

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

Re: [netmod] YANG action not allowed at root?

[Martin Björklund]

Per Hedeland  wrote:
> On 2020-05-05 11:55, Juergen Schoenwaelder wrote:
> > On Tue, May 05, 2020 at 11:45:41AM +0200, Per Hedeland wrote:
> >> On 2020-05-05 11:00, Martin Björklund wrote:
> >>> Hi,
> >>>
> >>> If we were to redo YANG, I would prefer to have a single statement
> >>> "operation", either on the top-level, or tied to a node.
> >>
> >> So, no rpc statement, and thereby no possibility to extend NETCONF
> >> with new RPCs? (Or to be precise, YANG would extend NETCONF with
> >> exactly one RPC, called "operation"?)
> >>
> >
> > OLD
> >
> >   rpc foo {}
> >   list something { action bar {} }
> >
> > NEW
> >
> >   operation foo {}
> >   list something { operation bar {} }
> 
> Yes, that much is obvious, my question was really about the NETCONF
> encoding.
> 
> > Syntactic sugar if you will.
> 
> So you're saying that the NETCONF encoding of "operation foo" at the
> top level would be an RPC called "foo"

Yes.

> while the NETCONF encoding of
> "operation foo" elsewhere would be an RPC called "action"?

Yes; or called something else.


/martin

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

Re: [netmod] YANG action not allowed at root?

[Per Hedeland]

On 2020-05-05 11:55, Juergen Schoenwaelder wrote:
> On Tue, May 05, 2020 at 11:45:41AM +0200, Per Hedeland wrote:
>> On 2020-05-05 11:00, Martin Björklund wrote:
>>> Hi,
>>>
>>> If we were to redo YANG, I would prefer to have a single statement
>>> "operation", either on the top-level, or tied to a node.
>>
>> So, no rpc statement, and thereby no possibility to extend NETCONF
>> with new RPCs? (Or to be precise, YANG would extend NETCONF with
>> exactly one RPC, called "operation"?)
>>
>
> OLD
>
>   rpc foo {}
>   list something { action bar {} }
>
> NEW
>
>   operation foo {}
>   list something { operation bar {} }

Yes, that much is obvious, my question was really about the NETCONF
encoding.

> Syntactic sugar if you will.

So you're saying that the NETCONF encoding of "operation foo" at the
top level would be an RPC called "foo", while the NETCONF encoding of
"operation foo" elsewhere would be an RPC called "action"?

--Per

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

Re: [netmod] status-description

[Rob Wilton (rwilton)]

[As an individual contributor]

I'm not keen on the idea of adding information related to 
deprecation/obsoletion to the data node description.

I think that this will cause problems for schema comparison, since tooling 
cannot easily understand the semantic difference in changes in description and 
hence will probably need extra annotations to indicate whether such changes are 
BC or NBC.  Whereas I think that such tooling could probably reasonably handle 
a description statement under status differently (e.g., perhaps treat all such 
status description changes as BC or insignificant changes).

However, I'm more sympathetic to the argument that this is not worth fixing 
now, and that this issue could be deferred to YANG.Next.

Regards,
Rob


> -Original Message-
> From: netmod  On Behalf Of Martin Björklund
> Sent: 04 May 2020 19:15
> To: Reshad Rahman (rrahman) 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] status-description
> 
> "Reshad Rahman (rrahman)"  wrote:
> > What are your thoughts on having description statement under status in
> > yang-next?
> 
> No problem!  In fact, "description" could be allowed under _any_
> statement...
> 
> 
> /martin
> 
> 
> > Is it the same as what you’ve stated on status-description
> > extension?
> >
> > I believe the extension is useful, although I do see the point made
> > that an extra statement leads to extra complexity. But using
> > description statement in yang-next should not be an issue?
> >
> > Regards,
> > Reshad.
> >
> > From: 'Andy Bierman' 
> > Date: Monday, May 4, 2020 at 1:32 PM
> > To: Martin Björklund 
> > Cc: Balazs Lengyel , "Reshad Rahman
> > (rrahman)" , NetMod WG 
> > Subject: Re: [netmod] status-description
> >
> >
> >
> > On Mon, May 4, 2020 at 9:38 AM Martin Björklund
> > mailto:mbj%2bi...@4668.se>> wrote:
> > Hi,
> >
> > Balázs Lengyel
> > mailto:balazs.leng...@ericsson.com>>
> > wrote:
> > > Hello,
> > > While status-description is not a critical part of this work, it is
> > > still useful, does not harm and is such a small addition, I do not
> > > understand why Martin objects.
> >
> > Every additional statement adds to the overall complexity.  As Jason
> > explained, this particular statement doesn't really help much.
> >
> >
> > +1
> >
> > We should not start down the path of specialized description
> > statements.
> >
> > I was part of a design team many years ago that was trying to
> > figure out why engineers were having so much trouble writing MIB
> > modules.
> > One significant finding: people disliked working on MIBs because there
> > were so
> > many special little rules (CLRs) for every little detail in the
> > module.
> >
> > IMO we are starting to make the same mistake with YANG.
> >
> >
> > /martin
> >
> > Andy
> >
> >
> > >
> > > So why is status-description good:
> > > Sometimes additional information is needed about deprecation,
> > > obsolescence:
> > > - is the item still fully functional?
> > > - when will its functionality be removed?
> > > - when will the schema node itself be removed?
> > > - is there a replacement or workaround that could/should be used
> instead
> > > - of deprecated/obsolete item?
> > > The text can be used by tools. Using a separate statement to provide
> > > this
> > > information is a method to separate the main description from this
> > > status specific description.
> > > In most cases both in the CLI and on NMS GUIs only the description is
> > > displayed.
> > > However there is a possibility  to display the status information too.
> > >
> > > In a way it is similar why we have separate description, contact,
> > > reference, organization statements under module.
> > > All these are just text, they could all be pushed under a single
> > > description statement. Tools can't act on these automatically, still
> > > it is good to separate them.
> > >
> > > Regards Balazs
> > >
> > > -Original Message-
> > > From: netmod mailto:netmod-boun...@ietf.org>>
> > > On Behalf Of Sterne, Jason
> > > (Nokia - CA/Ottawa)
> > > Sent: 2020. április 29., szerda 23:38
> > > To: Reshad Rahman (rrahman)
> > >
> mailto:40cisco@dmarc.ietf.org>>;
> > > Martin Björklund mailto:mbj%2bi...@4668.se>>;
> > > netmod@ietf.org
> > > Subject: Re: [netmod] status-description (WAS Re: mbj review of
> > > draft-verdt-netmod-yang-module-versioning-01)
> > >
> > > I think we could wait until YANG 2.0 to add a description to the
> > > status.
> > >
> > > Without a status description, an intelligent "YANG diff" of the models
> > > would produce this:
> > > a) new status deprecated statement
> > > b) change to a description
> > >
> > > With a status description we'd identify this:
> > > a) new status deprecated statement
> > > b) new status description
> > >
> > > In both cases it is (a) that identifies the most clear information.
> > >
> > > In both cases (b) provides no additional information that can be acted
> > > upon in an automated fashion. The tool could only flag that (b)
> > > 

Re: [netmod] YANG action not allowed at root?

[Per Hedeland]

On 2020-05-05 11:00, Martin Björklund wrote:
> Hi,
>
> If we were to redo YANG, I would prefer to have a single statement
> "operation", either on the top-level, or tied to a node.

So, no rpc statement, and thereby no possibility to extend NETCONF
with new RPCs? (Or to be precise, YANG would extend NETCONF with
exactly one RPC, called "operation"?)

--Per

> /martin
>
> Christian Hopps  wrote:
>> An action is defined as being something bound to a node. Talking about
>> actions that aren't bound to a node is talking about RPCs AFAICT. In
>> the server it just comes down to passing the bound node data in to the
>> function or not. Defining "unbound actions" to replace RPCs is just
>> different syntax for the same thing, right? Having 2 ways to do the
>> same thing wouldn't help make servers easier to implement (it would do
>> the opposite actually).
>>
>> Thanks,
>> Chris.
>>
>>> On Apr 30, 2020, at 11:50 AM, Sterne, Jason (Nokia - CA/Ottawa)
>>>  wrote:
>>>
>>> Yes - the intent was to address the limitation that an RPC can only be
>>> at root. Actions can be out in a tree & nicely associated with
>>> something (e.g. instead of having a pile of flat RPCs with long names
>>> that encode containers like reset-www-xxx-yyy-zzz-entity).
>>>
>>> But I don't really understand why we limited actions from being at the
>>> root. It prevents a strategy of implementing all operations in a
>>> server (some of which may be desirable at root for various reasons,
>>> some of which may be desirable in the tree) as actions.
>>>
>>> Why not allow this?
>>>
>>>module bar {
>>>  action do-stuff {
>>>input {
>>>  leaf iterations {
>>>type uint8;
>>>   }
>>> }
>>>  }
>>>}
>>>}
>>>
>>> Which could be called from NETCONF like this:
>>>
>>>  >>   xmlns="urn:ietf:params:xml:ns:netconf:base:1..0">
>>>
>>>  
>>>5
>>>  
>>>
>>>  
>>>
>>>
>>> Jason
>>>
>>> From: Reshad Rahman (rrahman) 
>>> Sent: Thursday, April 30, 2020 11:31 AM
>>> To: Sterne, Jason (Nokia - CA/Ottawa) ;
>>> netmod@ietf.org
>>> Subject: Re: [netmod] YANG action not allowed at root?
>>>
>>> I dont know the history on this but the intent is to have action tied
>>> to a data node.
>>>
>>> https://tools.ietf.org/html/rfc7950#section-7.15
>>>The difference between an action and an rpc is that an action is tied
>>>to a node in the datastore, whereas an rpc is not.  When an action is
>>>invoked, the node in the datastore is specified along with the name
>>>of the action and the input parameters.
>>>
>>> Regards,
>>> Reshad.
>>>
>>> From: netmod  on behalf of "Sterne, Jason
>>> (Nokia - CA/Ottawa)" 
>>> Date: Thursday, April 30, 2020 at 11:08 AM
>>> To: "netmod@ietf.org" 
>>> Subject: [netmod] YANG action not allowed at root?
>>>
>>> Hi all,
>>>
>>> I was a bit surprised to find this in section 7.15 of 7950 recently:
>>>
>>>Since an action cannot be defined at the top level of a module or in
>>>a "case" statement, it is an error if a grouping that contains an
>>>action at the top of its node hierarchy is used at the top level of a
>>>module or in a case definition.
>>>
>>> I realize that actions can be placed down in a schema tree (i.e. sit
>>> in the context of a container or list), but why is it phrased that
>>> they *must* be in a container?
>>>
>>> RPCs are limited to being at the root. I would have thought actions
>>> could be anywhere (root or down in the tree).
>>>
>>> Jason
>>>
>>>
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> ___
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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

Re: [netmod] YANG action not allowed at root?

[Robert Varga]

On 05/05/2020 11:00, Martin Björklund wrote:
> Hi,
> 
> If we were to redo YANG, I would prefer to have a single statement
> "operation", either on the top-level, or tied to a node.

Yeah, and we could introduce 'operation' as a generalized concept and
have rpc/action be just syntactic aliases for it in yang-next... :)

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG action not allowed at root?

[Juergen Schoenwaelder]

On Tue, May 05, 2020 at 11:00:11AM +0200, Martin Björklund wrote:
> Hi,
> 
> If we were to redo YANG, I would prefer to have a single statement
> "operation", either on the top-level, or tied to a node.
>

+1

/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] YANG action not allowed at root?

[Martin Björklund]

Hi,

If we were to redo YANG, I would prefer to have a single statement
"operation", either on the top-level, or tied to a node.


/martin

Christian Hopps  wrote:
> An action is defined as being something bound to a node. Talking about
> actions that aren't bound to a node is talking about RPCs AFAICT. In
> the server it just comes down to passing the bound node data in to the
> function or not. Defining "unbound actions" to replace RPCs is just
> different syntax for the same thing, right? Having 2 ways to do the
> same thing wouldn't help make servers easier to implement (it would do
> the opposite actually).
> 
> Thanks,
> Chris.
> 
> > On Apr 30, 2020, at 11:50 AM, Sterne, Jason (Nokia - CA/Ottawa)
> >  wrote:
> > 
> > Yes - the intent was to address the limitation that an RPC can only be
> > at root. Actions can be out in a tree & nicely associated with
> > something (e.g. instead of having a pile of flat RPCs with long names
> > that encode containers like reset-www-xxx-yyy-zzz-entity).
> >  
> > But I don't really understand why we limited actions from being at the
> > root. It prevents a strategy of implementing all operations in a
> > server (some of which may be desirable at root for various reasons,
> > some of which may be desirable in the tree) as actions.
> >  
> > Why not allow this?
> >  
> >module bar {
> >  action do-stuff {
> >input {
> >  leaf iterations {
> >type uint8;
> >   }
> > }
> >  } 
> >} 
> >} 
> >  
> > Which could be called from NETCONF like this:
> >  
> >   >   xmlns="urn:ietf:params:xml:ns:netconf:base:1..0">
> >
> >  
> >5
> >  
> >
> >  
> >  
> >  
> > Jason
> >  
> > From: Reshad Rahman (rrahman)  
> > Sent: Thursday, April 30, 2020 11:31 AM
> > To: Sterne, Jason (Nokia - CA/Ottawa) ;
> > netmod@ietf.org
> > Subject: Re: [netmod] YANG action not allowed at root?
> >  
> > I don’t know the history on this but the intent is to have action tied
> > to a data node.
> >  
> > https://tools.ietf.org/html/rfc7950#section-7.15
> >The difference between an action and an rpc is that an action is tied
> >to a node in the datastore, whereas an rpc is not.  When an action is
> >invoked, the node in the datastore is specified along with the name
> >of the action and the input parameters.
> >  
> > Regards,
> > Reshad.
> >  
> > From: netmod  on behalf of "Sterne, Jason
> > (Nokia - CA/Ottawa)" 
> > Date: Thursday, April 30, 2020 at 11:08 AM
> > To: "netmod@ietf.org" 
> > Subject: [netmod] YANG action not allowed at root?
> >  
> > Hi all,
> >  
> > I was a bit surprised to find this in section 7.15 of 7950 recently:
> >  
> >Since an action cannot be defined at the top level of a module or in
> >a "case" statement, it is an error if a grouping that contains an
> >action at the top of its node hierarchy is used at the top level of a
> >module or in a case definition.
> >  
> > I realize that actions can be placed down in a schema tree (i.e. sit
> > in the context of a container or list), but why is it phrased that
> > they *must* be in a container?
> >  
> > RPCs are limited to being at the root. I would have thought actions
> > could be anywhere (root or down in the tree).
> >  
> > Jason
> >  
> >  
> > ___
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG action not allowed at root?

[Christian Hopps]

An action is defined as being something bound to a node. Talking about actions 
that aren't bound to a node is talking about RPCs AFAICT. In the server it just 
comes down to passing the bound node data in to the function or not. Defining 
"unbound actions" to replace RPCs is just different syntax for the same thing, 
right? Having 2 ways to do the same thing wouldn't help make servers easier to 
implement (it would do the opposite actually).

Thanks,
Chris.

> On Apr 30, 2020, at 11:50 AM, Sterne, Jason (Nokia - CA/Ottawa) 
>  wrote:
> 
> Yes - the intent was to address the limitation that an RPC can only be at 
> root. Actions can be out in a tree & nicely associated with something (e.g. 
> instead of having a pile of flat RPCs with long names that encode containers 
> like reset-www-xxx-yyy-zzz-entity).
>  
> But I don't really understand why we limited actions from being at the root. 
> It prevents a strategy of implementing all operations in a server (some of 
> which may be desirable at root for various reasons, some of which may be 
> desirable in the tree) as actions.
>  
> Why not allow this?
>  
>module bar {
>  action do-stuff {
>input {
>  leaf iterations {
>type uint8;
>   }
> }
>  } 
>} 
>} 
>  
> Which could be called from NETCONF like this:
>  
> xmlns="urn:ietf:params:xml:ns:netconf:base:1..0">
>
>  
>5
>  
>
>  
>  
>  
> Jason
>  
> From: Reshad Rahman (rrahman)  
> Sent: Thursday, April 30, 2020 11:31 AM
> To: Sterne, Jason (Nokia - CA/Ottawa) ; 
> netmod@ietf.org
> Subject: Re: [netmod] YANG action not allowed at root?
>  
> I don’t know the history on this but the intent is to have action tied to a 
> data node.
>  
> https://tools.ietf.org/html/rfc7950#section-7.15
>The difference between an action and an rpc is that an action is tied
>to a node in the datastore, whereas an rpc is not.  When an action is
>invoked, the node in the datastore is specified along with the name
>of the action and the input parameters.
>  
> Regards,
> Reshad.
>  
> From: netmod  on behalf of "Sterne, Jason (Nokia - 
> CA/Ottawa)" 
> Date: Thursday, April 30, 2020 at 11:08 AM
> To: "netmod@ietf.org" 
> Subject: [netmod] YANG action not allowed at root?
>  
> Hi all,
>  
> I was a bit surprised to find this in section 7.15 of 7950 recently:
>  
>Since an action cannot be defined at the top level of a module or in
>a "case" statement, it is an error if a grouping that contains an
>action at the top of its node hierarchy is used at the top level of a
>module or in a case definition.
>  
> I realize that actions can be placed down in a schema tree (i.e. sit in the 
> context of a container or list), but why is it phrased that they *must* be in 
> a container?
>  
> RPCs are limited to being at the root. I would have thought actions could be 
> anywhere (root or down in the tree).
>  
> Jason
>  
>  
> ___
> 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