[ippm] Re: WG Last Call: draft-ietf-ippm-alt-mark-yang-02 (Ends 2026-05-28)
Alex Huang Feng <[email protected]> Wed, 3 Jun 2026 13:41:34 +0200
| Newsgroups | gmane.ietf.ippm,gmane.ietf.bmwg |
|---|---|
| Message-ID | <[email protected]> |
--===============2891823215925882714== Content-Type: multipart/alternative; boundary="Apple-Mail=_3053264B-BEBA-4E24-87EA-C4D99C7397E7" --Apple-Mail=_3053264B-BEBA-4E24-87EA-C4D99C7397E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Marcus, alt-mark-yang authors, IPPM and BMWG, I was reviewing draft-ietf-ippm-on-path-telemetry-yang but ended up here = as that draft had a normative reference to = draft-ietf-ippm-alt-mark-yang. I support the progress of this document. However, I don=E2=80=99t think = it is ready for publication. At least, a new iteration is needed = improving the descriptions to remove ambiguity. I=E2=80=99ll go by sections: ---- Abstract: - I would suggest to use =E2=80=9CYANG module=E2=80=9D instead of = =E2=80=9CYANG data model=E2=80=9D. There was some discussions around the = usage of these terms at OPSAWG. ---- Section 1: - Reading the introduction, it references RFC9341 and RFC9342, but the = reader misses if this YANG module covers the configuration of the actual = protocol (e.g. RFC9343, RFC9947=E2=80=A6). I think it is necessary to = explicitly say it, as RFC9341 and RFC9342 cannot be deployed by = themselves without the definition of the header (RFC9343, RFC9947, =E2=80=A6= ). ---- Section 2: - The encapsulation protocols are referenced here. While this can be = useful here, I would also welcome having some text in the introduction = saying that the YANG module defined in the document cover those = encapsulation protocols. - "Note that users can augment this module.=E2=80=9D =E2=80=94> This is = kinda obvious, no? ---- Section 3: - The container =E2=80=9Caltmark-profiles=E2=80=9D container is = explained in this section. Fine, however, there is no explanation of = what the container "altmark-info=E2=80=9D is. I would suggest adding = some text to help the reader understand what that container is for. ---- Section 4: - Please update copyright of the YANG module - The Tree diagram does not match the YANG module. I take the YANG = module as the one defining this model. - The =E2=80=9Cfeature altmark=E2=80=9D is redundant here. Would a = router implement this module without the support of AltMark? Two = choices, either (1) remove this feature or (2) leave this feature as is = and use this YANG module as reference in all other AltMark-dependent = documents (e.g. use =E2=80=9Cif-feature =E2=80=98altmark:altmark=E2=80=99 = =E2=80=9D in the draft-ietf-ippm-on-path-telemetry-yang instead of = defining a new one). For simplicity, I prefer option (1). - While the feature =E2=80=9Caltmark=E2=80=9D is redundant, I think a = router could implement only a subset of the encapsulation protocols = (this document covers ipv6, srh, and mpls). Thus, I suggest adding three = features representing the support of ipv6 [RFC9343], srh [RFC9947] and = mpls [RFC9714], each referencing their respective documents.=20 - For each of the identities ipv6, srh and mpls, they depend on the = implementation on the router. Thus I would suggest to add a = =E2=80=9Cif-feature=E2=80=9D statement based on the features ipv6, srh, = and mpls. This way, those identities could only be used if they are = actually implemented on the router. - I also note here that while this document is Standards Track, there is = a reference to srh [RFC9947], which is Experimental and Independent = Submission. I am not sure of the impact of having such reference from = the IETF perspective. - There is an identity =E2=80=9Cmeasurement-period=E2=80=9D. I don=E2=80=99= t get what this means. Should this be removed? - Then there are two identities =E2=80=9Cflow-mon-id=E2=80=9D and = =E2=80=9Cenable-loss-measurement=E2=80=9D. Same here, why do we need = those? We only need the leafs defined in the configuration container. = Should these two also be removed? - The descriptions from the =E2=80=9Cgrouping measurement-node=E2=80=9D = are not clear IMO: "hbh-measurement" and "e2e-measurement" says that = these objects indicate whether these measurement *can* be enabled. Are = we talking node capabilities? Later on, this grouping is used to = actually configuring the measurements, so there is mismatch. I think the = authors meant that those nodes are used to enabled and disable those = measurements rather than referring to capabilities. Please update the = description. - Can hbh-measurement=E2=80=9D and =E2=80=9Ce2e-measurement=E2=80=9D be = enabled at the same time? - The identities =E2=80=9Cmeasurement-mode=E2=80=9D are not used (same = for the =E2=80=9Ctypedef altmark-measurement-mode=E2=80=9D) - The =E2=80=9Cleaf flow-mon-id=E2=80=9D is not mandatory. What happens = if the user does not configure this flow-mon-id? Reading = https://datatracker.ietf.org/doc/html/rfc9343#name-data-fields-format, = this value MUST be set by the controller. So, should this value be = mandatory in the YANG module? If not, some text is needed. - In general, on the profile, all the leafs seem to not be mandatory, = please verify if some of them need to be mandatory for a config to be = valid. - The leaf =E2=80=9Cenabled=E2=80=9D from the grouping = =E2=80=9Caltmark-admin-config=E2=80=9D says "It MUST be true before = anything in the /altmark/altmark-profile can be edited. If false, any = configuration in place is not used.=E2=80=9D. It feels weird having this = sentence. Does this mean the router needs to perform 2 NETCONF = transactions to configure AltMark? One to enable this node first, then a = second one with the profile? If this constraint is needed, I would = suggest implementing this constraint with a =E2=80=9Cwhen=E2=80=9D = statement from YANG in the /altmark/altmark-profile list, but I don=E2=80=99= t think it is needed. - Having the =E2=80=9Cenabled=E2=80=9D leaf at the top also means that = *all* profiles are enabled on the node. Is this what the authors wanted, = or should the =E2=80=9Cenable=E2=80=9D node be implemented on the = profile level? - The container =E2=80=9CAltMark=E2=80=9D uses camelCase. I would = suggest to avoid camelCase in a YANG, maybe use =E2=80=9Caltmark=E2=80=9D = instead? - I am not fully getting what the "list available-interface=E2=80=9D = means. The description says =E2=80=9CA list of available interfaces that = support Alternate-Marking.=E2=80=9D. Is AltMark designed to be enabled on a per-interface basis or on a = per-node basis? What happens if the flow marked by the flow-mon-id goes = to an interface not supporting AltMark? I think this needs to be = clarified, if AltMark is configured on a per-interface basis, maybe the = =E2=80=9Cenable" leaf needs to be moved to the profile level. - Finally, please fix the indentations from the YANG module. The current = revision is not well-formatted. Regards, Alex > On 7 May 2026, at 12:03, Marcus Ihlar via Datatracker = <[email protected]> wrote: >=20 > This message starts a WG Last Call for: > draft-ietf-ippm-alt-mark-yang-02 >=20 > This Working Group Last Call ends on 2026-05-28 >=20 > Please note that this WGLC runs in parallel with a last call for = draft-ietf-ippm-alt-mark-deployment with the intention of progressing = both documents at the same time. >=20 > Abstract: > Alternate-Marking Method is a technique used to perform packet loss, > delay, and jitter measurements on in-flight packets. This document > defines a YANG data model for the Alternate Marking Method. >=20 > File can be retrieved from: >=20 > Please review and indicate your support or objection to proceed with = the > publication of this document by replying to this email keeping = [email protected] > in copy. Objections should be explained and suggestions to resolve = them are > highly appreciated. >=20 > Authors, and WG participants in general, are reminded of the = Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [1]. > Appropriate IPR disclosures required for full conformance with the = provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy = can be > found at [3]. >=20 > Thank you. >=20 > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ >=20 > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-yang/ >=20 > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-yang-02 >=20 > A diff from the previous version is available at: > = https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-alt-mark-yang-= 02 >=20 > _______________________________________________ > ippm mailing list -- [email protected] > To unsubscribe send an email to [email protected] >=20 >=20 >=20 >=20 --Apple-Mail=_3053264B-BEBA-4E24-87EA-C4D99C7397E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;">Dear Marcus, = alt-mark-yang authors, IPPM and BMWG,<div><br></div><div>I was reviewing = draft-ietf-ippm-on-path-telemetry-yang but ended up here as that draft = had a normative reference to = draft-ietf-ippm-alt-mark-yang.</div><div><br></div><div>I support the = progress of this document. However, I don=E2=80=99t think it is ready = for publication. At least, a new iteration is needed improving the = descriptions to remove ambiguity.</div><div><br></div><div>I=E2=80=99ll = go by sections:</div><div><br></div><div>---- Abstract:</div><div>- I = would suggest to use =E2=80=9CYANG module=E2=80=9D instead of =E2=80=9CYAN= G data model=E2=80=9D. There was some discussions around the usage of = these terms at OPSAWG.</div><div><br></div><div>---- Section = 1:</div><div>- Reading the introduction, it references RFC9341 and = RFC9342, but the reader misses if this YANG module covers the = configuration of the actual protocol (e.g. RFC9343, RFC9947=E2=80=A6). I = think it is necessary to explicitly say it, as RFC9341 and RFC9342 = cannot be deployed by themselves without the definition of the header = (<span style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">RFC9343, RFC9947, </span><font color=3D"#000000"><span = style=3D"caret-color: rgb(0, 0, = 0);">=E2=80=A6</span></font>).</div><div><br></div><div>---- Section = 2:</div><div>- The encapsulation protocols are referenced here. While = this can be useful here, I would also welcome having some text in the = introduction saying that the YANG module defined in the document cover = those encapsulation protocols.</div><div>- "Note that users can = augment this module.=E2=80=9D =E2=80=94> This is kinda obvious, = no?</div><div><br></div><div>---- Section 3:</div><div>- The container = =E2=80=9Caltmark-profiles=E2=80=9D container is explained in this = section. Fine, however, there is no explanation of what the container = "altmark-info=E2=80=9D is. I would suggest adding some text to help the = reader understand what that container is = for.</div><div><br></div><div>---- Section 4:</div><div>- Please update = copyright of the YANG module</div><div>- The Tree diagram does not match = the YANG module. I take the YANG module as the one defining this = model.</div><div>- The =E2=80=9Cfeature altmark=E2=80=9D is redundant = here. Would a router implement this module without the support of = AltMark? Two choices, either (1) remove this feature or (2) leave this = feature as is and use this YANG module as reference in all other = AltMark-dependent documents (e.g. use =E2=80=9Cif-feature = =E2=80=98altmark:altmark=E2=80=99 =E2=80=9D in the <span = style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, = 0);">draft-ietf-ippm-on-path-telemetry-yang instead of defining a new = one</span>). For simplicity, I prefer option (1).</div><div>- While the = feature =E2=80=9Caltmark=E2=80=9D is redundant, I think a router could = implement only a subset of the encapsulation protocols (this document = covers ipv6, srh, and mpls). Thus, I suggest adding three features = representing the support of ipv6 [RFC9343], srh [RFC9947] and mpls = [RFC9714], each referencing their respective = documents. </div><div>- For each of the identities ipv6, srh and = mpls, they depend on the implementation on the router. Thus I would = suggest to add a =E2=80=9Cif-feature=E2=80=9D statement based on the = features ipv6, srh, and mpls. This way, those identities could only be = used if they are actually implemented on the router.</div><div>- I also = note here that while this document is Standards Track, there is a = reference to srh [RFC9947], which is Experimental and Independent = Submission. I am not sure of the impact of having such reference from = the IETF perspective.</div><div>- There is an identity = =E2=80=9Cmeasurement-period=E2=80=9D. I don=E2=80=99t get what this = means. Should this be removed?</div><div>- Then there are two identities = =E2=80=9Cflow-mon-id=E2=80=9D and =E2=80=9Cenable-loss-measurement=E2=80=9D= . Same here, why do we need those? We only need the leafs defined in the = configuration container. Should these two also be = removed?</div><div><font color=3D"#000000">- The descriptions from the = =E2=80=9Cgrouping measurement-node=E2=80=9D are not clear IMO: = "</font>hbh-measurement" and "e2e-measurement" says that these objects = indicate whether these measurement *can* be enabled. Are we talking node = capabilities? Later on, this grouping is used to actually configuring = the measurements, so there is mismatch. I think the authors meant that = those nodes are used to enabled and disable those measurements rather = than referring to capabilities. Please update the = description.</div><div>- Can hbh-measurement=E2=80=9D and = =E2=80=9Ce2e-measurement=E2=80=9D be enabled at the same = time?</div><div>- The identities =E2=80=9Cmeasurement-mode=E2=80=9D are = not used (same for the =E2=80=9Ctypedef = altmark-measurement-mode=E2=80=9D)</div><div>- The =E2=80=9Cleaf = flow-mon-id=E2=80=9D is not mandatory. What happens if the user does not = configure this flow-mon-id? Reading <a = href=3D"https://datatracker.ietf.org/doc/html/rfc9343#name-data-fields-for= mat">https://datatracker.ietf.org/doc/html/rfc9343#name-data-fields-format= </a>, this value MUST be set by the controller. So, should this value be = mandatory in the YANG module? If not, some text is needed.</div><div>- = In general, on the profile, all the leafs seem to not be mandatory, = please verify if some of them need to be mandatory for a config to be = valid.</div><div>- The leaf =E2=80=9Cenabled=E2=80=9D from the grouping = =E2=80=9Caltmark-admin-config=E2=80=9D says "It MUST be true before = anything in the /altmark/altmark-profile can be edited. If false, any = configuration in place is not used.=E2=80=9D. It feels weird having this = sentence. Does this mean the router needs to perform 2 NETCONF = transactions to configure AltMark? One to enable this node first, then a = second one with the profile? If this constraint is needed, I would = suggest implementing this constraint with a =E2=80=9Cwhen=E2=80=9D = statement from YANG in the /altmark/altmark-profile list, but I don=E2=80=99= t think it is needed.</div><div>- Having the =E2=80=9Cenabled=E2=80=9D = leaf at the top also means that *all* profiles are enabled on the node. = Is this what the authors wanted, or should the =E2=80=9Cenable=E2=80=9D = node be implemented on the profile level?</div><div>- The container = =E2=80=9CAltMark=E2=80=9D uses camelCase. I would suggest to avoid = camelCase in a YANG, maybe use =E2=80=9Caltmark=E2=80=9D = instead?</div><div>- I am not fully getting what the "list = available-interface=E2=80=9D means. The description says =E2=80=9CA list = of available interfaces that support Alternate-Marking.=E2=80=9D.</div><di= v>Is AltMark designed to be enabled on a per-interface basis or on a = per-node basis? What happens if the flow marked by the flow-mon-id goes = to an interface not supporting AltMark? I think this needs to be = clarified, if AltMark is configured on a per-interface basis, maybe the = =E2=80=9Cenable" leaf needs to be moved to the profile = level.</div><div>- Finally, please fix the indentations from the YANG = module. The current revision is not = well-formatted.</div><div><br></div><div>Regards,</div><div>Alex</div><div= ><br></div><div><br></div><div><div><blockquote type=3D"cite"><div>On 7 = May 2026, at 12:03, Marcus Ihlar via Datatracker = <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div>This message starts a WG = Last Call for:<br>draft-ietf-ippm-alt-mark-yang-02<br><br>This Working = Group Last Call ends on 2026-05-28<br><br>Please note that this WGLC = runs in parallel with a last call for = draft-ietf-ippm-alt-mark-deployment with the intention of progressing = both documents at the same time.<br><br>Abstract:<br> = Alternate-Marking Method is a technique used to perform = packet loss,<br> delay, and jitter measurements on in-flight = packets. This document<br> defines a YANG data model = for the Alternate Marking Method.<br><br>File can be retrieved = from:<br><br>Please review and indicate your support or objection to = proceed with the<br>publication of this document by replying to this = email keeping [email protected]<br>in copy. Objections should be explained = and suggestions to resolve them are<br>highly = appreciated.<br><br>Authors, and WG participants in general, are = reminded of the Intellectual<br>Property Rights (IPR) disclosure = obligations described in BCP 79 [1].<br>Appropriate IPR disclosures = required for full conformance with the provisions<br>of BCP 78 [1] and = BCP 79 [2] must be filed, if you are aware of any.<br>Sanctions = available for application to violators of IETF IPR Policy can = be<br>found at [3].<br><br>Thank you.<br><br>[1] = https://datatracker.ietf.org/doc/bcp78/<br>[2] = https://datatracker.ietf.org/doc/bcp79/<br>[3] = https://datatracker.ietf.org/doc/rfc6701/<br><br>The IETF datatracker = status page for this Internet-Draft = is:<br>https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-yang/<br>= <br>There is also an HTMLized version available = at:<br>https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-yang= -02<br><br>A diff from the previous version is available = at:<br>https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-alt-mar= k-yang-02<br><br>_______________________________________________<br>ippm = mailing list -- [email protected]<br>To unsubscribe send an email to = [email protected]<br><br><br><br><br></div></div></blockquote></div><br>= </div></body></html>= --Apple-Mail=_3053264B-BEBA-4E24-87EA-C4D99C7397E7-- --===============2891823215925882714== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaXBwbSBtYWls aW5nIGxpc3QgLS0gaXBwbUBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IGlwcG0tbGVhdmVAaWV0Zi5vcmcK --===============2891823215925882714==--