Subject: Re: [netmod] draft-ietf-netmod-yang-model-classification-01

From: "Kenneth Kerpez (New Jersey)" <[email-masked]>
Date: Mon, 4 Apr 2016 19:32:06 +0000

The draft-ietf-netmod-yang-model-classification-01 could also consider a naming convention. In the Broadband Forum (BBF) we name files bbf-module-name-submodule.yang. ietf-name.yang is common. So perhaps <sdo>-<module/submodule name> is a convention.

Ken Kerpez
ASSIA, Inc.
Cell +1 908 432-1600
Landline +1908 876-4270

-------- Original message --------
From: [email-masked]
Date: 04/04/2016 2:57 PM (GMT-05:00)
To: [email-masked]
Subject: netmod Digest, Vol 97, Issue 5

Send netmod mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/netmod
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of netmod digest..."

Today's Topics:

   1. I-D Action:
      draft-ietf-netmod-yang-model-classification-01.txt
      ([email-masked])
   2. kw review of draft-liu-netmod-yang-schedule (Kent Watsen)
   3. actions and keyless lists (Ladislav Lhotka)
   4. a few editorial comments on structural-mount-02
      (Sterne, Jason (Nokia - CA))
   5. Re: actions and keyless lists (Andy Bierman)

----------------------------------------------------------------------

Message: 1
Date: Mon, 04 Apr 2016 04:50:17 -0700
From: [email-masked]
To: <[email-masked]>
Cc: [email-masked]
Subject: [netmod] I-D Action:
        draft-ietf-netmod-yang-model-classification-01.txt
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

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           : YANG Model Classification
        Authors         : Dean Bogdanovic
                          Benoit Claise
                          Carl Moberg
        Filename        : draft-ietf-netmod-yang-model-classification-01.txt
        Pages           : 9
        Date            : 2016-04-04

Abstract:
   The YANG [RFC6020] data modeling language is currently being
   considered for a wide variety of applications throughout the
   networking industry at large.  Many standards-defining organizations
   (SDOs), open source software projects, vendors and users are using
   YANG to develop and publish models of configuration, state data and
   operations for a wide variety of applications.  At the same time,
   there is currently no well-known terminology to categorize various
   types of YANG models.

   A consistent terminology would help with the categorization of
   models, assist in the analysis the YANG data modeling efforts in the
   IETF and other organizations, and bring clarity to the YANG-related
   discussions between the different groups.

   This document describes a set of concepts and associated terms to
   support consistent classification of YANG models.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-model-classification-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

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

------------------------------

Message: 2
Date: Mon, 4 Apr 2016 14:54:08 +0000
From: Kent Watsen <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [netmod] kw review of draft-liu-netmod-yang-schedule
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

[As a contributor]

While it's clear what this document is trying to achieve at a high level, it is unclear why the solution is needed.   A "motivation" section explaining why this should be standardized would be nice.

When reading this draft, I was reminded of my long expired draft https://tools.ietf.org/html/draft-kwatsen-conditional-enablement-00.  That draft provided a more general solution, in that it enabled sub-trees to be enabled/disabled for any reason.  It was primarily focused on supporting comments, but it did call out that expressions could include time, though it didn't flush out that thought to any extent.

Other than draft-kwatsen-conditional-enablement being a more generic solution, another difference is that this draft enables the module-designer to specify where in the data model the grouping is used, whereas my old draft let the client enabled/disabled nodes anywhere in the data model, potentially producing nonsensical results, though we have to assume that the server would fail any invalid results.

Regarding this solution, I have some specific questions:

1) why is the "schedule" node a list?  How is a list to be processed?   Are there any overlapping issues?

2) does the "schedule-id" leaf have any useful purpose other than being the list's key?

3) the "schedule-duration" node's pattern matches XSD's "duration" type, is it the intent to process it as such?

