Hi Med, All, Thank you for the review and detailed comments and suggestions. I have implemented the changes as per the comments below.
YANG validation now has 0 errors, 0 warnings, - thanks for the proposed change. Please see diff for the changes. https://author-tools.ietf.org/iddiff?url2=draft-jlu-dmm-udp-tunnel-acaas-02 Best Regards, John > -----Original Message----- > From: [email protected] > <[email protected]> > Sent: Friday, November 28, 2025 3:25 AM > To: Kaippallimalil John <[email protected]>; opsawg > <[email protected]>; [email protected] > Cc: Satoru Matsushima <[email protected]>; Sri Gundavelli > (sgundave) <[email protected]> > Subject: RE: Request for OPSAWG review of draft-jlu-dmm-udp-tunnel-acaas- > 01 > > Ho John, all, > > Please find below some few (minor) comments about this version: > > (1) Fix a validation warning > > The datatracker shows this warning: "libyang warn: Schema node "type" for > parent "/ietf-ac-svc:attachment-circuits/ac/ip-connection/l3-service/l3- > tunnel-service/l3-tunnel-service" not found; in expr "derived-from-or- > self(./type" with context node "/ietf-ac-svc:attachment-circuits/ac/ip- > connection/l3-service/l3-tunnel-service/l3-tunnel-service"." > > You can fix that as follows: > > OLD: > augment "/ac-svc:attachment-circuits/ac-svc:ac" > + "/ac-svc:ip-connection/ac-svc:l3-service" > + "/ac-svc:l3-tunnel-service/ac-svc:l3-tunnel-service" { > when "derived-from-or-self(./type, 'ac-udpt:udp')" { > ^^^^^^^^ > > NEW: > augment "/ac-svc:attachment-circuits/ac-svc:ac" > + "/ac-svc:ip-connection/ac-svc:l3-service" > + "/ac-svc:l3-tunnel-service/ac-svc:l3-tunnel-service" { > when "derived-from-or-self(./ac-svc:type, 'ac-udpt:udp')" { > > > (2) Update all AC I-D references to point the published RFCs. > > (3) Although this is an example, consider adding a reference for GTP-U for > readers convenience > > CURRENT: > An example of Layer 3 UDP > tunnel as a bearer is in 5G networks where a GTP-U (UDP) bearer is > used to transport datagrams of a mobile end-user between 3GPP user > plane functions. > > (4) Better description > > OLD: > Section 2 describes the "ietf-ac-udpt" YANG module > for Layer 3 UDP tunnel service. Section 3 describes the UDP tunnel > YANG data model. > > NEW: > Section 2 describes the "ietf-ac-udpt" YANG module > for Layer 3 UDP tunnel service defined in Section 3. > > (5) Bearers > > OLD: > [I-D.ietf-opsawg-teas-attachment-circuit] defines a YANG service > model for AC based on layer 2 bearers. > > NEW: > [I-D.ietf-opsawg-teas-attachment-circuit] defines a YANG service > model for AC based on underlying bearers. > > A bearer is a defined as a logical link. Better to add restrictions on what > is a > bearer in this doc. > > # Add 8085 to the informative references > > CURRENT: > reference > "RFC 8085: UDP Usage Guidelines, Section 3.1.11"; > > # Update the second par of Section 5 to follow the template in 8407bis > > # Normative references > > The following should be listed as normative: > > [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, > DOI 10.17487/RFC3688, January 2004, > > <https://w/ > ww.rfc- > editor.org%2Finfo%2Frfc3688&data=05%7C02%7Cjohn.kaippallimalil%40fut > urewei.com%7Cbb6520e8772b443c808e08de2e6349b5%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C0%7C638999201156050934%7CUnknown > %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=sMU6mbVJans%2BY5AfjnHcpgnQmkU7lzVdp%2FvKQAdQRog%3D&reser > ved=0>. > > [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for > the Network Configuration Protocol (NETCONF)", RFC 6020, > DOI 10.17487/RFC6020, October 2010, > > <https://w/ > ww.rfc- > editor.org%2Finfo%2Frfc6020&data=05%7C02%7Cjohn.kaippallimalil%40fut > urewei.com%7Cbb6520e8772b443c808e08de2e6349b5%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C0%7C638999201156079530%7CUnknown > %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=EbkBSlf5ig69XcY%2Br3T1FjG7uTW6VVlX9WXhddK3hgM%3D&reserved= > 0>. > > [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration > Access Control Model", STD 91, RFC 8341, > DOI 10.17487/RFC8341, March 2018, > > <https://w/ > ww.rfc- > editor.org%2Finfo%2Frfc8341&data=05%7C02%7Cjohn.kaippallimalil%40fut > urewei.com%7Cbb6520e8772b443c808e08de2e6349b5%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C0%7C638999201156097313%7CUnknown > %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=qi%2Fy%2FgVVxl27mbGf2S3sOTuTPBBIdKPhZ4sW4BsDBiI%3D&reserved > =0>. > > # Unused reference > > This one is not used: > > [RFC8972] Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., > and E. Ruffini, "Simple Two-Way Active Measurement > Protocol Optional Extensions", RFC 8972, > DOI 10.17487/RFC8972, January 2021, > > <https://w/ > ww.rfc- > editor.org%2Finfo%2Frfc8972&data=05%7C02%7Cjohn.kaippallimalil%40fut > urewei.com%7Cbb6520e8772b443c808e08de2e6349b5%7C0fee8ff2a3b24 > 0189c753a1d5591fedc%7C1%7C0%7C638999201156115792%7CUnknown > %7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > ata=0bTkRXXg%2Bfhid9%2FJ1hfyUndgL5J5N1YSDaSY2mWYRjI%3D&reserve > d=0>. > > # RFC 8792 needs to be cited as reference as this is needed for unfolding > > CURRENT: > > =============== NOTE: '\' line wrapping per RFC 8792 ================ > > # Move " Appendix A. Abbreviations" to be listed in the main document. You > can put it right under a terminology section. > > Hope this helps. > > Cheers, > Med > > > -----Message d'origine----- > > De : Kaippallimalil John <[email protected]> > > Envoyé : jeudi 6 novembre 2025 16:46 > > À : opsawg <[email protected]>; [email protected]; Mahesh Jethanandani > > <[email protected]>; BOUCADAIR Mohamed INNOV/NET > > <[email protected]> Cc : Satoru Matsushima > > <[email protected]>; Sri Gundavelli (sgundave) > > <[email protected]> Objet : Request for OPSAWG review of > > draft-jlu-dmm-udp-tunnel- > > acaas-01 > > > > > > Hi, > > > > In the DMM session on Monday (11/03) the draft-jlu-dmm-udp-tunnel- > > acaas-01 was discussed and the chairs (copied here) plan to issue a WG > > adoption call in the next couple of weeks. > > > > We would like to request reviews from OPSAWG as this draft has YANG > > model for Layer 3 (UDP) ACaaS. > > > > Link to the draft: > > [draft-jlu-dmm-udp-tunnel-acaas-01]: > > > https://fra0/ > > > 1.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252F > &dat > > > a=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7Cbb6520e8772b44 > 3c808e > > > 08de2e6349b5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63 > 8999201156 > > > 131657%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi > OiIwLjAuMDA > > > wMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C > %7C&sda > > > ta=ts0wM4iFpME2CVqp%2BcSbCmoKTO1QJ7oZcfa31iEJK10%3D&reserved= > 0 > > author-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-jlu-dmm-udp-tunnel- > > acaas- > > > 01&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cc6092ec0a > 098474 > > > 72b4b08de1d4b9d62%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C > 0%7C638 > > > 980407777425213%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn > RydWUsIl > > > YiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D > > > %7C0%7C%7C%7C&sdata=4TyCfTJ3cI%2BaqUvbYrYabSH4JghmWFVwZ1Ozik > dxzgU% > > 3D&reserved=0 > > > > Thanks, > > John > ___________________________________________________________________ > _________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
