[CCAMP] 回复: AD review of draft-ietf-ccamp-otn-topo-yang-17

[Zhenghaomian <[e-mail]>]

Hi John,

Thank you for the review and comments, we addressed them in the update -18, together with the comments from genart and secdir Last Call review.
We think the work can be proceeded, let us know if anything is missing.

Best wishes,
Haomian (on behalf of authors & contributors)

发件人: John Scudder <[e-mail]>
发送时间: 2024年3月7日 9:55
收件人: [e-mail]
抄送: [e-mail]
主题: Re: AD review of draft-ietf-ccamp-otn-topo-yang-17

Hi Everyone,

The IETF LC has ended for this document and I can put it on an IESG agenda for approval. However, before I do that I want to ask if you plan to address the Security Considerations point I raised in my earlier note. If you don’t plan to address it, tell me so and I’ll go ahead. But for now, I am putting the state into “revised I-D needed” to indicate that I think this revision would be prudent.

Note that the SEC directorate reviewer raised the same concern, https://mailarchive.ietf.org/arch/msg/ccamp/35Eb2phB7T207LNcnj6HQX4lxPI/ . If you need to discuss specific changes, following up with him would probably be a great idea.

Thanks,

—John


On Feb 21, 2024, at 12:08 PM, John Scudder <[e-mail]<mailto:[e-mail]>> wrote:

Hi All,

I remembered I had one additional comment that I forgot to include in my earlier note. I've observed that reviewers, especially from the SEC area, are keen to see specifics in the Security Considerations section, for example calling out specific leaves or subtrees that might be particularly sensitive and explaining the nature of the sensitivity. Your document doesn’t have such specifics — you cite “a number of data nodes” but don’t name them. While I don’t have specific omissions to point out, or changes to recommend, you might want to consider adding some details of this nature. For examples, you might look to recently-approved (https://datatracker.ietf.org/iesg/decisions/) YANG documents' SecCons sections.

—John


On Feb 16, 2024, at 4:21 PM, John Scudder <[e-mail]<mailto:[e-mail]>> wrote:

Hi Authors, WG,

Thanks for this document.

I have only a few small proofreading comments. I’ve supplied these in the form of an edited copy of the draft. There are only minor editorial suggestions and I’ve made them in place without further comment. The one point that might need a slight amount of explanation is I suggested changing “OTN network” to “OTN” because “network” is redundant with the expansion of “OTN" (consider the example of “ATM machine”). You can use your favorite diff tool to review them; I’ve attached the iddiff output for your convenience if you’d like to use it. I’ve also pasted a traditional diff below in case you want to use it for in-line reply.

Because all my comments are minor, I’m going to go ahead and request IETF last call without waiting for a document update, please do consider the comments in your next update though.

Thanks,

—John

--- draft-ietf-ccamp-otn-topo-yang-17.txt 2024-02-16 16:11:48
+++ draft-ietf-ccamp-otn-topo-yang-17-jgs-comments.txt 2024-02-16 16:13:41
@@ -114,7 +114,7 @@
Internet-Draft           OTN Topology YANG Model               July 2023


-   This document defines a data model of an OTN network topology, using
+   This document defines a data model of an OTN topology, using
  YANG [RFC7950].  The model can be used by an application
  communicating with a transport controller.  Furthermore, it can be
  used by an application for the following purposes (but not limited
@@ -326,7 +326,7 @@
            +--rw supported-client-signal*   identityref


-   The list of support-client-signal is used to provide the capabilities
+   The list of supported-client-signal is used to provide the capabilities
  of the client signal specified in [I-D.ietf-ccamp-layer1-types].


@@ -1709,7 +1709,7 @@
                  Network (OTN)-electrical layer.";
        description "OTN topology type";
      }
-       description "augment network types to include OTN newtork";
+       description "augment network types to include OTN network";
    }

    augment "/nw:networks/nw:network/nw:node/tet:te"
@@ -1769,7 +1769,7 @@
      }
      container client-svc {
        presence
-           "When present, indicates that the Link supports Costant
+           "When present, indicates that the Link supports Constant
          Bit Rate (CBR) client signals.";
        description
          "Attributes of the Link supporting CBR client signals.";
@@ -1815,7 +1815,7 @@
      container client-svc {
        presence
          "When present, indicates that the Link Termination Point
-           (LTP) supports Costant Bit Rate (CBR) client signals.";
+           (LTP) supports Constant Bit Rate (CBR) client signals.";
        description
          "OTN LTP Service attributes.";
        leaf-list supported-client-signal {
@@ -2112,7 +2112,7 @@
                whose nominal bitrate is used to compute the number of
                Tributary Slots (TS) required by the ODUflex LSPs
                set up along the underlay path of this OTN Local
-                 Link Connectivyt entry.";
+                 Link Connectivity entry.";
            }
          }
        }


<draft-ietf-ccamp-otn-topo-yang-17-jgs-comments.txt><draft-ietf-ccamp-otn-topo-yang-17.diff.html>