Subject: [Lime] WGLC: draft-ietf-lime-yang-oam-model-08

From: Ron Bonica <[email-masked]>
Date: Thu, 19 Jan 2017 16:13:56 +0000

Folks,

This message begins a WGLC on draft-ietf-lime-yang-oam-model-08. Please submit comments by February 3, 2017.

                                           Ron

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 24 Jan 2017 23:38:07 -0000

Hi,

I read through this document again and think it is ready for publication.

Here are some minor things to ix along the way.

Thanks,
Adrian
===
You might sort out the line lengths.
---
Abstract is missing a final period.
---
Some of the references in sections 1 8 and 9 seem to be duplicated.
---
The last sentence of section 2 presumably belongs with the first 
paragraph.
---
The text in section 2 that defines the notation used in the trees that
are found in this document is useful, but I suspect it of being generic.
(It would be nice if this was in a separate document so that everyone
can reference it, but that is not the job of these authors or this WG.)

I did find several parts of the text confusing and I wondered whether:
- you can can drop the statuses that are not used in this document
  (I think there are no deprecated or obsoleted objects)
- add the other flags that are used (I see, "w" although I am surprised
  to find what is effective a write-only object so perhaps that is an
  error?)
- give simple examples (because "x" and "-x" may be hard to distinguish)
---
In 4 you have
   Under each MA, there can be two or more MEPs (Maintenance Association
   End Points).
But your primary expansion of MEP in section 2.1 is different.
---
Sections 1 and 2.1 use "RPC" the rest of the document uses "rpc"
---
Section 4.4 has
   Please refer to Section 4 for the complete
   data hierarchy
which is a bit odd given that we are in the middle of section 4.
---
Not asking you to do it, but why after the whole of section 4, why are
there no "fragments" in section 4.5?
---
A number of description clauses need to begin with capital letters.
---
loss-of-continuity refers to the receiving MEP's configured CC-V
reception period.  I cannot find where I can read the value of that.
---
Any reason why sometimes

      leaf cc-transmit-interval {
        type Interval;
        description
          "Interval between echo requests";
      }

and sometimes

      leaf interval {
        type Interval;
        description
          "Interval between echo requests";
      }
---
Why is there a minimum packet-size of 64 octets?
Why can't I send smaller CC and CV packets?
---
Stray text "YANG module of OAM" right at the end of the module?
---
6.2 has MEPID and MEP-ID and MEP ID.
---
6.2 has
   In this document we propose to extend the range to 0 to
   65535.
s/propose to extend/extend/
---
6.3 has "MAID" unexpanded.  This is probably just the ID of the MA, but
...
---
Section 7 has
   This section demonstrates the usability of the connection-oriented
   YANG OAM data model to various connection-oriented OAM technologies,
   e.g., TRILL and MPLS-TP.
This should probably be
   This section demonstrates the applicability of the connection-oriented
   YANG OAM data model to TRILL and MPLS-TP.
---
I think the affiliations and emails of the Contributors and Authors need
to be double-checked.

---

From: wangzitao <[email-masked]>
Date: Wed, 25 Jan 2017 02:22:02 +0000

Thank Adrian for these valuable comments, please find my reply inline.

Best Regards!
-Michael

-----邮件原件-----
发件人: Adrian Farrel [mailto:[email-masked]] 
发送时间: 2017年1月25日 7:38
收件人: 'Ron Bonica'; [email-masked]; [email-masked]
主题: RE: [Lime] WGLC: draft-ietf-lime-yang-oam-model-08

Hi,

Thanks,
Adrian
===
You might sort out the line lengths.
[Michael]: Yes, I can fix it.

---
Abstract is missing a final period.
[Michael]: Thanks, I will fix it in next version.
---
Some of the references in sections 1 8 and 9 seem to be duplicated.
[Michael]: Yes, I will fix it.
---
The last sentence of section 2 presumably belongs with the first paragraph.
[Michael]: Indeed, it need to be fixed.
---
The text in section 2 that defines the notation used in the trees that are found in this document is useful, but I suspect it of being generic.
(It would be nice if this was in a separate document so that everyone can reference it, but that is not the job of these authors or this WG.)

I did find several parts of the text confusing and I wondered whether:
- you can can drop the statuses that are not used in this document
  (I think there are no deprecated or obsoleted objects)
[Michael]: Yep, the deprecated/obsolete statement is not used. Moving this flag from the section make sense for me.

- add the other flags that are used (I see, "w" although I am surprised
  to find what is effective a write-only object so perhaps that is an
  error?)
[Michael]: Agree.
- give simple examples (because "x" and "-x" may be hard to distinguish)
[Michael]: Agree.
---
In 4 you have
   Under each MA, there can be two or more MEPs (Maintenance Association
   End Points).
But your primary expansion of MEP in section 2.1 is different.
[Michael]: Yes, it need to be fixed.
---
Sections 1 and 2.1 use "RPC" the rest of the document uses "rpc"
[Michael]: Yes, it need to be synchronized. I'd like to fix it.
---
Section 4.4 has
   Please refer to Section 4 for the complete
   data hierarchy
which is a bit odd given that we are in the middle of section 4.
[Michael]: Yes, it seems odd, I think it can be modified to "Please refer to Section 4.5 for the complete
   data hierarchy".  
