Dear Alanna. > El 23 jun 2021, a las 18:16, Alanna Paloma <apal...@amsl.com> escribió: > > Greetings Authors and *ADs, > > *ADs - Please respond to a) and b) below: > > a) Please review and approve of the changes from > “ipsec-protocol-parameters” to “Ipsec-protocol-params” in Sections > 5.1.2, 5.2.1, 5.3.1, and 5.3.3 in the diff file below. > > https://www.rfc-editor.org/authors/rfc9061-ad-diff.html > > b) Please confirm the following: > >>> 8) <!--[rfced] In the Security Considerations section, the text >>> does not exactly match what appears on >>> <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>. >>> Paragraph 5 of the YANG boilerplate text is missing. This seems >>> intentional, but we'd like to confirm that this is correct. >>> —> >> >> [Authors] Yes, this is correct. > > Authors - Thank you for your replies. We have updated the files as requested. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9061.xml > https://www.rfc-editor.org/authors/rfc9061.txt > https://www.rfc-editor.org/authors/rfc9061.html > https://www.rfc-editor.org/authors/rfc9061.pdf > > The relevant diff files have been posted here: > https://www.rfc-editor.org/authors/rfc9061-diff.html (comprehensive diff) > https://www.rfc-editor.org/authors/rfc9061-auth48diff.html (AUTH48 changes) > https://www.rfc-editor.org/authors/rfc9061-lastdiff.html (last version to > this one) > > Please review the document carefully and contact us with any further > updates you may have. Note that we do not make changes once a > document is published as an RFC. > > We will await approvals from each party listed on the AUTH48 status > page above prior to moving this document forward in the publication > process.
The document is fine to me. Thank you very much for the detailed review. Best regards, Gabi. > > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9061 > > Thank you. > > RFC Editor/ap > >> On Jun 21, 2021, at 8:49 AM, Rafa Marín López <r...@um.es> wrote: >> >> Dear Paloma: >> >> We have just found this errata in the updated reference >> >> [ITU-T.X.690] >> >> "Recommendation >> >> >> International Telecommunication Untion, "Information >> Technology - ASN.1 encoding rules: Specification of Basic >> Encoding Rules (BER), Canonical Encoding Rules (CER) and >> Distinguished Encoding Rules (DER)", >> ITU-T X.690", August 2015. >> Recommendation >> X.690, ISO/IEC 8825-1, February 2021. >> >> >> >> Best Regards. >> >>> El 18 jun 2021, a las 18:01, Rafa Marin-Lopez <r...@um.es> escribió: >>> >>> Dear Alanna: >>> >>> Please see my comments inline >>> >>>> El 16 jun 2021, a las 21:29, Alanna Paloma <apal...@amsl.com> escribió: >>>> >>>> Authors and *ADs, >>>> >>>> *ADs - Please review and approve the changes from >>>> “ipse-protocol-parameters” to >>>> “Ipsec-protocol-params” in Sections 5.1.2, 5.2.1, 5.3.1, and 5.3.3 in the >>>> diff file below. >>>> >>>> https://www.rfc-editor.org/authors/rfc9061-ad-diff.html >>>> >>>> Additionally, please confirm the following: >>>> >>>>>> 8) <!--[rfced] In the Security Considerations section, the text >>>>>> does not exactly match what appears on >>>>>> <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>. >>>>>> Paragraph 5 of the YANG boilerplate text is missing. This seems >>>>>> intentional, but we'd like to confirm that this is correct. >>>>>> —> >>>>> >>>>> [Authors] Yes, this is correct. >>>> >>>> Authors - Thank you for your replies. We have updated as requested. >>> >>> Thank you very much for your effort. >>>> >>>> We have one additional question: >>>> >>>> <!--[rfced] RFC 2247 is listed as a normative reference to the YANG module >>>> >>>> in Section 5.2.3, but it is not referenced in the module. May we remove >>>> >>>> it as a reference, or where should it be cited?--> >>> >>> Yes, please remove the reference. It is not used. >>>> >>>> The files have been posted here (please refresh): >>>> https://www.rfc-editor.org/authors/rfc9061.txt >>>> https://www.rfc-editor.org/authors/rfc9061.pdf >>>> https://www.rfc-editor.org/authors/rfc9061.html >>>> https://www.rfc-editor.org/authors/rfc9061.xml >>>> >>>> The relevant diff files are posted here: >>>> https://www.rfc-editor.org/authors/rfc9061-diff.html (comprehensive diff) >>>> https://www.rfc-editor.org/authors/rfc9061-auth48diff.html (all AUTH48 >>>> changes) >>>> >>>> >>>> Please see the AUTH48 status page for this document here: >>>> https://www.rfc-editor.org/auth48/rfc9061 >>> >>> I have been checking this and I have a comment due to the new name of the >>> document. >>> >>> The three YANG modules still have: >>> >>> reference >>> "RFC >>> XXXX: 9061: >>> Software-Defined Networking >>> (SDN)-based IPsec Flow Protection.”; >>> >>> >>> Shouldn’t they be ? >>> >>> reference >>> "RFC >>> XXXX: 9061: A YANG Data Model for IPsec Flow Protection Based on >>> Software-Defined Networking (SDN)."; >>> >>> Best Regards and thank you. >>> >>>> >>>> Thank you. >>>> >>>> RFC Editor/ap >>>> >>>>> On Jun 15, 2021, at 6:48 AM, Gabriel Lopez <gab...@um.es> wrote: >>>>> >>>>> Hi Diego. >>>>> >>>>>> El 14 jun 2021, a las 16:47, Diego R. Lopez >>>>>> <diego.r.lo...@telefonica.com> escribió: >>>>>> >>>>>> Hi, >>>>>> >>>>>> It looks reasonable to me, but I wonder whether in order to avoid the >>>>>> stacking of hyphenated qualifiers we could use: >>>>>> >>>>>> A YANG Data Model for IPsec Flow Protection based on Software-Defined >>>>>> Networking (SDN) >>>>> >>>>> The title seems ok to me. >>>>> >>>>> Best regards, Gabi. >>>>> >>>>> >>>>>> >>>>>> Be goode, >>>>>> >>>>>> -- >>>>>> "Esta vez no fallaremos, Doctor Infierno" >>>>>> >>>>>> Dr Diego R. Lopez >>>>>> Telefonica I+D >>>>>> https://www.linkedin.com/in/dr2lopez/ >>>>>> >>>>>> e-mail: diego.r.lo...@telefonica.com >>>>>> Mobile: +34 682 051 091 >>>>>> ---------------------------------- >>>>>> >>>>>> On 14/06/2021, 09:24, "I2nsf on behalf of Rafa Marin-Lopez" >>>>>> <i2nsf-boun...@ietf.org on behalf of r...@um.es> wrote: >>>>>> >>>>>> Dear I2NSF WG members: >>>>>> >>>>>> We have received a suggestion from the RFC editor about a possible >>>>>> change in the title: >>>>>> >>>>>> Software-Defined Networking (SDN)-based IPsec Flow Protection —> >>>>>> >>>>>> A YANG Data Model for Software-Defined Networking (SDN)-based IPsec Flow >>>>>> Protection >>>>>> >>>>>> We think this is reasonable and it is inline with the document. >>>>>> >>>>>> If you do not have any objection, we can apply this change. Any thoughts? >>>>>> >>>>>> Best Regards. >>>>>> >>>>>> >>>>>>> Inicio del mensaje reenviado: >>>>>>> >>>>>>> De: rfc-edi...@rfc-editor.org >>>>>>> Asunto: Re: AUTH48 [AP]: RFC 9061 >>>>>>> <draft-ietf-i2nsf-sdn-ipsec-flow-protection-14.txt> NOW AVAILABLE >>>>>>> Fecha: 10 de junio de 2021, 22:58:29 CEST >>>>>>> Para: r...@um.es, gab...@um.es, fernando.perenig...@cud.upct.es >>>>>>> Cc: rfc-edi...@rfc-editor.org, i2nsf-...@ietf.org, >>>>>>> i2nsf-cha...@ietf.org, ynir.i...@gmail.com >>>>>>> >>>>>>> Authors, >>>>>>> >>>>>>> While reviewing this document during AUTH48, please resolve (as >>>>>>> necessary) the following questions, which are also in the XML file. >>>>>>> >>>>>>> 1) <!--[rfced] We note that most of the recently published RFCs >>>>>>> containing >>>>>>> YANG modules format their titles as "A YANG Data Model for...", for >>>>>>> example: >>>>>>> >>>>>>> RFC 8022 - A YANG Data Model for Routing Management >>>>>>> RFC 7407 - A YANG Data Model for SNMP Configuration >>>>>>> RFC 7317 - A YANG Data Model for System Management >>>>>>> RFC 7277 - A YANG Data Model for IP Management >>>>>>> >>>>>>> Please consider whether the title of this document should be updated. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 2) <!--[rfced] For clarity, may we change "while" to "whereas" here? >>>>>>> This would make it clear that the intended meaning is a contrast >>>>>>> rather than "at the same time". >>>>>>> >>>>>>> Original: >>>>>>> Therefore, the NSF will only have support for >>>>>>> IPsec while key management functionality is moved to the I2NSF >>>>>>> Controller. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 3) <!--[rfced] We see a number of author-inserted comments in the .xml >>>>>>> file for this document. We are unsure if these have been resolved. >>>>>>> Please review and let us know if these can be deleted or if they need >>>>>>> to be addressed. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 4) <!-- [rfced] FYI: Note that the YANG modules have been updated per >>>>>>> the formatting option of pyang. Please let us know any concerns. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 5) <!--[rfced] In Sections 6.2.1 and 6.2.3, should "rw enable?" >>>>>>> and "leaf enable" be "rw enabled?" (as used in RFC 8340 ad most >>>>>>> published RFCs) and "leaf enabled" (as used in most published RFCs)? >>>>>>> >>>>>>> Original: >>>>>>> rw enable? boolean >>>>>>> ... >>>>>>> leaf enable { >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 6) <!--[rfced] RFC 2560 is referenced in the YANG module in Section >>>>>>> 5.2.3 >>>>>>> but is not mentioned anywhere else in the text. May we add it as a >>>>>>> Normative Reference and to the introductory text in Section 5.2.3? >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 7) <!--[rfced] In tree diagram in Section 5.3.1, the two lines that >>>>>>> include "ipsec-protocol-parameters" are one character too long to >>>>>>> fit in the space allowed in the txt output file. Please let us know >>>>>>> how to adjust this so that it will fit. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 8) <!--[rfced] In the Security Considerations section, the text >>>>>>> does not exactly match what appears on >>>>>>> <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>. >>>>>>> Paragraph 5 of the YANG boilerplate text is missing. This seems >>>>>>> intentional, but we'd like to confirm that this is correct. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 9) <!--[rfced] The following reference has been superseded >>>>>>> by a 2021 version. Would you like for it to be updated? >>>>>>> >>>>>>> Original: >>>>>>> [ITU-T.X.690] >>>>>>> "Recommendation ITU-T X.690", August 2015. >>>>>>> >>>>>>> 2021 version: >>>>>>> [ITU-T.X.690] >>>>>>> International Telecommunication Union, "Information >>>>>>> technology - ASN.1 encoding rules: Specification of Basic >>>>>>> Encoding Rules (BER), Canonical Encoding Rules (CER) and >>>>>>> Distinguished Encoding Rules (DER)", ITU-T Recommendation >>>>>>> X.690, ISO/IEC 8825-1, February 2021. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 10) <!--[rfced] Should "SaaS" be expanded as "Software as a Service" >>>>>>> or "Storage as a Service"? >>>>>>> >>>>>>> Original: >>>>>>> For example, SD-WAN technologies are providing >>>>>>> dynamic and on-demand VPN connections between branch offices, or >>>>>>> between branches and SaaS cloud services. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> 11) <!-- [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. >>>>>>> --> >>>>>>> >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> RFC Editor/ap/jm >>>>>>> >>>>>>> On 6/10/21 3:55 PM, rfc-edi...@rfc-editor.org wrote: >>>>>>> >>>>>>> *****IMPORTANT***** >>>>>>> >>>>>>> Updated 2021/06/10 >>>>>>> >>>>>>> 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://xml2rfc.tools.ietf.org/xml2rfc-doc.html>. >>>>>>> >>>>>>> * 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 with one of the >>>>>>> following, >>>>>>> using ‘REPLY ALL’ as all the parties CC’ed on this message need to see >>>>>>> your changes: >>>>>>> >>>>>>> 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 s >>>>>>> tating that you approve this RFC for publication. Please use ‘REPLY >>>>>>> ALL’ >>>>>>> as all the parties CC’ed on this message need to see your approval. >>>>>>> >>>>>>> >>>>>>> Files >>>>>>> ----- >>>>>>> >>>>>>> The files are available here: >>>>>>> https://www.rfc-editor.org/authors/rfc9061.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9061.html >>>>>>> https://www.rfc-editor.org/authors/rfc9061.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9061.txt >>>>>>> >>>>>>> Diff file of the text: >>>>>>> https://www.rfc-editor.org/authors/rfc9061-diff.html >>>>>>> >>>>>>> Diff of the XML: >>>>>>> https://www.rfc-editor.org/authors/rfc9061-xmldiff1.html >>>>>>> >>>>>>> The following files are provided to facilitate creation of your own >>>>>>> diff files of the XML. >>>>>>> >>>>>>> Initial XMLv3 created using XMLv2 as input: >>>>>>> https://www.rfc-editor.org/authors/rfc9061.original.v2v3.xml >>>>>>> >>>>>>> XMLv3 file that is a best effort to capture v3-related format updates >>>>>>> only: >>>>>>> https://www.rfc-editor.org/authors/rfc9061.form.xml >>>>>>> >>>>>>> >>>>>>> Tracking progress >>>>>>> ----------------- >>>>>>> >>>>>>> The details of the AUTH48 status of your document are here: >>>>>>> https://www.rfc-editor.org/auth48/rfc9061 >>>>>>> >>>>>>> Please let us know if you have any questions. >>>>>>> >>>>>>> Thank you for your cooperation, >>>>>>> >>>>>>> RFC Editor >>>>>>> >>>>>>> -------------------------------------- >>>>>>> RFC9061 (draft-ietf-i2nsf-sdn-ipsec-flow-protection-14) >>>>>>> >>>>>>> Title : Software-Defined Networking (SDN)-based IPsec Flow >>>>>>> Protection >>>>>>> Author(s) : R. Marin-Lopez, G. Lopez-Millan, F. Pereniguez-Garcia >>>>>>> WG Chair(s) : Linda Dunbar, Yoav Nir >>>>>>> Area Director(s) : Roman Danyliw, Benjamin Kaduk >>>>>>> >>>>>>> >>>>>> >>>>>> ------------------------------------------------------- >>>>>> Rafa Marin-Lopez, PhD >>>>>> Dept. Information and Communications Engineering (DIIC) >>>>>> Faculty of Computer Science-University of Murcia >>>>>> 30100 Murcia - Spain >>>>>> Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es >>>>>> ------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, >>>>>> puede contener información privilegiada o confidencial y es para uso >>>>>> exclusivo de la persona o entidad de destino. Si no es usted. el >>>>>> destinatario indicado, queda notificado de que la lectura, utilización, >>>>>> divulgación y/o copia sin autorización puede estar prohibida en virtud >>>>>> de la legislación vigente. Si ha recibido este mensaje por error, le >>>>>> rogamos que nos lo comunique inmediatamente por esta misma vía y proceda >>>>>> a su destrucción. >>>>>> >>>>>> The information contained in this transmission is privileged and >>>>>> confidential information intended only for the use of the individual or >>>>>> entity named above. If the reader of this message is not the intended >>>>>> recipient, you are hereby notified that any dissemination, distribution >>>>>> or copying of this communication is strictly prohibited. If you have >>>>>> received this transmission in error, do not read it. Please immediately >>>>>> reply to the sender that you have received this communication in error >>>>>> and then delete it. >>>>>> >>>>>> Esta mensagem e seus anexos se dirigem exclusivamente ao seu >>>>>> destinatário, pode conter informação privilegiada ou confidencial e é >>>>>> para uso exclusivo da pessoa ou entidade de destino. Se não é vossa >>>>>> senhoria o destinatário indicado, fica notificado de que a leitura, >>>>>> utilização, divulgação e/ou cópia sem autorização pode estar proibida em >>>>>> virtude da legislação vigente. Se recebeu esta mensagem por erro, >>>>>> rogamos-lhe que nos o comunique imediatamente por esta mesma via e >>>>>> proceda a sua destruição >>>>>> _______________________________________________ >>>>>> I2nsf mailing list >>>>>> I2nsf@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2nsf >>>>> >>>>> ----------------------------------------------------------- >>>>> Gabriel López Millán >>>>> Departamento de Ingeniería de la Información y las Comunicaciones >>>>> University of Murcia >>>>> Spain >>>>> Tel: +34 868888504 >>>>> Fax: +34 868884151 >>>>> email: gab...@um.es >>>> >>> >>> ------------------------------------------------------- >>> Rafa Marin-Lopez, PhD >>> Dept. Information and Communications Engineering (DIIC) >>> Faculty of Computer Science-University of Murcia >>> 30100 Murcia - Spain >>> Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es >>> ------------------------------------------------------- >>> >>> >>> >>> >>> _______________________________________________ >>> I2nsf mailing list >>> I2nsf@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2nsf >> >> ------------------------------------------------------ >> Rafa Marin-Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: r...@um.es >> ------------------------------------------------------- >> > ----------------------------------------------------------- Gabriel López Millán Departamento de Ingeniería de la Información y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gab...@um.es
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf