[Gen-art] Genart last call review of draft-ietf-bess-evpn-vpws-fxc-09
Reviewer: Joel Halpern 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-bess-evpn-vpws-fxc-09 Reviewer: Joel Halpern Review Date: 2024-09-29 IETF LC End Date: 2024-10-04 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a Proposed Standard Major issues: N/A Minor issues: I found the description of the motivation in the introduction slightly misleading. It talks about the number of access circuits (ACs). Which is clearly where it needs to start. It would help if the text were clear about what level of aggregation is supported, and what ration of ACs this provides. The text in the introduction seems to imply aggregation across PEs, while the definition of VPWWS Service Tunnel seems to be for a single PE. Note that if it is aggregating across PEs, this should be called out explicitly early, as the naive reader will assume that aggregation in the default case is within a PE. I think the following is a minor issue. However, if I have misunderstood the draft, that suggests the issue may be more significant. As I read the draft, the scaling benefit is a reduction in the number of service labels needed, but not a reduction in the number of BGP advertisements required. If so, the introduction should make that clear. And probably call out the implication that these cases will still have a LOT of BGP advertisements. If I have misunderstood the benefit, we should probably correspond so that I can understand how this works and then suggest a text revision to make it clear. (I think 3.3 paragraph 3 says that I have understood the draft, which is why I consider this a minor issue.) Nits/editorial comments: N/A ___ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
[Gen-art] Re: Genart last call review of draft-ietf-opsawg-pcaplinktype-04
Michael, as far as I know, the request to IANA is not removed from the RFC, although the IANA registry is definitve from then on. Also, the fact that the HTML rendering of the draft is unreadable does seem to be a problem. And if Guy is correct that the descriptions are insufficient (as I presume he is) that seems a problem that needs to be fixed before publication. Yours, Joel On 8/16/2024 10:43 AM, Michael Richardson wrote: Guy Harris wrote: > The descriptions of many link-layer types are either 1) too long or 2) > insufficient to fully describe the link-layer type or 3) both(!). > The descriptions should be short, and the entry should have, as > a reference, a web page that gives a complete description. Some > entries already have that. I am much less concerned about getting the exact information in than you are, and more concerned that we get over this hump. I accept that not every entry will be fully described; and that's okay. As for the the width and contents. My understanding (and experience) is that when we give IANA the initial contents, they *take* it, initialize the registry, and then, the RPC actually removes the table from the document. The IANA registry itself is authoritative, not the document, so DRY. I also asked IANA is they would prefer to just receive this content as XML. They said they didn't care; we could do that if we wanted, but none of the tooling makes that easier. Joel: I have added a Security Considerations. Sorry for that obvious lack. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- *I*LIKE*TRAINS* ___ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
[Gen-art] Genart last call review of draft-ietf-opsawg-pcaplinktype-04
Reviewer: Joel Halpern 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-opsawg-pcaplinktype-04 Reviewer: Joel Halpern Review Date: 2024-08-15 IETF LC End Date: None IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as an Informational RFC. Major issues: While it may be vacuous, it is necessary to include a security considerations section. Minor issues: (Unclear if this is Major or Minor): The table layout for the IANA registry fails to conform to I-D / RFC requirements. Considered as text, it is much too wide. Considered as HTML, the normal rendering blocks important parts of the table. I recommend asking the RPC and IANA how to format the I-D so as to produce a suitable RFC. Nits/editorial comments: N/A ___ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
[Gen-art] Genart last call review of draft-ietf-ccwg-rfc5033bis-06
Reviewer: Joel Halpern 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-ccwg-rfc5033bis-06 Reviewer: Joel Halpern Review Date: 2024-07-06 IETF LC End Date: 2024-07-08 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a BCP. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
[Gen-art] Genart last call review of draft-ietf-cbor-edn-literals-09
Reviewer: Joel Halpern 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-cbor-edn-literals-09 Reviewer: Joel Halpern Review Date: 2024-05-25 IETF LC End Date: 2024-06-05 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as an Informational RFC. There is one NIT noted below. Major issues: N/A Minor issues: N/A Nits/editorial comments: It would be helpful if section 4.2 (IANA Considerations creating the Encoding Indications registry) said it was recording the assignments made in RFC 8949 section 8.1, and adding the _i indication. It would also be helpful if that sentence noted that _i is defined in the ABNF appendix, as otherwise the reader is left going "what is this and where did it come from?" ___ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
Re: [Gen-art] Genart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11
Thank you. Those edits do the job nicely. Joel On 5/6/2024 5:49 AM, mohamed.boucad...@orange.com wrote: Hi Joel, Thank you for the review. You got it right. Please see more context at [1]. I updated the text to address your review. Please check the diff [1] and let me know if any further change is needed. Thanks. Cheers, Med [1] https://mailarchive.ietf.org/arch/msg/opsawg/g-cXqAHzazaA_gOf7Woxv2SiVJ4/ [2] https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt&url_2=https://boucadair.github.io/ipfix-tcpoptions-and-v6eh/genart-review/draft-ietf-opsawg-ipfix-tcpo-v6eh.txt -Message d'origine----- De : Joel Halpern via Datatracker Envoyé : vendredi 3 mai 2024 05:01 À : gen-art@ietf.org Cc : draft-ietf-opsawg-ipfix-tcpo-v6eh@ietf.org; last- c...@ietf.org; ops...@ietf.org Objet : Genart last call review of draft-ietf-opsawg-ipfix-tcpo- v6eh-11 Reviewer: Joel Halpern 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F% 2Fwiki.ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cmoh amed.boucadair%40orange.com%7Cbfb8988782a541c5816808dc6b1d5145%7C 90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638503020857412204%7CU nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6 Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=WIsBdbKOD9ZyF0j%2BZKnq6 ke79zktUZ9q%2B5n2iW34U%2Fs%3D&reserved=0>. Document: draft-ietf-opsawg-ipfix-tcpo-v6eh-11 Reviewer: Joel Halpern Review Date: 2024-05-02 IETF LC End Date: 2024-05-10 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: None Minor issues: The document uses the phrasing "If several extension header chains are observed in a Flow" in several places. While I believe I figured out what was intended, it caused me difficulty. Assuming I understood the intent, I would suggest defining a term "flow with varying header chain" as "a flow wherein different packets in the flow have a different sequence of extension header types codes." And then use that term in the suitable places in the document. Nits/editorial comments: None 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
[Gen-art] Genart last call review of draft-ietf-opsawg-ipfix-tcpo-v6eh-11
Reviewer: Joel Halpern 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-opsawg-ipfix-tcpo-v6eh-11 Reviewer: Joel Halpern Review Date: 2024-05-02 IETF LC End Date: 2024-05-10 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: None Minor issues: The document uses the phrasing "If several extension header chains are observed in a Flow" in several places. While I believe I figured out what was intended, it caused me difficulty. Assuming I understood the intent, I would suggest defining a term "flow with varying header chain" as "a flow wherein different packets in the flow have a different sequence of extension header types codes." And then use that term in the suitable places in the document. Nits/editorial comments: None ___ 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-servprovider-oob-05
Reviewer: Joel Halpern 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-stir-servprovider-oob-05 Reviewer: Joel Halpern Review Date: 2024-03-28 IETF LC End Date: 2024-03-31 IESG Telechat date: Not scheduled for a telechat Summary: This draft is probably ready for publication as a proposed standard Major issues: N/A Minor issues: There is one aspect of the CPS Advertisements that I was unable to follow. I presume this is clear to those participating in the work, but wonder if my confusion indicates potential for clarification. The draft contains a very clear description of the cotnent of the advertisements, and how those advertisements can be used to map from a phone call being placed to URI to submit the PassPort. However, I do not know how the placing party finds the advertisements themselves? Is there some assumption about a STIR related information repository that would provide these? Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Bier] Genart last call review of draft-ietf-bier-tether-04
Thank you. That looks good. Joel On 2/16/2024 11:06 AM, Jeffrey (Zhaohui) Zhang wrote: Hi Joel, I posted the -05 revision. Besides the proposed text below, I also added an IANA request for the "BIER Helped Node" sub-TLV type for OSPFv3 - I had missed that. https://author-tools.ietf.org/iddiff?url1=draft-ietf-bier-tether-04&url2=draft-ietf-bier-tether-05&difftype=--html Thanks. Jeffrey Juniper Business Use Only -Original Message- From: Joel Halpern Sent: Thursday, February 15, 2024 11:27 PM To: Jeffrey (Zhaohui) Zhang ; gen-art@ietf.org Cc: b...@ietf.org; draft-ietf-bier-tether@ietf.org; last-c...@ietf.org Subject: Re: [Bier] Genart last call review of draft-ietf-bier-tether-04 [External Email. Be cautious of content] Thank you Jeffrey. On the major item, the proposed text addresses my concern. On the minor issue, thank you. I had failed to put the pieces together in my head, and you are correct. Bier operation will take care of the problem and there is nothing to specify here. (In fact, that is the point. It just works.) Yours, Joel On 2/15/2024 11:04 PM, Jeffrey (Zhaohui) Zhang wrote: Hi Joel, Thanks for your review and comments. Please see zzh> below. Juniper Business Use Only -Original Message- From: BIER On Behalf Of Joel Halpern via Datatracker Sent: Thursday, February 15, 2024 6:10 PM To: gen-art@ietf.org Cc: b...@ietf.org; draft-ietf-bier-tether@ietf.org; last-c...@ietf.org Subject: [Bier] Genart last call review of draft-ietf-bier-tether-04 [External Email. Be cautious of content] Reviewer: Joel Halpern 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://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!HnoMr9CvW2ImbH6LVeQkh-4CIMEuSojS_TOKsafTWXlzUP7cmGEeUOIn5afkDw9ceS4tFN9KrmjCnaQ$ >. Document: draft-ietf-bier-tether-04 Reviewer: Joel Halpern Review Date: 2024-02-15 IETF LC End Date: 2024-02-29 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as a proposed standard Major issues: Section 3.1 on IGP Signaling states "The helper node (BFRx) MUST advertise one or more BIER Helped Node sub-sub-TLVs". However, I only find a vague outline of this sub-sub TLV. The code point for it is requested in the IANA considerations section, but the description is a single sentence easily misread and lacking the conventional diagrams and precision that is used to define routing TLVs (and sub or sub-sub TLVs.) zzh> Point taken. How about the following? Suppose that the BIER domain uses BIER signaling extensions to ISIS [RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in the case of OSPF, one for each helped node: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length |Priority | Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address of the Helped Node | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type is TBD1 (in the case of ISIS) or TBD2 (in the case of OSPF). The Value field starts with a one-octet Priority field, followed by a one-octet Reserved field, and then the Address of the Helped Node (X). The Length is 6 for IPv4 and 18 for IPv6 respectively. Minor issues: In the paragraph about multiple helpers helping a single non-supporting router, I think I missed how one case works properly. (Section 2, additional considerations, paragraph 6). The text says that the sending BFR (BFR1 can choose to use multiple helpers if they are available. Assuming that BFR1 chooses to use BFR2 and BFR 3 to reach BFRs 4 .. BFR N, the text is clear that this results in BFR2 and BFR 3 both sending copies of the packet to Router X. That is fine. It is load, but it is a tradeoff. However, it appears that both BFR2 and BFR 3 would send packets to BFR4, and to all the other BFR children of X. This results in duplicate packets in the rest of the tree. Is there some assumption I missed that prevents this? Zzh> The BIER forwarding algorithm ensures that the two copies of the same packet that a BFR sends out never have overlapping bits in the BitStr
Re: [Gen-art] [Bier] Genart last call review of draft-ietf-bier-tether-04
Thank you Jeffrey. On the major item, the proposed text addresses my concern. On the minor issue, thank you. I had failed to put the pieces together in my head, and you are correct. Bier operation will take care of the problem and there is nothing to specify here. (In fact, that is the point. It just works.) Yours, Joel On 2/15/2024 11:04 PM, Jeffrey (Zhaohui) Zhang wrote: Hi Joel, Thanks for your review and comments. Please see zzh> below. Juniper Business Use Only -Original Message- From: BIER On Behalf Of Joel Halpern via Datatracker Sent: Thursday, February 15, 2024 6:10 PM To: gen-art@ietf.org Cc: b...@ietf.org; draft-ietf-bier-tether@ietf.org; last-c...@ietf.org Subject: [Bier] Genart last call review of draft-ietf-bier-tether-04 [External Email. Be cautious of content] Reviewer: Joel Halpern 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://urldefense.com/v3/__https://wiki.ietf.org/en/group/gen/GenArtFAQ__;!!NEt6yMaO-gk!HnoMr9CvW2ImbH6LVeQkh-4CIMEuSojS_TOKsafTWXlzUP7cmGEeUOIn5afkDw9ceS4tFN9KrmjCnaQ$ >. Document: draft-ietf-bier-tether-04 Reviewer: Joel Halpern Review Date: 2024-02-15 IETF LC End Date: 2024-02-29 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as a proposed standard Major issues: Section 3.1 on IGP Signaling states "The helper node (BFRx) MUST advertise one or more BIER Helped Node sub-sub-TLVs". However, I only find a vague outline of this sub-sub TLV. The code point for it is requested in the IANA considerations section, but the description is a single sentence easily misread and lacking the conventional diagrams and precision that is used to define routing TLVs (and sub or sub-sub TLVs.) zzh> Point taken. How about the following? Suppose that the BIER domain uses BIER signaling extensions to ISIS [RFC8401] or OSPF [RFC8444]. The helper node (BFRx) MUST advertise one or more BIER Helped Node sub-sub-TLVs in the BIER Info sub-TLV in the case of ISIS or BIER Helped Node sub-TLVs in the BIER sub-TLV in the case of OSPF, one for each helped node: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Type | Length |Priority | Reserved| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address of the Helped Node | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Type is TBD1 (in the case of ISIS) or TBD2 (in the case of OSPF). The Value field starts with a one-octet Priority field, followed by a one-octet Reserved field, and then the Address of the Helped Node (X). The Length is 6 for IPv4 and 18 for IPv6 respectively. Minor issues: In the paragraph about multiple helpers helping a single non-supporting router, I think I missed how one case works properly. (Section 2, additional considerations, paragraph 6). The text says that the sending BFR (BFR1 can choose to use multiple helpers if they are available. Assuming that BFR1 chooses to use BFR2 and BFR 3 to reach BFRs 4 .. BFR N, the text is clear that this results in BFR2 and BFR 3 both sending copies of the packet to Router X. That is fine. It is load, but it is a tradeoff. However, it appears that both BFR2 and BFR 3 would send packets to BFR4, and to all the other BFR children of X. This results in duplicate packets in the rest of the tree. Is there some assumption I missed that prevents this? Zzh> The BIER forwarding algorithm ensures that the two copies of the same packet that a BFR sends out never have overlapping bits in the BitString. Therefore, no duplication will happen. Zzh> Thanks! Zzh> Jeffrey Nits/editorial comments: ___ BIER mailing list b...@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier__;!!NEt6yMaO-gk!HnoMr9CvW2ImbH6LVeQkh-4CIMEuSojS_TOKsafTWXlzUP7cmGEeUOIn5afkDw9ceS4tFN9KMmQkevA$ ___ 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-bier-tether-04
Reviewer: Joel Halpern 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-bier-tether-04 Reviewer: Joel Halpern Review Date: 2024-02-15 IETF LC End Date: 2024-02-29 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as a proposed standard Major issues: Section 3.1 on IGP Signaling states "The helper node (BFRx) MUST advertise one or more BIER Helped Node sub-sub-TLVs". However, I only find a vague outline of this sub-sub TLV. The code point for it is requested in the IANA considerations section, but the description is a single sentence easily misread and lacking the conventional diagrams and precision that is used to define routing TLVs (and sub or sub-sub TLVs.) Minor issues: In the paragraph about multiple helpers helping a single non-supporting router, I think I missed how one case works properly. (Section 2, additional considerations, paragraph 6). The text says that the sending BFR (BFR1 can choose to use multiple helpers if they are available. Assuming that BFR1 chooses to use BFR2 and BFR 3 to reach BFRs 4 .. BFR N, the text is clear that this results in BFR2 and BFR 3 both sending copies of the packet to Router X. That is fine. It is load, but it is a tradeoff. However, it appears that both BFR2 and BFR 3 would send packets to BFR4, and to all the other BFR children of X. This results in duplicate packets in the rest of the tree. Is there some assumption I missed that prevents this? Nits/editorial comments: ___ 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-lspping-norao-06
Reviewer: Joel Halpern 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-mpls-lspping-norao-06 Reviewer: Joel Halpern Review Date: 2024-02-01 IETF LC End Date: 2024-02-15 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-ip-preof-08
Fixing it with the RFC Editor works for me. Thank you. Joel On 12/20/2023 5:13 AM, Balázs Varga A wrote: Hi Joel, Many thanks for the review. Regarding the editorial comment: - PREOF appears first in the abstract, so it is elaborated there. If You think it is necessary to do so in the introduction as well, we can fix it with the RFC editor. Thanks & Cheers Bala'zs -Original Message----- From: Joel Halpern via Datatracker Sent: Tuesday, December 19, 2023 3:39 PM To: gen-art@ietf.org Cc: det...@ietf.org; draft-ietf-detnet-mpls-over-ip-preof@ietf.org; last-c...@ietf.org Subject: Genart last call review of draft-ietf-detnet-mpls-over-ip-preof-08 Reviewer: Joel Halpern 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-detnet-mpls-over-ip-preof-08 Reviewer: Joel Halpern Review Date: 2023-12-19 IETF LC End Date: 2023-12-22 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: The term PREOF is used without any expansion or definition in the introduction. Some elaboration of the term should be included at first usage. It may make sense to define F-label even though all the references to it in this document are saying that it is not used. As a reader, I was left inferring what was not being done. ___ 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-ip-preof-08
Reviewer: Joel Halpern 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-detnet-mpls-over-ip-preof-08 Reviewer: Joel Halpern Review Date: 2023-12-19 IETF LC End Date: 2023-12-22 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: The term PREOF is used without any expansion or definition in the introduction. Some elaboration of the term should be included at first usage. It may make sense to define F-label even though all the references to it in this document are saying that it is not used. As a reader, I was left inferring what was not being done. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Genart early review of draft-ietf-bess-bgp-multicast-05
Thank you Jeffrey. These edits address my concerns. I believe they also significantly improve document readability. Yours, Joel On 11/30/2023 3:53 PM, Jeffrey (Zhaohui) Zhang wrote: Hi Joel, We had offline exchanges and I just posted the -06 revision that addressed all your comments: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-multicast/06/. Thanks again for your thorough review and lots of comments - a great help in improving the document quality. Jeffrey Juniper Business Use Only -Original Message- From: Jeffrey (Zhaohui) Zhang Sent: Monday, October 23, 2023 4:23 PM To: Joel Halpern ; gen-art@ietf.org Cc: b...@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org Subject: RE: Genart early review of draft-ietf-bess-bgp-multicast-05 Hi Joel, Thanks for your review and comments. I will address them and come back. Jeffrey -Original Message- From: Joel Halpern via Datatracker Sent: Monday, October 23, 2023 3:00 PM To: gen-art@ietf.org Cc: b...@ietf.org; draft-ietf-bess-bgp-multicast@ietf.org Subject: Genart early review of draft-ietf-bess-bgp-multicast-05 [External Email. Be cautious of content] Reviewer: Joel Halpern Review result: Not Ready This is a requested genart early review of draft-ietf-bess-bgp-multicast-05 Prepared on 23-Oct-2023 Summary: This draft is not ready, having a number of issues that need to be addressed. I presume this draft will be socialized with the PIM and IDR working groups before completion (or maybe it already has been?) Major: While I appreciate the effort to give an overview of the operation before providing the specification, the actual text is almost impossible to follow. At a guess, the authors have a coherent view of what happens, and have then written down each "interesting" piece. This does not give the reader clarity. As a first step, before giving the overview, all the terminology needs to be defined. Including such things as the fact that MCAST-TREE NLRI is a general holder, within which there are a number of different NLRI (which is finally explained in section 2, after the reader is thoroughly confused.) All terms and abbreviations should be defined or, when they are from other documents, expanded with a citation so the reader knows where to look for the term. (I did figure out what FHR and LHR were, but the draft did not help me do so.) Secondly, the extensive use of construction of the form ~this use of construct A is just like the use in document B except...~ is very confusing. The reader is left without a coherent description of how this protocol works, exactly which pieces from the other document must be followed, and exactly how the changes are to be applied. Third, if the intention of the introductory material is to provide a perspective on, but not duplicative specification of, the material in section 2.2, then each overview should have forward references explaining where the detailed procedures can be found. If material in the overview is intended to be the normative specification of the operation (as for example when and which rotue communities are to be used, and apparently all of section 1.2.1.1) then normative language is needed. It is quite hard to exgtract from these sections the required procedures. I also note that ID-Nits ha a lot of complaints. I will not repeat them, but they need to be dealt with. (For example, the addresses used in various examples are not example addresses. They should be.) Scaling needs to be better addressed. While I understand the use of RT constraints helps the avoidance of overloading the leaves of the tree, it appears that any network using route reflectors is likely to have state about every sender of every multicast group in every rotue reflector. It may be that this is acceptable. But it should be called out explicitly. Section 2.2.1 sates that source advertisement will be triggered only by sources sending multicast traffic. And will expire based on time. Except that the network has no idea what the suitable time interval is for a given multicast group. Some groups will have long inter-packet intervals, while some will be short and some will be quite variable. Also, some groups will have the property that the senders will know who they are before sending, and receivers may even want to join before the senders are active. If the working group wishes to exclude such use cases, then the document should be explicit about what use cases it is covering. Moderate: Additional explanation is needed in section 1.2.1.2. This section describes how to set up a shared tree for an ANY-Source Multicast Group. Unlike the earlier discussion of advertising sources with a route target community to restrict distribution, this section explicitly says that the sources sending t
[Gen-art] Genart last call review of draft-ietf-core-oscore-edhoc-09
Reviewer: Joel Halpern 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-core-oscore-edhoc-09 Reviewer: Joel Halpern Review Date: 2023-11-12 IETF LC End Date: 2023-11-13 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a proposed standard reviewer note: I did not attempt to verify that the description here of the underlying security protocols is correct. I leave that to the WG and the security reviewers. Major issues: N/A Minor issues: In reading the first part of section 3, I found myself confused in two regards. First, the diagram shows the third message as containing EDHOC message_3 + OSCORE-protected data. But the text refers to it as also containing C_R which is not apparently part of EDHOC message 3. I think this is explained in step 4 of section 3.2, but it is at best jarring at this stage. (Maybe just call it OSCORE option C_R? Or note at this point,as you do later, in the text that the EDHOC C_R and the OSCORE C_R are identical?) Second, the description here is worded in a way that leads the reader to understand that the EDHOC message is part of the OSCOR content. The processing order and protection structure is spelled out in section 3.2. Maybe just add something like "This structure can be processed in order due to the construction rules in section 3.2? Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart early review of draft-ietf-bess-bgp-multicast-05
Reviewer: Joel Halpern
Review result: Not Ready
This is a requested genart early review of
draft-ietf-bess-bgp-multicast-05
Prepared on 23-Oct-2023
Summary: This draft is not ready, having a number of issues that need to be
addressed.
I presume this draft will be socialized with the PIM and IDR working groups
before completion (or maybe it already has been?)
Major:
While I appreciate the effort to give an overview of the operation before
providing the specification, the actual text is almost impossible to
follow. At a guess, the authors have a coherent view of what happens, and
have then written down each "interesting" piece. This does not give the
reader clarity. As a first step, before giving the overview, all the
terminology needs to be defined. Including such things as the fact that
MCAST-TREE NLRI is a general holder, within which there are a number of
different NLRI (which is finally explained in section 2, after the reader
is thoroughly confused.) All terms and abbreviations should be defined or,
when they are from other documents, expanded with a citation so the reader
knows where to look for the term. (I did figure out what FHR and LHR were,
but the draft did not help me do so.) Secondly, the extensive use of
construction of the form ~this use of construct A is just like the use in
document B except...~ is very confusing. The reader is left without a
coherent description of how this protocol works, exactly which pieces from
the other document must be followed, and exactly how the changes are to be
applied. Third, if the intention of the introductory material is to provide
a perspective on, but not duplicative specification of, the material in
section 2.2, then each overview should have forward references explaining
where the detailed procedures can be found. If material in the overview is
intended to be the normative specification of the operation (as for example
when and which rotue communities are to be used, and apparently all of
section 1.2.1.1) then normative language is needed. It is quite hard to
exgtract from these sections the required procedures.
I also note that ID-Nits ha a lot of complaints. I will not repeat them,
but they need to be dealt with. (For example, the addresses used in various
examples are not example addresses. They should be.)
Scaling needs to be better addressed. While I understand the use of RT
constraints helps the avoidance of overloading the leaves of the tree, it
appears that any network using route reflectors is likely to have state
about every sender of every multicast group in every rotue reflector. It
may be that this is acceptable. But it should be called out explicitly.
Section 2.2.1 sates that source advertisement will be triggered only by sources
sending multicast traffic. And will expire based on time. Except that the
network has no idea what the suitable time interval is for a given multicast
group. Some groups will have long inter-packet intervals, while some will be
short and some will be quite variable. Also, some groups will have the
property that the senders will know who they are before sending, and receivers
may even want to join before the senders are active. If the working group
wishes to exclude such use cases, then the document should be explicit about
what use cases it is covering.
Moderate:
Additional explanation is needed in section 1.2.1.2. This section describes
how to set up a shared tree for an ANY-Source Multicast Group. Unlike the
earlier discussion of advertising sources with a route target community to
restrict distribution, this section explicitly says that the sources sending to
the ASM Group are advertised in BGP without the restricting community. I
presume there is some other assumed aspect that restrits the information so it
is only received by the Rendezvous points for the shared tree. But I can not
see how this is achieved. Please add explanation of why this approach does not
flood the whole domain with information it does not want or need.
The last paragraph (short) of section 1.2.1.2 gives a vague description of
certain cases. Presuming it is described in more detail later, a forward
reference would be extremely helpful.
Section 1.2.1.3 has very confusing use of ingress and egress PE. I would have
assumed ingress and egress were in terms of the direction of traffic flow (from
traffic sources to interested receivers). But the usage in both paragraphs
seems to be exactly the opposite.
Section 1.2.3 refers to establishing information via an IGP ("IGP neighbor
discovery"). Except that the earlier descriptions indicate that the deployment
case here is for a pure BGP domain, with no IGP. (Otherwise, there would need
to be extensive procedures as to how the multicasts traverse regions that use
the IGP instead of BGP.)
Section 1.2.4 dis
[Gen-art] Genart last call review of draft-ietf-lake-traces-06
Reviewer: Joel Halpern 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-lake-traces-?? Reviewer: Joel Halpern Review Date: 2023-09-03 IETF LC End Date: 2023-09-11 IESG Telechat date: Not scheduled for a telechat Summary: This document is technically ready, but has what appears to me to be a significant procedural error that should be fixed before resolving publication. Major issues: The draft lists [I-D.ietf-lake-edhoc] as an informative reference. As that is the definition of the protocol for which this is providing traces, this appears to be meaningless without that, and thus [I-D.ietf-lake-edhoc] should be a normative reference. Minor issues: N/A Nits/editorial comments: N/A ___ 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-pbb-evpn-isid-cmacflush-07
Reviewer: Joel Halpern 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-bess-pbb-evpn-isid-cmacflush-07 Reviewer: Joel Halpern Review Date: 2023-06-30 IETF LC End Date: 2023-07-11 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard. reviewers note: My thanks to the authors / editors for a very helpful introduction that made clear the problem to be solved. Major issues: N/A Minor issues: I got a bit confused in section 3, where the text says: All the other fields are set and used as defined in [RFC7623]. This document will refer to this route as the BMAC/I-SID route, as opposed to the [RFC7623] BMAC/0 route (BMAC route sent with Ethernet Tag ID = 0). I got confused because when I went to RFC 7623, I could not find the string BMAC/0, and while I tried searching for related terms, I could not find what term is being distinguished. The string BMAC does not occur in RFC 7623. So this and later (e.g. 4.1) references to 7623 use of BMAC/0 is confusing. Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [ippm] Genart last call review of draft-ietf-ippm-stamp-srpm-11
Thank you Rakesh. Your changes address my concerns. Yours, Joel On 5/29/2023 3:12 PM, Rakesh Gandhi wrote: Thanks Joel for the Gen-ART review and the suggestions. We have posted a new revision that addresses your comments: * https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-srpm-12.txt Please see replies inline with On Mon, May 8, 2023 at 7:42 PM Joel Halpern via Datatracker wrote: Reviewer: Joel Halpern 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-ippm-stamp-srpm-11 Reviewer: Joel Halpern Review Date: 2023-05-08 IETF LC End Date: 2023-05-17 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as a Proposed Standard. Major issues: The document has six authors. The shepherd writeup simply says "that is what the authors want". That does not seem sufficient justification. The Structured SRv6 Segment List Sub-TLV in section 4.1.3 seems problematic. It complicates using the TLV to build the reply message, and adds no value to the responding node. The only node which could make sue of this information is the control node which provided the information. As such, including it in the message does not seem helpful. If it really meets a need, a better explanation is required. Removed this sub-TLV from the draft. Minor issues: In my experience the practice of using the length of an address field to distinguish IPv4 and IPv6 often leads to problems. It would seem much better to use two TLV type codes, one for IPv4 addresses and one for IPv6 addresses. (Section 3) This also applies to the Return Address sub-tly in section 4.1.2. Separated them. In the description in section 4.1.3 of the return segment list sub-tlv, the text reads "An SR-MPLS Label Stack Sub-TLV may carry only Binding SID Label [I-D.ietf-pce-binding-label-sid] or Path Segment Identifier of the Return SR-MPLS Policy." and similar for SRv6 in the next paragraph. This seems ambiguous. Clearly, the TLV can carry a set of label or SRv6 SIDs. If it carries a binding SID, whose binding SID is it? I presume it is a binding SID known to the receiver, and provided to the sender via control mechanisms? How can the receiver tell the difference between a valid SID in the LIST and a Path Segment Identifier? Made the text changes to clarify. It is unclear at the end of section 3, if a responder is sending a reply with the U bit set to indicate that it received the STAMP request apparently in error, should it still use the Destination Node Address (that is not itself) as the source address? Added a sentence to clarify Thanks, Rakesh Nits/editorial comments: ___ ippm mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ippm ___ 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-stamp-srpm-11
Reviewer: Joel Halpern 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-ippm-stamp-srpm-11 Reviewer: Joel Halpern Review Date: 2023-05-08 IETF LC End Date: 2023-05-17 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as a Proposed Standard. Major issues: The document has six authors. The shepherd writeup simply says "that is what the authors want". That does not seem sufficient justification. The Structured SRv6 Segment List Sub-TLV in section 4.1.3 seems problematic. It complicates using the TLV to build the reply message, and adds no value to the responding node. The only node which could make sue of this information is the control node which provided the information. As such, including it in the message does not seem helpful. If it really meets a need, a better explanation is required. Minor issues: In my experience the practice of using the length of an address field to distinguish IPv4 and IPv6 often leads to problems. It would seem much better to use two TLV type codes, one for IPv4 addresses and one for IPv6 addresses. (Section 3) This also applies to the Return Address sub-tly in section 4.1.2. In the description in section 4.1.3 of the return segment list sub-tlv, the text reads "An SR-MPLS Label Stack Sub-TLV may carry only Binding SID Label [I-D.ietf-pce-binding-label-sid] or Path Segment Identifier of the Return SR-MPLS Policy." and similar for SRv6 in the next paragraph. This seems ambiguous. Clearly, the TLV can carry a set of label or SRv6 SIDs. If it carries a binding SID, whose binding SID is it? I presume it is a binding SID known to the receiver, and provided to the sender via control mechanisms? How can the receiver tell the difference between a valid SID in the LIST and a Path Segment Identifier? It is unclear at the end of section 3, if a responder is sending a reply with the U bit set to indicate that it received the STAMP request apparently in error, should it still use the Destination Node Address (that is not itself) as the source address? Nits/editorial comments: ___ 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-digest-headers-11
Reviewer: Joel Halpern 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-httpbis-digest-headers-11 Reviewer: Joel Halpern Review Date: 2023-03-17 IETF LC End Date: 2023-03-21 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [OPSAWG] Genart last call review of draft-ietf-opsawg-tlstm-update-11
Thank you. Joel On 2/15/2023 10:50 AM, Kenneth Vaughn wrote: I have uploaded an update that more accurately indicates that a "session" is a secure association between two /_instances of_ /the TLSTM. Regards, Ken Vaughn Trevilon LLC 1060 S Hwy 107 Del Rio, TN 37727 +1-571-331-5670 cell kvau...@trevilon.com www.trevilon.com <http://www.trevilon.com/> On Feb 9, 2023, at 6:56 PM, Joel Halpern via Datatracker wrote: Reviewer: Joel Halpern 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-opsawg-tlstm-update-11 Reviewer: Joel Halpern Review Date: 2023-02-09 IETF LC End Date: 2023-02-20 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: In the fourth paragraph of section 1.1, the text refers to "a secure association between two TLS Transport Models (TLSTMs)". As I understand the terminology, there is one TLSTM. There are two instances of / realizations of the model. Should the sentence refer to instances or realizations, rather than two models? (i-d nits gets confused by the references to rfc 5953 in the revision description. After looking at it, I realized there was no problem here, rather it is accurate. A comment on this in item 14 of the shepherd writeup would have been helpful.) Nits/editorial comments: N/A ___ OPSAWG mailing list ops...@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ 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-opsawg-tlstm-update-11
Reviewer: Joel Halpern 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-opsawg-tlstm-update-11 Reviewer: Joel Halpern Review Date: 2023-02-09 IETF LC End Date: 2023-02-20 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: In the fourth paragraph of section 1.1, the text refers to "a secure association between two TLS Transport Models (TLSTMs)". As I understand the terminology, there is one TLSTM. There are two instances of / realizations of the model. Should the sentence refer to instances or realizations, rather than two models? (i-d nits gets confused by the references to rfc 5953 in the revision description. After looking at it, I realized there was no problem here, rather it is accurate. A comment on this in item 14 of the shepherd writeup would have been helpful.) Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-pti-pen-registration-09
Reviewer: Joel Halpern 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-pti-pen-registration-09 Reviewer: Joel Halpern Review Date: 2022-11-21 IETF LC End Date: 2022-12-04 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-extra-sieve-action-registry-04
Reviewer: Joel Halpern 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-action-registry-04 Reviewer: Joel Halpern Review Date: 2022-11-02 IETF LC End Date: 2022-11-23 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-lightweight-cmp-profile-14
Reviewer: Joel Halpern 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-lamps-lightweight-cmp-profile-14 Reviewer: Joel Halpern Review Date: 2022-10-13 IETF LC End Date: 2022-10-24 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publicationa s a Proposed Standard Major issues: Minor issues: In section 4.1.1 (Enrolling an End Entity to a New PKI), in the description of the ir message, some fields are listed as optional, with text saying roughly required in case A, omitted in case B.Which makes sense. However, the subjectPublicKey is listed as REQUIRED, even though the text only says it is needed for locally generated keys. The text does not deal with whether it should be omitted or Null-DN or? for centrally generated keys? Section 4.1.6 does deal with this, but I am asking because the field is marked in the 4.1.1 ir as being REQUIRED. Nits/editorial comments: ___ 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-evpn-lsp-ping-08
Reviewer: Joel Halpern 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-bess-evpn-lsp-ping-08 Reviewer: Joel Halpern Review Date: 2022-10-07 IETF LC End Date: 2022-10-18 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC. Major issues: N/A Minor issues: N/A Nits/editorial comments: Should the RDs in section 6.1 and 6.2 use example IP addresses instead of 1.1.1.1 and 2.2.2.2? (ID Nits called my attention to this, and I could not decide if it was important. So it is a nit here.) ___ 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-v2-05
Reviewer: Joel Halpern 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-quic-v2-05 Reviewer: Joel Halpern Review Date: 2022-09-29 IETF LC End Date: 2022-10-11 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-ipsecme-mib-iptfs-04
That suffices for the document and my review. Whether it suffices for the community and IESG is up to them. (I wonder about the precedent of defining MIBs for monitoring every new thing we do. But that is up to others, not something you can fix in this document.) Yours, Joel On 9/29/2022 10:25 AM, Don Fedyk wrote: Hi Joel The reason this was requested by the community is that there is SNMP management equipment deployed that they would like to be able use for monitoring IP-TFS. I suggest I add this text to clearify. OLD: The objects defined here are the same as [I-D.ietf-ipsecme-yang-iptfs] with the exception that only operational data is supported. This module uses the YANG model as a reference point for managed objects. Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing MIB implementations. NEW: The objects defined here are the same as [I-D.ietf-ipsecme-yang-iptfs] with the exception that only operational data is supported. By making operational data accessible via SNMP existing network management systems can monitor IP-TFS. This module uses the YANG model as a reference point for managed objects. Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing MIB implementations. Doses that suffice? Thanks Don -Original Message- From: Joel Halpern via Datatracker Sent: Wednesday, September 21, 2022 6:50 PM To: gen-art@ietf.org Cc: draft-ietf-ipsecme-mib-iptfs@ietf.org; ip...@ietf.org; last-c...@ietf.org Subject: Genart last call review of draft-ietf-ipsecme-mib-iptfs-04 Reviewer: Joel Halpern 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-ipsecme-mib-iptfs-04 Reviewer: Joel Halpern Review Date: 2022-09-21 IETF LC End Date: 2022-10-04 IESG Telechat date: Not scheduled for a telechat Summary: Assuming a reasonable answer to one question, this document is ready for publication as a Proposed Standard RFC. Major issues: The one question I have is "why?" I could not find anywhere in the document any explanation of why we are defining an SNMP MIB for monitoring ipsecme, nor the equivalent why an operator would choose to use this MIB instead of the YANG based model that it is based upon. Minor issues: N/A Nits/editorial comments: N/A ___ 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-ippm-ioam-ipv6-options-08
Thank you for addressing my comments. trimmed, responses where needed in line. Yours, Joel On 9/24/2022 10:01 PM, Shwetha Bhandari wrote: Thank you for the detailed review and sorry for a very late response. I am creating a revision of the draft based on this feedback. Responses and clarifications inline @SB On Wed, Jun 29, 2022 at 1:39 AM Joel Halpern via Datatracker wrote: Reviewer: Joel Halpern 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://urldefense.com/v3/__https://trac.ietf.org/trac/gen/wiki/GenArtfaq__;!!MZ3Fw45to5uY!NoSxZQbYffG7SJV0yDCTEy7dKRhLkASqrXTvmSZYhuyCrik6ftQvulTvbfT6xyFBWdoxk_7S4nD87nOYMkJnckbF$ >. Document: draft-ietf-ippm-ioam-ipv6-options-08 Reviewer: Joel Halpern Review Date: 2022-06-28 IETF LC End Date: 2022-07-01 IESG Telechat date: Not scheduled for a telechat Minor issues: Section 5.1 (Considerations for IOAM deployment in IPv6 networks) requirement C1 seems to be an implementation requirement not a deployment requirement. The text even ends with "Implementations of IOAM SHOULD..." Why is this in a deployment considerations section? [SB] This was an important consideration for implementation and deployment that came up during the workgroup discussions. Would renaming the sesion to deployment and implementation considerations work? Yes, renaming the section to "deployment and implementation considerations" would resolve this concern. Requirement C5 in 5.1 says that leaks need to be easily identified and attributed. That's nice. It doesn't seem to say HOW that is to be done. So how does an implementor or deployer comply with the requirement? [SB] This is not addressed in the current draft. A future draft could add IOAM field to indicate the AS that added the IOAM data. I marked this as minor, so if you really can't say anything else, I guess I can live with it. But it seems more than a little odd to have a requirement in a draft with no way to meet it. Nits/editorial comments: It would be helpful if section 5.3 (IOAM domains bounded by network devices) restated that such ingress edge devices will encapsulate the user packet, and put the IOAM option in the resulting encapsulating header. And decapsulate at the egress. [SB] The deployment options elaborates this option, it is difficult to summarize that and add it as part of the requirement. I would prefer to keep this context in the deployment options section. Okay. Thanks, Shwetha___ 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-mib-iptfs-04
Reviewer: Joel Halpern 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-ipsecme-mib-iptfs-04 Reviewer: Joel Halpern Review Date: 2022-09-21 IETF LC End Date: 2022-10-04 IESG Telechat date: Not scheduled for a telechat Summary: Assuming a reasonable answer to one question, this document is ready for publication as a Proposed Standard RFC. Major issues: The one question I have is "why?" I could not find anywhere in the document any explanation of why we are defining an SNMP MIB for monitoring ipsecme, nor the equivalent why an operator would choose to use this MIB instead of the YANG based model that it is based upon. Minor issues: N/A Nits/editorial comments: N/A ___ 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-yang-iptfs-06
Reviewer: Joel Halpern
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-ipsecme-yang-iptfs-06
Reviewer: Joel Halpern
Review Date: 2022-07-21
IETF LC End Date: 2022-08-04
IESG Telechat date: Not scheduled for a telechat
Summary: This document is ready for publicaiton as a Proposed standards
Major issues: N/A
Minor issues:
I think that in augment "/nsfikels:ipsec-ikeless/nsfikels:sad/"
+ "nsfikels:sad-entry"
the container ipsec-stats {
should have, after if-feature "ipsec-stats";,
config false;?
Nits/editorial comments: N/A
___
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-ipv6-options-08
Reviewer: Joel Halpern 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-ippm-ioam-ipv6-options-08 Reviewer: Joel Halpern Review Date: 2022-06-28 IETF LC End Date: 2022-07-01 IESG Telechat date: Not scheduled for a telechat Summary: If the issues identified below are addressed, this document will be ready for publication as a Proposed Standard RFC. Major issues: Why is the domain boundary expectation in section 4 only a SHOULD? Either there is no need to restrict it, or it is important and it is a MUST? This comes up again in section 5.1 item C4. Minor issues: The document uses the term IOAM extensively. It expands the term as "In-situ Operations, Administration, and Maintenance". While a good start, it would be very helpful if the document either defined IOAM or cited a definition. The expansion does not explain what the difference is between IOAM and other forms of OAM, nor indicate what sorts of packets IOAM applies to. Section 5.1 (Considerations for IOAM deployment in IPv6 networks) requirement C1 seems to be an implementation requirement not a deployment requirement. The text even ends with "Implementations of IOAM SHOULD..." Why is this in a deployment considerations section? Requirement C3 in section 5.1 is very oddly worded. It seems to say "X should not happen" but does not tell the implementor or deployer how to avoid having X occur. I would recommend rewording. (At a guess, something about how entities sending errors outside of an IOAM domain should remove any IOAM data??) Requirement C5 in 5.1 says that leaks need to be easily identified and attributed. That's nice. It doesn't seem to say HOW that is to be done. So how does an implementor or deployer comply with the requirement? Could the description clause of the two IANA entries please use "IOAM destination option" and "IOAM hop-by-hop option" rather than describing them both just as "IOAM". Nits/editorial comments: Given the problems of acronym overload and the sparse need for it, I would recommend not using the acronym ION (IOAM Overlay Network), and simply spelling that out in the few places it is needed. It would be helpful if section 5.3 (IOAM domains bounded by network devices) restated that such ingress edge devices will encapsulate the user packet, and put the IOAM option in the resulting encapsulating header. And decapsulate at the egress. ___ 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-8410-ku-clarifications-01
Reviewer: Joel Halpern 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-lamps-8410-ku-clarifications-01 Reviewer: Joel Halpern Review Date: 2022-05-03 IETF LC End Date: 2022-05-09 IESG Telechat date: Not scheduled for a telechat Summary: Ready Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-uberti-rtcweb-rfc8829bis-02
Reviewer: Joel Halpern 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-uberti-rtcweb-rfc8829bis-02 Reviewer: Joel Halpern Review Date: 2022-03-27 IETF LC End Date: 2022-04-05 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard. However, there are some issues that should be considered before final approval. Major issues: None Minor issues: I found myself confused as a reader about one aspect of this document The document seems to describe both the Interface to the JSEP and the details of what the underlying system must do in response to JSEP operations. The later is described very well and clearly. The former is described quite vaguely. I suspect that the assumption is that the required parameters are described in the W3C documents. But it is hard to tell, and the only formal reference is a vague citation in the introduction to an outdated W3C specification. A little more clarity on how an implementor is supposed to know what actual interface objects, methods, and parameters they need to provide would be helpful. Also, the reference should be updated to whatever is the current W3C specification. Nits/editorial comments: ___ 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-bfd-rfc9127-bis-01
Reviewer: Joel Halpern 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-bfd-rfc9127-bis-01 Reviewer: Joel Halpern Review Date: 2022-01-26 IETF LC End Date: 2022-02-03 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-acme-dtnnodeid-07
Reviewer: Joel Halpern 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-acme-dtnnodeid-07 Reviewer: Joel Halpern Review Date: 2021-11-24 IETF LC End Date: 2021-11-29 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an experimental RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-regext-rfc7484bis-04
Reviewer: Joel Halpern 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-regext-rfc7484bis-04 Reviewer: Joel Halpern Review Date: 2021-10-06 IETF LC End Date: 2021-10-27 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Internet Standard Major issues: N/A Minor issues: I think this is intended to move the document to Full Internet Standard. If so, it would have been nice if there were an appendix "Changes since rfc 7484. It could have said "There are no substantive changes except for updates to the implementation status section of the document. This update is primarily to meet the requirements for moving to Internet Standard." Nits/editorial comments: N/A ___ 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-opsawg-vpn-common-09
Reviewer: Joel Halpern 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-vpn-common-09 Reviewer: Joel Halpern Review Date: 2021-07-30 IETF LC End Date: 2021-08-06 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: I just want to confirm that one form of reference is normal for YANG models? There are a few identities whose meaning is defined by I-Ds that are under way. The references section of the identity gives the I-D name. Which is fine. The references at the bottom of the document makes those informative references. That seems a little odd since those references are necessary to understand the meaning of those identities. Is this a normal practice for YANG models? I am a little confused as to why the srv6 identity includes in its references clause RFC 8663 (MPLS SR). Is this a copy-and-paste error? I hope I am misreading the qos-classification-policy definition. It appears to have an id, a match rule, and a match action. The match rule can be a match-flow or a match-application. So far, so good. (putting aside the nit below on customer-application.) But the match rule is a choice between an L3 and an L4 rule. As I understand it, there are many cases where the actual classification is based on a combination of l3 and l4 information. How is that to be represented? Nits/editorial comments: The "customer-application" identity seems to be asking for problems in two regards.It seems that it is a shorthand way of expressing some combination of protocols and ports. The larger concern I have is that there is no reference that explains what classification rules should be used for any of the derived identities. Which means that for an interoperable implementation, there seems to be some difficulty in ensuring that the client and server mean the same thing when using them. (For example, just what filer corresponds to "voice"?) As a lesser issue, the current IAB work on path signals and the care that should be taken with them would seem to suggest that this is a less than desirable approach to the problem. ___ 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-dnsop-iana-class-type-yang-02
Thank you Lada. I had missed the union, reading the introductory material with more attention. Glad to hear IANA did an early review. Yours, Joel On 5/17/2021 8:25 AM, Ladislav Lhotka wrote: Hi Joel, thanks for the review, please see my responses below. Joel Halpern via Datatracker writes: Reviewer: Joel Halpern 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-dnsop-iana-class-type-yang-02 Reviewer: Joel Halpern Review Date: 2021-05-14 IETF LC End Date: 2021-05-24 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a proposed standard. I do have two questions that I hope has already been considered by the WG and is a non-issue. See minor issues. Major issues: Minor issues: 1) I presume IANA has been involved in the development of this document, and is willing to undertake the maintenance? I looked for but did not see where that was noted. Yes, Michelle Cotton of IANA did an early review last year. One issue that remains to be decided has to do with the XSLT stylesheet that is intended to be used for generating the initial revision of the YANG module: is it to be removed before publication or not? 2) I question the use of enumerations for the content. I understand that since IANA will generate new YANG modules when there is a change, the new models can have new values. I am concerned that if an implementation using the older schema reads data from a DNS repository with updated entries (and the corresponding updated version) the version skew will cause processing errors instead of simply handing over the numeric value in a fashion that is acceptable but not understood. This is partly alleviated by the YANG union types "dns-class" and "rr-type" that should be used for configuration data: old clients can always use corresponding numeric values in place of unsupported enums. If the module update rules of sec. 11 in RFC 7950 are observed, then the risk of interoperability issues is IMO reasonably low. Lada Nits/editorial comments: ___ 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-iana-class-type-yang-02
Reviewer: Joel Halpern 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-dnsop-iana-class-type-yang-02 Reviewer: Joel Halpern Review Date: 2021-05-14 IETF LC End Date: 2021-05-24 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a proposed standard. I do have two questions that I hope has already been considered by the WG and is a non-issue. See minor issues. Major issues: Minor issues: 1) I presume IANA has been involved in the development of this document, and is willing to undertake the maintenance? I looked for but did not see where that was noted. 2) I question the use of enumerations for the content. I understand that since IANA will generate new YANG modules when there is a change, the new models can have new values. I am concerned that if an implementation using the older schema reads data from a DNS repository with updated entries (and the corresponding updated version) the version skew will cause processing errors instead of simply handing over the numeric value in a fashion that is acceptable but not understood. Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-tsvwg-transport-encrypt-20
Reviewer: Joel Halpern 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-tsvwg-transport-encrypt-20 Reviewer: Joel Halpern Review Date: 2021-03-19 IETF LC End Date: 2021-02-19 IESG Telechat date: 2021-04-08 Summary: This document is ready for publication as an Informational RFC My thanks to the authors for addressing my earlier comments. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-transport-encrypt-19
Reviewer: Joel Halpern 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-tsvwg-transport-encrypt-19 Reviewer: Joel Halpern Review Date: 2021-02-15 IETF LC End Date: 2021-02-19 IESG Telechat date: Not scheduled for a telechat Summary: THis document is ready for publication as an Informational RFC Major issues: Minor issues: While section 2 does include a discussion of traffic mis-ordering, it does not include a discussion of ECMP, and the dependence of ECMP on flow identification to avoid significant packet mis-ordering. Section 5.1 of this document discusses the use of Hop-by-Hop IPv6 options. It seems that it should acknowledge and discuss the applicability of the sentence "New hop-by-hop options are not recommended..." from section 4.8 of RFC 8200. I think a good argument can be made in this case as to why (based on the rest of the sentence from 8200) the recommendation does not apply to this proposal. The document should make the argument. Nits/editorial comments: I found the discussion of header compression slightly confusing. Given that the TCP / UDP header is small even compared to the IP header, it is difficult to see why encrypting it would have a significant impact on header compression efficacy. The wording in section 6.2 on adding header information to an IP packet has the drawback of seeming to imply that one could add (or remove) such information in the network, without adding an encapsulating header. That is not permitted by RFC 8200. It would be good to clarify the first paragraph. (The example, which talks about the sender putting in the information is, of course, fine.) ___ 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-regext-rfc7483bis-04
Reviewer: Joel Halpern 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-regext-rfc7483bis-04 Reviewer: Joel Halpern Review Date: 2021-01-28 IETF LC End Date: 2021-02-08 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Internet Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-carpenter-eligibility-expand-08
Reviewer: Joel Halpern 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-carpenter-eligibility-expand-08 Reviewer: Joel Halpern Review Date: 2020-12-06 IETF LC End Date: 2020-12-30 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an experimental RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-invariants-11
Reviewer: Joel Halpern 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-quic-invariants-11 Reviewer: Joel Halpern Review Date: 2020-10-30 IETF LC End Date: 2020-11-16 IESG Telechat date: Not scheduled for a telechat Summary: This Document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-oauth-jwsreq-30
Reviewer: Joel Halpern 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-oauth-jwsreq-30 Reviewer: Joel Halpern Review Date: 2020-09-24 IETF LC End Date: 2020-10-02 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-mdn-15
Reviewer: Joel Halpern 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-jmap-mdn-15 Reviewer: Joel Halpern Review Date: 2020-09-11 IETF LC End Date: 2020-09-18 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-cellar-ffv1-16
Reviewer: Joel Halpern
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-cellar-ffv1-16
Reviewer: Joel Halpern
Review Date: 2020-07-13
IETF LC End Date: 2020-07-16
IESG Telechat date: Not scheduled for a telechat
Summary: This document appears to be ready for publication as an Informational
RFC.
*I would have raised question about the intended status, but it appears that
this is an established IETF convention and I see no reason to argue.)
Major issues:
Minor issues:
Section 3.4 (Context) introduces the notation Q_{#}[ subscript }. As that
is the first reference to Q_{#}, it is rather confusing to the reader. I
grant that the term is defined in the next section (3.5). Couldn't they be
reversed?
Section 3.8.1.1 refers to C(i), C_{i}, and C_i. Are these all the same
thing.
Section 3.8.1.2 refers to get-rac (which is treated as a function in the
pseudo-code) as being the process described in section 3.8.1.1. The text
in 3.8.1.1 does not call out any of its computed values as an explicit
result or return. While I would guess that the intention is to use the
byte stream (B()), the text does not actually say that. If that is the
intention, could the last line of 3.8.1.1 be "get_rac() returns sequential
bytes from the Byte Stream (B()) as computed by the computation described
in section 3.8.1.1"?
Nits/editorial comments:
___
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-capport-architecture-08
Reviewer: Joel Halpern 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-capport-architecture-08 Reviewer: Joel Halpern Review Date: 2020-05-16 IETF LC End Date: 2020-05-25 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as an Informational RFC Major issues: This document says it is Informational. It says it describes "a" capport architecture. But the third paragraph of the introduction says that this document standardizes an architecture. The rest of this review assumes that is an error, and this is describing "an" architecture, rather than "the IETF" architecture. Minor issues: The abstract really should expand "capport". As simple as having the first sentence read "This document describes a "captive portal" (capport) archtiecture." Nits/editorial comments: Following the first bulleted list in the introduction, the document reads: "this document does not yet describe...? The word "yet" seems inappropriate. We are pbulsihgin this as an RFC. Please remove the "yet". ___ 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-extended-error-14
Reviewer: Joel Halpern 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-dnsop-extended-error-14 Reviewer: Joel Halpern Review Date: 2020-03-18 IETF LC End Date: 2020-04-02 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: The RPC Should examine the acknowledgments section carefully. ___ 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-vpls-multihoming-05
Reviewer: Joel Halpern 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-bess-vpls-multihoming-05 Reviewer: Joel Halpern Review Date: 2020-03-18 IETF LC End Date: 2020-03-12 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard. I would recommend that the minor issues below be addressed before approval for publication. Major issues: N/A Minor issues: Section 1 seems to have some language oddities. The first paragraph appears to be technically correct that RFC 4761 and 6074 both describe using BGP for auto-discovery. As written, the text seems to imply that the same thing is defined in two places. This is going to confuse readers and tempt them into trying to understand the wrong problem. Please either simplify or explain. (I believe the distinction in the RFCs is about use with LDP. While the text refers to that, the English construction is not clear.) Section 1.1 paragraph 4 is a duplicate of the latter half of paragraph 3. VE (VPLS Edge) is defined in section 1.1 as being about a device. The introductory text then starts talking about VE NLRI and VE-IDs. It looks like the point is merely to setup the definition for CE-NLRI. If so, the text could be restructured to say: BGP VPLS NLRI as specified in section 3.2.2 in [RFC4761] includes a number of fields. This document refers to the VE-ID, VE offset, from that RFC. This document should reference RFC 8174 as part of BCP 14. And should use upper case usage (MUST, SHOULD, ...) consistently. It currently mixes upper and lower case usage in different places. Even though some of each usage are clearly normative. It is unclear why discarding CE-ID=0 (which is defined to be invalid) is a should rather than a MUST. The beginning of section 3.3.1 seems to say that the L2-info community may be omitted (e.g. is optional). Then the text says that it must (presumably upper case) be present. As written, this is quite confusing. Reading later, it appears that this is intended to support backwards compatibility. If so, then the sentence about handling their absence should say "Although required, this document specifies mechanisms for dealing with their absence to support backwards compatibility." Alternatively, it seems that the L2-info is allways required, but that the L2-pref is not required unless the VPLS advertisement is inter-AS. If that is the case, say that. Nits/editorial comments: I found myself misreading the definition of multi-homing: "redundant connectivity to one or more sites". What is there is technically correct. It would help I think if this were split into two pieces: multi-homing is when the provider provides redundant VPLS connectivity to a customer site. If the customer has more than one site, the service is considered to be multi-homed if at least one site is multi-homed. Section 3.3.1, the two new flags in the L2-info community are presumably defined in this document rather than proposed. Or at least, that is how they need to be described once this document is approved. ___ 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-rmcat-eval-criteria-11
Reviewer: Joel Halpern 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-eval-criteria-11 Reviewer: Joel Halpern Review Date: 2020-02-13 IETF LC End Date: 2020-02-26 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-kucherawy-rfc8478bis-03
Reviewer: Joel Halpern 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-kucherawy-rfc8478bis-03 Reviewer: Joel Halpern Review Date: 2019-12-26 IETF LC End Date: 2020-01-17 IESG Telechat date: Not scheduled for a telechat Summary: This review primarily focused on the differences, which seem appropriate, from the RFC. Major issues: N/A Minor issues: N/A Nits/editorial comments: I presume that bits within a byte are still interpreted in the normal fashions since we do not work in terms of the serialization of bits on a wire, and in fact different wires may do it differently. This does leave the question of how bit fields are interpreted when they describe bits within a byte. Thus, I assume that the "last block" flag is the least significant bit of the first byte of the block header? And Literals_Block_Type is the least significant two bits of the first byte of the Literals_Section_Header? (I presume that the use of little-endian encoding is due to existing practice, and therefore presume it is what this needs to describe.) Should this be stated more explicitly? ___ 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-6man-ra-pref64-07
Reviewer: Joel Halpern 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-6man-ra-pref64-07 Reviewer: Joel Halpern Review Date: 2019-11-08 IETF LC End Date: 2019-11-27 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard. Major issues: Minor issues: While IDNits complains about the prefixes begin used for an example, the text makes it clear that the example needs to be private IP space, and thus seems appropriate as given. Nits/editorial comments: ___ 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-ippm-initial-registry-12
Thanks Al. I presumed all the ducks were in a row, but thought I should ask to be certain. Yours, Joel On 11/3/2019 3:14 PM, MORTON, ALFRED C (AL) wrote: Hi Joel, Thanks for your review, please see replies below. Al -Original Message- From: Joel Halpern via Datatracker [mailto:nore...@ietf.org] Sent: Friday, November 1, 2019 12:55 PM To: gen-art@ietf.org Cc: last-c...@ietf.org; draft-ietf-ippm-initial-registry@ietf.org; i...@ietf.org Subject: Genart last call review of draft-ietf-ippm-initial-registry-12 Reviewer: Joel Halpern 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://urldefense.proofpoint.com/v2/url?u=https- 3A__trac.ietf.org_trac_gen_wiki_GenArtfaq&d=DwICaQ&c=LFYZ- o9_HUMeMTSQicvjIg&r=OfsSu8kTIltVyD1oL72cBw&m=GTgiUHp01_savOvQS49iOt8XRHfRw hPgZj-TNotgKGk&s=M0ib3zYg2qffmRujLJv2h_WHQ16W9fOYat9hNtBqcFk&e=>. Document: draft-ietf-ippm-initial-registry-12 Reviewer: Joel Halpern Review Date: 2019-11-01 IETF LC End Date: 2019-11-06 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Side note: I presume that as part of the process for draft-ietf-ippm-metric-registry (the normative reference the defines the structure used in this document) there has been discussion with IANA explicitly about the fact that this registry has an extremely large number of columns, some with extremely verbose content, and it will likely take some work for IANA to determine how to present this in a human-readable fashion? And the lesser point that is probably covered by existing procedures, but I wanted to check, that IANA is prepared to fill in the URLs scattered throughout the document? [acm] Yes and Yes. We prepared a mock-up of the new Registry at various stages of development. Humbly, it was my idea to make the registry entries both readable and useful. The IANA reps suggested the mock-up early-on, and we have shared the different versions with the IPPM WG. We/IANA plan to make the mock-up more widely available (but we failed to do that in time for Last Call). Second note: I did not review the accuracy of the descriptions of the metrics, but only looked for clarity. This is material well known to the WG, and mostly derived from other documents this or closely related working groups have produced. Major issues: N/A Minor issues: For those entries that are defining two (or more) closely related metrics, should the document actually have two (or more) lines for URL, since the text says that IANA is to assign two URLs. (And the list of differing fields should presumably include URL?) [acm] There are sections of the document that define more than one registry entry, so yes, there will be >1 URLs, etc. in the corresponding rows. In the first part of section 5, there is a note about potentially splitting the registry entry into two registry entries. I can not understand the note. The registry is either defined with one entry or defined with two entries. Is this still an open item? (If so, my "ready" above clearly should be "Ready with issues.") I think it is just an erroneous retention of text from earlier? [acm] Exactly, it is a note left-stranded by editing later in the section, thanks for catching it - deleted in the working version. Nits/editorial comments: If there are no roles to define in 5.3.6, shouldn't it say "N/A" [acm] Actually, it should define the Roles (Src and Dst) as with other Metrics. Something went wrong with formatting here - the text below the section header disappeared... thanks for catching that! Some comments and remarks say "None" which makes sense. Some say "Additional (Informational) details for this entry" which seems to be text left over from the template that should say "None"? [acm] Right, found and replaced in working copy. ___ 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-initial-registry-12
Reviewer: Joel Halpern 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-ippm-initial-registry-12 Reviewer: Joel Halpern Review Date: 2019-11-01 IETF LC End Date: 2019-11-06 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard Side note: I presume that as part of the process for draft-ietf-ippm-metric-registry (the normative reference the defines the structure used in this document) there has been discussion with IANA explicitly about the fact that this registry has an extremely large number of columns, some with extremely verbose content, and it will likely take some work for IANA to determine how to present this in a human-readable fashion? And the lesser point that is probably covered by existing procedures, but I wanted to check, that IANA is prepared to fill in the URLs scattered throughout the document? Second note: I did not review the accuracy of the descriptions of the metrics, but only looked for clarity. This is material well known to the WG, and mostly derived from other documents this or closely related working groups have produced. Major issues: N/A Minor issues: For those entries that are defining two (or more) closely related metrics, should the document actually have two (or more) lines for URL, since the text says that IANA is to assign two URLs. (And the list of differing fields should presumably include URL?) In the first part of section 5, there is a note about potentially splitting the registry entry into two registry entries. I can not understand the note. The registry is either defined with one entry or defined with two entries. Is this still an open item? (If so, my "ready" above clearly should be "Ready with issues.") I think it is just an erroneous retention of text from earlier? Nits/editorial comments: If there are no roles to define in 5.3.6, shouldn't it say "N/A" Some comments and remarks say "None" which makes sense. Some say "Additional (Informational) details for this entry" which seems to be text left over from the template that should say "None"? ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [regext] Genart telechat review of draft-ietf-regext-bundling-registration-11
If we do not have agreement on what the meaning is for the relevant terms, then either 1) The document should not be an IETF consensus document (which even Informational publication is) or 2) The document should be Experimental, indicating explicitly that there is ambiguity in the terms, and one of the points of the experiment would be to find out if that matters. Yours, Joel On 10/15/2019 12:59 PM, John C Klensin wrote: Joel, Let me try one reason why this should not be Standards Track or, if it should, it isn't ready. It uses, and is dependent on, terminology for which there is no consensus definition and that is used to describe different things in the wild. As I think I suggested one of my earlier notes about this, it would be possible to say "these terms mean whatever the registry says they mean", explicitly anticipating that different registries might use the extension for slightly different purposes. While not a problem for an Informational document whose purpose is to inform the community about what some registries are doing and perhaps not for an Experimental one, neither that option nor ignoring the definitional issue are consistent with our expectations that standards track documents will at least lay a foundation for interoperability. Even if it worked for each registry that uses it taken separately, many of us have seen situations in which companies with different definitions and applicability for given named concepts merge and the difficulties that result. For a standards track document, creating such a situation would be, at least, a "known defect" that requires exploration and explanation in the document, text that is not present. More details on these terminology issues in my two comments on the Secdir review on the 13th. best, john --On Tuesday, October 15, 2019 08:10 -0400 "Joel M. Halpern" wrote: Regarding the document status, neither of the emails you pointed to explains why the document is Informational. I understand from that and other discussions that there is no desire to make this standards track. As has been noted, publication of usages of protocol by small groups is normally handled by the Independent Stream. This document has been processed by the working group. It is very strange for a protocol document to be processed by a working group, be accepted as not needing experimental status, and not be published as a standards track document. Reading teh dcouemtn, I see no reason for it not to be standards track. If there is concern that there may be problems with the document, then Experimental status would be the normal way to handle this document. With an explanation of what the experiment is intended to represent. If the working group feels there is a good reason for informational publication, that should be document somewhere. It is currently not documented in either the document itself or the shepherd report. The fact that proprietary extensions to EPP are allowed by the protocol and registries is irrelevant. This document is an IETF working group product and therefore is not a proprietary extension. With regard to the "b-dn:" elements of this document, I am now more concerned than I was. I had thought those were a reference to some other document that clearly defined the syntax and semantics of those elements. I now understand that the given prefix is used for the new elements defined in this document. The structure that is used to describe the expected and permitted content of these elements is qutie confusing. The actual definition is only in the "formal syntax" section. The descriptions are scattered embedded in descriptions of the messages, expecting to user to determine the permitted and required behavior from informal descriptive text. Yes, for those who already know how it works and what it needs, everything is hear. For a new implementor it is very hard to follow. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-regext-bundling-registration-11
Reviewer: Joel Halpern 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 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-regext-bundling-registration-11 Reviewer: Joel Halpern Review Date: 2019-10-10 IETF LC End Date: None IESG Telechat date: 2019-10-17 Summary: This document is almost ready for publication as an RFC. I have received no response to my earlier review. Some of the items have been addressed, but not all of them. Major issues: This document clearly defines normative protocol behavior. As such, it would seem to either be Experimental or Proposed Standard, but not Informational. Minor issues: The document incorporates items from a name space "urn:ietf:params:xml:ns:epp:b-dn", referred to with the prefix "b-dn:". The only explanation of this meaning is in the terminology section. However, the description does not indicate what document defines this information. Nits/editorial comments: I note and appreciate that my comments on the SHOULD usage in section 7.2 has been addressed. ___ 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-implicit-iv-07
Reviewer: Joel Halpern 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-ipsecme-implicit-iv-07 Reviewer: Joel Halpern Review Date: 2019-09-27 IETF LC End Date: 2019-10-07 IESG Telechat date: Not scheduled for a telechat Summary: THis document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-callinfo-spam-04
Reviewer: Joel Halpern 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-callinfo-spam-04 Reviewer: Joel Halpern Review Date: 2019-09-08 IETF LC End Date: 2019-09-14 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: ID Nits and inspection of the txt show that the ABNF is formatted with lines that are too long. While I expect that the RFC Editor can fix this, it seems safer for the authors to do the repairs themselves. (The shepherd has indicated they will be fixed, so I am merely including this here to make sure it is not forgotten.) Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-klensin-idna-unicode-review-02
Reviewer: Joel Halpern 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-klensin-idna-unicode-review-02 Reviewer: Joel Halpern Review Date: 2019-08-08 IETF LC End Date: 2019-08-30 IESG Telechat date: Not scheduled for a telechat Summary: THis document is ready for publication as a Proposed Standard This reviewer found the document quite readable and clear about what it was doing (with one minor issue noted below.) The reviewer does not have the background to evaluate whether the technical substance is correct or incorrect, and leaves that to the community review. The document is quite persuasive. Major issues: N/A Minor issues: I would like to see a little more explicit text in section 3.2. It was not until I reached the IANA considerations (section 8) that I realized that section 3.2 intended to mandate that the IESG create and where applicable use a broad review team for the new code point review. I think a sentence or so along the lines of "Creation of this team when needed is a new responsibility placed on the IESG by this document." would have helped. Nits/editorial comments: N/A ___ 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-rmcat-nada-11
Reviewer: Joel Halpern 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-rmcat-nada-11 Reviewer: Joel Halpern Review Date: 2019-08-05 IETF LC End Date: 2019-08-12 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as an Experimental RFC Major issues: It is unclear reading this RFC how the observation information is to be communicated from the receiver to the sender. At first I thought it was to use the RTP Receiver report. But there is no description of how to map the fields to that report. Then section 5.3 describes requirements for a reporting mechanism, but does not seem to actually define one. Thus, I am left unclear how independent interoperable implementations of this draft can be created. Minor issues: The document has 7 front page authors. The shepherd writeup does not comment on this. The shepherd writeup seems quite sparse. II would have expected some reference to the experimental behavior described in the draft. This comment is just to confirm that I am reading the draft correctly. It looks like when the observed delay cross the delay boundary, the reporting system reports using a smaller delay than actually approved (slightly more than 1/9th of observed delay when delay is 3*QTH). I presume this is intentional, and that the various analysis pointed to evaluate the risks of such false reporting? Is it intentional in section 4.3 in the pseudo-code that the rate clipping (to keep the rate between RMIN and RMAX) is only applied to the gradual rate change, not to the accelerated rate change? The later code says that the clipping is always applied, which is what I would expect. Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [babel] Genart last call review of draft-ietf-babel-applicability-06
I do not consider this a show-stopper (I listed it as a nit / editorial), but at least the -07 text does not look better in this regard. In my experience, if this were indeed mathematics, one would talk about a metric (how one measures) and a distance (the result of applying the measure. E.g. Given two points in a metric space, with a distance between them of d, ... Or more verbosely, given a space with a metric M, the distance between two points a and b is M(A, b). Yours, Joel On 7/7/19 10:26 AM, Juliusz Chroboczek wrote: Dear Joel, Thank you very much for your kind review. Nits/editorial comments: In section 2.2, in talking about "metric M", if I have understood properly, I think it would be clearer if you referred to "metric value M". This section has been expanded with human-readable text and a reference to a research paper, and should therefore now be easier to understand. I have, however, decided to follow the usual style of mathematical writing, and have therefore chosen not to follow your advice. I hope that is okay. Thanks again, -- Juliusz ___ babel mailing list ba...@ietf.org https://www.ietf.org/mailman/listinfo/babel ___ 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-babel-applicability-06
Reviewer: Joel Halpern 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-babel-applicability-06 Reviewer: Joel Halpern Review Date: 2019-06-24 IETF LC End Date: 2019-07-04 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: In section 2.2, in talking about "metric M", if I have understood properly, I think it would be clearer if you referred to "metric value M". ___ 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-pkix-shake-11
Reviewer: Joel Halpern 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-pkix-shake-11 Reviewer: Joel Halpern Review Date: 2019-06-24 IETF LC End Date: None IESG Telechat date: 2019-06-27 Summary: This document is ready for publication as a Proposed Standard My thanks to those involved for addressing my comments. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-softwire-map-radius-24
Reviewer: Joel Halpern 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-softwire-map-radius-24 Reviewer: Joel Halpern Review Date: 2019-06-06 IETF LC End Date: None IESG Telechat date: 2019-06-13 Summary: This document is ready for publication as a Proposed Standard RFC My thanks to the authors for addressing the comments I raised. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-hash-of-root-key-cert-extn-05
Reviewer: Joel Halpern 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-hash-of-root-key-cert-extn-05 Reviewer: Joel Halpern Review Date: 2019-05-21 IETF LC End Date: None IESG Telechat date: 2019-05-30 Summary: This Internet Draft is ready for publication as an Informational RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-softwire-map-radius-23
Reviewer: Joel Halpern 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-softwire-map-radius-?? Reviewer: Joel Halpern Review Date: 2019-05-17 IETF LC End Date: 2019-05-31 IESG Telechat date: Not scheduled for a telechat Summary: Major issues: Figure 1 of section 3.1.1 and section 3.1.1.3 do not match. It appears from later text that the problem is simple. Figure 3.1.1 needs to include, in the portion for the Softwire46-Lightweight-4over6 Attribute, the fact that the Softwire46-BR attribute is permitted there. Particularly since it is required. Section 3.1.4.1 states that the IPv6 prefix is 128 bits. It also points to RFC 8044 section 3.10. Section 3.10 is quite clear that in order to include the prefix length, the TLV may be longer that 128 bits. (Section 3.1.5.2 correctly uses the ipv6pref type.) Thus, it also appears that the stated TLV length is wrong. Section 3.1.4.2 states that the IPv4 prefix is 32 bits. It also points to RFC 8044 section 3.11. Section 3.11 states that the TLV is 48 bits. Thus, it also appears that the stated TLV length is wrong. Minor issues: I trust that the WG Chairs and document shepherd will work with the authors to reduce the number of front page authors? I looked in the shepherd writeup to see if there was an explanation of the large number of authors, but did not see one. Section 3.1 states that the Softwire46-Configuration Attribute may appear in an Access Request message. Unlike the later material on multicast, there is no further explanation here of why it might appear, and how it should be processed if it does appear. It would seem sensible to include this material. Nits/editorial comments: In the description of the entries in table 2 (in section 3.1.2) should the entry for "1" read "1 Mandatory, may occur only once" rather than simply "Mandatory"? ___ 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-idr-bgpls-segment-routing-epe-18
Reviewer: Joel Halpern 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-idr-bgpls-segment-routing-epe-18 Reviewer: Joel Halpern Review Date: 2019-04-06 IETF LC End Date: 2019-04-17 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC. Major issues: N/A Minor issues: N/A Nits/editorial comments: Section 3 begins "his section". I expect that should be "This section". ___ 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-pkix-shake-08
Reviewer: Joel Halpern 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-lamps-pkix-shake-08 Reviewer: Joel Halpern Review Date: 2019-03-30 IETF LC End Date: 2019-04-10 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as a Proposed Standard Major issues: One of the key points of this RFC seems to be to assign the identifiers for the use of the two SHAKE variants. It is thus confusing that the identifiers end with "TBD", and thus are not defined in this document. Minor issues: The algorithm identifiers are label as TVD. There are at least two values (one for SHAKE128 and one for SHAKE256) with each used in two context (RSASSA-PSS and ECDSA). It would be helpful if the two (or four) identifiers were labeled clearly TBD1 and TBD2 (and possibly TBD3 and TBD4). Nits/editorial comments: There is one use of "SHAKES" as the plural of SHAKE in section 5.1.1. All other uses are "SHAKEs", which seems to be correct. ___ 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-regext-bundling-registration-09
Reviewer: Joel Halpern 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-regext-bundling-registration-09 Reviewer: Joel Halpern Review Date: 2019-03-07 IETF LC End Date: 2019-03-15 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as some form of RFC Major issues: This document defines protocol extensions and mandatory procedures to go with them. As such, it seems it is either Experimental or Proposed Standard, but not Informational. Minor issues: Section 5 consists of a list of behavioral requirements that appear normative, but do not use RFC 2119 language. If these are indeed normative behavioral requirements, the document should use RFC 2119 language to be clear. (And therefore, should also include the text explaining and citing RFC 2119.) The description in 7.2.1 of the EPP command seems lacking. After saying that it needs an extension element, it says: The element SHOULD contain a child element that identifies the bundle namespace and the location of the bundle name schema. It is unclear when it is reasonable to omit this element. (We normally include with "SHOULD" explanations of this sort.) It is unspecified what format of the information in the element has. I suspect that it is assumed to be the same as some other piece of EPP information, but it does not say so. The only child element for given in the schema is the which is neither a namespace identifier nor a location of the bundle name schema. Again in 7.2.2 on the EPP command, when discussing the addition to the response, it is a SHOULD with no explanation of when it is okay to omit it. The same applies to the 7.2.3 EPP command, the 7.2.4 EPP command, and the 7.2.5 EPP command. Nits/editorial comments: ___ 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-trans-rfc6962-bis-31
Reviewer: Joel Halpern 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-trans-rfc6962-bis-31 Reviewer: Joel Halpern Review Date: 2019-03-01 IETF LC End Date: 2019-03-14 IESG Telechat date: 2019-03-14 Summary: This document is ready for publication as an Experimental RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-detnet-architecture-11
Reviewer: Joel Halpern 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-detnet-architecture-11 Reviewer: Joel Halpern Review Date: 2019-02-07 IETF LC End Date: 2018-10-03 IESG Telechat date: 2019-02-21 Summary: This Internet Draft is ready for publication as a Proposed Standard Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-hash-of-root-key-cert-extn-03
Reviewer: Joel Halpern 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-lamps-hash-of-root-key-cert-extn-03 Reviewer: Joel Halpern Review Date: 2019-01-04 IETF LC End Date: 2019-01-10 IESG Telechat date: Not scheduled for a telechat Summary: This draft is nearly ready for publication as an Informational RFC. Major issues: N/A Minor issues: The explanation at the end of section 5 about the remedy for losing access to the new root key left me confused. It looks like the situation is that there is a certificate out there, with the hash of root key extensions. The certificate owner loses access to the new key pair underlying the hash. The certificate owner clearly has to issue a new key pair. So far, so good. What the text seems to say is to simply issue a new self-signed certificate. There are two possibilities for what is intended. I think the idea is that the new certificate will use the existing key pair (not the promised one, nor another new one) for its own signature, and include a new hash of root key for the newly generated pair. If the certificate owner can do that (I have not dived into the rest of the certificate operations to figure out if that is legal) then it works. Please add some words explaining that better. If the certificate owner can not simply issue a new self-signed certificate with the existing key pair, then I am lost. It appears that the text says that the certificate owner issues a new self-signed certificate using a new key pair. But that will fail the check against the previous certificate hash of root key. I am hoping that it is the first of these alternatives, and all that is needed is clearer explanatory text stating that the new cert uses the existing key pair, and includes a new hash of root key promise. Nits/editorial comments: N/A ___ 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-cdn-loop-01
Reviewer: Joel Halpern 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-httpbis-cdn-loop-01 Reviewer: Joel Halpern Review Date: 2018-12-03 IETF LC End Date: 2018-12-11 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC There are two issues that I think should be addressed before publication Major issues: N/A Minor issues: This depends upon CDNs which have not been upgraded not stripping this header. While I can believe that is a reasonable assumption, it seems that a paragraph explaining that it is the case, and if possible what experience leads us to think it is the case, would be helpful. This document says that it is to protect against attackers causing loops. If the attacker is an external customer, the advice in the security considerations section makes sense. The other apparent attack would be an attacker in the network who strips the information each time it comes past. I believe the reason this is only an apparent attack is that such an attacker could almost as easily simply generate additional messages instead of producing a loop. If I have inferred this correctly, it seems useful to state it. Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-opsawg-ipfix-bgp-community-11
Reviewer: Joel Halpern 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-opsawg-ipfix-bgp-community-11 Reviewer: Joel Halpern Review Date: 2018-11-29 IETF LC End Date: 2018-09-24 IESG Telechat date: 2018-12-06 Summary: This document is ready for publication as a Proposed Standard RFC Major issues: N/A Minor issues: N/A Nits/editorial comments: As id-nits notes, references should not be included in the abstract. ___ 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-pce-segment-routing-14
Reviewer: Joel Halpern 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-pce-segment-routing-14 Reviewer: Joel Halpern Review Date: 2018-10-18 IETF LC End Date: 2018-10-29 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard RFC. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-anima-reference-model-08
Reviewer: Joel Halpern 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 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-anima-reference-model-08 Reviewer: Joel Halpern Review Date: 2018-10-11 IETF LC End Date: 2018-08-21 IESG Telechat date: 2018-10-25 Summary: This document is ready for publication as a Informational RFC. I appreciate the author's work in addressing my concerns. Major issues: N/A Minor issues: N/A Nits/editorial comments: The reference [IDevID] still appears to me to be a normative reference. In 3.3.3, the new parenthetical e.g. (replacing the wording "For example", seems to have no closing parenthesis. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-netmod-schema-mount-11
Reviewer: Joel Halpern 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 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-netmod-schema-mount-?? Reviewer: Joel Halpern Review Date: 2018-10-03 IETF LC End Date: 2018-06-29 IESG Telechat date: 2018-10-11 Summary: This document seems to meet the specific requirements for publication as a proposed standard. Major issues: It is still this reviewer's opinion that for a reader who has not been involved in the discussion in the working group, the document is quite unclear and confusing. For somewhat more details, please see my previous review at https://datatracker.ietf.org/doc/review-ietf-netmod-schema-mount-10-genart-lc-halpern-2018-06-28/ Minor issues: N/A Nits/editorial comments: N/A ___ 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-architecture-08
Reviewer: Joel Halpern 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-detnet-architecture-08 Reviewer: Joel Halpern Review Date: 2018-09-20 IETF LC End Date: 2018-10-03 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard I presume that the status was selected so as to avoid the need for downrefs when other Detnet documents normatively reference this one? Major issues: N/A Minor issues: Section 3.1 states that worst case delay for priority queueing is unbounded. That does not match my understanding. I know that DelayBound DSCP behavior tightly (although, I think, not as tightly as Detnet) limits both the worst case delay and the delay variation. It seems very odd that section 3.2.1.1 says that DetNet flows can not be throttled when earlier text says that DetNet flows do have a maximum bandwidth. Buried in section 4.3.2 I find that what is meant by throttled is not "enforcing a rate limit", but rather "sending congestion notification to cause the source to slow down." I think the wording about "can not be throttled" both in 3.2.1.1 and 4.3.2 should be adjusted for clarity. 3.2.1.1 also reads oddly in that it seems to recommend providing significant buffering, when the need for and use of such buffers is a major source of jitter. In section 4.1.2, I realized that the Detnet Transit node terminology had mildly confused me. The text says "DetNet enabled nodes are interconnected via transit nodes (e.g., LSRs) which support DetNet, but are not DetNet service aware." Reading this, and the definitions in section 2.1, it appears that a Detnet Transit node is a node that is providing transport behavior that detnet needs, but is not actually modified for detnet. Section 4.4.2 talks about per flow per node state. It would be good to have a forward reference to section 4.9 about scaling to larger networks. Nits/editorial comments: It would be good if there were some explanation for the 75% maximum number in section 3.3.1. That there is some limit seems intuitive. What value that limit has is not so obvious. Section 4.7.3 introduces an example using Ethernet Mulicast destiantions as part of labeling. There is no earlier explanation of the use of an Ethernet MAC Multicast destination, and the text does not seem to require that the traffic be actually multicast. Hence the reader is liable to be confused by the reference to multicast. I rate this only a nit as it seems clear that this is an example whose details are presumably explained in another document.Still, it would help to clarify the example. ___ 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-opsawg-ipfix-bgp-community-07
Reviewer: Joel Halpern 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-opsawg-ipfix-bgp-community-07 Reviewer: Joel Halpern Review Date: 2018-09-14 IETF LC End Date: 2018-09-24 IESG Telechat date: Not scheduled for a telechat Summary: This draft is ready for publication as a Proposed Standard Major issues: While I am still concerned (see my previous reviews) that this may well be the wrong answer to the wrong question, the authors have done a good job of explaining what they are doing and justifying why in some situations it will be useful. That seems the appropriate standard, and thus the document is ready for publication. Minor issues: Nits/editorial comments: ___ 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-anima-reference-model-06
Thanks Michael. That sounds like you are covering my concerns quite effectively. On the IDevID reference, all I think is needed is to change the IEEE reference to be normative instead of informative. (Or if Toerless' suggestion is effective in your view, change the text to say that IDevID is defined in a normatively referenced I-D instead of in the IEEE document.) Yours, Joel PS: Regarding copying i...@ietf.org, I think it is okay to have removed them now. Anyone outside the WG who wants to know about the conversation is aware that it is occurring. Because these are IETF LC comments, the initial comments need to go to the ietf list. On 8/11/18 10:36 AM, Michael H. Behringer wrote: Thanks Joel for the thorough review! Sorry for the delayed response, I was mostly offline on business travel. As Brian, I also took i...@ietf.org off the cc, please let me know if this is inappropriate, in which case I repost with that list on. Inline... On 10/08/2018 10:00, Joel Halpern wrote: Reviewer: Joel Halpern 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-anima-reference-model-06 Reviewer: Joel Halpern Review Date: 2018-08-09 IETF LC End Date: 2018-08-21 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as an Informational RFC. Clarity would be improved if the minor issues below were addressed. Major issues: N/A Minor issues: Section 2 includes "naming" in the list of services the ANI provides. Which surprised me. But then section 3 does not include "naming" in the list of services of the ANI in Figure 2 of section 3.1? Yes, naming is actually required for an autonomic solution. I understand your concern though, and added it to figure 2 and section 3.1. It's more consistent, you're right. In section 3.2, in the second paragraph on where adjacency information comes from, the text of the second bullet refers to vendor redirects. While I understand that those are an important part of the system information, they do not appear to create an adjacency? If they do, then the term adjacency needs to be better explained in this section. The first bullet in the next list says the same thing. My best guess is that adjacency sometime means actual topological adjacency, and sometimes means a more general form of adjacency. As written, I think it will confuse readers. Hmmm... I re-read our text, and I think it describes exactly what we want to say. :-) So there is clearly a problem. The original idea was that a new node with factory default settings needs to be able to find where it should connect. Since a factory default device cannot have specific information of its final network placement, the vendor MASA can be set up to provide information to the new node on where its home network is. I think we're probably in sync up to here. Now, our design decision was that this re-direct from the MASA should not require any other treatment than any other adjacency: It delivers an IP address to connect to, and to set up the ACP with. From this logic follows that the re-direct address is also entered into the adjacency table, and not treated in any "special" way. So, the real problem is probably the referernce to BRSKI, since this behaviour is not yet defined there. I suggest to simply remove the reference to BRSKI at this point. That seems to be the only confusing bit. And it allows potentially another document in the future to take up the details. I've taken it out for now. If anyone thinks that's a bad idea, shout! :-) IDevID (referenced in section 3.3.1 at least) appears to be a normative reference. Devices supporting the Anima Reference Model are required to support that, so understanding how to do so seems necessary for understanding this specification. I just read the entire discussion on this point, and am unsure what you would like us to do, or what the problem actually is. Can you be more specific? Does section 3.3.2 intend to mandate that devices have persistent storage for the LDevID? Or is it trying to say that on power cycle it stays in Enrolled state if it retains its LDevID, but goes back to the Factory default state if not? (Given that folks have repeatedly said that these may be low power devices, I think we need to be clear about what we are requiring.) Yes, your guess is absolutely right. I clarified that now by adding in the intro of section 3.3 (it affects the state machine in TWO poi
[Gen-art] Genart last call review of draft-ietf-anima-reference-model-06
Reviewer: Joel Halpern 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-anima-reference-model-06 Reviewer: Joel Halpern Review Date: 2018-08-09 IETF LC End Date: 2018-08-21 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication as an Informational RFC. Clarity would be improved if the minor issues below were addressed. Major issues: N/A Minor issues: Section 2 includes "naming" in the list of services the ANI provides. Which surprised me. But then section 3 does not include "naming" in the list of services of the ANI in Figure 2 of section 3.1? In section 3.2, in the second paragraph on where adjacency information comes from, the text of the second bullet refers to vendor redirects. While I understand that those are an important part of the system information, they do not appear to create an adjacency? If they do, then the term adjacency needs to be better explained in this section. The first bullet in the next list says the same thing. My best guess is that adjacency sometime means actual topological adjacency, and sometimes means a more general form of adjacency. As written, I think it will confuse readers. IDevID (referenced in section 3.3.1 at least) appears to be a normative reference. Devices supporting the Anima Reference Model are required to support that, so understanding how to do so seems necessary for understanding this specification. Does section 3.3.2 intend to mandate that devices have persistent storage for the LDevID? Or is it trying to say that on power cycle it stays in Enrolled state if it retains its LDevID, but goes back to the Factory default state if not? (Given that folks have repeatedly said that these may be low power devices, I think we need to be clear about what we are requiring.) Section 5 starts by saying that the administrator does not have to configure security. In the very next paragraph it says that a PKI must be in place. That clearly requires configuring some security properties. Please reword. Section 6.2 says that all ASA must "follow the same operating principles". The general guideliens of what these must cover is then given. It is appropriate that this document does not specify the detailed behavior. That would go in a standards track document. But there is no reference to a draft covering that. So we have text saying that all ASA must follow "something", but no reference as to the content of that "something". Is this a real requirement? If so, it appears to be unmeetable. Nits/editorial comments: In section 3.2, why would / could an adjacency table track "validity and trust of the adjacent autonomic node's certificate" if all transactions have to verify that separately anyway? Why mention it here? In the next to last bullet of the second bulleted list of section 3.2, the text states that the node will start a "join assistant" ASA. Could we have a forward reference to 6.3.1.2 (which then has the necessary normative reference)? The first use of LDevID in section 3.3.1 should have a forward reference to the definition (which I think is section 5.2.) Section 3.3.2 in defining when a device is in the Enrolled state says that it in the Enrolled state if it has an LDevID. As far as I can tell, the added constraint is that it is not currently a member of an ACP. The text should include that. The third paragraph of section 6.1 refers to the Autonomic nodes and the ASAs as "self-aware". I do not know what meaning is being ascribed to that phrase. The usage does not seem to correspond to any meaning I can understood. Can we just remove the sentence? (I suspect that the intention is to lead to the fact that the functions can advertise their capabilities, and negotiate them. We don't need the sentence as grounding for that.) While I appreciate the reference to SUPA in section 7.2, the working group having been terminated by the AD makes this a difficult topic for people to find. Presumably, PCIM should be an actual reference to the relevant RFC. Personal opinion: Section 8 on coordination is too hypothetical to be useful to a reader of this document. I think it is better removed. ___ 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-object-security-14
Reviewer: Joel Halpern 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-core-object-security-14 Reviewer: Joel Halpern Review Date: 2018-07-26 IETF LC End Date: 2018-07-30 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standqrd RFC My thanks to the authors for addressing my minor concerns. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-dnsop-session-signal-12
Reviewer: Joel Halpern 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-dnsop-session-signal-12 Reviewer: Joel Halpern Review Date: 2018-07-26 IETF LC End Date: 2018-06-25 IESG Telechat date: 2018-08-02 Summary: This document is ready for publication as a Proposed Standard My thanks to the authors and working group for addressing my comments. Major issues: N/A Minor issues: N/A Nits/editorial comments: N/A ___ 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-object-security-13
Reviewer: Joel Halpern 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-core-object-security-13 Reviewer: Joel Halpern Review Date: 2018-07-19 IETF LC End Date: 2018-07-30 IESG Telechat date: Not scheduled for a telechat Summary: this document is ready for publication as a Proposed Standard RFC. My minor concerns from draft -08 have been addressed. Major issues: N/A Minor issues: Section 7.2 is about sequence numbers. The first sentence in 7.2 discusses Nonces. Then the discussion switches to sequence numbers? My guess is that the Nonce is left over from previous text? Nits/editorial comments: In the first paragraph of 3.3, the text reads: The requirement that Sender ID SHALL be unique in the set of all security contexts using the same Master Secret, Master Salt, and ID Context guarantees unique (key, nonce) pairs, which avoids nonce reuse. Unfortunately, that is not a grammatical sentence. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-dnsop-session-signal-11
Reviewer: Joel Halpern 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 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-dnsop-session-signal-11 Reviewer: Joel Halpern Review Date: 2018-07-05 IETF LC End Date: 2018-06-25 IESG Telechat date: 2018-08-02 Summary: This document is ready for publication as a Proposed Standard RFC Some of my earlier comments have been addressed. It appears that an effort was made to address more, but I was apparently unclear. I have copied the comments that seem to still apply, with elaboration. If I am still unclear, please contact me. Major issues: N/A Minor issues: Section 5.1.3 places some requirements on application level middleboxes, and includes a very clear explanation of why it places these requirements. While it may be "obvious" to one who lives and breathes DNS, I think it would help to explain why the usual operation of an existing middlebox will (typically? always? inherently?) meet this requirement. To rephrase, the text says things like "the middlebox MUST NOT blindly forward DSO messages in either direction." Apparently, somehow, the existing world middleboxes will do comply with this. How? The third and fourth paragraphs of section 5.2.2 do not talk about optional additional TLVs. It would be helpful if the document stated that in addition to those additional TLVs required by the primary TLV, other TLVs may be included based on their individual definition, independent of the definition of the primary TLV. (Both the Encryption padding and the delay retry TLVs may be included in suitable messages without being called out in the definition of the primary TLVs.) An effort appears to have been made to address this, which suggests I was unclear. The text says: A DSO response message may contain no TLVs, or it may be specified to contain one or more TLVs appropriate to the information being communicated. The definition of the specific response messages does not discuss the encryption padding or delay response TLVs. They are clearly intended to be allowed. So can we tune the text to make that clear. I think the intention is that the specification of the response message indicates which TVLs are required, and that others are allowed. So say that. Nits/editorial comments: Section 5.4 talks about by default the TCP data ack and the DSO reply message being combined. Doesn't this depend upon the responsiveness of the DSO engine? Is there an implicit assumption about such timeliness (sub 200 ms)? I suspect from the lack of comment on this that I am missing something obvious? ___ 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-netmod-schema-mount-10
Reviewer: Joel Halpern 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-netmod-schema-mount-10 Reviewer: Joel Halpern Review Date: 2018-06-28 IETF LC End Date: 2018-06-29 IESG Telechat date: Not scheduled for a telechat Summary: This document is almost ready for publication as a Proposed Standards. I believe that the working group has gotten too close to the work, and failed to notice that important explanations that they understand do not actually appear in the document. Major issues: There is no explanation in the document as to who controls mounting and how it is specified. From this, I infer that the intention is that the server knows what is to be mounted at specific mount points, and does so. The Client does not tell the server to mount specific schemas in specific places. Ok. Say so. And explain that the server knows this by means external to the YANG modules. The text explicitly states that the case where the mount point definition selects the data model to be mounted is NOT supported by this document. There is some ambiguity, quite possibly only in this reader, as to what a client finds when it does a NETCONF Get at or below the mount point. I had assumed originally that it would find structure defined by the schema that is mounted there, as defined by the schema-mount container. However, the Schema-mount definition itself states that what is found at the mount point is an instance of YANG library. Given that this lefft me completely confused, please add some explanatory text? Minor issues: N/A Nits/editorial comments: The introduction, in its third paragraph refers to the "source or target YANG module" seeming to use both the term source and the term target to refer to the module with the uses or augments statement. Even if other YANG documents use both terms, this is a confusing construction. ___ 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-session-signal-10
Reviewer: Joel Halpern 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-dnsop-session-signal-10 Reviewer: Joel Halpern Review Date: 2018-06-15 IETF LC End Date: 2018-06-25 IESG Telechat date: Not scheduled for a telechat Summary: This document is ready for publication as a Proposed Standard. Also, the document is well-written and clear. Major issues: Minor issues: Section 5.1.3 places some requirements on application level middleboxes, and includes a very clear explanation of why it places these requirements. While it may be "obvious" to one who lives and breathes DNS, I think it would help to explain why the usual operation of an existing middlebox will (typically? always? inherently?) meet this requirement. The third and fourth paragraphs of section 5.2.2 do not talk about optional additional TLVs. It would be helpful if the document stated that in addition to those additional TLVs required by the primary TLV, other TLVs may be included based on their individual definition, independent of the definition of the primary TLV. (Both the Encryption padding and the delay retry TLVs may be included in suitable messages without being called out in the definition of the primary TLVs.) Nits/editorial comments: Section 5.4 talks about by default the TCP data ack and the DSO reply message being combined. Doesn't this depend upon the responsiveness of the DSO engine? Is there an implicit assumption about such timeliness (sub 200 ms)? In section 7.1, the description of the Keepalive message seems to be missing the explicit sentence that a keepalive response MUST contain a Keepalive TLV. I realize this is implicit in much of the description, but it seems a good practice to be clear about the requriement, and we should establish that practice in this document. (This would seem to belong in the next-to-last paragraph of section 7.1.) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-spring-segment-routing-ldp-interop-12
Reviewer: Joel Halpern 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-spring-segment-routing-ldp-interop-12 Reviewer: Joel Halpern Review Date: 2018-06-07 IETF LC End Date: 2018-05-24 IESG Telechat date: 2018-06-21 Summary: This document is ready to be published as a Proposed Standard The authors' additions of material to explain the SRMS both addresses by earlier concerns and provides sufficient motivation for publishing this as a PS. My thanks to the authors for their work. Major issues: Minor issues: Nits/editorial comments: ___ 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-spring-segment-routing-ldp-interop-11
Thank you. I apologize for missing the other normative items. With those, plus the elaboration on the SRMS, the status as PS makes good sense. Yours, Joel On 5/21/18 11:45 AM, Ahmed Bashandy wrote: Thanks a lot for the review The document specifies externally visible behavior that must be implemented by routers, otherwise SR and LDP routers cannot talk to each other. For example, section 4.2.2 specifies preference rules. Another example is the last two paragraphs in section 4.2.1. Hence I do not think it can be informational. A third example is section 4.2 which requires the existence of one SRMS in order for SR-only to speak to LDP-only routers But I agree that a more crisp description of SRMS is warranted. I will add a section describing the SRMS functionality and specifying what to do when receiving both prefix-SID sub-tlv and SRMS advertisements in the next version, which I plan to send out in the next few days Ahmed On 5/14/18 1:01 PM, Joel Halpern wrote: Reviewer: Joel Halpern 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-spring-segment-routing-ldp-interop-11 Reviewer: Joel Halpern Review Date: 2018-05-14 IETF LC End Date: 2018-05-24 IESG Telechat date: Not scheduled for a telechat Summary: This document appears to be ready for publication as an RFC. The question of whether it is an Informational RFC or a Proposed Standards track RFC is one that the ADs should examine. Major issues: This document is quite readable, and quite useful. If my reading below (minor comment about section 4.2) is wrong, then everything is fine. However, reading the text, it does not appear to define SRMS. Rather, it describes a good way to use SRMS to achive smooth SR - LDP integration and migration. As such, this seems to me to be a really good Informational Document. Minor issues: Section 4.2 states that it defines the SRMS (Segment Routing Mapping Server). Looking at the relevant routing protocol document, they point to https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the defining source for the SRMS. And that document does appear to define the SRMS. Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [spring] Genart last call review of draft-ietf-spring-segment-routing-ldp-interop-11
I meant "this" (the document under review), not "that" (conflict-resolution). Since the other documents I found indicated that conflict resolution defined it, I assumed it did.Given that conflict-resolution is a dead document, something needs to actually define the SRMS. Yours, Joel On 5/14/18 4:32 PM, Les Ginsberg (ginsberg) wrote: Joel - I don’t fully understand the rest of your comment then. You said: " And that document does appear to define the SRMS." (where "that document" refers to draft-ietf-spring-conflict-resolution). But the conflict resolution document never defined an SRMS - it merely described how SRMS advertisements were used in the context of conflict resolution. So if you are unsatisfied with the "SRMS definition" in ldp-interop draft I think you need to be more clear as to what you think is lacking. I leave it to the draft authors to resolve this issue with you. Les -Original Message- From: Joel Halpern Direct Sent: Monday, May 14, 2018 1:16 PM To: Les Ginsberg (ginsberg) ; Joel Halpern ; gen-art@ietf.org Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org; spr...@ietf.org; i...@ietf.org Subject: Re: [spring] Genart last call review of draft-ietf-spring-segment- routing-ldp-interop-11 Thanks Les. I wondered if that were the case. Looking again at the draft, the problem then is that section 4.2 of the subject draft is not a normative definition of an SRMS. It states the general functionality, and then provides an example of how it would work in the given scenario. If the text were enhanced to be an effective normative definition of an SRMS, then that would also resolve the quesiton of the intended status of the draft. Yours, Joel On 5/14/18 4:12 PM, Les Ginsberg (ginsberg) wrote: Joel - I am not an author of this draft - but I am an author on the referenced IS-IS draft - which I assume is one of the drafts mentioned in your comment: Server). Looking at the relevant routing protocol document, they point to https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the defining source for the SRMS. The IGP document references in the ldp-interop draft are stale. Newer versions of the IGP drafts have been published and they no longer reference draft-ietf-spring-conflict-resolution - a draft which is no longer active. HTH Les -Original Message- From: spring On Behalf Of Joel Halpern Sent: Monday, May 14, 2018 1:01 PM To: gen-art@ietf.org Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org; spr...@ietf.org; i...@ietf.org Subject: [spring] Genart last call review of draft-ietf-spring-segment-routing- ldp-interop-11 Reviewer: Joel Halpern 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-spring-segment-routing-ldp-interop-11 Reviewer: Joel Halpern Review Date: 2018-05-14 IETF LC End Date: 2018-05-24 IESG Telechat date: Not scheduled for a telechat Summary: This document appears to be ready for publication as an RFC. The question of whether it is an Informational RFC or a Proposed Standards track RFC is one that the ADs should examine. Major issues: This document is quite readable, and quite useful. If my reading below (minor comment about section 4.2) is wrong, then everything is fine. However, reading the text, it does not appear to define SRMS. Rather, it describes a good way to use SRMS to achive smooth SR - LDP integration and migration. As such, this seems to me to be a really good Informational Document. Minor issues: Section 4.2 states that it defines the SRMS (Segment Routing Mapping Server). Looking at the relevant routing protocol document, they point to https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the defining source for the SRMS. And that document does appear to define the SRMS. Nits/editorial comments: ___ spring mailing list spr...@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [spring] Genart last call review of draft-ietf-spring-segment-routing-ldp-interop-11
Thanks Les. I wondered if that were the case. Looking again at the draft, the problem then is that section 4.2 of the subject draft is not a normative definition of an SRMS. It states the general functionality, and then provides an example of how it would work in the given scenario. If the text were enhanced to be an effective normative definition of an SRMS, then that would also resolve the quesiton of the intended status of the draft. Yours, Joel On 5/14/18 4:12 PM, Les Ginsberg (ginsberg) wrote: Joel - I am not an author of this draft - but I am an author on the referenced IS-IS draft - which I assume is one of the drafts mentioned in your comment: Server). Looking at the relevant routing protocol document, they point to https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the defining source for the SRMS. The IGP document references in the ldp-interop draft are stale. Newer versions of the IGP drafts have been published and they no longer reference draft-ietf-spring-conflict-resolution - a draft which is no longer active. HTH Les -Original Message- From: spring On Behalf Of Joel Halpern Sent: Monday, May 14, 2018 1:01 PM To: gen-art@ietf.org Cc: draft-ietf-spring-segment-routing-ldp-interop@ietf.org; spr...@ietf.org; i...@ietf.org Subject: [spring] Genart last call review of draft-ietf-spring-segment-routing- ldp-interop-11 Reviewer: Joel Halpern 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-spring-segment-routing-ldp-interop-11 Reviewer: Joel Halpern Review Date: 2018-05-14 IETF LC End Date: 2018-05-24 IESG Telechat date: Not scheduled for a telechat Summary: This document appears to be ready for publication as an RFC. The question of whether it is an Informational RFC or a Proposed Standards track RFC is one that the ADs should examine. Major issues: This document is quite readable, and quite useful. If my reading below (minor comment about section 4.2) is wrong, then everything is fine. However, reading the text, it does not appear to define SRMS. Rather, it describes a good way to use SRMS to achive smooth SR - LDP integration and migration. As such, this seems to me to be a really good Informational Document. Minor issues: Section 4.2 states that it defines the SRMS (Segment Routing Mapping Server). Looking at the relevant routing protocol document, they point to https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the defining source for the SRMS. And that document does appear to define the SRMS. Nits/editorial comments: ___ spring mailing list spr...@ietf.org https://www.ietf.org/mailman/listinfo/spring ___ 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-spring-segment-routing-ldp-interop-11
Reviewer: Joel Halpern 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-spring-segment-routing-ldp-interop-11 Reviewer: Joel Halpern Review Date: 2018-05-14 IETF LC End Date: 2018-05-24 IESG Telechat date: Not scheduled for a telechat Summary: This document appears to be ready for publication as an RFC. The question of whether it is an Informational RFC or a Proposed Standards track RFC is one that the ADs should examine. Major issues: This document is quite readable, and quite useful. If my reading below (minor comment about section 4.2) is wrong, then everything is fine. However, reading the text, it does not appear to define SRMS. Rather, it describes a good way to use SRMS to achive smooth SR - LDP integration and migration. As such, this seems to me to be a really good Informational Document. Minor issues: Section 4.2 states that it defines the SRMS (Segment Routing Mapping Server). Looking at the relevant routing protocol document, they point to https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-05 as the defining source for the SRMS. And that document does appear to define the SRMS. Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-teas-sr-rsvp-coexistence-rec-03
Reviewer: Joel Halpern 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 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-teas-sr-rsvp-coexistence-rec-03 Reviewer: Joel Halpern Review Date: 2018-04-26 IETF LC End Date: 2018-04-20 IESG Telechat date: 2018-05-10 Summary: This document is ready for publication as a Proposed Standard Major issues: N/A Minor issues: As noted in my email response to this document revision, the authors have responded to my earlier comments. While I think there are significant regards in which the document should be clearer, and would be helped by such increased clarity, it is technically correct and publishable as is. Nits/editorial comments: N/A ___ 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-teas-sr-rsvp-coexistence-rec-02
Reviewer: Joel Halpern 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-teas-sr-rsvp-coexistence-rec-02 Reviewer: Joel Halpern Review Date: 2018-04-19 IETF LC End Date: 2018-04-20 IESG Telechat date: 2018-05-10 Summary: Major issues: The focus of the draft seems to be the recommendation in section 3.5 that the maximum reservable bandwidth on a link be adjusted to reflect the SR traffic consumption. There appear to be two issues that need to be discussed, both related to the difference between what the SR controller wants to reserve and what the router observes. First, an SR controller may be performing calculations without requiring that bandwidth be committed to the traffic. The recommendation here assumes that all traffic using SR is high priority. It may suffice to note that QoS markings in the labels (corresponding to diffserv markings in the underlying packet may hel with this. Given the range of allowed behaviors in when RSVP-TE and SR are separate, it may also be necessary to restrict what the SR controllers do in these interworking cases. Second, and more importantly, this solution assumes that short term traffic measurements are a good proxy for intended reservation. Even assuming edge policing so that usage is less than or equal to the reservation, this will frequently underestimate the traffic reservation. Such underestimates would seem to be able to cause significant problems. Minor issues: Section 3.5 assumes that the router can measure the traffic using SR. This seems to rely on the unstated premise that the measurement is conditioned by the recognition of which labels are being used for SR. This is reasonable. It should be stated. Nits/editorial comments: The second paragraph of the introduction seems to have the opening text repeated twice. The third paragraph of section 3.1 seems to be a repetition of the end of the second paragraph using slightly different words. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Rtgdir early review of draft-ietf-opsawg-ipfix-bgp-community-06
Reviewer: Joel Halpern Review result: Not Ready This is both a gen-art re-review and a routing directorate requested review. The revisions from draft-04 to -06 show some improvement. However, I still have serious problems with this work. The primary problem is that this seems to violate the designed work distribution in the IPFIX architecture. The draft itself notes that the correlation requested could be done in the collector. Which is where correlation is designed to be done. Instead, it puts a significant new processing load on the router that is delivering the IPFIX information. For example, if one delivers IPFIX from the router data plane, one either has to modify the router architecture to include additional complex computed information in the data plane architecture (a bad place to add complexity) or one has to give up and move all the information through the control plane. And even the control plane likely has to add complexity to its RIB logic, as it has to move additional information from BGP to the common structures. The secondary problem is that this additional work is justified for the router by the claim that the unusual usage of applying community tags for geographical location of customers is a common practice. It is a legal practice. And I presume it is done somewhere or the authors would not be asking for it. But it is not common. In short, since even the draft admits that this is not needed, I recommend against publishing this document as an RFC. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-uta-smtp-tlsrpt-18
Reviewer: Joel Halpern 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-uta-smtp-tlsrpt-18 Reviewer: Joel Halpern Review Date: 2018-04-05 IETF LC End Date: 2018-04-02 IESG Telechat date: 2018-04-19 Summary: This document is ready for publication as a Proposed Standard RFC My thanks to the authors for addressing my major concerns and most of my minor concerns. Major issues: Minor issues: There are several areas where the document would be helped by better explanations. From my previous review: Section 3, bullet 3, says that submitters using POST can ignore certificate validation errors when using https. That seems to undermine the usage of https. As such, I would expect to at least see some explanation of when and why ignoring such errors is appropriate. It is surprising in Section 3 Bullet 4 that reporting via email requires that the report submitted use DKIM. Particularly while ignoring any security errors in communicating with the recipient domain. In the formal definition of the txt record, shouldn't the URI format also indicate that semicolon needs to be encoded? Section 5.1 defines a report filename. This is probably a naive question, but what is that for? If using HTTPS, the earlier text says that the POST operation goes to the target URI from the txt record. When using email, there is no apparent need for a filename. Most of the security risks described in the Security section (7) do not seem to have any mitigation. Should there not be some explanation why deployment is acceptable with these risks? Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
