Hi Diego. > El 14 jun 2021, a las 16:47, Diego R. Lopez <[email protected]> > 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/ <https://www.linkedin.com/in/dr2lopez/> > > e-mail: [email protected] <mailto:[email protected]> > Mobile: +34 682 051 091 > ---------------------------------- > > On 14/06/2021, 09:24, "I2nsf on behalf of Rafa Marin-Lopez" > <[email protected] <mailto:[email protected]> on behalf of > [email protected] <mailto:[email protected]>> 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: [email protected] <mailto:[email protected]> >> 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: [email protected] <mailto:[email protected]>, [email protected] <mailto:[email protected]>, >> [email protected] <mailto:[email protected]> >> Cc: [email protected] <mailto:[email protected]>, >> [email protected] <mailto:[email protected]>, [email protected] >> <mailto:[email protected]>, [email protected] >> <mailto:[email protected]> >> >> 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 >> <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 >> <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, [email protected] >> <mailto:[email protected]> 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/ >> <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/ >> <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 >> <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.xml> >> https://www.rfc-editor.org/authors/rfc9061.html >> <https://www.rfc-editor.org/authors/rfc9061.html> >> https://www.rfc-editor.org/authors/rfc9061.pdf >> <https://www.rfc-editor.org/authors/rfc9061.pdf> >> https://www.rfc-editor.org/authors/rfc9061.txt >> <https://www.rfc-editor.org/authors/rfc9061.txt> >> >> Diff file of the text: >> https://www.rfc-editor.org/authors/rfc9061-diff.html >> <https://www.rfc-editor.org/authors/rfc9061-diff.html> >> >> Diff of the XML: >> https://www.rfc-editor.org/authors/rfc9061-xmldiff1.html >> <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 >> <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 >> <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 >> <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: [email protected] <mailto:[email protected]> > ------------------------------------------------------- > > > > > > > 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 > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/i2nsf > <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: [email protected]
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
