Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D296BC1CAF52; Wed, 3 Jul 2024 17:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeXikq3WYA82; Wed, 3 Jul 2024 17:44:59 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1A7C157931; Wed, 3 Jul 2024 17:44:54 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2c93627e773so109733a91.0; Wed, 03 Jul 2024 17:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720053894; x=1720658694; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=qVYSCBckxiZpwO0icmeeUKBq14UTDX5YKHIo9rII2NQ=; b=Fc3m3Hivbv6ATGsjV9LkbbK8Cf6tYOZKzPHAooxh1LW8thdpjiW/D0X0be3hcbUsMq cNb/2wFEgMTGCXpQpx8QUaz/oStF6km/D+OHzoGCRHLtQ+L9vFerZ0heBRvSAkxb1/FU YikUzrN53UJqIgs3GdOELbfgWApI1KKElEiIZ0iJaLXQ19fORJQR7GAbcSykZ1pW6+C3 UP5Xg0VzbFCPKabx8ZTxysqrUE3TaxjGCCmUfMDyC615UzJK63RGtPlLTuMJmx5A1SJK Ov1yrXVl2I/mHPMs8cApWCx9xNx1MOF796fG3PZ8lQTXuSDTJWar7WSopiVu0uGOnuAe TMkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720053894; x=1720658694; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qVYSCBckxiZpwO0icmeeUKBq14UTDX5YKHIo9rII2NQ=; b=dSJaI272qPYPH5UjItxbgfUzTsbc7g0uhC/g46iC+LCCdi2v7vYnnZzomZW3pHID7O Docgxy67YfMuNVVp603DRFUZm7g2yrNDlBY62XQF0S/dIC4NOIWl/f1YtH3NX6ZSZRjU Ev9t82V9M7ex+SABYrcigL5fqM6ntt4PiRFjy0RQKUp9+paplHFWZT/ckDOjiSTJt2+0 05Xh0LYdodMoFVoQReWSw40+UM5hHudO67QjJWxlnCfB+b9LsCV9iE0/XUGQlgQvtsSk XXrm5fNa6cEELK0j3vf8SOA/kGPQr41b5arOXx6uZW/LKhMVjoBAwSdWvCACqNNguQNo +lrQ== X-Forwarded-Encrypted: i=1; AJvYcCUxk0oHtxCzae7B8J4JwaN3Fyak1UyVOV+Bjmu9biM8WO5lLqTaphVAWzVG2IRsvTFEMa9gp6bC7hRtvuO6DbNfJQ9d4HnUnZCJUPhDxLidit+c3Q5Nf5xwxSJuxf63mA5Jhouj5V3541khsE2bHqdWfLuTwwOeatzEjTNqf+0= X-Gm-Message-State: AOJu0Yz6TyshcclX1J2DBKVn0s60IcEuNzlZQDBydTANEPqKbEpk1MwK LxivnKqf+tYbxNYROWTsLT9rV+lm9vPlq8LJvGFAS4xBnvbeR7x2 X-Google-Smtp-Source: AGHT+IHh4YdMdLmnMMOgXlkhC3lZSVwD6Y9pIK7ifUsXaxzgkPnpjWQEqEMBwbuP9pq24xsA/K1WZw== X-Received: by 2002:a17:90a:17e6:b0:2c9:6514:3a12 with SMTP id 98e67ed59e1d1-2c99c804602mr87572a91.34.1720053893545; Wed, 03 Jul 2024 17:44:53 -0700 (PDT) Received: from smtpclient.apple ([70.234.233.187]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2c99a92a05dsm153887a91.3.2024.07.03.17.44.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Jul 2024 17:44:52 -0700 (PDT) From: Mahesh Jethanandani Message-Id: <8F2384FB-6141-4A72-9561-8C22C7955B7B@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E8178C0F-1738-42C0-938B-67A8A6280F69" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.15\)) Date: Wed, 3 Jul 2024 17:44:51 -0700 In-Reply-To: To: Italo Busi References: <171408353174.41086.10890247237741950845@ietfa.amsl.com> X-Mailer: Apple Mail (2.3654.120.0.1.15) Message-ID-Hash: XTXGI6ZQZPB6YR3TZUQS3OIUZMVLEY3W X-Message-ID-Hash: XTXGI6ZQZPB6YR3TZUQS3OIUZMVLEY3W X-MailFrom: mjethanandani@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ccamp.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The IESG , "draft-ietf-ccamp-otn-topo-yang@ietf.org" , "ccamp-chairs@ietf.org" , "ccamp@ietf.org" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BCCAMP=5DRe=3A_Mahesh_Jethanandani=27s_Discuss_on_draft-ietf-cca?= =?utf-8?q?mp-otn-topo-yang-18=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: Discussion list for the CCAMP working group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_E8178C0F-1738-42C0-938B-67A8A6280F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Italo, > On Jun 25, 2024, at 8:17 AM, Italo Busi wrote: >=20 > Dear Mahesh,=20 >=20 > Thank you for the review, the authors have updated the document to = address your comments and posted the updated document as = draft-ietf-ccamp-otn-topo-yang-19 >=20 > See our feedbacks in line, marked as [Authors] >=20 > Thanks for the support and review.=20 >=20 > Authors, Haomian and Italo. >=20 >> -----Original Message----- >> From: Mahesh Jethanandani via Datatracker > >> Sent: venerd=C3=AC 26 aprile 2024 00:19 >> To: The IESG > >> Cc: draft-ietf-ccamp-otn-topo-yang@ietf.org = ; ccamp-chairs@ietf.org = ; >> ccamp@ietf.org ; daniel@olddog.co.uk = ; daniel@olddog.co.uk = >> Subject: Mahesh Jethanandani's Discuss on = draft-ietf-ccamp-otn-topo-yang-18: >> (with DISCUSS and COMMENT) >>=20 >> Mahesh Jethanandani has entered the following ballot position for >> draft-ietf-ccamp-otn-topo-yang-18: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all = email >> addresses included in the To and CC lines. (Feel free to cut this = introductory >> paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/about/groups/iesg/statements/handling- >> ballot-positions/ >> for more information about how to handle DISCUSS and COMMENT = positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> I am not an expert in OTN technology, so some of these DISCUSSes = could be >> my >> lack of understanding of the technology. Therefore, it will be good = to have >> some discussion around them. >>=20 >=20 > [Authors] We have added few sentences in the Introduction clarifying = that the readers is assumed to be familiar with OTN and with the TE = topology model, providing some references. You can also refer to RFC7062 = for some framework description. Ok. >=20 >> But before that: >>=20 >> Section 1, paragraph 1 >>=20 >> The document needs to be explicit whether this is a YANG 1.0 or a = YANG 1.1 >> model. It also needs to state here, just as it has done in the YANG = model >> itself, whether it supports the NMDA architecture. >>=20 >=20 > [Authors] The conformance to the NMDA architecture is written at the = end of section 1. We have added a paragraph indicating that the model is = using YANG 1.1 Thanks for adding that.=20 >=20 >> Section 2.2, paragraph 3 >>> augment /nw:networks/nw:network/nt:link/tet:te >>> /tet:te-link-attributes: >>> +--rw otn-link >>> +--rw odtu-flex-type? l1-types:odtu-flex-type >>> +--rw tsg? identityref >>> +--rw distance? uint32 >>=20 >> Is a user expected to specify the parameters above or this somehow = learnt or >> derived from a certain link attribute, e.g. odtu-flex-type? If the = latter, >> should these nodes not be state (ro) nodes? This DISCUSS applies to = most of >> the >> remaining rw nodes in the module, e.g., link bandwidth etc. >>=20 >=20 > [Authors] According to RFC8345, a network topology can be system = controlled or not. This also applies to the OTN network topology. >=20 > In this data model, a network is categorized as either system > controlled or not. If a network is system controlled, then it is > automatically populated by the server and represents dynamically > learned information that can be read from the operational state > datastore. The data model can also be used to create or modify > network topologies that might be associated with an inventory model > or with an overlay network. Such a network is not system = controlled; > rather, it is configured by a client. Thanks for that reference. Reading RFC 8345, and in particular paragraph = 3 of Section 4.4.10, it says: In general, a configured network topology will refer to an underlay topology and include layering information, such as the supporting node(s) underlying a node, supporting link(s) underlying a link, and supporting termination point(s) underlying a termination point. You have provided the layering information for nodes, link, and = termination points, but where is the reference to the underlay topology? >=20 >> Section 2.2, paragraph 6 >>> augment /nw:networks/nw:network/nw:node/nt:termination-point >>> /tet:te: >>> +--rw client-svc! >>> +--rw supported-client-signal* identityref >>=20 >> As an example, two paragraphs up in the draft, it says that the OTN = topology >> models is reporting on access link. The word "reporting" tells me = that this >> state (ro) data. If it is, why are these nodes rw? >>=20 >=20 > [Authors] We have improved the text to support the case where the OTN = network topology is not system controlled. I am looking at the diffs, between -19 and -18, for the text that = provides such a clarification, but do not see it. Can you point me to = it? >=20 >> Section 6, paragraph 1 >>=20 >> Please use the latest template from >> https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-11.html, >> Section >> 3.7.1. In particular, and as pointed out by the YANG doctor (thanks = Radek), >> and >> in the SECDIR review (thanks Watson), it is not enough to just say = that all >> writeable nodes are vulnerable without describing them using a XPath, = or a >> name, and describing why or how are they vulnerable. >>=20 >>=20 >=20 > [Authors] We have updated the security considerations to follow the = guidelines but since the sensitivity/vulnerability considerations for = the different subtrees would be the same as those provided in section 8 = of RFC8795, we think it is better to reference rather than copying that = text. I agree that the nodes defined in RFC 8795 do not need to copied here. = However, the nodes that are defined in this draft, and do not exist in = RFC 8795 need to have their own Security Considerations. By leaving the = section blank for each of writeable/readable/actionable (RPCs) sections, = I am not sure what is being implied. At the minimum, the document needs = to say for each of the writeable/readable/actionable sections, that the = nodes in this document have no security considerations. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> The remaining review is split between COMMENT and NIT >>=20 >> = --------------------------------------------------------------------------= ----- >> COMMENT >> = --------------------------------------------------------------------------= ----- >> My overall comment is on the lack of instance data examples in the = model. >> There >> are several published YANG models that carry such examples, e.g. BGP = YANG >> model. Without such an example, it is difficult if not impossible to = understand >> how to use the model. >>=20 >=20 > [Authors] Examples added Great. Was it validated using any of the tools, e.g. yanglint? Thanks >=20 >> Section 3, paragraph 0 >>> 3. YANG Tree for OTN topology >>=20 >> Please move the complete tree diagram to the Appendix or to an = external site, >> per the recommendation in draft-ietf-netmod-rfc8407bis, Section 3.4. >>=20 >=20 > [Authors] fixed >=20 >> Section 4, paragraph 0 >>> 4. The YANG Code >> s/YANG Code/YANG Model/ >>=20 >=20 > [Authors] fixed >=20 >> Also, you need to provide a list of all the references cited in the = YANG module >> here. For example, you cite RFC 8345 in the YANG module below. That = needs >> to be >> called out as a reference before the YANG model with text such as = "This YANG >> module references A YANG Data Model for Network Topologies [RFC = 8345], >> YANG >> Data Model for Traffic Engineering [RFC 8795], ... >>=20 >=20 > [Authors] fixed >=20 >> Section 4, paragraph 18 >>> grouping label-range-info { >>> description >>> "OTN technology-specific label range related information = with >>> a presence container indicating that the label range is an >>> OTN technology-specific label range. >>>=20 >>> This grouping SHOULD be used together with the >>> otn-label-start-end and otn-label-step groupings to provide >>> OTN technology-specific label information to the models = which >>> use the label-restriction-info grouping defined in the = module >>> ietf-te-types."; >>> uses l1-types:otn-label-range-info { >>> refine otn-label-range { >>> presence >>> "Indicates the label range is an OTN label range. >>>=20 >>> This container MUST NOT be present if there are other >>> presence containers or attributes indicating another = type >>> of label range."; >>> } >>> } >>> } >>=20 >> I agree with the YANG Doctor (Radek), that unless there is a strong = reason of >> resuability of the grouping by other modules, the grouping should be = removed, >> and the code inlined with where it is being used. >>=20 >=20 > [Authors] This grouping is not intended to be re-used by other modules = but it is used multiple times within this module. >=20 >> No reference entries found for these items, which were mentioned in = the text: >> [RFCYYYY] and [odu-type]. >>=20 >=20 > [Authors] The [odu-type] is not used as a reference but only as a list = key in the YANG tree. >=20 > [Authors] Regarding [RFCYYYY], we have followed the common convention = used in multiple drafts is to > - reference RFC YYYY within the YANG code and add an RFC Editor Note = to replace YYYY with the RFC number assigned to the corresponding draft; > - use in the prefix table the text [RFCYYYY] and an RFC Editor Note to = replace YYYY with the RFC number assigned to a draft >=20 >> Possible DOWNREF from this Standards Track doc to [ITU-T_G.709]. If = so, the >> IESG needs to approve it. >>=20 >=20 > [Authors] ITU-T G.709 is a normative ITU-T Recommendation so it should = not be a DOWNREF. >=20 >> = --------------------------------------------------------------------------= ----- >> NIT >> = --------------------------------------------------------------------------= ----- >>=20 >> All comments below are about very minor potential issues that you may >> choose to >> address in some way - or ignore - as you see fit. Some were flagged = by >> automated tools (via https://github.com/larseggert/ietf-reviewtool), = so there >> will likely be some false positives. There is no need to let me know = what you >> did with these suggestions. >>=20 >> Section 2.2, paragraph 1 >>> There are a few characteristics augmenting to the generic TE >>> topology. >>=20 >> s/augmenting to the/augmenting the/ >>=20 >=20 > [Authors] fixed >=20 >> Section 2.2, paragraph 3 >>> Three OTN technology-specific parameters are specified to augment = the >>> generic TE link attributes. >>=20 >> s/specified to augment/specified that augment/ >>=20 >=20 > [Authors] Rephrased as "Three OTN technology-specific parameters that = augment the generic TE link attributes are specified." >=20 >> Section 1, paragraph 3 >>> d information pertaining to an Optical Transport Networks (OTN) = electrical l >>> ^^^^^^^^^^^^^^^^^^^^ >> Uncountable nouns are usually not used with an indefinite article. = Use simply >> "Optical Transport". >>=20 >=20 > [Authors] fixed >=20 >> Section 1, paragraph 7 >>> ms used in this document are listed as follow. * TS: Tributary Slot. = * TSG: T >>> ^^^^^^^^^ >> Did you mean "as follows"? >>=20 >=20 > [Authors] fixed >=20 >> Section 2.2, paragraph 5 >>> hat kind of signal can be carried as follow. The same presence = container is >>> ^^^^^^^^^ >> Did you mean "as follows"? >>=20 >>=20 >=20 > [Authors] fixed Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_E8178C0F-1738-42C0-938B-67A8A6280F69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Italo,

On Jun 25, 2024, at 8:17 AM, Italo Busi = <Italo.Busi@huawei.com> wrote:

Dear Mahesh, 

Thank you for the review, the = authors have updated the document to address your comments and posted = the updated document as draft-ietf-ccamp-otn-topo-yang-19

See our feedbacks in line, = marked as [Authors]

Thanks for the support and review. 

Authors, Haomian and = Italo.

-----Original Message-----
From: Mahesh = Jethanandani via Datatracker <noreply@ietf.org>
Sent: venerd=C3=AC 26 = aprile 2024 00:19
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ccamp-otn-topo-yang@ietf.org; ccamp-chairs@ietf.org;
ccamp@ietf.org; daniel@olddog.co.uk; daniel@olddog.co.uk
Subject: Mahesh Jethanandani's Discuss on = draft-ietf-ccamp-otn-topo-yang-18:
(with DISCUSS and = COMMENT)

Mahesh Jethanandani has entered = the following ballot position for
draft-ietf-ccamp-otn-topo-yang-18: Discuss

When responding, please keep the subject line intact and = reply to all email
addresses included in the To and CC = lines. (Feel free to cut this introductory
paragraph, = however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-=
ballot-positions/
for more information = about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot = positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang= /



---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

I am not an expert in OTN = technology, so some of these DISCUSSes could be
my
lack of understanding of the technology. Therefore, it will = be good to have
some discussion around them.


[Authors] We have added few sentences in the Introduction = clarifying that the readers is assumed to be familiar with OTN and with = the TE topology model, providing some references. You can also refer to = RFC7062 for some framework description.

Ok.


But before that:

Section 1, paragraph 1

The = document needs to be explicit whether this is a YANG 1.0 or a YANG = 1.1
model. It also needs to state here, just as it has = done in the YANG model
itself, whether it supports the = NMDA architecture.


[Authors] The conformance to the = NMDA architecture is written at the end of section 1. We have added a = paragraph indicating that the model is using YANG 1.1

Thanks for = adding that. 


Section 2.2, paragraph 3
          &nb= sp;augment /nw:networks/nw:network/nt:link/tet:te
          &nb= sp;    /tet:te-link-attributes:
         +--rw = otn-link
          &nb= sp;+--rw odtu-flex-type?   l1-types:odtu-flex-type
          &nb= sp;+--rw tsg? =             &n= bsp;identityref
          &nb= sp;+--rw distance? =         uint32

Is a user expected to specify the = parameters above or this somehow learnt or
derived from a = certain link attribute, e.g. odtu-flex-type? If the latter,
should these nodes not be state (ro) nodes? This DISCUSS = applies to most of
the
remaining rw nodes in = the module, e.g., link bandwidth etc.


[Authors] According to RFC8345, a network topology can be = system controlled or not. This also applies to the OTN network = topology.

  In = this data model, a network is categorized as either system
  controlled or not. =  If a network is system controlled, then it is
  automatically = populated by the server and represents dynamically
  learned information = that can be read from the operational state
  datastore.  The = data model can also be used to create or modify
  network topologies = that might be associated with an inventory model
  or with an overlay = network.  Such a network is not system controlled;
  rather, it is = configured by a client.

Thanks for that reference. Reading RFC 8345, and in = particular paragraph 3 of Section 4.4.10, it says:

   In general, a = configured network topology will refer to an underlay
   topology and include layering information, such = as the supporting
   node(s) underlying a = node, supporting link(s) underlying a link, and
   supporting termination point(s) underlying a = termination point.

You have provided the layering information for nodes, link, = and termination points, but where is the reference to the underlay = topology?


Section 2.2, paragraph 6
       augment = /nw:networks/nw:network/nw:node/nt:termination-point
          &nb= sp;      /tet:te:
         +--rw = client-svc!
          &nb= sp; +--rw supported-client-signal*   identityref

As an example, two paragraphs up = in the draft, it says that the OTN topology
models is = reporting on access link. The word "reporting" tells me that this
state (ro) data.  If it is, why are these nodes rw?


[Authors] We have improved the text to support the case where = the OTN network topology is not system controlled.

I am looking at = the diffs, between -19 and -18, for the text that provides such a = clarification, but do not see it. Can you point me to it?


Section= 6, paragraph 1

Please use the latest = template from
https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-11= .html,
Section
3.7.1. In particular, and = as pointed out by the YANG doctor (thanks Radek),
and
in the SECDIR review (thanks Watson), it is not enough to = just say that all
writeable nodes are vulnerable without = describing them using a XPath, or a
name, and describing = why or how are they vulnerable.



[Authors] We have updated the security considerations to = follow the guidelines but since the sensitivity/vulnerability = considerations for the different subtrees would be the same as those = provided in section 8 of RFC8795, we think it is better to reference = rather than copying that text.

I agree that the nodes defined in RFC 8795 do not need = to copied here. However, the nodes that are defined in this draft, and = do not exist in RFC 8795 need to have their own Security Considerations. = By leaving the section blank for each of writeable/readable/actionable = (RPCs) sections, I am not sure what is being implied. At the minimum, = the document needs to say for each of the writeable/readable/actionable = sections, that the nodes in this document have no security = considerations.


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

The remaining review is split = between COMMENT and NIT

---------------------------------------------------------------= ----------------
COMMENT
---------------------------------------------------------------= ----------------
My overall comment is on the lack of = instance data examples in the model.
There
are= several published YANG models that carry such examples, e.g. BGP = YANG
model. Without such an example, it is difficult if = not impossible to understand
how to use the model.


[Authors] Examples added

Great. Was it validated using any of the tools, e.g. = yanglint?

Thanks


Section= 3, paragraph 0
3. =  YANG Tree for OTN topology

Please move the complete tree diagram to the Appendix or to = an external site,
per the recommendation in = draft-ietf-netmod-rfc8407bis, Section 3.4.


[Authors] fixed

Section 4, paragraph 0
4.  The YANG = Code
s/YANG Code/YANG Model/


[Authors] fixed

Also, you need to provide a list of = all the references cited in the YANG module
here. For = example, you cite RFC 8345 in the YANG module below. That needs
to be
called out as a reference before the YANG = model with text such as "This YANG
module references A = YANG Data Model for Network Topologies [RFC 8345],
YANG
Data Model for Traffic Engineering [RFC 8795], ...


[Authors] fixed

Section 4, paragraph 18
    grouping label-range-info {
      description
        "OTN = technology-specific label range related information with
        a presence = container indicating that the label range is an
        OTN = technology-specific label range.

        This grouping = SHOULD be used together with the
        otn-label-start= -end and otn-label-step groupings to provide
        OTN = technology-specific label information to the models which
        use the = label-restriction-info grouping defined in the module
        ietf-te-types."= ;
      uses = l1-types:otn-label-range-info {
        refine = otn-label-range {
          pre= sence
          &nb= sp; "Indicates the label range is an OTN label range.

          &nb= sp; This container MUST NOT be present if there are other
          &nb= sp; presence containers or attributes indicating another type
          &nb= sp; of label range.";
        }
      }
    }

I agree with the YANG Doctor (Radek), that unless there is a = strong reason of
resuability of the grouping by other = modules, the grouping should be removed,
and the code = inlined with where it is being used.


[Authors] This grouping is not intended to be re-used by = other modules but it is used multiple times within this = module.

No = reference entries found for these items, which were mentioned in the = text:
[RFCYYYY] and [odu-type].


[Authors] The [odu-type] is not used as a reference but only = as a list key in the YANG tree.

[Authors] Regarding [RFCYYYY], we have followed the common = convention used in multiple drafts is to
- reference RFC YYYY within the YANG code and add an RFC = Editor Note to replace YYYY with the RFC number assigned to the = corresponding draft;
- use in the prefix table the text [RFCYYYY] and an RFC = Editor Note to replace YYYY with the RFC number assigned to a = draft

Possible DOWNREF from this Standards Track doc to = [ITU-T_G.709]. If so, the
IESG needs to approve it.


[Authors] ITU-T G.709 is a normative ITU-T Recommendation so = it should not be a DOWNREF.

---------------------------------------------------------------= ----------------
NIT
---------------------------------------------------------------= ----------------

All comments below are = about very minor potential issues that you may
choose = to
address in some way - or ignore - as you see fit. Some = were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so = there
will likely be some false positives. There is no = need to let me know what you
did with these = suggestions.

Section 2.2, paragraph 1
  There are a = few characteristics augmenting to the generic TE
  topology.

s/augmenting to the/augmenting the/


[Authors] fixed

Section 2.2, paragraph 3
  Three OTN = technology-specific parameters are specified to augment the
  generic TE link attributes.

s/specified to augment/specified = that augment/


[Authors] Rephrased as "Three = OTN technology-specific parameters that augment the generic TE link = attributes are specified."

Section 1, paragraph 3
d information pertaining = to an Optical Transport Networks (OTN) electrical l
          &nb= sp;            = ;    ^^^^^^^^^^^^^^^^^^^^
Uncountable nouns are usually not used with an = indefinite article. Use simply
"Optical Transport".


[Authors] fixed

Section 1, paragraph 7
ms used in this document = are listed as follow. * TS: Tributary Slot. * TSG: T
          &nb= sp;            = ;            ^= ^^^^^^^^
Did you mean "as follows"?


[Authors] fixed

Section 2.2, paragraph 5
hat kind of signal can = be carried as follow. The same presence container is
          &nb= sp;            = ;          ^^^^^^^^^
Did you mean "as follows"?



[Authors] fixed


Mahesh = Jethanandani
mjethanandani@gmail.com






= --Apple-Mail=_E8178C0F-1738-42C0-938B-67A8A6280F69--