[ippm] Re: WG Last Call: draft-ietf-ippm-alt-mark-yang-02 (Ends 2026-05-28)
Giuseppe Fioccola <giuseppe.fioccola=40huawei.com-Tr9gZwTxerDR74oF6e/[email protected]> Fri, 5 Jun 2026 13:21:05 +0000
| Newsgroups | gmane.ietf.ippm,gmane.ietf.bmwg |
|---|---|
| Message-ID | <[email protected]> |
--===============2574105683078781726== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_c600eaa3362a48008ce031b3ae84f145huaweicom_" --_000_c600eaa3362a48008ce031b3ae84f145huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex, Thanks a lot for your review. Please see inline [GF]. Regards, Giuseppe From: Alex Huang Feng <[email protected]> Sent: Wednesday, June 3, 2026 1:42 PM To: Marcus Ihlar <marcus.ihlar-IzeFyvvaP7pWk0Htik3J/[email protected]>; draft-ietf-ippm-alt-mark-yang= @ietf.org Cc: [email protected]; [email protected]; [email protected]; [email protected]= g Subject: Re: [ippm] WG Last Call: draft-ietf-ippm-alt-mark-yang-02 (Ends 20= 26-05-28) 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't think it is ready= for publication. At least, a new iteration is needed improving the descrip= tions to remove ambiguity. I'll go by sections: ---- Abstract: - I would suggest to use "YANG module" instead of "YANG data model". There = was some discussions around the usage of these terms at OPSAWG. [GF]: Ok ---- Section 1: - Reading the introduction, it references RFC9341 and RFC9342, but the read= er misses if this YANG module covers the configuration of the actual protoc= ol (e.g. RFC9343, RFC9947...). I think it is necessary to explicitly say it= , as RFC9341 and RFC9342 cannot be deployed by themselves without the defin= ition of the header (RFC9343, RFC9947, ...). [GF]: Yes, I will clarify this point by adding all the relevant references = (RFC9343, RFC9714, RFC9947). ---- 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 tha= t the YANG module defined in the document cover those encapsulation protoco= ls. - "Note that users can augment this module." -> This is kinda obvious, no? [GF]: Yes I will mention the supported encapsulation protocols in the intro= duction too. ---- Section 3: - The container "altmark-profiles" container is explained in this section. = Fine, however, there is no explanation of what the container "altmark-info"= is. I would suggest adding some text to help the reader understand what th= at container is for. [GF]: Sure, I will clarify that. ---- Section 4: - Please update copyright of the YANG module - The Tree diagram does not match the YANG module. I take the YANG module a= s the one defining this model. [GF]: Yes, I will fix it. - The "feature altmark" is redundant here. Would a router implement this mo= dule without the support of AltMark? Two choices, either (1) remove this fe= ature or (2) leave this feature as is and use this YANG module as reference= in all other AltMark-dependent documents (e.g. use "if-feature 'altmark:al= tmark' " in the draft-ietf-ippm-on-path-telemetry-yang instead of defining = a new one). For simplicity, I prefer option (1). [GF]: I will think about that. I'm considering to change the YANG module an= d put the profiles under the interfaces. In this case we may need if-featur= e at the interface level. - While the feature "altmark" is redundant, I think a router could implemen= t only a subset of the encapsulation protocols (this document covers ipv6, = srh, and mpls). Thus, I suggest adding three features representing the supp= ort of ipv6 [RFC9343], srh [RFC9947] and mpls [RFC9714], each referencing t= heir respective documents. - For each of the identities ipv6, srh and mpls, they depend on the impleme= ntation on the router. Thus I would suggest to add a "if-feature" statement= based on the features ipv6, srh, and mpls. This way, those identities coul= d only be used if they are actually implemented on the router. [GF]: Yes, it is possible to add the if-feature for IPv6, SRH and MPLS glob= ally on the router, and then relate it to the protocol identities. Also, I'= m thinking to add an IANA-maintained YANG module for the protocol identitie= s so it will simplify future AltMark extensions to the YANG module. - I also note here that while this document is Standards Track, there is a = reference to srh [RFC9947], which is Experimental and Independent Submissio= n. I am not sure of the impact of having such reference from the IETF persp= ective. [GF]: The SRH implementation can also be done with RFC9343. I will clarify = this point. - There is an identity "measurement-period". I don't get what this means. S= hould this be removed? [GF]: It is the altmark measurement period we want to configure. I will exp= lain it. - Then there are two identities "flow-mon-id" and "enable-loss-measurement"= . Same here, why do we need those? We only need the leafs defined in the co= nfiguration container. Should these two also be removed? [GF]: Yes they can be removed as identities. - The descriptions from the "grouping measurement-node" are not clear IMO: = "hbh-measurement" and "e2e-measurement" says that these objects indicate wh= ether 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 t= o enabled and disable those measurements rather than referring to capabilit= ies. Please update the description. [GF]: Ok, will update. - Can hbh-measurement" and "e2e-measurement" be enabled at the same time? [GF]: No. - The identities "measurement-mode" are not used (same for the "typedef alt= mark-measurement-mode") [GF]: Ok will remove. - The "leaf flow-mon-id" is not mandatory. What happens if the user does no= t 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 i= s needed. [GF]: If it is not configured, it is pseudo-randomly generated by the node.= I will clarify this point. - In general, on the profile, all the leafs seem to not be mandatory, pleas= e verify if some of them need to be mandatory for a config to be valid. [GF]: Ok, I will doublecheck. - The leaf "enabled" from the grouping "altmark-admin-config" says "It MUST= be true before anything in the /altmark/altmark-profile can be edited. If = false, any configuration in place is not used.". It feels weird having this= sentence. Does this mean the router needs to perform 2 NETCONF transaction= s to configure AltMark? One to enable this node first, then a second one wi= th the profile? If this constraint is needed, I would suggest implementing = this constraint with a "when" statement from YANG in the /altmark/altmark-p= rofile list, but I don't think it is needed. [GF]: Ok, we have chosen it to be aligned with IOAM Yang model in RFC 9617.= But we can now change it. - Having the "enabled" leaf at the top also means that *all* profiles are e= nabled on the node. Is this what the authors wanted, or should the "enable"= node be implemented on the profile level? [GF]: Yes, this is what we wanted. - The container "AltMark" uses camelCase. I would suggest to avoid camelCas= e in a YANG, maybe use "altmark" instead? [GF]: Ok, I will replace with altmark. - I am not fully getting what the "list available-interface" means. The des= cription says "A list of available interfaces that support Alternate-Markin= g.". 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 inter= face not supporting AltMark? I think this needs to be clarified, if AltMark= is configured on a per-interface basis, maybe the "enable" leaf needs to b= e moved to the profile level. [GF]: It is designed to be enabled on the interfaces. - Finally, please fix the indentations from the YANG module. The current re= vision is not well-formatted. [GF]: Ok Regards, Alex On 7 May 2026, at 12:03, Marcus Ihlar via Datatracker <[email protected]<mai= lto:[email protected]>> wrote: This message starts a WG Last Call for: draft-ietf-ippm-alt-mark-yang-02 This Working Group Last Call ends on 2026-05-28 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. 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. File can be retrieved from: Please review and indicate your support or objection to proceed with the publication of this document by replying to this email keeping [email protected]= g<mailto:[email protected]> in copy. Objections should be explained and suggestions to resolve them are highly appreciated. 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 provisio= ns 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]. Thank you. [1] https://datatracker.ietf.org/doc/bcp78/ [2] https://datatracker.ietf.org/doc/bcp79/ [3] https://datatracker.ietf.org/doc/rfc6701/ The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-yang/ There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-yang-02 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-alt-mark-yang-0= 2 _______________________________________________ ippm mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:ippm-leave@ietf.= org> --_000_c600eaa3362a48008ce031b3ae84f145huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} span.EmailStyle18 {mso-style-type:personal-reply; font-family:"Calibri",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea= k-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal">Hi Alex,<o:p></o:p></p> <p class=3D"MsoNormal">Thanks a lot for your review.<o:p></o:p></p> <p class=3D"MsoNormal">Please see inline [GF].<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Regards,<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Giuseppe<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in"> <p class=3D"MsoNormal"><b>From:</b> Alex Huang Feng <alex.huang-feng@ins= a-lyon.fr> <br> <b>Sent:</b> Wednesday, June 3, 2026 1:42 PM<br> <b>To:</b> Marcus Ihlar <marcus.ihlar-IzeFyvvaP7pWk0Htik3J/[email protected]>; draft-ietf-ippm-= [email protected]<br> <b>Cc:</b> [email protected]; [email protected]; [email protected]; bmwg-chairs@= ietf.org<br> <b>Subject:</b> Re: [ippm] WG Last Call: draft-ietf-ippm-alt-mark-yang-02 (= Ends 2026-05-28)<o:p></o:p></p> </div> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">Dear Marcus, alt-mark-yang authors, IPPM and BMWG,<o= :p></o:p></p> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I was reviewing draft-ietf-ippm-on-path-telemetry-ya= ng but ended up here as that draft had a normative reference to draft-ietf-= ippm-alt-mark-yang.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I support the progress of this document. However, I = don’t think it is ready for publication. At least, a new iteration is= needed improving the descriptions to remove ambiguity.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">I’ll go by sections:<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">---- Abstract:<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">- I would suggest to use “YANG module” i= nstead of “YANG data model”. There was some discussions around = the usage of these terms at OPSAWG.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Ok<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">---- Section 1:<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">- Reading the introduction, it references RFC9341 an= d RFC9342, but the reader misses if this YANG module covers the configurati= on of the actual protocol (e.g. RFC9343, RFC9947…). I think it is nec= essary to explicitly say it, as RFC9341 and RFC9342 cannot be deployed by themselves without the definition of the= header (<span style=3D"color:black">RFC9343, RFC9947, …</span>)= .<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Yes, I will clarify this point by adding all t= he relevant references (RFC9343, RFC9714, RFC9947).<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">---- Section 2:<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">- The encapsulation protocols are referenced here. W= hile 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 thos= e encapsulation protocols.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">- "Note that users can augment this module= .” —> This is kinda obvious, no?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Yes I will mention the supported encapsulation= protocols in the introduction too.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">---- Section 3:<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">- The container “altmark-profiles” conta= iner is explained in this section. Fine, however, there is no explanation o= f what the container "altmark-info” is. I would suggest adding s= ome text to help the reader understand what that container is for.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Sure, I will clarify that.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">---- Section 4:<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">- Please update copyright of the YANG module<o:p></o= :p></p> </div> <div> <p class=3D"MsoNormal">- The Tree diagram does not match the YANG module. I= take the YANG module as the one defining this model.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Yes, I will fix it.<o:p></o:p></p> <p class=3D"MsoNormal" style=3D"text-indent:.5in"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- The “feature altmark” is redundant her= e. 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 an= d use this YANG module as reference in all other AltMark-dependent documents (e.g. use “if-feature ‘altmark:alt= mark’ ” in the <span style=3D"color:black">draft-ietf-ippm= -on-path-telemetry-yang instead of defining a new one</span>). For simplici= ty, I prefer option (1).<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: I will think about that. I’m considering= to change the YANG module and put the profiles under the interfaces. In th= is case we may need if-feature at the interface level.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- While the feature “altmark” is redunda= nt, I think a router could implement only a subset of the encapsulation pro= tocols (this document covers ipv6, srh, and mpls). Thus, I suggest adding t= hree features representing the support of ipv6 [RFC9343], srh [RFC9947] and mpls [RFC9714], each referencing their respec= tive documents. <o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">- For each of the identities ipv6, srh and mpls, the= y depend on the implementation on the router. Thus I would suggest to add a= “if-feature” statement based on the features ipv6, srh, and mp= ls. This way, those identities could only be used if they are actually implemented on the router.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Yes, it is possible to add the if-feature for = IPv6, SRH and MPLS globally on the router, and then relate it to the protoc= ol identities. Also, I’m thinking to add an IANA-maintained YANG modu= le for the protocol identities so it will simplify future AltMark extensions to the YANG module.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- I also note here that while this document is Stand= ards Track, there is a reference to srh [RFC9947], which is Experimental an= d Independent Submission. I am not sure of the impact of having such refere= nce from the IETF perspective.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: The SRH implementation can also be done with R= FC9343. I will clarify this point.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- There is an identity “measurement-periodR= 21;. I don’t get what this means. Should this be removed?<o:p></o:p><= /p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: It is the altmark measurement period we want t= o configure. I will explain it.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- Then there are two identities “flow-mon-id&#= 8221; and “enable-loss-measurement”. Same here, why do we need = those? We only need the leafs defined in the configuration container. Shoul= d these two also be removed?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Yes they can be removed as identities.<o:p></o= :p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><span style=3D"color:black">- The descriptions from = the “grouping measurement-node” are not clear IMO: "</span= >hbh-measurement" and "e2e-measurement" says that these obje= cts 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 tho= se nodes are used to enabled and disable those measurements rather than ref= erring to capabilities. Please update the description.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Ok, will update.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- Can hbh-measurement” and “e2e-measurem= ent” be enabled at the same time?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: No.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- The identities “measurement-mode” are = not used (same for the “typedef altmark-measurement-mode”)<o:p>= </o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Ok will remove.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- The “leaf flow-mon-id” is not mandator= y. What happens if the user does not configure this flow-mon-id? Reading&nb= sp;<a href=3D"https://datatracker.ietf.org/doc/html/rfc9343#name-data-field= s-format">https://datatracker.ietf.org/doc/html/rfc9343#name-data-fields-fo= rmat</a>, this value MUST be set by the controller. So, should this value be mandato= ry in the YANG module? If not, some text is needed.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: If it is not configured, it is pseudo-randomly= generated by the node. I will clarify this point.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- 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.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Ok, I will doublecheck.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- The leaf “enabled” from the grouping &= #8220;altmark-admin-config” says "It MUST be true before anythin= g in the /altmark/altmark-profile can be edited. If false, any configuratio= n in place is not used.”. It feels weird having this sentence. Does this mean the router needs to perform 2 NETCONF transactions to confi= gure AltMark? One to enable this node first, then a second one with the pro= file? If this constraint is needed, I would suggest implementing this const= raint with a “when” statement from YANG in the /altmark/altmark-profile list, but I don’t think it is n= eeded.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Ok, we have chosen it to be aligned with IOAM = Yang model in RFC 9617. But we can now change it.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- Having the “enabled” leaf at the top a= lso means that *all* profiles are enabled on the node. Is this what the aut= hors wanted, or should the “enable” node be implemented on the = profile level?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Yes, this is what we wanted.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- The container “AltMark” uses camelCase= . I would suggest to avoid camelCase in a YANG, maybe use “altmark= 221; instead?<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Ok, I will replace with altmark.<o:p></o:p></p= > <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- I am not fully getting what the "list availab= le-interface” means. The description says “A list of available = interfaces that support Alternate-Marking.”.<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">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 b= e clarified, if AltMark is configured on a per-interface basis, maybe the “enable" leaf needs to be m= oved to the profile level.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: It is designed to be enabled on the interfaces= .<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">- Finally, please fix the indentations from the YANG= module. The current revision is not well-formatted.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> <p class=3D"MsoNormal">[GF]: Ok<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal">Regards,<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal">Alex<o:p></o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> <div> <div> <blockquote style=3D"margin-top:5.0pt;margin-bottom:5.0pt"> <div> <p class=3D"MsoNormal">On 7 May 2026, at 12:03, Marcus Ihlar via Datatracke= r <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<o= :p></o:p></p> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> <div> <div> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt">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 <a href=3D"m= ailto:[email protected]"> [email protected]</a><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<b= r> Property Rights (IPR) disclosure obligations described in BCP 79 [1].<br> Appropriate IPR disclosures required for full conformance with the provisio= ns<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] <a href=3D"https://datatracker.ietf.org/doc/bcp78/">https://datatracker= .ietf.org/doc/bcp78/</a><br> [2] <a href=3D"https://datatracker.ietf.org/doc/bcp79/">https://datatracker= .ietf.org/doc/bcp79/</a><br> [3] <a href=3D"https://datatracker.ietf.org/doc/rfc6701/">https://datatrack= er.ietf.org/doc/rfc6701/</a><br> <br> The IETF datatracker status page for this Internet-Draft is:<br> <a href=3D"https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-yang/"= >https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark-yang/</a><br> <br> There is also an HTMLized version available at:<br> <a href=3D"https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-y= ang-02">https://datatracker.ietf.org/doc/html/draft-ietf-ippm-alt-mark-yang= -02</a><br> <br> A diff from the previous version is available at:<br> <a href=3D"https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-alt-= mark-yang-02">https://author-tools.ietf.org/iddiff?url2=3Ddraft-ietf-ippm-a= lt-mark-yang-02</a><br> <br> _______________________________________________<br> ippm mailing list -- <a href=3D"mailto:[email protected]">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]">ippm= [email protected]</a><br> <br> <br> <br> <o:p></o:p></p> </div> </div> </blockquote> </div> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </div> </body> </html> --_000_c600eaa3362a48008ce031b3ae84f145huaweicom_-- --===============2574105683078781726== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KaXBwbSBtYWls aW5nIGxpc3QgLS0gaXBwbUBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IGlwcG0tbGVhdmVAaWV0Zi5vcmcK --===============2574105683078781726==--