[Gen-art] Genart last call review of draft-ietf-lamps-ocsp-nonce-update-05
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-lamps-ocsp-nonce-update-05 Reviewer: Ines Robles Review Date: 2024-04-03 IETF LC End Date: 2024-04-03 IESG Telechat date: Not scheduled for a telechat Summary: This document updates the maximum allowed length of Nonce to 128 octets for the Online Certificate Status Protocol (OCSP). OCSP is used for checking the status of a certificate, and the Nonce extension is used to cryptographically bind an OCSP response message to a particular OCSP request message. This document also modifies Nonce section to clearly define the encoding format and values distinctively for an easier implementation and understanding. This document obsoletes RFC 8954 and provides updated ASN.1 modules for OCSP, updates RFC 6960. The document is well written and easy to read. Major issues: None Minor issues: None Nits/editorial comments: None Thanks for this document, Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lsr-isis-fast-flooding-07
Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-lsr-isis-fast-flooding-07 Reviewer: Ines Robles Review Date: 2024-02-28 IETF LC End Date: 2024-02-29 IESG Telechat date: Not scheduled for a telechat Summary: This document outlines the limitations of current Link State Protocol Data Unit (PDU) flooding rates within the IS-IS protocol and highlights the need for faster flooding to meet the objectives of modern networks. It addresses the challenges associated with this requirement, provides examples, and defines protocol extensions relevant to enhancing flooding speeds. The document is well-written. My minor comments are detailed below. Major issues: None Minor issues: 1- In Section 6.2.4, the term 'relatively static parameters' is introduced to describe the operational behavior of flooding parameters within the IS-IS protocol. Could you please clarify the criteria or conditions under which these parameters are considered relatively static, I mean which are the criteria or conditions that define these parameters as relatively static? 2- How do the pacing and rate-limiting mechanisms affect the IS-IS protocol's efficiency in detecting and responding to lost LSPs, considering the potential for fast loss detection provided by ordered acknowledgments? Nits/editorial comments: 3- Should "today" be replaced with something like "at the moment of writing this specification". Or, since "today" is mentioned several times in the text, should a clarification be added at the first instance, example: today --> today (at the moment of writing this specification). ? 4- In Section 6.2.2.1 "...fast rates in short periods of time..." --> it would be nice to add an example, e.g.: "... fast rates in short periods of time (For example, 12 LSPs in 20ms) ". What do you think ? Thanks for this document, Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Jmap] Genart last call review of draft-ietf-jmap-sieve-17
Thank you Kenneth for addressing my comments. The changes are Ok for me. Best Regards, Ines. On Tue, Feb 6, 2024 at 6:58 PM Ken Murchison wrote: > Hi Ines, > > Thanks for the detailed review. I used you input to produce draft -18. > Comments inline. > > > On 2/2/24 3:42 PM, Ines Robles via Datatracker wrote: > > Reviewer: Ines Robles > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > > > Document: draft-ietf-jmap-sieve-17 > > Reviewer: Ines Robles > > Review Date: 2024-02-02 > > IETF LC End Date: 2024-02-01 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > > > The document specifies a data model for managing Sieve scripts using > JMAP, a > > protocol for synchronizing data such as email between clients and > servers. The > > model also includes details about server capabilities, script properties, > > activation, and validation processes. The document is well written. I > have > > minor comments/questions below. > > > > Major issues: None > > > > Minor issues: None > > > > Nits/editorial comments: > > > > 1- Section 1: "...however the functionality offered over the two > protocols may > > differ" > > > > It would be nice to clarify How the protocols may differ, for example, > what > > about: "While both JMAP and ManageSieve provide mechanisms for managing > Sieve > > scripts on a server, the range of features and operations available may > vary > > between the two protocols. This could affect how scripts are created, > edited, > > or executed, depending on which protocol is used." or something like > that. What > > do you think? > > I've removed the sentence about differing functionality, and broken out > a separate section discussing of the only functional difference between > the two protocols. > > > > 2- Section 1.3.1: "This represents support..." --> Perhaps: "The > > urn:ietf:params:jmap:sieve capability object represents support..." ? > > Done. > > > > 3- Section 2.2: "...This method provides similar functionality to the > > PUTSCRIPT, DELETESCRIPT, RENAMESCRIPT, and SETACTIVE commands in > [RFC5804]." > > > > It would be nice to clarify a bit in which aspects are > similar/dissimilar, for > > example, what about: "This method provides similar functionality to the > > PUTSCRIPT, DELETESCRIPT, RENAMESCRIPT, and SETACTIVE commands in > [RFC5804]. > > Similar functionality here means that, though the protocols differ, the > JMAP > > method achieves the same end goals (e.g. managing Sieve scripts by > allowing > > their creation, deletion, renaming, and activation)" Is this correct? > What do > > you think? > > > I've changed all instances of "similar functionality" to "equivalent > functionality" which I believe is more accurate and doesn't require > having to explain any differences. > > -- > Kenneth Murchison > Senior Software Developer > Fastmail US LLC > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-jmap-sieve-17
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-jmap-sieve-17 Reviewer: Ines Robles Review Date: 2024-02-02 IETF LC End Date: 2024-02-01 IESG Telechat date: Not scheduled for a telechat Summary: The document specifies a data model for managing Sieve scripts using JMAP, a protocol for synchronizing data such as email between clients and servers. The model also includes details about server capabilities, script properties, activation, and validation processes. The document is well written. I have minor comments/questions below. Major issues: None Minor issues: None Nits/editorial comments: 1- Section 1: "...however the functionality offered over the two protocols may differ" It would be nice to clarify How the protocols may differ, for example, what about: "While both JMAP and ManageSieve provide mechanisms for managing Sieve scripts on a server, the range of features and operations available may vary between the two protocols. This could affect how scripts are created, edited, or executed, depending on which protocol is used." or something like that. What do you think? 2- Section 1.3.1: "This represents support..." --> Perhaps: "The urn:ietf:params:jmap:sieve capability object represents support..." ? 3- Section 2.2: "...This method provides similar functionality to the PUTSCRIPT, DELETESCRIPT, RENAMESCRIPT, and SETACTIVE commands in [RFC5804]." It would be nice to clarify a bit in which aspects are similar/dissimilar, for example, what about: "This method provides similar functionality to the PUTSCRIPT, DELETESCRIPT, RENAMESCRIPT, and SETACTIVE commands in [RFC5804]. Similar functionality here means that, though the protocols differ, the JMAP method achieves the same end goals (e.g. managing Sieve scripts by allowing their creation, deletion, renaming, and activation)" Is this correct? What do you think? Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-mpls-sfl-control-04
Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-mpls-sfl-control-04 Reviewer: Ines Robles Review Date: 2023-11-27 IETF LC End Date: 2023-11-27 IESG Telechat date: Not scheduled for a telechat Summary: This document describes a control protocol that runs over an associated control header to request, withdraw, and extend the lifetime of MPLS synonymos flow labels (SFL). I have some minor comments/questions indicated below. Major issues: None Minor issues: * In the text it is mentioned - "well-managed MPLS Network" (Section 1, Section 6). I think that this is vague because it lacks specific, measurable criteria. Thus, to improve the clarity and precision of the document, it would be nice to replace the term "well-managed" with more specific and quantifiable attributes. Something like: "...This protocol is designed for use in an MPLS network that adheres to Internet standard management practices such as [addReference, e.g. RFC6427?]..." * Should this draft describe how this control protocol might interact with or support various SFL Actions? (for context and understanding the broader application of SFLs in a network.) * Should this draft specify topics related to the performance impact of the protocol, including how it handles high volumes of SFL requests and scalability in large-scale networks? * Section 3.1 - error codes: While the draft mentions error codes, Should this draft specify comprehensive error handling at various stages of the SFL request, management process or operational inconsistencies?, What do you think? * Section 3.2.4: More precise definitions or examples of what constitutes "significantly" would be helpful. * Section 3.2.4: Should this draft explain how these time margins might impact network performance, especially in high-density or high-traffic scenarios? * Section 3.2.4: Should this draft explain or reference how to manage potential inaccuracies in timer synchronization across the network? * Section 6: Should this draft reference RFC 5920? Nits/editorial comments: * Section 3. Related with the terminology, it would be nice to add RFC 5586 in here, since it defines the Generic Associated Channel Header. I understand RFC 5586 is mentioned in IANA section, but it would be nice to include it in here as well. * Section 3.1: In "Flags" and "Control Code" definition it would be nice to add a sentence such as "See below for detailed explanation", since these concepts are expanded below in the text. * Section 3.1: (Allocated (A) --> (Allocated (A)) Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-cose-cwt-claims-in-headers-06
Many thanks, Mike, for addressing my comments. Best Regards, Ines. On Mon, Oct 23, 2023 at 7:35 AM Michael Jones wrote: > > Thanks for taking the time to review the document and for your useful > suggestions, Ines! FYI, we published > https://www.ietf.org/archive/id/draft-ietf-cose-cwt-claims-in-headers-07.html > to address the Last Call comments received. > > I've responded to your comments inline below, with responses prefixed by > "Mike>". > > -----Original Message- > From: Ines Robles via Datatracker > Sent: Tuesday, October 17, 2023 1:45 PM > To: gen-art@ietf.org > Cc: c...@ietf.org; draft-ietf-cose-cwt-claims-in-headers@ietf.org; > last-c...@ietf.org > Subject: Genart last call review of > draft-ietf-cose-cwt-claims-in-headers-06 > > Reviewer: Ines Robles > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-cose-cwt-claims-in-headers-06 > Reviewer: Ines Robles > Review Date: 2023-10-17 > IETF LC End Date: 2023-10-20 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > This document describes how to include CBOR Web Token (CWT) claims in the > header parameters of any COSE structure. > > The document is well written, I have minor issues, nits indicated below. > > Major issues: None > > Minor issues: > > 1- Section 3: "Some of the registered CWT claims may contain > privacy-sensitive information. Therefore care must be taken when expressing > CWT claims in COSE headers." --> What kind of care?, there is some specific > guidelines to follow? > could you add an example? or add some reference? > > Mike> We expanded the description in the Privacy Considerations section. > > 2- Section 4: > > Detached Signatures: The security section does not delve into the security > considerations of using detached signatures. Since detached signatures are > one focus of the functionality, it might be helpful to discuss the security > implications specific to them. > > Mike> We added a Security Consideration on detached signatures. > > Claims in Headers: Considering that some claims can be available before > decryption or without inspecting the payload, perhaps it would be nice to > discuss the risks associated with exposing claims in this manner, or add > reference? > > Mike> We added a Privacy Consideration about unencrypted claims in header > parameters. > > Data Consistency: Is there a security angle to ensuring that claims > present both in the payload and header are identical, beyond just > verification?. > > Mike> We added a Security Consideration about claims that are present in > both the payload and the header of a CWT. > > It seems that these items are not included in the security considerations > of RFC 8392, What do you think? > > Mike> See the enhanced Privacy Considerations and Security Considerations > sections. > > Nits/editorial comments: > > 3- It would be nice to expand JWT the first time of use -> JSON Web Token > (JWT) > > Mike> Done! > > 4- It would be nice to have a caption for Table 1 > > Mike> Neither of the authors could figure out how to do this. > https://thesynack.com/posts/markdown-captions/ says "The truth is that, > as of now, captions are not part of the original Markdown specifications, > nor are they part of the more modern CommonMark specifications." Once > we're working with the RFC Editor on XML source, we can add it then. > > 5- Table 1: "TBD (requested assignment 13)", the 13 was assigned to kcwt, > so maybe suggest another value? > > Mike> Now 15 > > Thanks for this document, > > Mike> You're welcome! > > Ines. > > Thanks again, > -- Mike > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-cose-cwt-claims-in-headers-06
Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-cose-cwt-claims-in-headers-06 Reviewer: Ines Robles Review Date: 2023-10-17 IETF LC End Date: 2023-10-20 IESG Telechat date: Not scheduled for a telechat Summary: This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. The document is well written, I have minor issues, nits indicated below. Major issues: None Minor issues: 1- Section 3: "Some of the registered CWT claims may contain privacy-sensitive information. Therefore care must be taken when expressing CWT claims in COSE headers." --> What kind of care?, there is some specific guidelines to follow? could you add an example? or add some reference? 2- Section 4: Detached Signatures: The security section does not delve into the security considerations of using detached signatures. Since detached signatures are one focus of the functionality, it might be helpful to discuss the security implications specific to them. Claims in Headers: Considering that some claims can be available before decryption or without inspecting the payload, perhaps it would be nice to discuss the risks associated with exposing claims in this manner, or add reference? Data Consistency: Is there a security angle to ensuring that claims present both in the payload and header are identical, beyond just verification?. It seems that these items are not included in the security considerations of RFC 8392, What do you think? Nits/editorial comments: 3- It would be nice to expand JWT the first time of use -> JSON Web Token (JWT) 4- It would be nice to have a caption for Table 1 5- Table 1: "TBD (requested assignment 13)", the 13 was assigned to kcwt, so maybe suggest another value? Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-anima-constrained-join-proxy-14
Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-anima-constrained-join-proxy-14 Reviewer: Ines Robles Review Date: 2023-09-06 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: This document extends the work of Bootstrapping Remote Secure Key Infrastructures (BRSKI) by replacing the Circuit-proxy between Pledge and Registrar by a stateless/stateful constrained Join Proxy. This document defines a protocol to securely assign a Pledge to a domain, represented by a Registrar, using an intermediary node between Pledge and Registrar. The document is well written. There are 12 github issues open with this draft. https://github.com/anima-wg/constrained-join-proxy/issues I understand that the document is currently being modified to address them, I am willing to review also the corrected version. Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Rats] Genart last call review of draft-ietf-rats-eat-21
Thank you Laurence, + 1 as well, both of the suggested sentences are Ok for me. Have a nice weekend, Ines. On Fri, Aug 11, 2023 at 9:38 PM Smith, Ned wrote: > +1 to either of LL's suggestions. > > On 8/11/23, 11:28 AM, "lgl securitytheory.com" <mailto:l...@securitytheory.com>> wrote: > > > > > > On Aug 10, 2023, at 1:51 PM, Ines Robles 40googlemail@dmarc.ietf.org <mailto:40googlemail@dmarc.ietf.org>> > wrote: > > > > Many thanks Laurence for addressing my comments and for the providing > clarifications > > > > I understand the provided motive to not imply the trust to be static. > Perhaps, one way to convey the potentially varying degree of trust > dependant on context can be achieved by replacing "wishes" (which is > usually attributed to human sentiments) and as well as changing "how much" > (which represents in my understanding a quantity value): > > > > Thus, instead of: > > "This claims set is used by a relying party, server or service to > determine how much it wishes to trust the entity." > > how about?: > > "This claims set is used by a relying party, server or service to > determine the applicable trust in the entity." > > > It’s kind of an important sentence. Appreciate the thoughtful wordsmithing > here. :-) > > > I like this: > "This claims set is used by a relying party, server or service to > determine the type and degree of trust placed in the entity” > > > This is OK too: > "This claims set is used by a relying party, server or service to > determine the type and degree of trust attributed to the entity” > > > LL > > > > > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-rats-eat-21
Many thanks Laurence for addressing my comments and for the providing clarifications I understand the provided motive to not imply the trust to be static. Perhaps, one way to convey the potentially varying degree of trust dependant on context can be achieved by replacing "wishes" (which is usually attributed to human sentiments) and as well as changing "how much" (which represents in my understanding a quantity value): Thus, instead of: "This claims set is used by a relying party, server or service to determine how much it wishes to trust the entity." how about?: "This claims set is used by a relying party, server or service to determine the applicable trust in the entity." What do you think? Thank you and Best Regards, Ines. On Thu, Aug 10, 2023 at 10:03 PM lgl securitytheory.com < l...@securitytheory.com> wrote: > The PR to address these is here: > https://github.com/ietf-rats-wg/eat/pull/403 > > Comments below. > > > > On Aug 9, 2023, at 4:47 PM, Ines Robles via Datatracker < > nore...@ietf.org> wrote: > > > > Reviewer: Ines Robles > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > > > Document: draft-ietf-rats-eat-21 > > Reviewer: Ines Robles > > Review Date: 2023-08-09 > > IETF LC End Date: 2023-08-09 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > > > This document describes Entity Attestation Token (EAT) that provides an > > attested claims set that describes state and characteristics of an > entity. This > > claims set is used by a relying party, server, or service to assess the > > trustworthiness of the entity. EAT is constructed as a framework for > defining > > specific attestation tokens for specific use cases. > > > > The document is well documented, with good set of references. No major > issues > > found, minor nits found as specified below. > > > > Major Issues: None > > > > Minor Issues: None > > > > Nits: > > > > - Abstract: What about "...service to determine how much it wishes to > trust the > > entity." --> "...service to assess the trustworthiness of the entity." ? > > I prefer it as is, but am open to the change if there is consensus. > > I prefer it as is because it I think the existing wording leaves room for > the context of the trust. To me your proposed wording seems like trust is > determined once for all use cases. I think one might trust the same entity > in one context, but not in another. For example, one context might be for > transaction in dollars and another might be for authentication to access > governmental data. I don’t think trust or trustworthiness is universal > (even though lots of engineers, marketing people and such do use the word > that way). > > > > > > - Section 4.1.17: Maybe "failure, fail to run, ..." --> "failure, fail > to run, > > among others." ? > > Changed to "success, failure, fail to run, and absence” because there are > only four options. > > > > > > - In Section 4.2.14 "(DLOAs))" --> (DLOAs), the same for (Section > 4.2.16)) in > > Section 6.2.12 > > Fixed. > > > > > > - Section 4.3.3 and Section 7.3.1. "TBD(BUNDLE-Untagged-Message)" --> > > TBD602(BUNDLE-Untagged-Message) ? (To be aligned with IANA Section) > > Fixed. > > > > > - Section 6.2.12: "This document requires an EAT receiver must accept all > > claims it does not understand." are there specific security > consideration to > > follow in this case not mentioned in section 9.1? > > Reworded to "This document requires an EAT receiver must accept tokens > with claims it does not understand” as the > existing sentence really didn’t say the right thing. > > I don’t think there are security concerns here. > > > > > > - Section 6.3: It would be nice to have a caption for Table 2. (Same for > rest > > of the tables) > > Fixed. > > > > > - Section 7.3.1: "one place that that a CBOR token" --> "one place where > a CBOR > > token" ? > > Fixed. > > > > > > - Appendix C.1: "EAT doesn't define a an device implementation and DevID > does." > > --> "EAT doesn't define a device implementation, but DevID does." ? > > Fixed. > > > > > > Thanks for this document, > > > Thank you for reviewing. It’s a long document and I know it takes a lot of > work. > > LL > > > > > > Ines. > > > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-rats-eat-21
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-rats-eat-21 Reviewer: Ines Robles Review Date: 2023-08-09 IETF LC End Date: 2023-08-09 IESG Telechat date: Not scheduled for a telechat Summary: This document describes Entity Attestation Token (EAT) that provides an attested claims set that describes state and characteristics of an entity. This claims set is used by a relying party, server, or service to assess the trustworthiness of the entity. EAT is constructed as a framework for defining specific attestation tokens for specific use cases. The document is well documented, with good set of references. No major issues found, minor nits found as specified below. Major Issues: None Minor Issues: None Nits: - Abstract: What about "...service to determine how much it wishes to trust the entity." --> "...service to assess the trustworthiness of the entity." ? - Section 4.1.17: Maybe "failure, fail to run, ..." --> "failure, fail to run, among others." ? - In Section 4.2.14 "(DLOAs))" --> (DLOAs), the same for (Section 4.2.16)) in Section 6.2.12 - Section 4.3.3 and Section 7.3.1. "TBD(BUNDLE-Untagged-Message)" --> TBD602(BUNDLE-Untagged-Message) ? (To be aligned with IANA Section) - Section 6.2.12: "This document requires an EAT receiver must accept all claims it does not understand." are there specific security consideration to follow in this case not mentioned in section 9.1? - Section 6.3: It would be nice to have a caption for Table 2. (Same for rest of the tables) - Section 7.3.1: "one place that that a CBOR token" --> "one place where a CBOR token" ? - Appendix C.1: "EAT doesn't define a an device implementation and DevID does." --> "EAT doesn't define a device implementation, but DevID does." ? Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-uta-rfc6125bis-12
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-uta-rfc6125bis-12 Reviewer: Ines Robles Review Date: 2023-05-26 IETF LC End Date: 2023-05-26 IESG Telechat date: Not scheduled for a telechat Summary: This document specifies procedures for representing and verifying the identity of application services in TLS. It obsoletes RFC6125. The document is clear. I just have minor nits-related-questions. Major issues: None Minor issues: None Nits/editorial comments: *Section 6.1: "...a list of acceptable reference identifiers...": acceptable according to whom? Maybe acceptable can be replaced by something like valid/authorized/approved?, e.g. "...a list of valid reference identifiers..."? What do you think? * Section 7.5: "... limiting the number of names that any server can speak for..." Maybe: "..."Limiting the number of names that any server can represent..."? What do you think? * Appendix A: What about to add a sentence such as: ...the title of this document is different from the title of RFC6125 because...? Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-ipsecme-labeled-ipsec-10
Many thanks Paul for addressing my comments Best Regards, Ines On Tue, Apr 11, 2023 at 12:32 AM Paul Wouters wrote: > On Mon, 10 Apr 2023, Ines Robles via Datatracker wrote: > > > The document is well written and easy to read. > > Thanks :) > > > Nits/editorial comments: > > > > Section 3.2: "198.51.0/24" --> "198.51.100.0/24" ? > > Fixed in -11. > > > Question: Section 2.1, the Security Label should be at least of one > octet. Is > > there a limit of octets for this field? > > There is no limit other than the limitations of packet sizes in IKE. And > even there, we have some drafts currently looking at changing that, so I > think it is best not to mention anything about maximums in this draft. > > Paul > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ipsecme-labeled-ipsec-10
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ipsecme-labeled-ipsec-10 Reviewer: Ines Robles Review Date: 2023-04-10 IETF LC End Date: 2023-04-10 IESG Telechat date: Not scheduled for a telechat Summary: This document defines a new Traffic Selector (TS) Type for Internet Key Exchange version 2 to add support for negotiating Mandatory Access Control (MAC) security labels as a traffic selector of the Security Policy Database (SPD). The new TS type is TS_SECLABEL. The document is well written and easy to read. Major issues: None Minor issues: None Nits/editorial comments: Section 3.2: "198.51.0/24" --> "198.51.100.0/24" ? Question: Section 2.1, the Security Label should be at least of one octet. Is there a limit of octets for this field? Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-pim-assert-packing-08
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-pim-assert-packing-08 Reviewer: Ines Robles Review Date: 2023-03-02 IETF LC End Date: 2023-03-02 IESG Telechat date: Not scheduled for a telechat Summary: This document defines a mechanism to send and receive information for multiple IP multicast flows in a single PackedAssert message. I have not found major issues in this document. Major issues: None Minor issues: None Nits/editorial comments: Missing caption for Figure 9 and Figure 10 Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-tcpm-rfc8312bis-14
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-tcpm-rfc8312bis-14 Reviewer: Ines Robles Review Date: 2022-12-19 IETF LC End Date: 2022-12-19 IESG Telechat date: Not scheduled for a telechat Summary: This document updates the specification of CUBIC to include algorithmic improvements based on implementations and recent academic work. It also moves the specification to the Standards Track, obsoleting RFC 8312. The document also requires updating RFC 5681, to allow for CUBIC's occasionally faster ramp up sending behavior. The errata proposed in RFC 8312 was rejected, thus, not included in this new version I only have minor nits for this document. Major issues: None Minor issues: None Nits/editorial comments: * Perhaps it would be nice to add a subsection in Section I, to explain the update to RFC5681 * It would be nice to add some explanation to the figure captions Thanks for this document, Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-ippm-ioam-deployment-02
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-ippm-ioam-deployment-02 Reviewer: Ines Robles Review Date: 2022-11-16 IETF LC End Date: 2022-11-16 IESG Telechat date: Not scheduled for a telechat Summary: The document provides a framework for "In-situ" Operations, Administration, and Maintenance (IOAM) deployment and discusses IOAM Deployment, Types of IOAM, IOAM Encapsulations, IOAM Data Export, Deployment Considerations and IOAM Manageability The document is well written, and has a good set of references. I have some minor questions that I set as nits. Major issues: None Minor issues: None Nits/editorial comments/Questions: 1- Page 19: "... defining performance limits on IOAM encapsulation and IOAM exporting" -> how are defined the performance limits? 2- What about the IOAM Data overhead? if it is possible to have it, how to handle it? 3- The IOAM data is inserted in the packet, even if the data payload is zero? or this scenario is not possible? 4- In [https://datatracker.ietf.org/meeting/104/materials/slides-104-6man-sessb-in-situ-oam-ioam-in-ipv6-and-deployment-considerations-for-in-situ-oam-with-ipv6-options-00.pdf] states: "Packet forwarding behaviour or decisions should not change due to presence of IOAM". Does this apply to this document as well, right? Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [homenet] Genart last call review of draft-ietf-homenet-naming-architecture-dhc-options-21
Hi Daniel,
Thanks for addressing my comments. I agree with your suggestions.
BR,
Ines.
On Wed, Oct 5, 2022 at 5:01 AM Daniel Migault wrote:
> Hi Ines,
>
> Thanks for the reviews. We can of course include 7227 and I added the
> reference as follows:
>
> This section details the payload of the DHCPv6 options following the
> guidelines of {
> {?RFC7227}}.
>
> Regarding your second comment, I think what we meant is that the trust
> associated with the information obtained via the DHCP option described in
> this document is similar to the trust associated with the IP prefix. I
> think the texte might be clearer saying:
>
> OLD:
> The use of DHCPv6 options provides a similar level of trust as
> the one used to provide the IP prefix
>
> NEW:
> The trust associated with the information carried by the DHCPv6 Options
> described in this document is similar to the one associated with the IP
> prefix - when configured via DHCPv6.
>
> The changes can be seen on github:
>
> https://github.com/ietf-homenet-wg/front-end-naming-delegation-dhc-options/blob/master/draft-ietf-homenet-naming-architecture-dhc-options.md
>
> Yours,
> Daniel
>
> On Tue, Oct 4, 2022 at 12:58 PM Ines Robles via Datatracker <
> nore...@ietf.org> wrote:
>
>> Reviewer: Ines Robles
>> Review result: Ready with Nits
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair. Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-homenet-naming-architecture-dhc-options-??
>> Reviewer: Ines Robles
>> Review Date: 2022-10-04
>> IETF LC End Date: 2022-10-04
>> IESG Telechat date: 2022-10-20
>>
>> Summary:
>>
>> This document defines DHCPv6 options so an Homenet Naming Authority (HNA)
>> can
>> automatically proceed to the appropriate configuration and outsource the
>> authoritative naming service for the home network.
>>
>> The document is well written and easy to understand.
>>
>> I have two minor questions as nits.
>>
>> Major issues: None
>> Minor issues: None
>> Nits/editorial comments/Questions:
>>
>> 1- Have you consider in this document RFC 7227- Guidelines for Creating
>> New
>> DHCPv6 Options -? If yes, should it be added in the references? If not,
>> why
>> not? 2- Page 9: "The use of DHCPv6 options provides a similar level of
>> trust as
>> the one used to provide the IP prefix." In which features are similar? In
>> which
>> features are dissimilar?
>>
>> Thanks for this document,
>>
>> Ines.
>>
>>
>>
>> ___
>> homenet mailing list
>> home...@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
>>
>
>
> --
> Daniel Migault
> Ericsson
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-homenet-naming-architecture-dhc-options-21
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-homenet-naming-architecture-dhc-options-?? Reviewer: Ines Robles Review Date: 2022-10-04 IETF LC End Date: 2022-10-04 IESG Telechat date: 2022-10-20 Summary: This document defines DHCPv6 options so an Homenet Naming Authority (HNA) can automatically proceed to the appropriate configuration and outsource the authoritative naming service for the home network. The document is well written and easy to understand. I have two minor questions as nits. Major issues: None Minor issues: None Nits/editorial comments/Questions: 1- Have you consider in this document RFC 7227- Guidelines for Creating New DHCPv6 Options -? If yes, should it be added in the references? If not, why not? 2- Page 9: "The use of DHCPv6 options provides a similar level of trust as the one used to provide the IP prefix." In which features are similar? In which features are dissimilar? Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-tsvwg-ecn-l4s-id-26
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-tsvwg-ecn-l4s-id-26 Reviewer: Ines Robles Review Date: 2022-07-21 IETF LC End Date: 2022-07-21 IESG Telechat date: Not scheduled for a telechat Summary: The document, with experimental intended status, defines the protocol to be used for a new network service called low latency, low loss and scalable throughput (L4S). L4S uses an Explicit Congestion Notification (ECN) scheme at the IP layer. The document is well written, includes also discussion about open issues/questions to be addressed through experimentation Major issues: None Minor issues: None Nits/comments: Page 17: " ..The members of the Transport Working group are not aware of any... " it would be nice to add something like: "At the time of writing this specification, the members of the Transport Working group are not aware.." Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-masque-h3-datagram-10
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-masque-h3-datagram-10 Reviewer: Ines Robles Review Date: 2022-06-08 IETF LC End Date: 2022-06-08 IESG Telechat date: 2022-06-16 Summary: The document describes HTTP Datagrams, a convention that supports the bidirectional and optionally multiplexed exchange of data inside an HTTP connection. The document also defines the HTTP capsule protocol that addresses HTTP/3 cases where use of the QUIC DATAGRAM frame is unavailable or undesirable. Major issues: None Minor issues: None Nits/editorial comments: None Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-anima-constrained-join-proxy-09
Reviewer: Ines Robles Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-anima-constrained-join-proxy-09 Reviewer: Ines Robles Review Date: 2022-04-08 IETF LC End Date: 2022-04-08 IESG Telechat date: Not scheduled for a telechat Summary: The document defines a mechanism to assign a Device (Pledge) to a (anima) domain, represented by a Registrar, using an intermediate node (e.g. 6LR) called constrained Joint Proxy. Once that the Pledge is enrolled to the network, it can take the role of a Joint Proxy. I understand that the document is going currently under modifications, new text is being proposed into the Mailing List (e.g. updates on section 4, etc.), and the open issues are being tracked into github [https://github.com/anima-wg/constrained-join-proxy/issues/] Additional Comments/Questions: 1- Which are the differences between a "Circuit-proxy" and a "stateful constrained join Proxy"? I understand that both are stateful join proxy entities, right? (Maybe the difference is in the constrained level?). In the abstract states that they replace each other. Maybe a better description could be: "instead of having only stateful join proxy (Circuit-proxy) mode, this spec also include the stateless join proxy mode", is this correct? 2- Terminology Section: 2.1- It mentions JCR, but in the text is used "Registrar", thus, it could be mentioned here that both refers to the same. 2.2- Other terms such as TOFU, MASA and imprint are never used through the document [Maybe it should be described (in SEC. section?) how these terms are related in this document (if applicable)]. 2.3- Additionally, it would be nice to include the definition of the: a) "constrained Joint Proxy" [smth similar what RFC9030 defines?]; b) "Stateful and Stateless mode" (the text from the introduction could be moved to this section); c) circuit-proxy (refer to RFC8995?) 3- What happens when a joint-proxy restart in a stateful mode during a joining message flow? 4- Just for better understanding: E.g. If a Pledge participates in two different use cases, meaning two different domains, then is it possible that the Pledge become Stateful and Stateless Join Proxy (in different domains)?. I understand that this is possible, but not useful, since the device will include the specification complexity of both modes. Thus, I could think that it is recommended to select the same mode for all the domains that a device join? This could be a decision point whether to become or not a joint proxy? (Although, at the end of the day it could be defined by the use case requirements/available network resources). 5- Section 5, Page 6: "..A Join Proxy MAY implement both, with an unspecified mechanism to switch between the two modes." I understand that it refers to one single domain, I do not understand the meaning of "unspecified mechanism". Maybe it should read: "the mechanism to switch between modes is not in the scope of this document" ? 6- Section 5.1, Page 6: "...The Join Proxy maintains a 4-tuple array to translate the DTLS messages received from the Registrar and forwards it back to the Pledge..." Translate the DTLS message to what? Please clarify. 7- Page 11: I understand that when the Pledge is one hop from the Registrar, it does not need the join proxy, right? Nit (Pag. 11): "...Step 2 in implementation dependent..." -> "...Step 2 is implementation dependent..." Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-quic-applicability-14
Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-quic-applicability-14 Reviewer: Ines Robles Review Date: 2022-02-07 IETF LC End Date: 2022-02-07 IESG Telechat date: Not scheduled for a telechat Summary: This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. The document is well written and clear. I have one minor issue. Major issues: None Minor issues: Section 2 on the sentence: "While recent measurements have shown no evidence of a widespread, systematic disadvantage of UDP traffic compared to TCP in the Internet" Statement of "no evidence of a widespread, systematic disadvantage" may be seen as misleading when the example is about networks that simply block UDP traffic without considering other possible disadvantages, moreover when one of the references specifically states the opposite "3% failure is a lot". Additionally references are rather old (2016) materials. Suggestion for avoidance of doubt: "Measurements have shown 3-5% of networks blocking UDP, constituting a disadvantage of UDP traffic compared to TCP in the Internet [Edeline16], [Trammell16] [Swett16]. All applications running on top of QUIC must therefore..." Nits: None Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-httpbis-priority-10
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-httpbis-priority-10 Reviewer: Ines Robles Review Date: 2021-11-29 IETF LC End Date: 2021-11-29 IESG Telechat date: 2022-01-06 Summary: The document describes a scheme that allows an HTTP client to communicate its preferences for how the upstream server prioritizes responses to its requests, and also allows a server to hint to a downstream intermediary how its responses should be prioritized when they are forwarded. The document does not present major issues, just one minor nit. Major issues: None Minor issues: None Nits/editorial comments: Page 6: "Multiple experiments from independent research have shown" --> please add references to this claim Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-tsvwg-rfc4960-bis-15
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-tsvwg-rfc4960-bis-15 Reviewer: Ines Robles Review Date: 2021-10-14 IETF LC End Date: 2021-10-14 IESG Telechat date: Not scheduled for a telechat Summary: This document describes the Stream Control Transmission Protocol (SCTP) and incorporates the specification of the chunk flags registry from RFC 6096 and the specification of the I bit of DATA chunks from RFC 7053. This document obsolotes RFC 4960, RFC 6069 and RFC 7053. Some minor nits found. Major issues: None Minor issues: None Nits/editorial comments: Page 10: Primary Path:destination and source address -> destination and source transport address? Page 16: Section 2.5.7: "...currently perceived reachability..." -> Which mechanisms are used to perceive reachability? Page 18: "... for ABC..." => "... for Appropriate Byte Counting (ABC)..."? Page 42: "... send a HEARTBEAT..." -> ... send a HEARTBEAT (HB)..." Page 55, Figure 3: "generate Cookie" -> "generate State Cookie"?. "start init timer" -> "start T1-init timer"? "start cookie timer" -> "start T1-cookie timer"? Page 58, Section 5.1: In the section A) , should be added the creation of the TCB? Page 66, Section 5.2: "... this endpoint. , the endpoint processes..." -> "...this endpoint. Therefore, the endpoint processes..."? Page 76: "... ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT." -> "... ESTABLISHED, SHUTDOWN-PENDING, and SHUTDOWN-SENT states."? "... SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED."->"... SHUTDOWN-PENDING, and SHUTDOWN-RECEIVED states."? Page 77: "... indefinte " -> indefinite? Page 80: One of the reason for setting the I bit from RFC 7053 (Section 5.1. Sender-Side Considerations) is not present in the draft, is this Ok? "The sending of an Outgoing SSN Reset Request Parameter or an SSN/TSN Reset Request Parameter is pending, if the association supports the Stream Reconfiguration extension defined in [RFC6525]." Page 81: "...Gap Ack Block fields. , the endpoint"-> "Gap Ack Block fields. Therefore, the endpoint"? Page 94: "...then IP fragmentation MUST be used. , an SCTP association can..." -> "...then IP fragmentation MUST be used. Therefore, an SCTP ..."? Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-mmusic-rfc8843bis-04
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mmusic-rfc8843bis-04 Reviewer: Ines Robles Review Date: 2021-08-09 IETF LC End Date: 2021-08-09 IESG Telechat date: Not scheduled for a telechat Summary: The document defines a new Session Description Protocol (SDP) Grouping Framework extension called 'BUNDLE'. The document obsoletes RFC8843 (published on Jan 2021) by removing the inconsistency between RFC 8843 and RFC8829. - The procedures regarding assigning the port value to a bundled "m=" section in an answer and instead use the same port for all bundled "m=" sections; some (initial or subsequent) and a subsequent offer were inconsistent. This specification removes the inconsistency by aligning the port value assignment procedure with the procedure in RFC 8829.- This specification updates also RFCs 3264, 5888, and 7941. Major issues: Not found Minor issues: Not found Nits/editorial comments: Not found Thanks for this document, Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-bmwg-evpntest-07
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-bmwg-evpntest-07 Reviewer: Ines Robles Review Date: 2021-05-24 IETF LC End Date: 2021-05-24 IESG Telechat date: Not scheduled for a telechat Summary: This document defines methodologies for benchmarking Ethernet VPN (EVPN) and Provider Backbone Bridging EVPN (PBB-EVPN) performance. This document is Informational. No major issues found. Major issues: None Minor issues: None Nits/editorial comments: - Check punctuation, some sentences do not start with space after period. e.g. page 16 "... sample.The time ..." - Some paragraphs do not start with upper-case letter. e.g. page 10, "confirm the DUT..." - I would expand PBB-EVPN the first time used. Perhaps in the introduction, "Provider Backbone Bridging EVPN (PBB-EVPN) is defined in RFC 7623, discussing how can be combined with EVPNs to provide a new/combined solution" Thank you for this document, Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-lamps-crmf-update-algs-04
Hi Russ, Thank you very much for addressing my comments promptly. I am ok with your proposals. BR, Ines On Fri, Mar 26, 2021 at 9:27 PM Russ Housley wrote: > Ines Robles: > > Thank you for the careful review and comments. > > > Nits/Comments: > > > > 1- Introduction: "however, these algorithms are no longer > > considered the best choices. " => It would be nice to add 1 or more > > sentences explaining why they are no longer the best choices > > I suggest: > >This document updates the cryptographic algorithm requirements for >the Password-Based Message Authentication Code (MAC) in the Internet >X.509 Public Key Infrastructure Certificate Request Message Format >(CRMF) [RFC4211]. The algorithms specified in [RFC4211] were >appropriate in 2005; however, these algorithms are no longer >considered the best choices: > >* HMAC-SHA1 [HMAC][SHS] is not boken yet, but there are much > stronger alternatives [RFC6194]. > >* DES-MAC [PKCS11] provides 56 bits of security, which is no longer > considered secure [WITHDRAW]. > >* Triple-DES-MAC [PKCS11] provides 112 bits of security, which is > now deprecated [TRANSIT]. > >This update specifies algorithms that are more appropriate today. > > With these references: > >[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security > Considerations for the SHA-0 and SHA-1 Message-Digest > Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, > <https://www.rfc-editor.org/info/rfc6194>. > >[TRANSIT] National Institute of Standards and Technology, > "Transitioning the use of cryptographic algorithms and key > lengths", NIST SP 800-131Ar2, March 2019. > >[WITHDRAW] National Institute of Standards and Technology, "NIST > Withdraws Outdated Data Encryption Standard", 2 June 2005. > > > 2- Page 3: "id-PasswordBasedMAC as presented in Section 4.4 of this > document" > > It should be perhaps be "id-PasswordBasedMAC as presented in Section 4.4 > of > > [RFC4211]" ? > > I was thinking of the NEW text appearing in the "updated" RFC 4211. Your > suggestion is more clear. > > > 3- If this document does not present privacy considerations, should it be > > explicitly mentioned in Section 6? > > I do not agree. A document that simply modernized the > mandatory-to-implement cryptographic algorithm in not the place to > introduce the privacy considerations for CRMF. > > > 4- Since the new updates include the use of PBMAC1, HMAC-SHA256, > AES-GMAC AES. > > Should Section 6 include considerations about them or point to place > where to > > find them? e.g. For information on security considerations for PBMAC1 see > > [rfc8018#section-8]. > > Good idea. I suggest: > >Please see [RFC8018] for security considerations related to PBMAC1. > >Please see [HMAC] and [SHS] for security considerations related to >HMAC-SHA256. > >Please see [AES] and [GMAC] for security considerations related to >AES-GMAC. > > Russ > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lamps-crmf-update-algs-04
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lamps-crmf-update-algs-04 Reviewer: Ines Robles Review Date: 2021-03-26 IETF LC End Date: 2021-03-26 IESG Telechat date: Not scheduled for a telechat Summary: The document updates the cryptographic algorithm requirements for the Password-Based Message Authentication Code in the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF). The document is well written, I have minor comments/questions to the authors. Major Issues: None Minor Issues: None Nits/Comments: 1- Introduction: "however, these algorithms are no longer considered the best choices. " => It would be nice to add 1 or more sentences explaining why they are no longer the best choices 2- Page 3: "id-PasswordBasedMAC as presented in Section 4.4 of this document" It should be perhaps be "id-PasswordBasedMAC as presented in Section 4.4 of [RFC4211]" ? 3- If this document does not present privacy considerations, should it be explicitly mentioned in Section 6? 4- Since the new updates include the use of PBMAC1, HMAC-SHA256, AES-GMAC AES. Should Section 6 include considerations about them or point to place where to find them? e.g. For information on security considerations for PBMAC1 see [rfc8018#section-8]. Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-stir-cert-delegation-03
Hi Jon, Thank you very much for your comments. Best regards, Ines On Tue, Feb 23, 2021 at 1:41 AM Peterson, Jon wrote: > Hi Ines, > > Thanks for the read on this one (and sorry for the lengthy RTT). A few > responses. > > Minor issues: > > 1-Introduction Section: > > "..., including various forms of robocalling, voicemail hacking, and > swatting..." --> should a reference to RFC7375 be added here? > > Sure, I added that. > > 2- It would be nice to add in Terminology section: > > - delegation: the concept of delegation and its levels are defined in > RFC8226. > - definition for "legitimate spoofing". I understand that the draft > explain it > with an example. > > Okay, done. > > 3- It would be nice to add references to concepts, e.g. cA boolean --> > cA > boolean [rfc5280#section-4.2.1.9] > > Happy to add an RFC5280 ref there, though there's one in the next sentence > as well. > > "x5u" link -> "x5u" (X.509 URL) [RFC7515#section-4.1.5] link > > Above, the document already clarified that it is the '"x5u" field of a > PASSporT", so I think this is okay, > > 4- Section 4: It would be nice to add graphics explaining the process. > E.g. can be used as a model the images displayed in > > https://urldefense.com/v3/__https://access.atis.org/apps/group_public/download.php/47134/IPNNI-2019-00043R000.pdf__;!!N14HnBHF!pqqZYxfzyDJsOfjv6c430dpNOf2YhrmkDNAxZirgs5A8IzZ83HtQcqUazIErtBmFUer3YYg$ > > or > https://urldefense.com/v3/__https://niccstandards.org.uk/wp-content/uploads/2019/03/ND1522V1.1.1.pdf__;!!N14HnBHF!pqqZYxfzyDJsOfjv6c430dpNOf2YhrmkDNAxZirgs5A8IzZ83HtQcqUazIErtBmFvLx6Y_8$ > > > Not sure about adding new pictures at this point; or at least, I think the > basic idea should be clear from the text by itself. > > 5- Section 5:"Authentication service behavior for delegate > certificates is > little >changed from [RFC8224] STIR behavior" --> It is not clear to me > what are the >little changes. > > Additionally, how you quantify little/big changes?, maybe something > like?: > "Authentication service behavior varies from STIR behavior [RFC8224] as > follows:" > > Okay, I can do that. > > 6- Section 8.1: Should the picture displayed in > > https://urldefense.com/v3/__https://www.ietf.org/proceedings/104/slides/slides-104-stir-certificate-delegation-00--Slide__;!!N14HnBHF!pqqZYxfzyDJsOfjv6c430dpNOf2YhrmkDNAxZirgs5A8IzZ83HtQcqUazIErtBmFHaoqDrY$ > > 5 be added here? > > Really would rather not do new pictures at this point. > > 7- Security Consideration section: should a reference to RFC7375 be > added here? > > Added. > > Nits/editorial comments: > > 8- Expand the first time: JWS -> JSON Web Signature (JWS) > > Done. Thanks! > > Jon Peterson > Neustar, Inc. > > Thank you for this document, > > Ines. > > > > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-detnet-mpls-over-tsn-05
Hi Balázs, Thank you for your clarifications. It is Ok for me. BR, Ines On Mon, Feb 8, 2021 at 10:46 PM Balázs Varga A wrote: > Hi Ines, > Many thanks for your review. > See my reactions and proposed updates below. > Thanks > Bala'zs > > -Original Message- > From: Ines Robles via Datatracker > Sent: Saturday, February 6, 2021 12:57 AM > To: gen-art@ietf.org > Cc: det...@ietf.org; draft-ietf-detnet-mpls-over-tsn@ietf.org; > last-c...@ietf.org > Subject: Genart last call review of draft-ietf-detnet-mpls-over-tsn-05 > > Reviewer: Ines Robles > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-detnet-mpls-over-tsn-05 > Reviewer: Ines Robles > Review Date: 2021-02-05 > IETF LC End Date: 2021-02-05 > IESG Telechat date: 2021-02-18 > > Summary: > > This document specifies the Deterministic Networking MPLS data plane when > operating over a TSN sub-network. > > I have some minor questions to the authors. > > Major issues: None > > Minor issues: None > > Nits/editorial comments: > > - Page 5: Could you please describe what the "TSN treatment" comprise? > > TSN treatment means to execute TSN functionalities during > forwarding. I will extend the text > OLD TEXT: >... All these functions have to identify flows those >require TSN treatment. > NEW TEXT: >... All these functions have to identify flows those >require TSN treatment (i.e., applying TSN functions >during forwarding). > END > > - Are the security considerations the same for TSN-unaware that are for > TSN-aware nodes? - How are the privacy considerations for those? It would > be nice to mention explicitly how or where (I-D.ietf-detnet-security???) > the privacy considerations are addressed for TSN-unaware and TSN-aware nodes > > The I-D.ietf-detnet-security contains DetNet specific security > considerations. TSN-unaware nodes are out-of-scope in the draft. TSN-aware > nodes are part of both the MPLS and the TSN domain, where both domain has > its own security considerations, which must be applied. > > Thank you for this document > > Ines. > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-detnet-mpls-over-tsn-05
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-detnet-mpls-over-tsn-05 Reviewer: Ines Robles Review Date: 2021-02-05 IETF LC End Date: 2021-02-05 IESG Telechat date: 2021-02-18 Summary: This document specifies the Deterministic Networking MPLS data plane when operating over a TSN sub-network. I have some minor questions to the authors. Major issues: None Minor issues: None Nits/editorial comments: - Page 5: Could you please describe what the "TSN treatment" comprise? - Are the security considerations the same for TSN-unaware that are for TSN-aware nodes? - How are the privacy considerations for those? It would be nice to mention explicitly how or where (I-D.ietf-detnet-security???) the privacy considerations are addressed for TSN-unaware and TSN-aware nodes Thank you for this document Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-core-echo-request-tag-11
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-core-echo-request-tag-11 Reviewer: Ines Robles Review Date: 2020-12-02 IETF LC End Date: 2020-12-02 IESG Telechat date: Not scheduled for a telechat Summary: This document specifies the Echo option that enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address, and specifies also the Request-Tag that allows the CoAP server to match block-wise message fragments belonging to the same request. Also, this document updates RFC7252 with respect to the client Token processing requirements. The document is well written, I have some minor questions/comments below. Major issues: None. Minor issues: None. Nits/editorial comments: 1.- It would be nice to have the definition of Freshness into the terminology section. 2.- Figure 1 and Figure 4 have two columns named "U" (Unsafe), is that Ok?, or should one of these columns be deleted/renamed? 3- Page 26: Please expand IV. Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-opsawg-model-automation-framework-06
Hi Med, Thank you very much for the provided information. I have updated my gen-art review. BR, Ines On Mon, Oct 12, 2020 at 9:41 AM wrote: > Hi Ines, > > > > Thank you. A new version that takes into account all reviews, including > yours can be seen at: > > > > URL: > https://www.ietf.org/id/draft-ietf-opsawg-model-automation-framework-07.txt > > Status: > https://datatracker.ietf.org/doc/draft-ietf-opsawg-model-automation-framework/ > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-model-automation-framework > > Htmlized: > https://tools.ietf.org/html/draft-ietf-opsawg-model-automation-framework-07 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-model-automation-framework-07 > > > > > Please see also inline. > > > > Cheers, > > Med > > > > *De :* Ines Robles [mailto:mariainesrob...@googlemail.com] > *Envoyé :* dimanche 11 octobre 2020 12:03 > *À :* BOUCADAIR Mohamed TGI/OLN > *Cc :* gen-art@ietf.org; ops...@ietf.org; > draft-ietf-opsawg-model-automation-framework@ietf.org; > last-c...@ietf.org > *Objet :* Re: Genart last call review of > draft-ietf-opsawg-model-automation-framework-06 > > > > Hi Med, > > > > Thank you very much for addressing my comments. Please find my answers > below. > > > > > > > > d- Figure 3: The box Device includes Device Modeling. Should be > > added in Device as another box for "Resource Orchestration"? (As > > e.g. Service has Service > > Orchestration) > > > > [Med] Resource orchestration/allocation is more on the network level. The > network model definition says the following: > > It can be used by a network operator to allocate resources (e.g., > tunnel resource, topology resource) for the service or schedule > resources to meet the service requirements defined in a Service > Model. > > Of course some of this may be distributed, but I don't think that we need > to overload the document with this. > > > > Ok, it is fine for me, my question was more related to device > resources e.g. sensors/actuators as device resources > > > > [Med] Thank you for the clarification. This is a sub-component of the > overall “Device Modelling”. Please refer to “A.4.2. Device Management”. We > don’t want to overload figure 3 with many internal components. > > > > > > e.3- In the explanation of the Functional Blocks and Interactions > > section, why the following blocks are not defined/explained in the > > subsections?: *Service Assurance *Specific Service > > Creation/Modification *Specific Service Optimization *Specific > > Service Assurance > > [Med] We don’t repeat "Specific-*" as we do say the following: > >The end-to-end service lifecycle management is technology-independent >service management and spans across multiple network domains and/or >multiple layers while technology specific service lifecycle >management is technology domain specific or layer specific service >lifecycle management. > > We also include in the description of the journey among layers. For > example, the service creation section says: > >If the request is accepted, the service orchestrator/management >system maps such service request to its view. This view can be >described as a technology specific Network Model or a set of >technology specific Device Models and this mapping may include a >choice of which networks and technologies to use depending on which >service features have been requested. > > That is basically about "Specific Service Creation". > > Will double check, though. > >Ok, thank you. But what about the service Assurance? > > [Med] A new sub-section was added. > > > > > > _ > > 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. > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-opsawg-model-automation-framework-06
Hi Med, Thank you very much for addressing my comments. Please find my answers below. On Fri, Oct 9, 2020 at 11:04 AM wrote: > Hi Ines, > > Thank you for the review. > > Please see inline. > > Cheers, > Med > > > -Message d'origine- > > De : Ines Robles via Datatracker [mailto:nore...@ietf.org] > > Envoyé : vendredi 9 octobre 2020 00:48 > > À : gen-art@ietf.org > > Cc : ops...@ietf.org; draft-ietf-opsawg-model-automation- > > framework@ietf.org; last-c...@ietf.org > > Objet : Genart last call review of draft-ietf-opsawg-model- > > automation-framework-06 > > > > Reviewer: Ines Robles > > Review result: Ready with Issues > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed by > > the IESG for the IETF Chair. Please treat these comments just like > > any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-opsawg-model-automation-framework-06 > > Reviewer: Ines Robles > > Review Date: 2020-10-08 > > IETF LC End Date: 2020-10-08 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > > > This document describes an architectural framework for service and > > network management automation, with respect of service, network and > > device level. > > > > I have some concerns as detailed below that I would like to be > > addressed before publication > > > > Major issues: None > > > > Minor issues: > > > > a-Introduction: > > > > "framework...that takes advantage of YANG modeling technologies" --> > > how does it take advantage? > > > > [Med] We can add this NEW text: > > Concretely, the following benefits can be provided: > >o Allow for vendor-agnostic interfaces to manage a service and the > underlying network. > >o Move from deployment schemes where vendor-specific network > managers are required to a scheme where the entities that are > responsible for orchestrating and controlling services and network > resources provided by multi-vendor devices are unified. > >o Ease data inheritance and reusability among the various > architecture layers promoting thus a network-wise provisioning > instead of device-specific configuration. > >o Dynamically fed a decision-making process (e.g., Controllers, > Orchestrators) with notifications that will trigger appropriate > actions allowing thus to continuously adjust a network stats (and > thus devices) to comply the intended service. > > Do we need to say more? > Ok, that is great, thank you > > > b- Section 2.2: I would add in the acronyms list: SP, ASes, SBE/DBE, > > E2E > > [Med] OK. > > > > > c- Section 3.1: > > > > It would be nice to add clarification: Data models can be classified > > -> Data models in the context of . can be classified... > > > > [Med] Agree. Changed to "Data models in the context of network management". > Ok, thank you > > > d- Figure 3: The box Device includes Device Modeling. Should be > > added in Device as another box for "Resource Orchestration"? (As > > e.g. Service has Service > > Orchestration) > > > > [Med] Resource orchestration/allocation is more on the network level. The > network model definition says the following: > > It can be used by a network operator to allocate resources (e.g., > tunnel resource, topology resource) for the service or schedule > resources to meet the service requirements defined in a Service > Model. > > Of course some of this may be distributed, but I don't think that we need > to overload the document with this. > Ok, it is fine for me, my question was more related to device resources e.g. sensors/actuators as device resources > > > e- Section 4, Figure 4: > > > > e.1- [RFC8309] divides the Service Model into two categories: > > Customer Service Model and Service Delivery Model > > > > How these categories are descripted into the Service Lifecycle in > > the Figure? > > > > [Med] Customer Service Model are used at the service layer. See for > example this mention in the document: > >L2SM and L3SM are customer Service Models as per [RFC8309]. > > We are not using "Service Delivery Model" as this may not be specific. > Ple
[Gen-art] Genart last call review of draft-ietf-opsawg-model-automation-framework-06
Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-opsawg-model-automation-framework-06 Reviewer: Ines Robles Review Date: 2020-10-08 IETF LC End Date: 2020-10-08 IESG Telechat date: Not scheduled for a telechat Summary: This document describes an architectural framework for service and network management automation, with respect of service, network and device level. I have some concerns as detailed below that I would like to be addressed before publication Major issues: None Minor issues: a-Introduction: "framework...that takes advantage of YANG modeling technologies" --> how does it take advantage? b- Section 2.2: I would add in the acronyms list: SP, ASes, SBE/DBE, E2E c- Section 3.1: It would be nice to add clarification: Data models can be classified -> Data models in the context of . can be classified... d- Figure 3: The box Device includes Device Modeling. Should be added in Device as another box for "Resource Orchestration"? (As e.g. Service has Service Orchestration) e- Section 4, Figure 4: e.1- [RFC8309] divides the Service Model into two categories: Customer Service Model and Service Delivery Model How these categories are descripted into the Service Lifecycle in the Figure? e.2- in the Device Level: Should be added Accounting Management and Security Management [RFC5706]? e.3- In the explanation of the Functional Blocks and Interactions section, why the following blocks are not defined/explained in the subsections?: *Service Assurance *Specific Service Creation/Modification *Specific Service Optimization *Specific Service Assurance f- Section 6: I think it would be nice to explain the security considerations based on the possible attacks/threats/privacy to Service Level, Network Level and Device Level. In other words, explains the vulnerabilities for each part of the entities that conform the proposed framework. g- Does this framework applies to the management plane, right? h- What do you think about policies, e.g.[rfc8328], should it be applied here? Nits/editorial comments: cutsomer-facing -> customer-facing data module --> data model? expand OSS/BSS -> Operations Support System (OSS) or a Business Support System (BSS) Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-stir-cert-delegation-03
Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-stir-cert-delegation-03 Reviewer: Ines Robles Review Date: 2020-08-26 IETF LC End Date: 2020-08-26 IESG Telechat date: Not scheduled for a telechat Summary: This specification details how that authority can be delegated from a parent certificate to a subordinate certificate. This supports a number of use cases where callers want to use a particular calling number, but for whatever reason, their outbound calls will not pass through the authentication service of the service provider that controls that numbering resource, it includes also those where service providers grant credentials to enterprises or other customers capable of signing calls with Secure Telephone Identity Revisited (STIR). I have some minor suggestions/questions to the authors. Major issues: None Minor issues: 1-Introduction Section: "..., including various forms of robocalling, voicemail hacking, and swatting..." --> should a reference to RFC7375 be added here? 2- It would be nice to add in Terminology section: - delegation: the concept of delegation and its levels are defined in RFC8226. - definition for "legitimate spoofing". I understand that the draft explain it with an example. 3- It would be nice to add references to concepts, e.g. cA boolean --> cA boolean [rfc5280#section-4.2.1.9] "x5u" link -> "x5u" (X.509 URL) [RFC7515#section-4.1.5] link 4- Section 4: It would be nice to add graphics explaining the process. E.g. can be used as a model the images displayed in https://access.atis.org/apps/group_public/download.php/47134/IPNNI-2019-00043R000.pdf or https://niccstandards.org.uk/wp-content/uploads/2019/03/ND1522V1.1.1.pdf 5- Section 5:"Authentication service behavior for delegate certificates is little changed from [RFC8224] STIR behavior" --> It is not clear to me what are the little changes. Additionally, how you quantify little/big changes?, maybe something like?: "Authentication service behavior varies from STIR behavior [RFC8224] as follows:" 6- Section 8.1: Should the picture displayed in https://www.ietf.org/proceedings/104/slides/slides-104-stir-certificate-delegation-00--Slide 5 be added here? 7- Security Consideration section: should a reference to RFC7375 be added here? Nits/editorial comments: 8- Expand the first time: JWS -> JSON Web Signature (JWS) Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08
Hi Michael, Yes, that would be great, if possible. Thank you, Ines On Mon, Jul 13, 2020 at 3:56 AM Michael Richardson wrote: > > Ines Robles via Datatracker wrote: > > 2- Introduction: "reports from implementers suggest..." It would be > nice to add > > reference/s here > > Well, I'm not sure how I can add a reference to private emails. > I can ask the implementers to write a public email if that is intended. > Please advise. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08
Hi Russ,
Thank you very much for your reply,
Best,
Ines
On Wed, Jul 8, 2020 at 10:37 PM Russ Housley wrote:
> Ines:
>
> Thanks for the very carful review. I'll tackle the ones about the ASN.1...
>
> 4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {...}
>
> 4.1- pkcs9(9) should be pkcs-9(9) ?
>
>
> Both are used in different modules. They have become synonyms. That
> said, we should pick one, and the use it in the two places where this is
> used.
>
> The hyphen is used in RFC 6268, where we import some things, so I suggest
> we use the hyphen here too.
>
>
> 4.2- aa(2) should be id-aa(2) ?
>
>
> No. This one is correct.
>
> Russ
>
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lamps-rfc7030est-clarify-08
Reviewer: Ines Robles
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-lamps-rfc7030est-clarify-08
Reviewer: Ines Robles
Review Date: 2020-07-08
IETF LC End Date: 2020-07-09
IESG Telechat date: Not scheduled for a telechat
Summary:
This document updates RFC7030 to address errata. This document deprecates the
specification of "Content-Transfer-Encoding" headers for EST endpoints. This
document fixes some
syntactical errors in ASN.1 that were presented.
The document is clear and well written. I have some minor nits/questions
Major issues: None
Minor issues: None
Nits/editorial comments/questions:
1- It would be nice to add in Terminology section that the document uses the
terminology of RFC7030 and RFC5272
2- Introduction: "reports from implementers suggest..." It would be nice to add
reference/s here
3- Security Considerations:
It would be nice to add smth like "security considerations from RFC7030 applies
also for the clarifications described in this document."
5- IANA Considerations:
It would be nice to add the specific registry that IANA should update.
For example, instead of "IANA is requested to update the "Reference" column for
the Asymmetric Decryption Key Identifier attribute to also include a reference
to
this document." you could add smth like (if applicable): " IANA is requested
to update the registry SMI Security for S/MIME Attributes
(1.2.840.113549.1.9.16.2) "
with the reference of this document as follows:
Decimal - Description -Reference
54 id-aa-asymmDecryptKeyID [RFC7030] [ThisDocument]
4- Appendix A: In id-aa-asymmDecryptKeyID OBJECT IDENTIFIER ::= {...}
4.1- pkcs9(9) should be pkcs-9(9) ?
4.2- aa(2) should be id-aa(2) ?
Thank you for this document,
Ines.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dhc-slap-quadrant-09
Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dhc-slap-quadrant-09 Reviewer: Ines Robles Review Date: 2020-05-27 IETF LC End Date: 2020-05-27 IESG Telechat date: 2020-06-11 Summary: This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server allocates the MAC addresses to the given client out of the quadrant requested by relay or client. A new DHCPv6 option (OPTION_SLAP_QUAD, or QUAD) is defined for this purpose. The document is easy to read, however I have some minor issues/questions for the authors Major issues: Not found Minor issues: Section 1: 1- Should be specified for each quadrant who is responsible to ensure: a) uniqueness of assigned addresses and b) compatibility with other assignment protocols on the same LAN (if applicable)?, e.g for AAI, the administrator should be the responsible? 2- The caption in Figure 1, should state: "Initial octet of the IEEE 48-bit MAC address structure?" since you are representing 1 byte in the figure instead of the 6 bytes. Section 1.1.1: 3- Should be added "(IEEE 802.11)" to WiFi? 4- When it is mentioned IoT devices, I think it would be nice identify the use case with the class of device (RFC7228) instead of "there are a lot of cheap, sometimes short lived and disposable devices". I am not sure if cheap is a right word here, since it is subjective, I mean it has to be defined what is considerate cheap. Relate with -short lived- it could be due to a malfunction that the device gets broken, thus I suggest use battery-powered device or similar. Thus, it could be: "IoT (Internet of Things): In general, composed of constrained devices [RFC7228] with constrains such as ..." Note: There is another document taking place for IoT terminology [draft-bormann-lwig-7228bis] 5- Related to: " This type of device is typically not moving". Do you have a reference for this? Following my understanding there is a huge amount of smart health devices that are mobile Section 2: 6- It would be nice to add the definition and expansion for IA_LL and LLADDR Section 3: 7- Related to "Managed/unmanaged: depending on whether the IoT device is managed during its lifetime or cannot be re-configured the selected quadrant might be different" 7.1-It would be nice to describe the example referencing the management during the life cycle (rfc7548#section-3) 7.2- The sentence is not fully clear to me. "quadrant might be different" would it be better: "the quadrant might change when the device gets a configuration update"? Or the draft refers self-managed devices (rfc7547#section-3.5) gets a quadrant different to those managed by a manager server? There are specific quadrant recommendations for different IoT configuration functionality levels (RFC7547, section 1.7)? 7.3 "it can be managed, this means that network topology changes might occur during its lifetime": Would it be better to explain this based on the Dynamicity level of the network topology (rfc7547#section1.3), for example smth like: "networks with high dinamicity level have high probability of quadrant changes", does it make sense? Section 7: Should the security considerations section includes reference to the security section and privacy considerations of RFC7227? Nits/editorial comments: Not found Thank you for this document, Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-iesg-nomcom-eligibility-2020-01
Hi Barry, Thank you for the fast response and addressing the comments. Have a nice day, Ines. On Thu, Apr 30, 2020 at 5:13 PM Barry Leiba wrote: > Thanks for your review, Ines. Reasonable comments, and we'll consider > them as we go into IESG Evaluation. (On comment 3, I'm just going to > make the necessary change myself, and remove the CREF, so it's moot.) > > Barry > > On Thu, Apr 30, 2020 at 8:35 AM Ines Robles via Datatracker > wrote: > > > > Reviewer: Ines Robles > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-iesg-nomcom-eligibility-2020-01 > > Reviewer: Ines Robles > > Review Date: 2020-04-30 > > IETF LC End Date: 2020-04-30 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > > > This document provides a one-time interpretation of the eligibility > rules (BCP > > 10) that is required for the exceptional situation of the cancellation > of the > > in-person IETF 107 meeting. This document only affects the seating of the > > 2020-2021 NomCom and any rules that relate to NomCom eligibility or > process > > before IETF 108, and does not set a precedent for the future. > > > > The document is clear and well written. Please find some comments below. > > > > Major issues: Not found > > Minor issues: Not found > > Nits/editorial comments: > > > > Some comments/questions: > > > > 1- It would be nice to add a reference here > > > > Section 1: > > > > "...resulting in its conversion to a limited-agenda virtual meeting, > with remote > >participation only.": > > > >e.g. [IETF 107 Virtual] = > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/Gqc4-GIsnvccObQrrciL_Vm0HMU/ > > > > 2- Should this clarification be added? > > > > " ...before IETF 108..." --> "...before IETF 108 (virtual or in-person > > meeting)..." e.g. in the introduction or in section 3. > > > > 3- Related to this comment > > [https://mailarchive.ietf.org/arch/msg/ietf/kHVPn0tyF5o4Rvd3aZ51JA2MDtU/ > ] > > > > "... In section 2, last paragraph, I suggest changing the CREF to, > "Note: The > > previous two sentences will be replaced before publication with, 'This > document > > contains the outcome of that discussion.'" > > > > Should this suggestion be applied? > > > > Note that CREF2 mentions "the previous sentence", not "the previous two > > sentences" > > > > 4- It would be nice to add a reference to eligibility-discuss mailing > list/ > > draft-carpenter-eligibility-expand > > > > Section 3: > > > > "...as there will be time for proper community work on such an update..." > > > > Thus, e.g. "...community work on such an update (e.g. efforts such as > > [Eligibility-discuss-ml] and [Eligibility-criteria])" > > > > [Eligibility-discuss-ml]= > > https://mailarchive.ietf.org/arch/browse/eligibility-discuss/ > > [Eligibility-criteria]= > > https://datatracker.ietf.org/doc/draft-carpenter-eligibility-expand/ > > > > Thank you for this document, > > > > Ines. > > > > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-iesg-nomcom-eligibility-2020-01
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-iesg-nomcom-eligibility-2020-01 Reviewer: Ines Robles Review Date: 2020-04-30 IETF LC End Date: 2020-04-30 IESG Telechat date: Not scheduled for a telechat Summary: This document provides a one-time interpretation of the eligibility rules (BCP 10) that is required for the exceptional situation of the cancellation of the in-person IETF 107 meeting. This document only affects the seating of the 2020-2021 NomCom and any rules that relate to NomCom eligibility or process before IETF 108, and does not set a precedent for the future. The document is clear and well written. Please find some comments below. Major issues: Not found Minor issues: Not found Nits/editorial comments: Some comments/questions: 1- It would be nice to add a reference here Section 1: "...resulting in its conversion to a limited-agenda virtual meeting, with remote participation only.": e.g. [IETF 107 Virtual] = https://mailarchive.ietf.org/arch/msg/ietf-announce/Gqc4-GIsnvccObQrrciL_Vm0HMU/ 2- Should this clarification be added? " ...before IETF 108..." --> "...before IETF 108 (virtual or in-person meeting)..." e.g. in the introduction or in section 3. 3- Related to this comment [https://mailarchive.ietf.org/arch/msg/ietf/kHVPn0tyF5o4Rvd3aZ51JA2MDtU/] "... In section 2, last paragraph, I suggest changing the CREF to, "Note: The previous two sentences will be replaced before publication with, 'This document contains the outcome of that discussion.'" Should this suggestion be applied? Note that CREF2 mentions "the previous sentence", not "the previous two sentences" 4- It would be nice to add a reference to eligibility-discuss mailing list/ draft-carpenter-eligibility-expand Section 3: "...as there will be time for proper community work on such an update..." Thus, e.g. "...community work on such an update (e.g. efforts such as [Eligibility-discuss-ml] and [Eligibility-criteria])" [Eligibility-discuss-ml]= https://mailarchive.ietf.org/arch/browse/eligibility-discuss/ [Eligibility-criteria]= https://datatracker.ietf.org/doc/draft-carpenter-eligibility-expand/ Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-dnsop-7706bis-07
Hi Warren, Thank you very much for your reply, Best wishes, Ines. On Fri, Feb 28, 2020 at 8:18 PM Warren Kumari wrote: > On Fri, Feb 28, 2020 at 8:02 AM Ines Robles via Datatracker > wrote: > > > > Reviewer: Ines Robles > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-dnsop-7706bis-07 > > Reviewer: Ines Robles > > Review Date: 2020-02-28 > > IETF LC End Date: 2020-02-28 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > > > The document is well written, it supplies appendixes with examples. > > > > This document describes a method for the operator of a recursive > resolver to > > have a complete root zone locally, and to hide queries for the root zone > from > > outsiders, at the cost of adding some operational fragility for the > operator. > > > > I have some minor questions. > > > > Major issues: None > > > > Minor issues: None. > > > > Nits/editorial comments: > > > > Thank you for the review! > > > 1- Appendix B.5: it seems that the link is not valid: <https://knot- > >resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc- > >7706> > > > > This link worked for me: > > https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html. > > Thanks - not just for pointing out the issue, but also finding a > better version - as suggested, I am changing this (in a git branch > where I am collecting updates) to > https://knot-resolver.readthedocs.io/en/v5.0.1/modules-rfc7706.html - > I believe that stability is the most important attribute. AD, please > let us know if you disagree. > > > > > Questions: > > > > 1- It seems that this document replaces RFC7706, but the document states > that > > it updates RFC7706, is that correct? > > Oh, good point - once this is published, it does replace 7706 (it is a > bis, and contains all of the content from 7706), so Obsoletes is > better. > Thank you, changed. > > > > > 2- Abstract: "The cost of adding some operational fragility for the > operator", > > Does it introduce security considerations that have to be mentioned? > > > > 3- Section 1: "Research shows that the vast majority of queries going to > the > > root are for names that do not exist in the > >root zone." - Do you have some references to that research that can > be added > >to the draft? > > H... I think that we missed this because, within the DNS community > this is sufficiently well known that we don't even think about / > question it. > There is quite a lot of research on this, but much if it is behind > paywalls - while almost 20 years old now (Gods, I feel old!), I think > that the best one to cite is still: > https://www.caida.org/publications/papers/2001/DNSMeasRoot/dmr.pdf ( > DNS Measurements at a Root Server ) -- I will add this. > > > > > 4- I would expand KSK to Key signing key (KSK). > > Thanks! Done! > > > > > 5- Should this draft add a reference to rfc8499? > > Seems like a good idea, thanks! I'm adding: > "Readers are expected to be familiar with ." > > > > > Thank you for this document, > > ... and thank you for the review. > > W > > > > > Ines. > > > > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. >---maf > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dnsop-7706bis-07
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dnsop-7706bis-07 Reviewer: Ines Robles Review Date: 2020-02-28 IETF LC End Date: 2020-02-28 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written, it supplies appendixes with examples. This document describes a method for the operator of a recursive resolver to have a complete root zone locally, and to hide queries for the root zone from outsiders, at the cost of adding some operational fragility for the operator. I have some minor questions. Major issues: None Minor issues: None. Nits/editorial comments: 1- Appendix B.5: it seems that the link is not valid: <https://knot- resolver.readthedocs.io/en/stable/modules.html#root-on-loopback-rfc- 7706> This link worked for me: https://knot-resolver.readthedocs.io/en/stable/modules-rfc7706.html. Questions: 1- It seems that this document replaces RFC7706, but the document states that it updates RFC7706, is that correct? 2- Abstract: "The cost of adding some operational fragility for the operator", Does it introduce security considerations that have to be mentioned? 3- Section 1: "Research shows that the vast majority of queries going to the root are for names that do not exist in the root zone." - Do you have some references to that research that can be added to the draft? 4- I would expand KSK to Key signing key (KSK). 5- Should this draft add a reference to rfc8499? Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-sipcore-locparam-04
Hi Roland,
Thank you for addressing my comments. I agree with them.
Best,
Ines.
On Wed, Jan 29, 2020 at 8:50 AM wrote:
> Hi Ines,
> Thank you for your review.
> I have incoperated your comments within the draft.
>
> On Question 1 In Section 1 I have changed the last paragraph by adding the
> reference of RF64412 as follows:
> " This document extends the Geolocation header field of RFC6442, by
> allowing an entity adding the locationValue to identity itself using a
> hostname. This is done by defining a new geoloc-param header field
> parameter,
>
> Hope this is OK for you.
>
> Question 2: It is difficult to reference the various architectures for
> emergency since each country, based on national regulation rules, may have
> it's own architecture.
>
> Question 3: This apply to the rules defined in RFC6442 in Section 4.4.
>
> Best Regards
>
> Roland
>
> -Ursprüngliche Nachricht-
> Von: Ines Robles via Datatracker
> Gesendet: Sonntag, 26. Januar 2020 23:29
> An: gen-art@ietf.org
> Cc: last-c...@ietf.org; sipc...@ietf.org;
> draft-ietf-sipcore-locparam@ietf.org
> Betreff: Genart last call review of draft-ietf-sipcore-locparam-04
>
> Reviewer: Ines Robles
> Review result: Ready with Nits
>
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair. Please treat these comments just like any other last call
> comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-sipcore-locparam-04
> Reviewer: Ines Robles
> Review Date: 2020-01-26
> IETF LC End Date: 2020-01-27
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> This document proposes for SIP protocol, a new geolocation parameter, the
> location-source ("loc-src"), so that an entity adding the locationValue to
> Geolocation header field can identify itself using its hostname.
>
> The document does not present major issues. I have some minor
> questions/suggestions at the end.
>
> Major issues: Not found
>
> Minor issues: Not found
>
> Nits/editorial comments:
>
> Section 4: "A UA MUST..." it would be nice to expand UA "A User Agent (UA)
> MUST..."
>
> Questions/Suggestions:
>
> 1- Section 1: I think it would be nice to add explicitly "This document
> updates
> 6442 by extending the Geolocation header field..."
>
> 2- Section 3: where it states "There are various architectures defined
> f...Each has it own characteristics with corresponding pros and cons" I
> think it would be nice to add a reference/s to it.
>
> 3- Which Geolocation-Error codes correspond to the situation when the
> "loc-scr"
> field presents some error, or one LocationValue presents two "loc-src"
> fields and the locationValue in both cases is correct?
>
> Thank you for this document,
>
> Ines.
>
>
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-sipcore-locparam-04
Reviewer: Ines Robles
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-sipcore-locparam-04
Reviewer: Ines Robles
Review Date: 2020-01-26
IETF LC End Date: 2020-01-27
IESG Telechat date: Not scheduled for a telechat
Summary:
This document proposes for SIP protocol, a new geolocation parameter, the
location-source ("loc-src"), so that an entity adding the locationValue to
Geolocation header field can identify itself using its hostname.
The document does not present major issues. I have some minor
questions/suggestions at the end.
Major issues: Not found
Minor issues: Not found
Nits/editorial comments:
Section 4: "A UA MUST..." it would be nice to expand UA "A User Agent (UA)
MUST..."
Questions/Suggestions:
1- Section 1: I think it would be nice to add explicitly "This document updates
6442 by extending the Geolocation header field..."
2- Section 3: where it states "There are various architectures defined
f...Each has it own characteristics with corresponding pros and cons" I
think it would be nice to add a reference/s to it.
3- Which Geolocation-Error codes correspond to the situation when the "loc-scr"
field presents some error, or one LocationValue presents two "loc-src" fields
and the locationValue in both cases is correct?
Thank you for this document,
Ines.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-tls-tls13-cert-with-extern-psk-03
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-tls-tls13-cert-with-extern-psk-?? Reviewer: Ines Robles Review Date: 2019-12-02 IETF LC End Date: 2019-12-02 IESG Telechat date: Not scheduled for a telechat Summary: The document is well written. This document specifies a TLS 1.3 extension permitting certificate-based server authentication to be combined with an external PSK as an input to the TLS 1.3 key schedule. Major issues: Not found Minor issues: Not found Nits/editorial comments: I think that would be nice to add in IANA Considerations a table specifying the fields of the TLS ExtensionType Values indicated in https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dmm-pmipv6-dlif-04
Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dmm-pmipv6-dlif-04 Reviewer: Ines Robles Review Date: 2019-10-14 IETF LC End Date: 2019-10-14 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written. The document proposes Distributed Mobility Management for Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router called MAAR (mobility anchor and access router). The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. I have a minor concern detailed in Nits section. Major issues:Not Issues found Minor issues: Not Issues found Nits/editorial comments: It would be nice to specify IANA Section with more details, such as indicating the registry which the option type belong, etc. [rfc8126] Thank you for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-mpls-rfc8287-len-clarification-02
Hi Carlos, Ok, thank you very much for addressing my comments. Best, Ines. On Tue, Aug 6, 2019 at 10:25 PM Carlos Pignataro (cpignata) < cpign...@cisco.com> wrote: > Hi, Ines, Many thanks for your very useful review! > > Thanks Alissa for flagging this. > > Please find some follow-up comments inline. > > > On Aug 6, 2019, at 3:11 PM, Alissa Cooper wrote: > > > > Ines, thanks for your review. I entered a DISCUSS ballot to get the > figure fixed in Section 4.2. > > > > Alissa > > > > > >> On Jul 30, 2019, at 8:11 AM, Ines Robles via Datatracker < > nore...@ietf.org> wrote: > >> > >> Reviewer: Ines Robles > >> Review result: Ready with Issues > >> > >> I am the assigned Gen-ART reviewer for this draft. The General Area > >> Review Team (Gen-ART) reviews all IETF documents being processed > >> by the IESG for the IETF Chair. Please treat these comments just > >> like any other last call comments. > >> > >> For more information, please see the FAQ at > >> > >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > >> > >> Document: draft-ietf-mpls-rfc8287-len-clarification-02 > >> Reviewer: Ines Robles > >> Review Date: 2019-07-30 > >> IETF LC End Date: 2019-07-31 > >> IESG Telechat date: Not scheduled for a telechat > >> > >> Summary: > >> > >> I believe the draft is technically good. This document is well written.. > >> > >> The document updates RFC8287 by clarifying the length for the following > Segment > >> ID Sub-TLVs: IPv4 IGP-Prefix Segment ID Sub-TLV, IPv6 IGP-Prefix > Segment ID > >> Sub-TLV and IGP-Adjacency Segment ID Sub-TLV. > >> > >> There are some minor issues detailed below that should be addressed. > >> > >> Major issues: Not found > >> > >> Minor issues: > >> > >> 1- Section 3 - Requirements notation is not complete, it should be > added: "NOT > >> RECOMMENDED" and "...are to be interpreted as described in BCP 14 > [RFC2119] > >> [RFC8174] when, and only when, they appear in all capitals, as shown > here.” > >> > > Sure. > > >> 2- Figure of Section 4.2: Type = 35 (IPv4 IGP-Prefix SID) ---> Type = > 35 (IPv6 > >> IGP-Prefix SID) > >> > > Indeed. Great catch and many thanks. > > >> 2.1- It would be nice if the figures have a caption where we can point > to the > >> figure number, and the figure number is referenced in the text. The > same for > >> the table of Section 4.3. > >> > > We had thought about this, and received this comment before also, but > since this is largely a fix and update to RFC 8287, we want to remain > consistent to the format used there. > > >> 3- Question: What do you think? > >> > >> I think it would be nice to explain a bit more the length for the > different > >> combinations of the table of Section 4.3, e.g. with tables as detailed > below: > > Thanks for this suggestion. To me, it seems a bit overkill to explain the > the size of an IPv4 is 4 octets, and the size of an IPv6 is 16 octets, etc. > The fact that we are including the table seems the right middle-ground for > readability, thoroughness, and detailed-orientedness. > > But thanks for the suggestion. > > Best, > > Carlos. > > >> > >> +-+---+ > >> |Field | Parallel (octets) | > >> | rfc8287#section-5.3+-+--+--+ > >> | | Any | OSPF | > ISIS | > >> +-+-+--+--+ > >> | Local Interface ID| 4 | 4 | 4 | > >> +-+-+--+--+ > >> | Remote Interface ID | 4 | 4 | 4 | > >> +-+-+--+--+ > >> | Advertising Node Identifier | 4 | 4 | 6 | > >> +-+-+--+--+ > >> | Receiving Node Identifier | 4 | 4 | 6 | > >> +-+-+--+--+ > >> | Reserved | 2 | 2 | > 2 | > >> +-+-+--+--+ > >> | Adj. Type + Protocol | 2 | 2 | 2 | > >> +-+-+---
[Gen-art] Genart last call review of draft-ietf-mpls-rfc8287-len-clarification-02
Reviewer: Ines Robles Review result: Ready with Issues I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mpls-rfc8287-len-clarification-02 Reviewer: Ines Robles Review Date: 2019-07-30 IETF LC End Date: 2019-07-31 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written. The document updates RFC8287 by clarifying the length for the following Segment ID Sub-TLVs: IPv4 IGP-Prefix Segment ID Sub-TLV, IPv6 IGP-Prefix Segment ID Sub-TLV and IGP-Adjacency Segment ID Sub-TLV. There are some minor issues detailed below that should be addressed. Major issues: Not found Minor issues: 1- Section 3 - Requirements notation is not complete, it should be added: "NOT RECOMMENDED" and "...are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here." 2- Figure of Section 4.2: Type = 35 (IPv4 IGP-Prefix SID) ---> Type = 35 (IPv6 IGP-Prefix SID) 2.1- It would be nice if the figures have a caption where we can point to the figure number, and the figure number is referenced in the text. The same for the table of Section 4.3. 3- Question: What do you think? I think it would be nice to explain a bit more the length for the different combinations of the table of Section 4.3, e.g. with tables as detailed below: +-+---+ |Field | Parallel (octets) | | rfc8287#section-5.3+-+--+--+ | | Any | OSPF | ISIS | +-+-+--+--+ | Local Interface ID| 4 | 4 | 4 | +-+-+--+--+ | Remote Interface ID | 4 | 4 | 4 | +-+-+--+--+ | Advertising Node Identifier | 4 | 4 | 6 | +-+-+--+--+ | Receiving Node Identifier | 4 | 4 | 6 | +-+-+--+--+ | Reserved | 2 | 2 | 2 | +-+-+--+--+ | Adj. Type + Protocol | 2 | 2 | 2 | +-+-+--+--+ | Sum Total octets = | 20 | 20 | 24 | +-+-+--+--+ +-+---+ |Field| IPv4 (octets) | | rfc8287#section-5.3 +-+--+--+ || Any | OSPF | ISIS | +-+-+--+--+ | Local Interface ID | 4 | 4 | 4 | +-+-+--+--+ | Remote Interface ID | 4 | 4 | 4 | +-+-+--+--+ | Advertising Node Identifier | 4 | 4 | 6 | +-+-+--+--+ | Receiving Node Identifier | 4 | 4 | 6 | +-+-+--+--+ | Reserved | 2 | 2 | 2 | +-+-+--+--+ | Adj. Type + Protocol | 2 | 2 | 2 | +-+-+--+--+ | Sum Total octets = | 20 | 20 | 24 | +-+-+--+--+ +-+---+ |Field| IPv6 (octets) | | rfc8287#section-5.3 +-+--+--+ | | Any | OSPF | ISIS | +-+-+--+--+ | Local Interface ID| 16 | 16 | 16 | +-+-+--+--+ | Remote Interface ID | 16 | 16 | 16 | +-+-+--+--+ | Advertising Node IdentifieR | 4 | 4 | 6 | +-+-+--+--+ | Receiving Node Identifier | 4 | 4 | 6 | +-+-+--+--+ | Reserved | 2 | 2 | 2 | +-+-+--+--+ | Adj. Type + Protocol
[Gen-art] Genart last call review of draft-ietf-sipcore-rejected-08
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sipcore-rejected-08 Reviewer: Ines Robles Review Date: 2019-06-03 IETF LC End Date: 2019-06-04 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written. The document defines the 608 (Rejected) SIP response code, that enables calling parties to learn that an intermediary rejected their call attempt. I have some minor questions. Major issues: none Minor issues: none Nits/editorial comments: Section 1- I think it would be nice to expand SIP and add a reference to RFC3261 the first time that SIP is mentioned in the Introduction. Comments/Questions: 1- Section 1. "...a user (human)..." A user could be as well a smart device, right?. For example, in a smart home scenario, we have Alexa rejecting a call from a supermarket. The call rejection is ordered by a human or ordered by another device (e.g. a fridge with temporal calling-management functions that can send commands to Alexa to accept, reject calls from supermarket ). In the latter case the user is not a human, but a smart device. In this case, Alexa would be the UAS? 2- In Figure 2 is not clear to me if the INVITE command goes as well to the "call analytics engine" entity, since the arrow goes directly to the UAS. Should this image indicate arrows to the "call analytics engine" entity, to be aligned with figure 1? 3- Figure 5: +-+--+-+ +---+ +-+ +---+ +-+ +-+ |Called| |UAC+--->+Proxy+--->+SBC+--->+Proxy+--->+Proxy+--->+Party | +---+ +-+ +---++-+ +-+ |Proxy | +--+ 3.1- The arrows of the UAC to the Called Party Proxy are unidirectional. Should be bidirectional? Since there are messages from the Called Party Proxy entity to the SBC, and then to the UAC. 3.2- Should the "Proxy" entities be identified for example with Proxy A, Proxy B and Proxy C, to indicate that they are different Proxy entities? 3.3- Should be added in the figure the flow of messages that the "Proxy" entities goes through, or at least mentioned when explaining figure 5. Thank you for this draft, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-roll-useofrplinfo-25
Hi Russ, Thank you for your review. New version was submitted with corrections. Please find answer in-line. On Wed, Apr 3, 2019 at 8:34 PM Russ Housley via Datatracker < nore...@ietf.org> wrote: > Reviewer: Russ Housley > Review result: Ready with Nits > Minor Concerns: > > Section 1 says: > >... This document clarifies examples that intend to >illustrate the result of the normative language in RFC8200 and >RFC6553. In other words, the examples are intended to be normative >explanation of the results of executing that language. > > This set the wrong expectation for me. What the document seems to > be doing is aligning with the recent normative change in RFC8200. The > alignment could lead to a flag day, and this document suggests a way to > avoid a flag day. It goes through a whole bunch of use cases to > illustrate the updates. > New text was added to adress this: "The ROLL WG analysized how [RFC2460] rules apply to storing and non- storing use of RPL. The result was 24 data plane use cases. They are exhaustively outlined here in order to be completely unambiguous. During the processing of this document, new rules were published as [RFC8200], and this document was updated to reflect the normative changes in that document. " > > > Nits: > > In Table 6, please move some of the whitespace on the right to the first > column to avoid so many words being split across lines. > > Tables were fixed. All the Best, Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-mptcp-rfc6824bis-13
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-mptcp-rfc6824bis-13 Reviewer: Ines Robles Review Date: 2019-04-26 IETF LC End Date: 2019-04-26 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written and clear to understand. I found the document quite complete. The document specifies v1 of Multipath TCP, obsoleting v0 as specified in RFC6824, through clarifications and modifications primarily driven by deployment experience. I have some minor questions for the authors. Major issues: Not found Minor issues: Not found Nits/editorial comments: Section 1.1 " the working group imposed..." --> " mptcp working group imposed..." Some Comments/Questions: - Section 1.4: "...A1<->B2 and A2<->B2. Although this additional session is shown as being initiated from A2, it could equally have been initiated from B1." --> would it be "initiated from B2"? or you mean B1 following the example showed in Figure 2? - For Figure 5 (Pag.24), Figure 6(Pag.26) and Figure 11(Pag.40): would it be correct to add "(rsv)" in the empty field (between "Subtype" and "B" fields) as showed in Figure 12 (Pag. 44).? - Section 8.1: "This document defines one additional subtype (ADD_ADDR) and updates the references to this document for all subtypes except ADD_ADDR, which is deprecated.": - It seems that the additional subtype is MP_TCPRST and not ADD_ADDR, comparing table 2 between this draft and RFC6824. - Would it be correct state instead of "ADD_ADDR deprecated" to "ADD_ADDR modified"? In Appendix E states; "The ADD_ADDR option (Section 3.4.1), which is used to inform the other host about another potential address, is different in several ways. It now includes an HMAC of the added address, for enhanced security. In addition, reliability for the ADD_ADDR option has been added: the IPVer field is replaced with a flag field, and one flag is assigned (E) which is used as an 'Echo' so a host can indicate that it has received the option." Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dots-signal-channel-30
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dots-signal-channel-30 Reviewer: Ines Robles Review Date: 2019-03-19 IETF LC End Date: 2019-03-19 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written and clear to understand. The draft is quite complete. The document specifies the Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client. Major issues: Not found Minor issues: Not found Nits/editorial comments: Not found Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-rmcat-video-traffic-model-06
Hi Xiaoqing,
Thanks a lot for the clarifications, I agree with your comments.
Best Regards,
Ines.
On Thu, Feb 21, 2019 at 8:46 PM Xiaoqing Zhu (xiaoqzhu)
wrote:
> Hi, Ines,
>
> Thanks a lot for your thorough review of this draft. We've updated to
> version -07 to
> incorporate your review comments. More detailed response inline below
> (tagged [XZ]).
>
> Best,
> Xiaoqing (on behalf of all authors).
>
> On 1/24/19, 2:10 PM, "Ines Robles"
> wrote:
>
> Reviewer: Ines Robles
> Review result: Ready
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair. Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-rmcat-video-traffic-model-06
> Reviewer: Ines Robles
> Review Date: 2019-01-24
> IETF LC End Date: 2019-01-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary:
>
> I believe the draft is technically good. This document is well written
> and
> clear to understand.
>
> This document describes two reference video traffic models for
> evaluating RTP
> congestion control algorithms. The first model statistically
> characterizes the
> behavior of a live video encoder in response to changing requests on
> target
> video rate. The second model is trace-driven, and emulates the output
> of
> actual encoded video frame sizes from a high-resolution test
> sequence. The
> document describes also how both approaches can be combined into a
> hybrid model.
>
> Additionally, The stand-alone traffic source module is available as an
> open
> source implementation, which I think it is very nice. :)
>
> I did not find issues. I have some minor questions/suggestions.
>
> Major issues: Not found
>
> Minor issues: Not found
>
> Nits/editorial comments:
>
> - Page 14: correponding -> corresponding
>
> [XZ] Thanks for the catch! Fixed.
>
>
> - steady state, sometimes appears as steady-state, it would be nice to
> unify
> these terms.
>
> [XZ] Thanks for pointing this out. We've completed one pass of purging to
> stick
> to "steady state" throughout. The only two excepts are out of grammatical
> considerations ("steady-state behavior" as in "five-year-old boy").
>
> Some Questions/suggestions:
>
> 1- In Figure 1, would it be correct to add an input as a self-loop
> arrow
> indicating "dummy video frames"? (As previously was an input "raw
> video frames"
> e.g. in version 4 )
>
> [XZ] We actually chose to take off the input of “raw video frames“ from
> version -04 since
> the synthetic video source does not need to perform any encoding process.
> Instead, it just
> needs to keep track of frame size and intervals, and generate dummy
> encoded video frames
> as output. To clarify, the output label has been revised to “dummy
> encoded video frames”
>
>
> 2- Would it be correct to add in:
>
> 2.1- Page 14: "...ongoing, steady-state behavior of a video..." =>
> "...ongoing,
> steady-state behavior (fluctuation around a constant target rate) of a
> video..."? [1]
>
> [XZ] Thanks a lot for the suggestion. This sentence is now revised as
> follows:
>
>In general, the trace-driven model is more realistic for mimicking
>the ongoing, steady-state behavior of a video traffic source with
>fluctuations around a constant target rate. In contrast, the
>statistical model is more versatile for simulating the behavior of a
>video stream in transient, such as when encountering sudden rate
>changes.
>
> 2.2 - Page 8: "...is considered to be in a transient state" =>
> "...is
> considered to be in a transient state (reaction to abrupt changes in
> target
> rate)"? [1]
>
> [1] Based in
>
> https://datatracker.ietf.org/meeting/101/materials/slides-101-rmcat-rmcat-video-traffic-model-00
> - Slide 2
>
> [XZ] This has been revised accordingly as well, as follows:
>
> The output bitrate R_o during the period [t, t+tau_v] is considered
>to be in a transient state when reacting to abrupt changes in target
>rate.
>
> 3- Would it be correct to add in the Figure 3 something like?:
>
> - R_v > R_v_previous for transient state
>
> - R_v <
[Gen-art] Genart last call review of draft-ietf-extra-sieve-fcc-08
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-extra-sieve-fcc-08 Reviewer: Ines Robles Review Date: 2018-12-17 IETF LC End Date: 2018-12-18 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written and clear to understand. This document defines an extension to Sieve Email Filtering Language commands to allow a copy of any generated message to be filed into a target mailbox. This document updates RFC5230 and RFC5435 by adding a new tagged argument to the "vacation" and "enotify" actions respectively. Major issues: Not found. Minor issues: Not found. Nits/editorial comments: Page 3. "how it interfacts with :fcc." => how it interacts with :fcc.? Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Thanks for this document, Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-dmarc-arc-protocol-21
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dmarc-arc-protocol-21 Reviewer: Ines Robles Review Date: 2018-11-19 IETF LC End Date: 2018-11-06 IESG Telechat date: 2018-11-21 Summary: I believe the draft is technically good. This document is well written and clear to understand. This document describes the Authenticated Received Chain (ARC) protocol, which provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. I like that the document mentions the available implementations. Major issues: Not found Minor issues: Not found Nits/editorial comments: Not found ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [dmarc-ietf] Genart last call review of draft-ietf-dmarc-arc-protocol-18
Thank you very much for the corrections! Ines On Mon, Nov 5, 2018, 11:33 AM Barry Leiba > Nits/editorial comments: > > > > Page 18: “ptypes” →types > > Page 22: “concocted” → connected? > > As Scott K says, "ptypes" is correct as written. > > "Concocted" is also correct as written. > > Barry > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-dmarc-arc-protocol-18
Reviewer: Ines Robles Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-dmarc-arc-protocol-18 Reviewer: Ines Robles Review Date: 11-03-2018 IETF LC End Date: 11-06-2018 IESG Telechat date: (if known) Summary: I believe the draft is technically good. This document is well written and clear to understand. This document describes the Authenticated Received Chain (ARC) protocol, which provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before, and to see what the message's authentication assessment was at each step in the handling. I like that the document mentions the available implementations. Major issues: Not found Minor issues: There is a TODO in Appendix B, so I suppose further information will be added to the draft later. Nits/editorial comments: Page 18: “ptypes” →types Page 22: “concocted” → connected? Thank you for this draft. Ines ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-cbor-cddl-05
Reviewer: Ines Robles
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-cbor-cddl-05
Reviewer: Ines Robles
Review Date: 2018-09-28
IETF LC End Date: 2018-10-04
IESG Telechat date: Not scheduled for a telechat
Summary:
I believe the draft is technically good. This document is well written and
clear to understand.
The document proposes a notational convention named Concise data definition
language (CDDL) to express Concise Binary Object Representation (CBOR) data
structures. Its main goal is to provide an easy and unambiguous way to express
structures for protocol messages and data formats that use CBOR or JSON.
I have some minor questions. The document presents nits that should be solved
before publication.
Major issues: Not found.
Minor issues: Not found.
Nits/editorial comments:
1)-Abstract: It would be nice to expand CBOR the first time that it is
mentioned.
2)-Section 2: Page 8, You mention anonymous group.
Does it would be a good definition for an anonymous group?: “Lists of
group_entries_ (between curly braces)that can be assigned to any type of
composition (arrays, maps)”
3)- Section 2.2.2.1 - Page 11: the ordering I think is ascendant, right? So,
maybe, would it be nice to add “natural ordering relationship”? question: is
the following valid?:
Take-off = {
takeoffcounting= 10..0 ; Is it valid? Is it applicable?
}
4)- In this paragraph: “...When using a name as the left hand side of a range
operator, use spacing as in
"min .. max" to separate off the range operator"
=> Question: Is "min .. max" equivalent to "min” .. “max"?
5)- There are some mismatches between Appendix B and Appendix C:
Appendix B: cddl = S 1*(rule S)
Appendix C: cddl = S 1*rule
Appendix B:
rule = typename [genericparm] S assignt S type
/ groupname [genericparm] S assigng S grpent
Appendix C:
rule = typename [genericparm] S assignt S type S
/ groupname [genericparm] S assigng S grpent S
Appendix B:type = type1 *(S "/" S type1)
Appendix C:type = type1 S *("/" S type1 S)
Appendix B: group = grpchoice *(S "//" S grpchoice)
Appendix C: group = grpchoice S *("//" S grpchoice S)
Appendix B:grpchoice = *(grpent optcom)
Appendix C:grpchoice = *grpent
Appendix B:grpent = [occur S] [memberkey S] type
Appendix C:grpent = [occur S] [memberkey S] type optcom
Appendix B:/ [occur S] groupname [genericarg] ; preempted by above
Appendix C:/ [occur S] groupname [genericarg] optcom ; preempted by
above
Appendix B: / [occur S] "(" S group S ")"
Appendix C: / [occur S] "(" S group S ")" optcom
6)- It would be nice to expand I-JSON to ("Internet JSON") in page 54
Thank you for this document.
Ines.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-bess-l2l3-vpn-mcast-mib-15
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-bess-l2l3-vpn-mcast-mib-15 Reviewer: Ines Robles Review Date: 2018-09-02 IETF LC End Date: 2018-09-03 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written and clear to understand. This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes common managed objects used by other MIB modules which are designed for monitoring and/or configuring both Layer 2 and Layer 3 Virtual Private Networks (VPN) that support multicast. Major issues: Not found Minor issues: Not found Nits/editorial comments: Not found ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-york-p-charge-info-08
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-york-p-charge-info-08 Reviewer: Ines Robles Review Date: 2018-08-13 IETF LC End Date: 2018-08-13 IESG Telechat date: Not scheduled for a telechat Summary: This document requests to IANA, the registration of a SIP P-header ,P-Charge-Info, as a "grandfathered case". Since the draft states that P-Charge-Info has been in deployment since prior to 2007 and pre-dates RFC 5727 (which deprecates new usage of "P-" header fields). It is aligned what is mentioned in the IANA web page [1] " ...Existing "P-" header field registrations are considered grandfathered, but new registrations of Informational header fields should not begin with the leading characters "P-" (unless the "P-" would preserve compatibility with an pre-existing unregistered usage of the header field, at the discretion of the Designated Expert)." I understand that this case is a pre-existing unregistered usage of the header field. This draft is Informational. RFC 5727[2] mentions: " ...the registration of SIP header fields in Informational RFCs, or in documents outside the IETF, is now permitted under the Designated Expert (per [RFC5226]) criteria". I understand that a designated Expert agreed on this. I believe the draft is technically good. This document is well written and clear to understand. Major issues: No major issues found. Minor issues: -In Introduction: I would add some examples of carriers, application providers and equipment in here. "Several carriers, application providers, and equipment providers have been using the P-Charge-Info header field since at least 2007 as a simple mechanism to exchange this billing identifier." Nits/editorial comments: Not found. Thanks for this document, Ines. [1] https://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml#sip-parameters-2 [2] https://tools.ietf.org/html/rfc5727#section-4 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-lamps-rfc5750-bis-06
Reviewer: Ines Robles Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lamps-rfc5750-bis-?? Reviewer: Ines Robles Review Date: 2018-06-14 IETF LC End Date: 2018-04-27 IESG Telechat date: 2018-06-21 Summary: This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. This document obsoletes RFC 5750. I believe the draft is technically good. This document is well written and clear to understand. The minor issues of version 05 were addressed in version 06. Major issues: No major issues found. Minor issues: No minor issues found. Nits/editorial comments: idnits tool shows: 4 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-rfc5750-bis-06.txt Thanks! Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-lamps-rfc5750-bis-05
Ok, Thanks for the feedback. Best, Ines. 2018-05-03 3:01 GMT+03:00 Jim Schaad <i...@augustcellars.com>: > > > > -Original Message----- > > From: Ines Robles <mariainesrob...@googlemail.com> > > Sent: Friday, April 27, 2018 4:28 AM > > To: gen-art@ietf.org > > Cc: sp...@ietf.org; draft-ietf-lamps-rfc5750-bis@ietf.org; > i...@ietf.org > > Subject: Genart last call review of draft-ietf-lamps-rfc5750-bis-05 > > > > Reviewer: Ines Robles > > Review result: Ready with Issues > > > > Hello, > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review > > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > > the IETF Chair. Please treat these comments just like any other last > call > > comments. > > > > For more information, please see the FAQ at > > > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > > > Document: draft-ietf-lamps-rfc5750-bis-05 > > Reviewer: Ines Robles > > Review Date: 27-04-2018 > > IETF LC End Date: 27-04-2018 > > IESG Telechat date: --- > > > > Summary: > > > > I believe the draft is technically good. This document is well written > and clear > > to understand. Some minor concerns are mentioned that should be resolved > > before publication. > > > > Major issues: No major issues found. > > > > Minor issues: > > > > Section 1.6: > > > > It would be nice to start the section with some text like "This > document > > obsoletes 5750 due to the addition of the following information" > > This is missing information, however I think it should go into section 1 - > Introduction and not be buried here. The new text does point to this > section. > > > > > Section 2.3: > > > > "but SHOULD use some other mechanism to determine " => It would > be > > nice > > to mention some examples of the other mechanism > > > > "...but SHOULD use some other mechanism (such as ) to > determine..." > > I am not sure that this would be a useful addition. I can see two > different outcomes from this which neither of which is helpful. > > * People will complain about implementations which do not implement all > of the items in the list > * People will complain that something should not be implemented because > it is not on the list > > One of the problems is that this will be a list that is not very useful. > Items can range anywhere from use the set of trust points you already have > and don't let it be expanded to call the other person up and get them to > read you a hash value to look at various trusted locations for root > certificates, including some types of transparency logs. I cannot really > say that any of these is what I would recommend. The knowledge of how > trust configuration is handed is an extremely application and > implementation specific function. > > > > > Section 4: > > > > Related to this: > > "Another method under consideration by the IETF is to provide > certificate > > retrieval services as part of the existing Domain Name System (DNS)" > > > > - This text seems to be out of the date (since belongs as well to > RFC5750 > > (2010)), maybe it would be nice to re-write it (e.g. method under > > consideration => method approved) and add a reference of the proposed > > methods. Would it be RFC 8162 [1] a good reference for this topic? > > > > [1] https://tools.ietf.org/html/rfc8162: Using Secure DNS to Associate > > Certificates with Domain Names for S/MIME > > This was raised during the rfc5751-bis review as well. I have replaced > that sentence with a pointer to the experimental DANE draft. > > > > > Nits/editorial comments: > > > > Section 2.3: CertificateSet --> Certificate Set > > > > Section 4.4.1: basicConstraints --> basic Constraints > > > > Thanks for this document! > > > > Ines. > > > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart last call review of draft-ietf-lamps-rfc5750-bis-05
Yes, right, Thank you for the corrections 2018-04-27 19:45 GMT+03:00 Russ Housley <hous...@vigilsec.com>: > These are references to ASN.1 definitions, so they should not be changed > as indicated. > > Russ > > > On Apr 27, 2018, at 7:28 AM, Ines Robles <mariainesrob...@googlemail.com> > wrote: > > Section 2.3: CertificateSet --> Certificate Set > > Section 4.4.1: basicConstraints --> basic Constraints > > > ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-ietf-lamps-rfc5750-bis-05
Reviewer: Ines Robles Review result: Ready with Issues Hello, I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-lamps-rfc5750-bis-05 Reviewer: Ines Robles Review Date: 27-04-2018 IETF LC End Date: 27-04-2018 IESG Telechat date: --- Summary: I believe the draft is technically good. This document is well written and clear to understand. Some minor concerns are mentioned that should be resolved before publication. Major issues: No major issues found. Minor issues: Section 1.6: It would be nice to start the section with some text like "This document obsoletes 5750 due to the addition of the following information" Section 2.3: "but SHOULD use some other mechanism to determine " => It would be nice to mention some examples of the other mechanism "...but SHOULD use some other mechanism (such as ) to determine..." Section 4: Related to this: "Another method under consideration by the IETF is to provide certificate retrieval services as part of the existing Domain Name System (DNS)" - This text seems to be out of the date (since belongs as well to RFC5750 (2010)), maybe it would be nice to re-write it (e.g. method under consideration => method approved) and add a reference of the proposed methods. Would it be RFC 8162 [1] a good reference for this topic? [1] https://tools.ietf.org/html/rfc8162: Using Secure DNS to Associate Certificates with Domain Names for S/MIME Nits/editorial comments: Section 2.3: CertificateSet --> Certificate Set Section 4.4.1: basicConstraints --> basic Constraints Thanks for this document! Ines. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
