Subject: [netmod] module revision and source

From: Andy Bierman <[email-masked]>
Date: Fri, 01 Aug 2008 19:42:12 -0700

Hi,

1) module revision

I did not hear if revision-stmt is now mandatory or not.
IMO, this is a good idea.  The description within it is
optional, so the burden on the writer is just:

    revision yyyy-mm-dd;

2) module source

Juergen mentioned that the revision description clause
is good for finding the source document that the module
was extracted from.  I agree.

I think the module reference field should be utilized
for this purpose:

    module yang-types {

       ...
       description "...";
       reference "draft-schoenw-netmod-yang-types-01.txt";
       ...

    }

IMO, a module description and reference
should be required for all IETF YANG modules.

Andy

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 02 Aug 2008 22:46:00 +0200 (CEST)

> I did not hear if revision-stmt is now mandatory or not.

My take on this is that it's obvious that regardless of what the YANG
spec says, IETF will require a revision for IETF modules.  I think it
should be mandatory in YANG only if it is necessary - for example if
we do import by revision.  So  I would rather not decide on this
particular issue stand-alone.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 02 Aug 2008 18:38:49 -0700

> particular issue stand-alone.

There are several categories of Clever Little Rules that
one can define for NETMOD (not a complete list obviously):

1) needed for the language to work:
    - set of prefixes used within a module must be unique
    - set of module names to be unique

2) needed for the mapping to XML to work:
    - set of namespace URIs used within an agent needs to be unique
    - YANG names must be legal XML element names
    - set of sibling nodes within the same namespace must be unique

3) needed for multi-vendor interoperability:
    - unique (within the module), ascending revision ID
      for each module release
    - data-def-stmt description clauses required
    - reference clauses whenever relevant
    - as many machine-readable clauses as relevant

4) needed for the mapping to XSD and DSDL to work:
    - pattern matching rules
    - default namespace in XPath 1.0

5) desired for the mapping to XML to favor simpler implementation:
    - key leaf nodes encoded first in list elements
    - no deep keys allowed
    - no XSD list data type
    - no XML attributes allowed

6) desired for better SMIv2 compatibility:
    - data type and TEXTUAL-CONVENTION reuse
    - OBJECT-TYPE and NOTIFICATION-TYPE reuse

7) desired for better security features:
    - standard instance naming with XPath

8) desired for 'safer' vendor extensibility:
    - augment guidelines (cannot break the contract, etc.)?
    - use capabilities to identify a group of extensions defining
      some feature set

Andy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 3 Aug 2008 14:58:21 +0200

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Martin Bjorklund
> Sent: Saturday, August 02, 2008 11:46 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [netmod] module revision and source
> 
> My take on this is that it's obvious that regardless of what 
> the YANG spec says, IETF will require a revision for IETF 
> modules.  I think it should be mandatory in YANG only if it 
> is necessary - for example if we do import by revision.  So  
> I would rather not decide on this particular issue stand-alone.
> 
> 
> /martin

This was one of the instances where I was surprised by the arguments in
the discussions last Friday. I hope that all participants in the NETMOD
effort are aware about the discussions about  SMIv2->XSD translations
vs. SMIv2->YANG->XSD translations and such. Even if REVISION clauses do
not directly generate XML, it is obvious that we need to define a
revision-stmt to be mandatory, even if it was only for compatibility of
translation and comparison of versioning. 

As a more general statement I would suggest that without entering in
limitations where it makes no sense, design decisions take SMIv2
compatibility as one of the principal objectives in YANG. 

Dan

---

From: Andy Bierman <[email-masked]>
Date: Sun, 03 Aug 2008 10:29:20 -0700

> compatibility as one of the principal objectives in YANG. 

One limitation:  There will no attempt whatsoever to provide
for YANG to SMIv2 translation.  This is a 1-way bus ride.

I am concerned about the long-term coexistence, but mostly
at the data type and 'leaf object' level for now.  It's not
as if this XML data type situation jumped up overnight.
XSD and SMIv2 have both existed for a long time.
Why is there such urgency now to create a very partial,
sub-optimal solution, instead of working on a real solution?

Consider the possibility that a multi-protocol application
will need to reconcile data from SMIv2 over SNMP, SMIv2 over NETCONF,
SMIv2-like over NETCONF, and SMIv2-like2-over-XML.
Do you really think this solution approach is going to
work in the long-run?  Is there any shared vision whatsoever
of what the multi-protocol network management end-state
even looks like?

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 05 Aug 2008 18:02:23 +0200

Hello,
I understand that SMI translation needs a revision clause, but my little playground module 
inside ericsson might not. On the other hand adding one extra line is not worth the time 
arguing about. So I would vote mandatory.
Balazs