4) the draft-ietf-netconf-server-model draft originally had a duration-like value, but the WG consensus was at the time was to instead use an unsigned integer value with a "units" value (e.g., seconds, minutes, etc.).  The claim was that, when large values where needed (e.g., 3600-seconds instead of 1-hour), that the client could always do the math.  Any thoughts on that?

5) are there any issues with the "repeat-interval" node?  I'm specifically thinking about the interval being expressed in terms of hours and days in the context of daylight savings and leap year...

Nit: some examples in the draft would've been nice.

Thanks,
Kent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/netmod/attachments/20160404/03fad290/attachment.html>

------------------------------

Message: 3
Date: Mon, 4 Apr 2016 14:48:19 -0300
From: Ladislav Lhotka <[email-masked]>
To: NETMOD WG <[email-masked]>
Subject: [netmod] actions and keyless lists
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

Hi,

in the thread [1], we agreed that it is necessary to prevent actions (and notifications) being defined on a state data node that is (or its ancestor is) a list for which no keys are defined because then the instance to which the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't address this situation though. Is it still possible to add a corresponding text to sections 7.15 and 7.16?

Lada

[1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

------------------------------

Message: 4
Date: Mon, 4 Apr 2016 18:24:14 +0000
From: "Sterne, Jason (Nokia - CA)" <[email-masked]>
To: netmod WG <[email-masked]>
Subject: [netmod] a few editorial comments on structural-mount-02
Message-ID:
        <[email-masked]>

Content-Type: text/plain; charset="us-ascii"

Hello,

A couple of minor points for the structural mount draft that I noticed while reading it recently:

The XML instance data in Appendix B seems to have <root> inside the <transport> context but that doesn't match the YANG model above it.

It would be great to show an example for section 3.2.

Regards,
Jason

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/netmod/attachments/20160404/f73fc059/attachment.html>

------------------------------

Message: 5
Date: Mon, 4 Apr 2016 11:57:44 -0700
From: Andy Bierman <[email-masked]>
To: Ladislav Lhotka <[email-masked]>
Cc: NETMOD WG <[email-masked]>
Subject: Re: [netmod] actions and keyless lists
Message-ID:
        <[email-masked]>
Content-Type: text/plain; charset="utf-8"

Hi,

I do not see any reason to prohibit this use of action-stmt
or notification-stmt.  If the list has no keys then there is
no need to distinguish instances because the data model defines
no such semantics.

What breaks if this is allowed?

Andy

On Mon, Apr 4, 2016 at 10:48 AM, Ladislav Lhotka <[email-masked]> wrote:

> Hi,
>
> in the thread [1], we agreed that it is necessary to prevent actions (and
> notifications) being defined on a state data node that is (or its ancestor
> is) a list for which no keys are defined because then the instance to which
> the action is tied may not be uniquely defined. The rfc6020bis-11 doesn't
> address this situation though. Is it still possible to add a corresponding
> text to sections 7.15 and 7.16?
>
> Lada
>
> [1] https://www.ietf.org/mail-archive/web/netmod/current/msg14936.html
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/netmod/attachments/20160404/d53c2f7b/attachment.html>

------------------------------

Subject: Digest Footer

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

------------------------------

End of netmod Digest, Vol 97, Issue 5
*************************************

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Apr 2016 21:54:40 +0200

> The draft-ietf-netmod-yang-model-classification-01 could also consider a naming convention. In the Broadband Forum (BBF) we name files bbf-module-name-submodule.yang. ietf-name.yang is common. So p…

See RFC 6020 section 7.1:

   It is RECOMMENDED to choose
   module names that will have a low probability of colliding with
   standard or other enterprise modules and submodules, e.g., by using
   the enterprise or organization name as a prefix for the module name.

RFC 6020bis says in section 5.1:

   Developers of YANG modules and submodules are RECOMMENDED to choose
   names for their modules that will have a low probability of colliding
   with standard or other enterprise modules, e.g., by using the
   enterprise or organization name as a prefix for the module name.
   Within a server, all module names MUST be unique.

So yes, using a prefix like bbf- for BBF module names is a good idea.

/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/>