Subject: [netmod] Clarification: No inline operation definition?

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 29 Jul 2008 10:06:04 -0400

Hi

In NETMOD, we don't really have a requirement to support definition of
NETCONF protocol operations inline in a data model do we? It wasn't
clear in reading the section in the yang document whether that was
encouraged or forbidden.

Just in case it is permitted, I just want to say that I don't think it
adds any value to be able to do this and it seems to discourage re-use
of verbs across different types of data, which is bad. I don't think we
really need 47 definitions of the 'reboot' operation, for example.

Sharon Chisholm
Nortel 
Ottawa, Ontario
Canada
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Jul 2008 16:24:10 +0200

> clear in reading the section in the yang document whether that was

Can you clarify please what the issue is? Which section of the YANG
document should I look at?

> really need 47 definitions of the 'reboot' operation, for example.

I need some help to understand the issue.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2008 07:33:28 -0700

> I need some help to understand the issue.

Me too.

The YANG language allows the definition of any RPC method
(conforming to the YANG data types).  If you choose to
write 47 versions of the reboot operation, or if you choose
to define inline data instead of reusable groupings, this is not
a problem with the language, but rather the people using
the language.

> /js

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 29 Jul 2008 10:47:24 -0400

Hi

I am talking about section 4.2.9 I guess.

My point is, I don't think we don't need the ability to define
operations inline, so why do we have it? What use case does this
support?

It would also be nice and human-friendly if it was easier to do the
right thing (common operations) then the wrong thing (47 different
reboot operations).

I propose we just allow for global operations.

Sharon 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 10:33 AM
To: Chisholm, Sharon (CAR:ZZ00); [email-masked]
Subject: Re: [netmod] Clarification: No inline operation definition?

Juergen Schoenwaelder wrote:
>> In NETMOD, we don't really have a requirement to support definition 
>> of NETCONF protocol operations inline in a data model do we? It 
>> wasn't clear in reading the section in the yang document whether that

>> was encouraged or forbidden.
> 
>> Just in case it is permitted, I just want to say that I don't think 
>> it adds any value to be able to do this and it seems to discourage 
>> re-use of verbs across different types of data, which is bad. I don't

>> think we really need 47 definitions of the 'reboot' operation, for
example.

Me too.

The YANG language allows the definition of any RPC method (conforming to
the YANG data types).  If you choose to write 47 versions of the reboot
operation, or if you choose to define inline data instead of reusable
groupings, this is not a problem with the language, but rather the
people using the language.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2008 07:59:24 -0700

> operations inline, so why do we have it? What use case does this

I don't understand.
Every document the NETCONF WG creates seem to
define new RPC methods in it.  Vendor RPC methods
are also important.

I'll repeat my argument for keeping rpc (and notification)
in the YANG language:

   - The DM reader must understand the entire API embodied
     in the NETCONF data model module.  This applies to
     config data, monitoring data, event notifications,
     and protocol verbs defined to manage some network service.

   - There needs to be 1 data modeling language to define
     the entire data model API for consistency and coherence.

   - If XSD or RNG is user-friendly enough to define part of this
     API, then they are good enough for all of it, and we don't need
     YANG at all.  (Given that lack of expertise demonstrated in either
     language by the IETF, I think we need YANG.)

> I propose we just allow for global operations.

We do not have local operations in YANG.
The rpc-stmt can only appear at the top-level
(body-stmts).

Andy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 29 Jul 2008 11:04:44 -0400

Hi

Ok. I did call the thread 'clarification' and it sounds like you have
just confirmed yang does not support inline operations?

Let me give an example of what I don't want to see to ensure I'm clear
(sorry, XSD is my pseudo code)

<element name="bgp">
  <element name="routes"/>  
  <element name="statistics" />
  <element name="configuration> /> 
  <element name="rpcOperation_Foo"/>
</element>

Sharon

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Tuesday, July 29, 2008 10:59 AM
To: Chisholm, Sharon (CAR:ZZ00)
Cc: [email-masked]
Subject: Re: [netmod] Clarification: No inline operation definition?

> operations inline, so why do we have it? What use case does this 

I don't understand.
Every document the NETCONF WG creates seem to define new RPC methods in
it.  Vendor RPC methods are also important.

I'll repeat my argument for keeping rpc (and notification) in the YANG
language:

We do not have local operations in YANG.
The rpc-stmt can only appear at the top-level (body-stmts).

Andy

> The YANG language allows the definition of any RPC method (conforming 
> to the YANG data types).  If you choose to write 47 versions of the 
> reboot operation, or if you choose to define inline data instead of 
> reusable groupings, this is not a problem with the language, but 
> rather the people using the language.
> 
> 
>> /js
>>
> 
> Andy
> 
> 
> 
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 29 Jul 2008 17:26:55 +0200

>   <element name="rpcOperation_Foo"/>

No, this will never happen. The rpc and notification statements in YANG
describe something else than the configuration schema tree. My DSDL
translator currently ignores them but I want to discuss better options.

Lada

-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2008 08:28:01 -0700

>   <element name="rpcOperation_Foo"/>

Thanks for pointing out how XSD and RNG model the XML language
itself, and nothing more.  Except for your naming conventions,
I would have no idea which XSD construct was the RPC method
in the bunch.

> </element>

body-stmts             = *((extension-stmt /
                             typedef-stmt /
                             grouping-stmt /
                             data-def-stmt /
                             rpc-stmt /
                             notification-stmt) stmtsep)

data-def-stmt          = container-stmt /
                          leaf-stmt /
                          leaf-list-stmt /
                          list-stmt /
                          choice-stmt /
                          anyxml-stmt /
                          uses-stmt /
                          augment-stmt

See how rpc-stmt is not in data-def-stmt?
It can never appear inside another definition.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Jul 2008 08:32:52 -0700

> translator currently ignores them but I want to discuss better options.

Look at the XSD output from yangdump or pyang.
The NETCONF XSD has hooks to 'connect' any RPC content
to its location in the protocol PDUs.  Ditto for the
Notifications XSD.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 30 Jul 2008 13:09:13 +0200

Hello,
Netmod charter does not specify all the details of YANG (naturally). It does not mention 
inline operations either. Whether we need some new feature is up to the working group (as 
always) as long as we don't change something that is explicitly stated in the charter.
Balazs