Re: [Lime] Comments on draft-ietf-lime-yang-connectionless-oam-01

[wangzitao <[e-mail]>]

Hi Greg,

Does you concern about item 2 ---“ tp-tools” need be “ro”?

And if yes, in 01 version ( https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-01.html), we have done below updates:


grouping tp-tools {

      description

        "Test Point OAM Toolset.";

      choice tools {

           default tools-empty;

           config false;

           description

           "choice of test point tools.

            Empty tools means based on Test Point it's implicit

            all OAM tools are present and no further configuration

            is supported.";
         ……

We add “config false” statement, therefore the entire “tools” attributes are modified to read-only (ro).

Best Regards!
-Michael
发件人: Greg Mirsky [mailto:[e-mail]]
发送时间: 2016年10月27日 12:57
收件人: wangzitao
抄送: [e-mail]
主题: Re: [Lime] Comments on draft-ietf-lime-yang-connectionless-oam-01

Hi Michael,
I'm looking at https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-01.html and still find the following:

      |        |  +--:(tools-ip)

      |        |  |  +--ro rfc792<https://tools.ietf.org/html/rfc792>?          boolean

      |        |  |  +--ro rfc4443<https://tools.ietf.org/html/rfc4443>?         boolean

      |        |  |  +--ro rfc4884<https://tools.ietf.org/html/rfc4884>?         boolean

      |        |  |  +--ro rfc5837<https://tools.ietf.org/html/rfc5837>?         boolean

      |        |  +--:(tools-bfd)

      |        |  |  +--ro rfc5881<https://tools.ietf.org/html/rfc5881>?         boolean

      |        |  |  +--ro rfc5883<https://tools.ietf.org/html/rfc5883>?         boolean

      |        |  |  +--ro rfc5884<https://tools.ietf.org/html/rfc5884>?         boolean

      |        |  |  +--ro rfc5885<https://tools.ietf.org/html/rfc5885>?         boolean

      |        |  +--:(tools-mpls)

      |        |  |  +--ro rfc4379<https://tools.ietf.org/html/rfc4379>?         boolean

      |        |  |  +--ro rfc4687<https://tools.ietf.org/html/rfc4687>?         boolean

      |        |  |  +--ro rfc4950<https://tools.ietf.org/html/rfc4950>?         boolean

      |        |  |  +--ro mpls-rfc5884?    boolean

      |        |  +--:(tools-pw)

      |        |     +--ro rfc5085<https://tools.ietf.org/html/rfc5085>?         boolean

      |        |     +--ro pw_rfc5885?      boolean

      |        |     +--ro rfc6423<https://tools.ietf.org/html/rfc6423>?         boolean

      |        |     +--ro rfc6310<https://tools.ietf.org/html/rfc6310>?         boolean

      |        |     +--ro rfc7023<https://tools.ietf.org/html/rfc7023>?         boolean



as result of the following:

        case tools-bfd {

          leaf rfc5881<https://tools.ietf.org/html/rfc5881> {

            type boolean;

                    description

                    "rfc5881<https://tools.ietf.org/html/rfc5881> supported.";

          }

          leaf rfc5883<https://tools.ietf.org/html/rfc5883> {

            type boolean;

                    description

                    "rfc5883<https://tools.ietf.org/html/rfc5883> supported.";

          }

          leaf rfc5884<https://tools.ietf.org/html/rfc5884> {

            type boolean;

                    description



                    "rfc5884<https://tools.ietf.org/html/rfc5884> supported.";

          }

          leaf rfc5885<https://tools.ietf.org/html/rfc5885> {

            type boolean;

                    description

                    "rfc5885<https://tools.ietf.org/html/rfc5885> supported.";

          }

        }



Am I looking at the wrong version?



Regards, Greg

On Wed, Oct 26, 2016 at 5:37 PM, wangzitao <[e-mail]<mailto:[e-mail]>> wrote:
Hi Greg and All,

In 00-version we already adopted Greg’s comments and modified the CL model. In 00-version, the “tools” be modified to “ro”, the “tools-mpls-tp” and “l3vpn case”  be removed.
And in 01 version we add a section to demonstrate the CL model’s capability and relationship with other exist models.
The attachment is a diff, and Greg’s comments is showed below.

Since I update the model in 00-version, maybe it cause misunderstanding.

Best Regards！
-Michael


Dear Authors, WG chairs, et. al,

I don't support adoption of the current version of the draft by the LIME WG. Below are my comments that may explain the reason for non-support:

•         the scope of the model isn’t clearly defined. The title suggests modeling OAM protocols that provide Fault Management (FM) and Performance Measurement (PM) in connectionless networks but the latter part seems absent in the proposed model. If only FM OAM is in the scope of this document, then I’d suggest updating the name of the draft;

•         the model uses references to the number of RFCs, e.g. RFC 5881,  within grouping tp-tools. If these are indication of OAM capability at a Test Point, then why is it rw as it seems to be more logical to be part of operational information, thus be ro;

•         the model still  refers to MPLS-TP even though WG agreed that MPLS-TP OM is an example of OAM for connection-oriented networks;

•         the model extensively refers to VPN cases, e.g. L3VPN, as example of connectionless network. I think that that yet has to be discussed as at the VPN layer network demonstrates characteristics of being connection-oriented;

•         the model does not reference, nor provides examples of use case of existing YANG data models of OAM protocols that are used in IP and IP/MPLS networks:

o   BFD (draft-ietf-bfd-yang);

o   LSP Ping (draft-zheng-mpls-lsp-ping-yang-cfg).



Perhaps another virtual interim meeting like one we had on May 27, 2016 would be helpful.



                Regards,

                                Greg

发件人: Lime [mailto:[e-mail]<mailto:[e-mail]>] 代表 Greg Mirsky
发送时间: 2016年10月26日 23:01
收件人: [e-mail]<mailto:[e-mail]>
主题: [Lime] Comments on draft-ietf-lime-yang-connectionless-oam-01

Dear All,
the -01version has great discussion of how the proposed YANG model may be changed but doesn't change the model itself. And thus all my comments from the adoption call remain to be addressed through changes to the model itself.

Regards,
Greg