Hi Alanna, > On Aug 13, 2025, at 12:01 PM, Alanna Paloma <apal...@staff.rfc-editor.org> > wrote: > > Hi Mahesh, > > We have slightly updated your suggested text; see below. > > Additionally, we have a clarifying question. Should the section citation be > updated to match the template (Section 3.7 vs. Section 3.7.1)? > > Current: > The remainder of this section is modeled after the template described > in Section 3.7 of [YANG-GUIDELINES]. > > Template (https://wiki.ietf.org/group/ops/yang-security-guidelines): > This section is modeled after the template described in Section 3.7.1 > of [RFC-to-be draft-ietf-netmod-rfc8407bis].
Reference should be to Section 3.7.1. Thanks for catching it. I am not sure of the first line though that starts with “Template (https://…)”. That would be odd, as we have the reference to the template in rfc8407bis already. Giving another reference, this time to the wiki would be a duplicate reference. Please drop that line. Cheers. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9834.xml > https://www.rfc-editor.org/authors/rfc9834.txt > https://www.rfc-editor.org/authors/rfc9834.html > https://www.rfc-editor.org/authors/rfc9834.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9834-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9834-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9834-auth48rfcdiff.html (AUTH48 changes > side by side) > > Thank you, > RFC Editor/ap > >> On Aug 13, 2025, at 10:35 AM, Mahesh Jethanandani <mjethanand...@gmail.com> >> wrote: >> >> Hi Alanna, >> >> Thanks for making the changes. Just one nit. Can we say? >> >> OLD: >> This section is modeled after the template described ... >> >> NEW: >> The remaining section is modeled after the template described … >> >> Thanks. >> >> >>> On Aug 13, 2025, at 9:27 AM, Alanna Paloma <apal...@staff.rfc-editor.org> >>> wrote: >>> >>> Hi Mahesh, >>> >>> Thank you for your reply. We have updated the Security Considerations >>> section accordingly; see the files below. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9834.xml >>> https://www.rfc-editor.org/authors/rfc9834.txt >>> https://www.rfc-editor.org/authors/rfc9834.html >>> https://www.rfc-editor.org/authors/rfc9834.pdf >>> >>> The relevant diff files have been posted here: >>> https://www.rfc-editor.org/authors/rfc9834-diff.html (comprehensive diff) >>> https://www.rfc-editor.org/authors/rfc9834-auth48diff.html (AUTH48 changes) >>> https://www.rfc-editor.org/authors/rfc9834-auth48rfcdiff.html (AUTH48 >>> changes side by side) >>> >>> For the AUTH48 status of this document, please see: >>> https://www.rfc-editor.org/auth48/rfc9834 >>> >>> Thank you, >>> RFC Editor/ap >>> >>>> On Aug 12, 2025, at 10:00 PM, Mahesh Jethanandani >>>> <mjethanand...@gmail.com> wrote: >>>> >>>> Hi Alice, >>>> >>>>> On Aug 11, 2025, at 10:48 PM, rfc-edi...@rfc-editor.org wrote: >>>>> >>>>> Authors, AD, >>>>> >>>>> * Mahesh (as AD), please reply to #13. >>>>> >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) the following questions, which are also in the XML file. >>>>> >>>>> 1) <!--[rfced] In the RFC's title, we suggest removing the single quotes >>>>> and hyphens. Other expansions of "ACaaS" in the document and the related >>>>> documents would be updated accordingly. Is the suggested title >>>>> acceptable? (This is similar to how "Software as a Service (SaaS)" >>>>> typically does not appear with hyphens when used as a noun.) >>>>> >>>>> Original: >>>>> YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service >>>>> (ACaaS) >>>>> >>>>> Suggested: >>>>> YANG Data Models for Bearers and Attachment Circuits as a Service (ACaaS) >>>>> --> >>>>> >>>>> >>>>> 2) <!--[rfced] In the second sentence below, does the customer >>>>> retrieve "a reference" or "an indication" or something else? >>>>> >>>>> Original: >>>>> The customers can then retrieve a provider-assigned bearer reference that >>>>> they will include in their AC service requests. Likewise, a customer >>>>> may retrieve whether their bearers support a synchronization >>>>> mechanism such as Sync Ethernet (SyncE) [ITU-T-G.781]. >>>>> >>>>> Perhaps: >>>>> The customers can then retrieve a provider-assigned bearer reference that >>>>> they will include in their AC service requests. Likewise, a customer >>>>> may retrieve a reference if their bearers support a synchronization >>>>> mechanism such as Sync Ethernet (SyncE) [ITU-T-G.781]. >>>>> --> >>>>> >>>>> >>>>> 3) <!--[rfced] FYI, we have reformatted some of the definitions in the >>>>> "Conventions and Definitions" section to reflect what appears in >>>>> RFCs-to-be 9833 and 9835. Please review and let us know any changes. >>>>> --> >>>>> >>>>> >>>>> 4) <!--[rfced] We note that the definitions for "Network controller" and >>>>> "Service orchestrator" in RFC-to-be 9835 each have an additional sentence >>>>> that does not appear in the definition in this document. Should this >>>>> sentence be added? (Specifically, "One or multiple..." and "A service >>>>> orchestrator may interact..." are the additional sentences.) >>>>> >>>>> This document (current): >>>>> Network controller: Denotes a functional entity responsible for the >>>>> management of the service provider network. >>>>> ... >>>>> Service orchestrator: Refers to a functional entity that interacts >>>>> with the customer of a network service. >>>>> >>>>> A service orchestrator is typically responsible for the attachment >>>>> circuits, the PE selection, and requesting the activation of the >>>>> requested service to a network controller. >>>>> >>>>> RFC-to-be 9835: >>>>> Network controller: Denotes a functional entity responsible for the >>>>> management of the service provider network. One or multiple >>>>> network controllers can be deployed in a service provider network. >>>>> ... >>>>> Service orchestrator: Refers to a functional entity that interacts >>>>> with the customer of a network service. >>>>> >>>>> A service orchestrator is typically responsible for the attachment >>>>> circuits, the Provider Edge (PE) selection, and requesting the >>>>> activation of the requested services to a network controller. >>>>> >>>>> A service orchestrator may interact with one or more network >>>>> controllers. >>>>> --> >>>>> >>>>> >>>>> 5) <!--[rfced] Since "L2VPN" and "L3VPN" are defined prior to these terms >>>>> listed >>>>> and to make the definitions more concise, may we update to "LxVPN"? Note >>>>> that >>>>> this would also match the text in RFC-to-be 9835. >>>>> >>>>> Original: >>>>> Service provider network: A network that is able to provide network >>>>> services (e.g., Layer 2 VPN, Layer 3 VPN, or Network Slice >>>>> Services). >>>>> >>>>> Service provider: An entity that offers network services (e.g., >>>>> Layer 2 VPN, Layer 3 VPN, or Network Slice Services). >>>>> >>>>> Perhaps: >>>>> Service provider network: A network that is able to provide network >>>>> services (e.g., LxVPN or Network Slice Services). >>>>> >>>>> Service provider: An entity that offers network services (e.g., >>>>> LxVPN or Network Slice Services). >>>>> --> >>>>> >>>>> >>>>> 6) <!--[rfced] Figure 5 uses "CE#1" and "CE#2", while other figures in the >>>>> document use "CE1" and "CE2". May we update the CEs in Figure 5 to match >>>>> the other figures in the document? >>>>> >>>>> If so, both artworks (svg and ascii-art) will be updated accordingly. >>>>> --> >>>>> >>>>> >>>>> 7) <!--[rfced] To avoid repetition of "future", may we remove "in the >>>>> future" from this sentence? >>>>> >>>>> Original: >>>>> Future placement criteria >>>>> ('constraint-type') may be defined in the future to accommodate >>>>> specific deployment contexts. >>>>> >>>>> Perhaps: >>>>> Future placement criteria >>>>> ('constraint-type') may be defined to accommodate specific deployment >>>>> contexts. >>>>> --> >>>>> >>>>> >>>>> 8) <!--[rfced] To avoid redundancy, may we remove "when requesting a >>>>> bearer"? >>>>> >>>>> Original: >>>>> A bearer request can indicate a device, a site, a >>>>> combination thereof, or a custom information when requesting a >>>>> bearer. >>>>> >>>>> Perhaps: >>>>> A bearer request can indicate a device, a site, a >>>>> combination thereof, or custom information. >>>>> --> >>>>> >>>>> >>>>> 9) <!--[rfced] To avoid redundancy, may we remove "actually"? Note that >>>>> there >>>>> are a number of other places throughout the document with similar >>>>> phrasing, >>>>> which would also be updated. >>>>> >>>>> Original: >>>>> 'actual-start': Reports the actual date and time when the bearer >>>>> actually was enabled. >>>>> >>>>> Perhaps: >>>>> >>>>> 'actual-start': Reports the actual date and time when the bearer >>>>> was enabled. >>>>> --> >>>>> >>>>> >>>>> 10) <!--[rfced] For clarity, may we update "by an identifier" to "of an >>>>> identifier"? >>>>> >>>>> Original: >>>>> All the above mentioned profiles are uniquely identified by the >>>>> provider server by an identifier. >>>>> >>>>> Perhaps: >>>>> All the above mentioned profiles are uniquely identified by the >>>>> provider server of an identifier. >>>>> --> >>>>> >>>>> >>>>> 11) <!--[rfced] We note that RFC 4271 is only cited in the "ietf-ac-svc" >>>>> YANG >>>>> module. In order to have a 1:1 matchup between the references section >>>>> and the text, may we add it to the RFCs listed prior to the YANG module >>>>> and add a normative reference for it? >>>>> >>>>> Original: >>>>> This module uses types defined in [RFC6991], [RFC9181], [RFC8177], >>>>> and [I-D.ietf-opsawg-teas-common-ac]. >>>>> >>>>> Perhaps:: >>>>> This module uses types defined in [RFC4271], [RFC6991], [RFC9181], >>>>> [RFC8177], >>>>> and [RFC9833]. >>>>> ... >>>>> [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A >>>>> Border Gateway Protocol 4 (BGP-4)", RFC 4271, >>>>> DOI 10.17487/RFC4271, January 2006, >>>>> <https://www.rfc-editor.org/info/rfc4271>. >>>>> --> >>>>> >>>>> >>>>> 12) <!--[rfced] FYI, the YANG module "ietf-ac-svc" has been updated per >>>>> the >>>>> formatting option of pyang. Please let us know any concerns. >>>>> (No changes were needed for "ietf-bearer-svc".) >>>>> --> >>>>> >>>>> >>>>> 13) <!--[rfced] *AD - We note that there is some text in the >>>>> Security Considerations section that differs from the template on >>>>> <https://wiki.ietf.org/group/ops/yang-security-guidelines>. >>>>> Please review and let us know if the text is acceptable. >>>>> >>>>> For example: >>>>> - Paragraph 3, the first 2 sentences are not from the template: >>>>> >>>>> "Servers MUST verify that requesting clients are entitled to access >>>>> and manipulate a given bearer or AC. For example, a given customer >>>>> must not have access to bearers/ACs of other customers." >>>> >>>> That is ok to add, while maintaining the rest of the statements from the >>>> template. >>>> >>>>> >>>>> - This sentence is not present: >>>>> "There are no particularly sensitive RPC or action operations." >>>>> If it should be added, should it be at the end of the section? >>>> >>>> Yes, it should be added to the end of the section. >>>> >>>>> >>>>> From the guidelines page: >>>>> If the data model contains any particularly sensitive RPC or action >>>>> operations, then those operations must be listed here, along with an >>>>> explanation of the associated specific sensitivity or vulnerability >>>>> concerns. Otherwise, state: "There are no particularly sensitive RPC or >>>>> action operations." >>>>> >>>>> - The last two paragraphs (after the readable nodes section) do >>>>> not seem to be within a section of the template. >>>>> --> >>>> >>>> >>>> These two paragraphs can be moved to the beginning of the Security >>>> Considerations section before the statement that says “This section is >>>> modeled after the template …”, just to be clear that it is not part of the >>>> template. Alternatively, they could be moved into a sub-section. >>>> >>>> Thanks. >>>> >>>>> >>>>> >>>>> >>>>> 14) <!--[rfced] "Step (3)" does not seem accurate here. Does it refer to >>>>> item 3 >>>>> in the list of assumptions, i.e., "3. The customer provisions the >>>>> networking >>>>> logic..."? If so, may it be updated as follows? >>>>> >>>>> Original: >>>>> * The Cloud Provider for the configuration per Step (3) above. >>>>> >>>>> Perhaps: >>>>> * The Cloud Provider for the configuration per item 3 above. >>>>> --> >>>>> >>>>> >>>>> 15) <!--[rfced] We note that this text was indented. As it is unclear to >>>>> us why >>>>> it was indented, we have removed the indentation. Was the intent for this >>>>> to be a "Note"? If yes, would you like this text to be in an <aside> >>>>> element, >>>>> which is defined as "a container for content that is semantically less >>>>> important >>>>> or tangential to the content that surrounds it" >>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). >>>>> >>>>> Original: >>>>> The module supports MD5 to basically accommodate the installed BGP >>>>> base (including by some Cloud Providers). Note that MD5 suffers >>>>> from the security weaknesses discussed in Section 2 of [RFC6151] >>>>> and Section 2.1 of [RFC6952]. >>>>> >>>>> Perhaps: >>>>> | Note: The module supports MD5 to basically accommodate the installed >>>>> | BGP base (including by some Cloud Providers). Note that MD5 suffers >>>>> | from the security weaknesses discussed in Section 2 of [RFC6151] >>>>> | and Section 2.1 of [RFC6952]. >>>>> --> >>>>> >>>>> >>>>> 16) <!--[rfced] To clarify the citation of >>>>> I-D.ietf-opsawg-ac-lxsm-lxnm-glue >>>>> (RFC-to-be 9836), we have added "AC Glue" preceding it. Please review >>>>> and let us know if further updates are needed. >>>>> >>>>> Original: >>>>> In any case, the parent >>>>> AC is a stable identifier, which can be consumed as a reference by >>>>> end-to-end service models for VPN configuration such as >>>>> [I-D.ietf-opsawg-ac-lxsm-lxnm-glue], Slice Service >>>>> [I-D.ietf-teas-ietf-network-slice-nbi-yang], etc. >>>>> >>>>> Current: >>>>> In any case, the parent >>>>> AC is a stable identifier, which can be consumed as a reference by >>>>> end-to-end service models for VPN configuration such as >>>>> AC Glue [RFC9836], Slice Service [NSSM], etc. >>>>> --> >>>>> >>>>> >>>>> 17) <!-- [rfced] FYI - We updated artwork to sourcecode in Sections 5.1, >>>>> 5.2.1, >>>>> 5.2.2.1, 5.2.4, 5.2.5, 5.2.5.1, 5.2.5.2, 5.2.5.3, 5.2.5.3.1, 5.2.5.3.2, >>>>> 5.2.5.3.3, 5.2.5.3.4, 5.2.5.3.5, 5.2.5.3.6, 5.2.5.4, 5.2.5.5, and 5.2.5.6 >>>>> and Appendix B. Please review whether this is correct. We note that a >>>>> YANG tree diagram is typically held in a sourcecode element >>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#sourcecode). >>>>> >>>>> In addition, please review the "type" attribute of each sourcecode element >>>>> in the XML file to ensure correctness. >>>>> >>>>> The current list of preferred values for "type" is available at >>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. >>>>> If the current list does not contain an applicable type, feel free to >>>>> suggest additions for consideration. Note that it is also acceptable >>>>> to leave the "type" attribute not set. >>>>> --> >>>>> >>>>> >>>>> 18) <!--[rfced] Abbreviations >>>>> >>>>> a) Both the expansion and the acronym for the following terms are used >>>>> throughout the document. Would you like to update to using the expansion >>>>> upon >>>>> first usage and the acronym for the rest of the document? >>>>> >>>>> attachment circuit (AC) >>>>> Customer Edge (CE) >>>>> Layer 2 VPN (L2VPN) >>>>> Layer 3 VPN (L3VPN) >>>>> Service Function (SF) >>>>> >>>>> >>>>> b) FYI - We have added expansions for the following abbreviations >>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>>> expansion in the document carefully to ensure correctness. >>>>> >>>>> Customer VLAN (CVLAN) >>>>> IP Address Management (IPAM) >>>>> Layer 2 VPN (L2VPN) >>>>> Layer 3 VPN (L3VPN) >>>>> Network Configuration Protocol (NETCONF) >>>>> --> >>>>> >>>>> >>>>> 19) <!-- [rfced] Terminology >>>>> >>>>> a) Throughout the text, the following terminology appears to be used >>>>> inconsistently. Please review these occurrences and let us know if/how >>>>> they >>>>> may be made consistent. >>>>> >>>>> Network Slice Service vs. Slice Service vs. IETF Network Slice Service >>>>> >>>>> b) To reflect how "parent AC" is consistently lowercase, may we update >>>>> instances of "Child AC" to "child AC"? Note that there is mixed usage >>>>> throughout the document. >>>>> --> >>>>> >>>>> >>>>> 20) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>> online >>>>> Style Guide >>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>>> and let us know if any changes are needed. Updates of this nature >>>>> typically >>>>> result in more precise language, which is helpful for readers. >>>>> >>>>> For example, please consider whether the following should be updated: >>>>> natively >>>>> --> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> RFC Editor/ap/ar >>>>> >>>>> >>>>> On Aug 11, 2025, rfc-edi...@rfc-editor.org wrote: >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2025/08/11 >>>>> >>>>> RFC Author(s): >>>>> -------------- >>>>> >>>>> Instructions for Completing AUTH48 >>>>> >>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>> approved by you and all coauthors, it will be published as an RFC. >>>>> If an author is no longer available, there are several remedies >>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>> >>>>> You and you coauthors are responsible for engaging other parties >>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>> your approval. >>>>> >>>>> Planning your review >>>>> --------------------- >>>>> >>>>> Please review the following aspects of your document: >>>>> >>>>> * RFC Editor questions >>>>> >>>>> Please review and resolve any questions raised by the RFC Editor >>>>> that have been included in the XML file as comments marked as >>>>> follows: >>>>> >>>>> <!-- [rfced] ... --> >>>>> >>>>> These questions will also be sent in a subsequent email. >>>>> >>>>> * Changes submitted by coauthors >>>>> >>>>> Please ensure that you review any changes submitted by your >>>>> coauthors. We assume that if you do not speak up that you >>>>> agree to changes submitted by your coauthors. >>>>> >>>>> * Content >>>>> >>>>> Please review the full content of the document, as this cannot >>>>> change once the RFC is published. Please pay particular attention to: >>>>> - IANA considerations updates (if applicable) >>>>> - contact information >>>>> - references >>>>> >>>>> * Copyright notices and legends >>>>> >>>>> Please review the copyright notice and legends as defined in >>>>> RFC 5378 and the Trust Legal Provisions >>>>> (TLP – https://trustee.ietf.org/license-info). >>>>> >>>>> * Semantic markup >>>>> >>>>> Please review the markup in the XML file to ensure that elements of >>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>> and <artwork> are set correctly. See details at >>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>> >>>>> * Formatted output >>>>> >>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>> formatted output, as generated from the markup in the XML file, is >>>>> reasonable. Please note that the TXT will have formatting >>>>> limitations compared to the PDF and HTML. >>>>> >>>>> >>>>> Submitting changes >>>>> ------------------ >>>>> >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>> the parties CCed on this message need to see your changes. The parties >>>>> include: >>>>> >>>>> * your coauthors >>>>> >>>>> * rfc-edi...@rfc-editor.org (the RPC team) >>>>> >>>>> * other document participants, depending on the stream (e.g., >>>>> IETF Stream participants are your working group chairs, the >>>>> responsible ADs, and the document shepherd). >>>>> >>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>> list: >>>>> >>>>> * More info: >>>>> >>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>> >>>>> * The archive itself: >>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>> >>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>> If needed, please add a note at the top of the message that you >>>>> have dropped the address. When the discussion is concluded, >>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>> its addition will be noted at the top of the message. >>>>> >>>>> You may submit your changes in one of two ways: >>>>> >>>>> An update to the provided XML file >>>>> — OR — >>>>> An explicit list of changes in this format >>>>> >>>>> Section # (or indicate Global) >>>>> >>>>> OLD: >>>>> old text >>>>> >>>>> NEW: >>>>> new text >>>>> >>>>> You do not need to reply with both an updated XML file and an explicit >>>>> list of changes, as either form is sufficient. >>>>> >>>>> We will ask a stream manager to review and approve any changes that seem >>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>> and technical changes. Information about stream managers can be found in >>>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>>> >>>>> >>>>> Approving for publication >>>>> -------------------------- >>>>> >>>>> To approve your RFC for publication, please reply to this email stating >>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>> as all the parties CCed on this message need to see your approval. >>>>> >>>>> >>>>> Files >>>>> ----- >>>>> >>>>> The files are available here: >>>>> https://www.rfc-editor.org/authors/rfc9834.xml >>>>> https://www.rfc-editor.org/authors/rfc9834.html >>>>> https://www.rfc-editor.org/authors/rfc9834.pdf >>>>> https://www.rfc-editor.org/authors/rfc9834.txt >>>>> >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc9834-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9834-rfcdiff.html (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc9834-xmldiff1.html >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://www.rfc-editor.org/auth48/rfc9834 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9834 (draft-ietf-opsawg-teas-attachment-circuit-20) >>>>> >>>>> Title : YANG Data Models for Bearers and 'Attachment >>>>> Circuits'-as-a-Service (ACaaS) >>>>> Author(s) : M. Boucadair, R. Roberts, O. Gonzalez de Dios, S. >>>>> Barguil Giraldo, B. Wu >>>>> WG Chair(s) : Joe Clarke, Benoît Claise >>>>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >>>>> >>>> >>>> >>>> Mahesh Jethanandani >>>> mjethanand...@gmail.com >>> >>> >> >> >> Mahesh Jethanandani >> mjethanand...@gmail.com >> >> >> >> >> >> > Mahesh Jethanandani mjethanand...@gmail.com
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
