Re: [I2nsf] [AD] AUTH48 [AP]: RFC 9061 <draft-ietf-i2nsf-sdn-ipsec-flow-protection-14.txt> NOW AVAILABLE

[Fernando Pereñíguez García <[e-mail]>]

Dear Alanna,

I have revised the last version of the document and all the changes are ok
to me.

Thank you very much for your work.

Regards,
Fernando.

El jue, 24 jun 2021 a las 18:42, Rafa Marin-Lopez (<[e-mail]>) escribió:

> Dear Alanna:
>
> Everything looks ok to me. Thank you very much for applying all the
> changes.
>
> Best Regards.
>
>
> El 23 jun 2021, a las 18:16, Alanna Paloma <[e-mail]> 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.
>
>
> 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 <[e-mail]> 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 <[e-mail]> escribió:
>
> Dear Alanna:
>
> Please see my comments inline
>
> El 16 jun 2021, a las 21:29, Alanna Paloma <[e-mail]> 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 <[e-mail]> wrote:
>
> Hi Diego.
>
> El 14 jun 2021, a las 16:47, Diego R. Lopez <[e-mail]>
> 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: [e-mail]
> Mobile:  [phone]
> ----------------------------------
>
> On 14/06/2021, 09:24, "I2nsf on behalf of Rafa Marin-Lopez" <
> [e-mail] on behalf of [e-mail]> 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: [e-mail]
> 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: [e-mail], [e-mail], [e-mail]
> Cc: [e-mail], [e-mail], [e-mail],
> [e-mail]
>
> 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, [e-mail] 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: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------
>
>
>
>
>
>
> 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
> [e-mail]
> 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: [phone]
> Fax: [phone]
> email: [e-mail]
>
>
>
> -------------------------------------------------------
> Rafa Marin-Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------
>
>
>
>
> _______________________________________________
> I2nsf mailing list
> [e-mail]
> 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: [phone] Fax: [phone] e-mail: [e-mail]
> -------------------------------------------------------
>
>
>
> -------------------------------------------------------
> Rafa Marin-Lopez, PhD
> Dept. Information and Communications Engineering (DIIC)
> Faculty of Computer Science-University of Murcia
> 30100 Murcia - Spain
> Telf: [phone] Fax: [phone] e-mail: [e-mail] <[e-mail]>
> -------------------------------------------------------
>
>
>
>
>

-- 
----------------------------------------------------------------------------------------------------
Fernando Pereñíguez García, PhD
Department of Engineering and Applied Technologies
University Defense Center, (CUD), Spanish Air Force Academy, MDE-UPCT
C/ Coronel Lopez Peña, s/n, 30720, San Javier, Murcia - SPAIN
Tel: [phone] Fax: [phone]
------------------------------------------------------------------------------------------------------