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

["Kenneth Kerpez (New Jersey)" <[e-mail]>]

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 [phone]
Landline [phone]


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

Send netmod mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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
      ([e-mail])
   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: [e-mail]
To: <[e-mail]>
Cc: [e-mail]
Subject: [netmod] I-D Action:
        draft-ietf-netmod-yang-model-classification-01.txt
Message-ID: <[e-mail]>
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 <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: [netmod] kw review of draft-liu-netmod-yang-schedule
Message-ID: <[e-mail]>
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 <[e-mail]>
To: NETMOD WG <[e-mail]>
Subject: [netmod] actions and keyless lists
Message-ID: <[e-mail]>
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)" <[e-mail]>
To: netmod WG <[e-mail]>
Subject: [netmod] a few editorial comments on structural-mount-02
Message-ID:
        <[e-mail]>

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 <[e-mail]>
To: Ladislav Lhotka <[e-mail]>
Cc: NETMOD WG <[e-mail]>
Subject: Re: [netmod] actions and keyless lists
Message-ID:
        <[e-mail]>
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 <[e-mail]> 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
> [e-mail]
> 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
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod


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

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