Subject: [netmod] I-D Action: draft-ietf-netmod-iana-if-type-06.txt

From: [email-masked]
Date: Fri, 19 Apr 2013 04:26:42 -0700

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 Working Group of the IETF.

	Title           : IANA Interface Type and Address Family YANG Modules
	Author(s)       : Martin Bjorklund
	Filename        : draft-ietf-netmod-iana-if-type-06.txt
	Pages           : 50
	Date            : 2013-04-19

Abstract:
   This document defines the initial versions of the iana-if-type and
   iana-afn-safi YANG modules.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-iana-if-type

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-netmod-iana-if-type-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-iana-if-type-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 19 Apr 2013 14:04:47 +0200

Hello,
 From the YANG RFC about the augment statement:
"If the target node is in another module, then nodes added by the
    augmentation MUST NOT be mandatory nodes (see Section 3.1)."

Why?
We have a datamodel in 2 parts YAM-A and YAM-B defined in two separate 
YANG Modules (YAMs).
The node must support A and may support B. However if it supports B, it 
must have at least one mandatory container/list-entry on it's top level. 
This is not allowed in YANG.

IMHO it is a perfectly valid use case, that if you indicate support 
function B the system shall automatically generate the top level 
container and all configuration updates must leave it there.
Implicitly you always have the possibility NOT to support YAM-B in which 
case its contents become non-mandatory.

How do you model this in YANG?

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 19 Apr 2013 14:21:38 +0200 (CEST)

Hi,

Balazs Lengyel <[email-masked]> wrote:
> The node must support A and may support B. However if it supports B,
> it must have at least one mandatory container/list-entry on it's top
> level. This is not allowed in YANG.

Sorry but I do not understand.  What does augmentation have to do with
this?

YANG allows mandatory nodes on the top-level.

The reason for the augmentation rule is that an augment must not break
a client that doesn't understand the augmentation.  Such a client will
never be able to add the mandatory nodes...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Apr 2013 08:13:26 -0700

> YANG allows mandatory nodes on the top-level.
We never came to an agreement as to what this meant.
As I recall, Phil thought this did not even make sense,
since 'mandatory' refers to "the client must create it".
Others think mandatory means "the node must exist".

Unless the server creates a top-level mandatory node,
as soon as the module is loaded, the running config
is invalid according to YANG.

What the server does at this point is also controversial.
Either continue, or shut down and become a brick, or
maybe reject the module load request?

Then there are the pathological YANG modules that,
either alone or combined with other modules, produce
a combination of validation constraints that can never be met.
If the server is smart enough to detect them in the first place,
then what to do about this corner-case as well?

> never be able to add the mandatory nodes...

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 19 Apr 2013 17:14:11 +0200

Hello,
In our case the top level object is systemCreated (the node creates it 
itself), so unprepared clients are not troubled.
regards Balazs