Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

Hi Adrian and Tianran, > On Feb 14, 2017, at 5:23 AM, Adrian Farrel wrote: > > Hi Tianran, > > Nice summary. > > I think some of the confusion may be that > draft-ietf-netmod-yang-model-classification shows "Network Service YANG > Modules" on the interface between

Re: [netmod] Yang 1.1 change: Allow type "empty" in a key.

Hi, It means exactly what the summary says. In YANG 1.0 (RFC 6020) we have: A leaf that is part of the key can be of any built-in or derived type, except it MUST NOT be the built-in type "empty". and in YANG 1.1 (RFC 7950) we have: A leaf that is part of the key can be of any

Re: [netmod] Module tags

On 14/02/2017 14:08, Christian Hopps wrote: Robert Wilton writes: Hi tags draft authors, On 09/02/2017 12:28, Lou Berger wrote: I'm personally more excited by the use of tags as additional module meta-data accessible via yang library. But also see no reason to preclude

Re: [netmod] Module tags

Robert Wilton writes: > Hi tags draft authors, > On 09/02/2017 12:28, Lou Berger wrote: >> >> I'm personally more excited by the use of tags as additional module >> meta-data accessible via yang library. But also see no reason to >> preclude this possible (even if unlikely)

Re: [netmod] circular chains - imports vs includes

> On 14 Feb 2017, at 14:30, Martin Ciglan -X (mciglan - PANTHEON TECHNOLOGIES > at Cisco) wrote: > > Hi all > > RFC says: > > There MUST NOT be any circular chains of imports. For example, if module "a" > imports module "b", "b" cannot import "a". > > Does same apply to

Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11

Hi, I just posted draft-ietf-netmod-syslog-model-12 which addresses the concerns that Alex and Andy raised in their review of draft 11. Changes from draft 11 to draft 12 can be seen at this link:

[netmod] circular chains - imports vs includes

Hi all RFC says: There MUST NOT be any circular chains of imports. For example, if module "a" imports module "b", "b" cannot import "a". Does same apply to includes too? Thanks Martin ___ netmod mailing list netmod@ietf.org

[netmod] I-D Action: draft-ietf-netmod-syslog-model-12.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language of the IETF. Title : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran

[netmod] YANG - valid enumeration names

Hi all RFC says: All assigned names in an enumeration MUST be unique.? We're wondering here, if something like this is valid YANG snippet: ... leaf foo { type enumeration { enum Foo; enum foo; } } ... Thanks for help Martin ___

Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

Hi Tianran, Nice summary. I think some of the confusion may be that draft-ietf-netmod-yang-model-classification shows "Network Service YANG Modules" on the interface between OSS/BSS and the network. But the "customer service model" is at a different place in the hierarchy as shown in Figure 4

Re: [netmod] [OPSAWG] Question on draft-ietf-netmod-yang-model-classification

I would prefer to have all terms people find agreement on in a single document. /js On Tue, Feb 14, 2017 at 09:54:10AM +, Tianran Zhou wrote: > Hi, > > Based on the discussion, here I try to clean up the confusion of the two I-Ds. > > [draft-ietf-netmod-yang-model-classification]

Re: [netmod] Module tags

On 13/02/2017 18:19, Kent Watsen wrote: As for a concrete use-case, would something like this be helpful for a server to indicate which datastores a module is supported in? I'm not sure. I would probably prefer to see the two kept separate, but it may depend on what the scope of modules tags

Re: [netmod] Question on draft-ietf-netmod-yang-model-classification

Hi, Based on the discussion, here I try to clean up the confusion of the two I-Ds. [draft-ietf-netmod-yang-model-classification] classifies the yang modules into "Network Service YANG Module" and the "Network Element YANG Module". And usually, it uses "service module" to imply the "Network

[netmod] 答复: Conflicting usage scenario for "invalid-value" error-tag between RFC 6241 & RFC 6020

Thanks Kent. My personally opinion is: it might be RFC6241’s errata. The reasons are: 1. RFC6020/7950 is more clear than RFC6241 for the usage of error-tag. And it is a MUST rule for Payload Parsing in YANG 1.0 and YANG 1.1. 2. RFC6241 is just give it as the example when define the well-known