---
Not asking you to do it, but why after the whole of section 4, why are there no "fragments" in section 4.5?
---
A number of description clauses need to begin with capital letters.
[Michael]:You are right, I will fix it in next version.
---
loss-of-continuity refers to the receiving MEP's configured CC-V reception period.  I cannot find where I can read the value of that.
[Michael]: I'd like to discuss with my coauthor to decide whether we need this attributes
---
Any reason why sometimes

and sometimes

      leaf interval {
        type Interval;
        description
          "Interval between echo requests";
      }
[Michael]: according to previous discussion, for continuity check, there is a little of difference on same terminology For example:
for mpls-tp, there are transmit-interval and receive-interval, therefore, we defined this attribute as cc-transmit-interval.
---
Why is there a minimum packet-size of 64 octets?
Why can't I send smaller CC and CV packets?
[Michael]: I agree with your concern, especially consider for future technologies, restrict the minimum packet-size as 64 octets seems not good idea.
I would like to discuss with coauthor and may be change it in next version. 
---
Stray text "YANG module of OAM" right at the end of the module?
[Michael]: yes, it need to be fixed.
---
6.2 has MEPID and MEP-ID and MEP ID.
[Michael]: Yes, it need to be synchronized. 
---
6.2 has
   In this document we propose to extend the range to 0 to
   65535.
s/propose to extend/extend/
[Michael]: Agree.
---
6.3 has "MAID" unexpanded.  This is probably just the ID of the MA, but ...
[Michael]: Yes, you are right, I would like to fix it.
Section 7 has
   This section demonstrates the usability of the connection-oriented
   YANG OAM data model to various connection-oriented OAM technologies,
   e.g., TRILL and MPLS-TP.
This should probably be
   This section demonstrates the applicability of the connection-oriented
   YANG OAM data model to TRILL and MPLS-TP.
[Michael]: This section demonstrates the CO model's applicability, it introduce the method of augmenting the CO model to derived technology specific model.
Trill and MPLS-TP are just some examples. 
---
I think the affiliations and emails of the Contributors and Authors need to be double-checked.
[Michael]: Agree.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 31 Jan 2017 10:06:32 -0800

Dear Authors, WG Chairs, et. al,
please consider my comments as part of WGLC discussion.

   - Overview of the OAM Model
   - Why MEF-38 Service OAM Fault Management YANG Modules not only used as
      prototype but not even referenced?
      - "... for VPLS this can be per VPLS instance" Is this OAM model of
      service OAM of provided by the VPLS instance service or of
IP/MPLS underlay
      that provides transport for the VPLS instance? If the former,
then we have
      MEF-38. if the latter, then it is IP/MPLS network OAM, i.e.
connectionless.
      - "... connectivity verification(loopback) ..." OAM method to verify
      proper connectivity between MEPs of the specified MA rarely, if any,
      supported by the Loopback command. In order to detect in
mis-connection and
      in-defect and out-of-defect conditions, CV should operate as
proactive OAM
      command, e.g. CCM in CFM/Y.1731 or BFD-based CV for MPLS-TP as
described in
      RFC 6428.
      - "The generic YANG model defined here does not require explicit
      configuration of OAM entities prior to using any of the OAM tools."

I consider configuration of a remote MEP to be absolute pre-requisite to
using even Loopback or Linktrace commands. Similarly, configuration of MIPs
may be required as well.

   - Is "base mode for" synonymous to "default values"? The mentioning that
      explicitly would be helpful.
   -  3.5
   <https://tools.ietf.org/html/draft-ietf-lime-yang-connectionless-oam-03#section-3.5>.
   Test Point Locations
      - "routing instance vrf name if required" YANG Data Model for MPLS-TP
      OAM  <https://tools.ietf.org/html/draft-zhang-mpls-tp-yang-oam-03> does
      not require or even reference to VRF name
   - I don't see any reference to the above mentioned YANG Data Model for
   MPLS-TP OAM.
   - Nor I see substantive references to RFC 6428
   - There's no operational information specific to operation of
   connectivity verification mechanism in container oper, but only ones
   related to operation of continuity check. How MEP reports its state in
   regard to mis-connection defect (in-defect or out-of-defect)?
   - tlv-address should not be used as tp-address but as MPLS-TP
   Identifiers per RFC 6370 and RFC 6428.
   - FEC is not address of a single Test Point but group of IP packets
   which are forwarded in the same manner, over the same path, and with the
   same forwarding treatment.
   - cos-id in grouping cos is of type uint8 though TC filed mentioned as
   example is only three bits long. How these are mapped?
   - output from traceroute allows only MEP response while in linktrace
   MIPs that belong to the same MA should respond with LTR. LSP Ping does the
   same.

Nits:

   - [lime retrieval methods] - looks as meant to be reference but there's
   no a document it points to.
   - grouping cos still refers to EXP field in MPLS-TP even though the
   field has been renamed Traffic Class (TC) in 2009 by RFC 5462
   - s/Ma name format/MA name format/
   - s/Yang/YANG/ (several occasions of this)
   - in 4. 6 s/Augment/augment/
   -

I cannot support publication of this version of the document.

Regards,
Greg

On Thu, Jan 19, 2017 at 8:13 AM, Ron Bonica <[email-masked]> wrote:

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