Re: [Gen-art] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15
On Tue, 18 Feb 2020 at 12:43, David Schinazi wrote: > > Hi Erik, > > Thank you for your review. Responses inline. > > Thanks, > David > > > On Mon, Feb 17, 2020 at 4:38 PM Erik Kline via Datatracker > wrote: > [snip] >> >> Are any of the recommendations for client resolvers in this document >> covered the IPR (https://datatracker.ietf.org/ipr/3077/) claimed for: >> >> https://tools.ietf.org/html/rfc8305#section-7 >> >> (which has some similar/related recommendations, especially 7.3)? > > > I was also an author on RFC 8305 and IPR claim 3077, but I am not a lawyer. > Speaking as an individual, I am not aware of any IPR related to > draft-cheshire-sudn-ipv4only-dot-arpa-15. > Apologies for the disclaimer, but if you're trying to ascertain whether a > specification is covered by a patent, I would suggest contacting a lawyer. I believe you, as an author, will have to assert that all applicable IPR declarations of which you are aware (here you're saying, "there are none") have been declared. I was just reminded of this one, in case you'd not thought about it in a while. I haven't read it, but I had presumed you had. >> Otherwise, I think this is basically ready, with just a few random nits >> noted below (and ignoring the jeremiad-esque tone about the >> design/implications of the middlebox protocol nature of RFC 7050 ;-). >> >> Major issues: >> >> Minor issues: >> >> Nits/editorial comments: > > > I have a PR that attempts to address these editorial comments here: > https://github.com/StuartCheshire/draft-cheshire-sudn-ipv4only-dot-arpa/pull/1/files > >> >> [ abstract ] >> * 3rd para could be removed for brevity (but keep same in the intro) > > > Done > >> [ 4.1 ] >> >> * Consider whether to including references to 1.1, 8.8, and 9.9 >> services. I think the following might suffice: >> >> 1.1.1.1 https://1.1.1.1 >> 8.8.8.8 https://developers.google..com/speed/public-dns/ >> 9.9.9.9 https://quad9.net/ > > > Done > >> * s/is is/it is/ > > > Done > >> >> [ 6 ] >> I'm not sure I follow the logic about whether/why ipv4only.arpa >> must not be a signed zone. It seems to me that the concluding >> paragraph beginning with 'Consequently, ...' actually lays out >> the rationale in the most straightforward manner in this section. >> >> It's a nice TL;DR, but I'm not sure how to formulate a useful >> recommendation for reflowing text to better highlight this. > > > I'm not sure how to act on this comment. Can you suggest text? I could not. I was just noting that it took me several readings of this section to grok what I thought was the point, and that the nice TL;DR was here at the bottom of the section. I don't think it needs any fixing, though. >> [ 8.1 ] >> Consider referring to RFC 8499 for DNS terminology, if that improves >> the descriptions of types of resolvers. > > > Added a reference to 8499. > ___ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-cheshire-sudn-ipv4only-dot-arpa-15
Reviewer: Erik Kline 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-cheshire-sudn-ipv4only-dot-arpa-?? Reviewer: Erik Kline Review Date: 2020-02-17 IETF LC End Date: 2020-02-17 IESG Telechat date: Not scheduled for a telechat Summary: Are any of the recommendations for client resolvers in this document covered the IPR (https://datatracker.ietf.org/ipr/3077/) claimed for: https://tools.ietf.org/html/rfc8305#section-7 (which has some similar/related recommendations, especially 7.3)? Otherwise, I think this is basically ready, with just a few random nits noted below (and ignoring the jeremiad-esque tone about the design/implications of the middlebox protocol nature of RFC 7050 ;-). Major issues: Minor issues: Nits/editorial comments: [ abstract ] * 3rd para could be removed for brevity (but keep same in the intro) [ 4.1 ] * Consider whether to including references to 1.1, 8.8, and 9.9 services. I think the following might suffice: 1.1.1.1 https://1.1.1.1 8.8.8.8 https://developers.google.com/speed/public-dns/ 9.9.9.9 https://quad9.net/ * s/is is/it is/ [ 6 ] I'm not sure I follow the logic about whether/why ipv4only.arpa must not be a signed zone. It seems to me that the concluding paragraph beginning with 'Consequently, ...' actually lays out the rationale in the most straightforward manner in this section. It's a nice TL;DR, but I'm not sure how to formulate a useful recommendation for reflowing text to better highlight this. [ 8.1 ] Consider referring to RFC 8499 for DNS terminology, if that improves the descriptions of types of resolvers. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart telechat review of draft-ietf-bfd-vxlan-09
Reviewer: Erik Kline 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-bfd-vxlan-?? Reviewer: Erik Kline Review Date: 2019-12-16 IETF LC End Date: None IESG Telechat date: 2019-12-19 Summary: -09 addresses my concerns from -07. Thank you for this. The one "nit" is that it seems to have introduced a recommendation to use :::7f00:0/104 as an IPv6 loopback prefix. (a) This document should follow the format recommendations of RFC 5952 section 4.3 and lowercase the "F"s. But (b) more importantly, I'm not sure how implementations may treats this space. The use of an RFC4291 section-2.5.5.2 mapped v4 address doesn't necessarily make the packet a part of an IPv6 connection. Nevertheless, I'm not sure I have a strong feeling about this as it may still exercise enough of the IPv6 stack in a VTEP. I definitely do think that in the case of BFD on the management VNI targeting an IPv6 link-local address of the VTEP would be better. However, I expect that if :::127.0.0.0 does prove to have some issues in the future a -bis can be written quickly with a recommendation. Also, Suresh may have ideas for a solution. Major issues: Minor issues: 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-opsec-v6-21
Reviewer: Erik Kline 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-opsec-v6-21 Reviewer: Erik Kline Review Date: 2019-12-02 IETF LC End Date: 2019-12-02 IESG Telechat date: Not scheduled for a telechat Summary: This is very large survey of applicable security text and RFCs. I think it's a good entry point for an operator starting out. I captured lots of nits, but most of them are extremely minor wording questions. Major issues: Minor issues: Nits/editorial comments: - in general - Several links that are meant to be other_rfc#section_X.Y.Z render instead as this_document#section_X.Y.Z (in the tools.ietf.org rendering). - Abstract ? "several places of a network" --> "several types of networks" ? "procedural mitigations techniques" --> "procedural mitigation techniques" - It's not clear if RFC 2119 text is needed for this document as it is now. - 2.1 ? "abundance of address space available" --> "abundance of address space is available" - 2.1.5 - Could perhaps more explicitly state that DHCPv6 is not mandatory to implement per IPv6 Node Requirements (RFC 8504). - 2.1.6 ? "are specific consideration" --> "are specific considerations" - 2.2 - One might quibble with the statement "the extension header chain must be be parsed completely". It has to be parsed enough so that it can be completely traversed, but it need not necessarily be parsed in a way that a node has to "understand" the contents -- this is how the extension headers are designed, after all. Regrettably, no better wording comes to mind, so I have no specific recommendation for what could be done here. - 2.3.2 ? "either intentional or malicious" --> "either unintentional or malicios" (not quite sure) - This section could have a callback to 2.1.7 as a possible solution (toward the end, where it talks about host isolation) as this can also solve these problems. (A forward link to 2.3.4 might be good too, since this is philosophically similar.) - 2.4 ? "number of Dijsktra execution" --> "number of Dijsktra executions" - 2.4.1 ? "configured such as" --> "configured so as to" - 2.4.2 - With the mention of NTP I suddenly thought: should there be DNS-related text as well, or does that fall within this section too? - 2.4.3 ? "Both the save" --> "Both to spare" - 2.5.3 - The CYMRU link doesn't seem to go to a useful page anymore. :-/ - 2.6 - SNMP is mentioned (eslewhere too). Should YANG/NETCONF/RESTCONF also get a gratuitous reference? - Same question for DIAMETER vis a vis RADIUS. - 2.6.1.5 ? "operation security" --> "operational security" - 2.6.2.2 ? "in some case" --> "in some cases" ? "can sometime be" --> "can sometimes be" - 2.6.2.3 - Even though section 2.6.1.1 already references RFC 5952 as the current recommended canonical string format, this section could link to it as well (just in case a reader has followed a deep link into this section and hasn't read anything else). - 2.7.1 - Perhaps "you have twice" --> "the network operator has twice". ? "more relax security" --> "more relaxed security" - 2.7.2 ? "no more automated in most environment" --> "no longer automatic in most environments" - 2.7.2.7 ? "is no more used by" --> "is no longer used by" - 2.7.2.8 - If UDP filtering guidelines are to be listed here (even parenthetically), you might include UDP 443 for QUIC, 500 for IKE, and 3478 for STUN. Maybe just replace "block all" with something like "filter all judiciously" or something. ? "no more enabled" --> "no longer enabled" - 2.7.3.1 ? "and effective" --> "an effective" - 3.2 ? "IPv6-in-IP4" --> "IPv6-in-IPv4" - There appears to be a broken internal reference to, I presume, section 2.8? ? "using IP4" --> "using IPv4" - Since this section mentions filtering at the Internet connection, should it also have a reference
[Gen-art] Genart last call review of draft-ietf-httpbis-http2-tls13-02
Reviewer: Erik Kline 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-http2-tls13-?? Reviewer: Erik Kline Review Date: 2019-10-12 IETF LC End Date: 2019-10-11 IESG Telechat date: 2019-10-17 Summary: LGTM; ready. Major issues: none Minor issues: none 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-pce-stateful-pce-auto-bandwidth-10
Reviewer: Erik Kline 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-pce-stateful-pce-auto-bandwidth-10 Reviewer: Erik Kline Review Date: 2019-08-27 IETF LC End Date: 2019-08-28 IESG Telechat date: Not scheduled for a telechat Summary: Gentle reminder for the authors to double-check all the lower case "should"s, "required"s, and "must not"s (etc) to make sure it's not important that they be capitalized (since the case-sensitive requirements text is referenced). Major issues: Minor issues: Nits/editorial comments: There are some periodic grammatical changes that I think would be nice, but I assume that can get sorted out with the RFC editor. Two random things I'll note: Section 1> I can't find "Path Control Element" in RFC 5440. Should this be "Path Computation Element"? Section 5.2> . s/speaker wish to disable/speaker wishes to disable/ . s/of same type/of the same type/ ___ 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-ospf-yang-23
Reviewer: Erik Kline 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-ospf-yang-?? Reviewer: Erik Kline Review Date: 2019-07-17 IETF LC End Date: 2019-07-17 IESG Telechat date: Not scheduled for a telechat Summary: Major issues: Minor issues: I feel like the "version" text in 2.3 was confusing. The first thing I did was glance back up the overview where I (a) didn't see "version" mentioned and (b) initially thought that "af" was maybe a proxy for "version". But then later on it seems that "version" is only a mandatory property of the LSA. I'm not sure that I have concretely useful suggestions for improving this text, and in fact it might well be that for expected readers of the document this is in fact a non-issue. Just thought I'd relay my experience. Nits/editorial comments: Page 25: NMDA RFC is 8342, not 8242. Page 81: references draft-ietf-bdf-yang-xx.txt. This is referenced elsewhere in the doc (correctly), so I think just remove the -xx may be 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-bfd-vxlan-07
Reviewer: Erik Kline Review result: On the Right Track I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-bfd-vxlan-07 Reviewer: Erik Kline Review Date: 2019-05-27 IETF LC End Date: 2019-05-31 IESG Telechat date: Not scheduled for a telechat Summary: If my understanding is correct (which it may well not be), this document places restrictions on the inner Ethernet and IP layer deployment that previously may not have been present. My reading if this document is that the outer IP header and the inner IP header have the same VTEP src and dst IPs. The outer and inner Ethernet headers have the same source MAC and may have the same dst MAC. Is this correct? If so, this would mean that the VTEP's MAC address (or the special dest MAC) cannot be used within the VXLAN network (or at least not on the same host. Similarly, it appears that the VTEP's IP addresses are no longer free to be used within the encapsulated VXLAN VNI. Do I understand this correctly? Was this always the case? If there is a document defining restrictions that VTEPs place on the inner VXLAN segment, that might be good to reference. Failing that, I think I would like to see some discussion of alternatives that were rejected with reasons behind their rejection. One possible solution might be to use "impossible" Ethernet addresses and "impossible" IP addresses in the inner packet. For example, a source IP address of all ones or all zeros would be very unlikely to ever be a valid IP packet. I'm not 100% sure, but I suspect that a source MAC of all ones would also never really be treated as valid. Clever use of multicast IP and Ethernet addresses in the source fields might also be sufficient to render the inner packet "invalid" in the sense that it would never collide with legitimate traffic. If I have misread this document, or VTEPs are already placing constraints on the inner VXLAN environment similar to those above, then this review should instead be treated as "Ready with Nits". Major issues: Only my concern/misunderstanding described above. Minor issues: None. Nits/editorial comments: * The document generally does a really good job of Expanding Acronyms At First Use (EAAFU) -- very much appreciated. In section 1 though, NVE is used without accompanying expansion, I think. * There is no 4.2 so maybe sections 4 and 4.1 could just be section 4. ___ 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-isis-segment-routing-extensions-23
Reviewer: Erik Kline 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-isis-segment-routing-extensions-?? Reviewer: Erik Kline Review Date: 2019-04-17 IETF LC End Date: 2019-04-17 IESG Telechat date: Not scheduled for a telechat Summary: For what little I know of IS-IS and segment routing, this all seems to make general sense. I simply had some language/style nits (below). Major issues: Minor issues: Nits/editorial comments: # Section 1 * "SR's control-plane can be applied ..., and do not require...". It looks like the subject of the sentence is "control-plane" and so perhaps "do not" should be "does not". * s/draft/document/g # Section 2.1 * "Algorithms identifiers" -> "Algorithm identifiers" # Section 2.2.2 * Length: variable Should this say "11-12" (1 + 1 + 6 + 3-4)? * "set of Adj-SID each router" -> "set of Adj-SIDs each router", perhaps. # Section 2.3 s/valu eis/value is/ # Section 2.4 Silly, naive question: does the length include the sum of the octets representing the sub-TLVs? # Section 2.4.6 In example 3, I would recommend s/0xD/0x0D/ & s/0x0/0x00/ & s/0x1/0x01/ , but perhaps that's just a personal readability thing. # Section 3.3 * "by other components than" -> "by components other than", perhaps. * "to know what are the local SIDs" -> "to know what the local SIDs are", perhaps. * "The SRLB sub-TLV is used for this purpose...", (instead of "that purpose") maybe. * "which mechanisms are outside" -> "which are outside", maybe. * "the SRLB TLV" -> "the SRLB sub-TLV", I think. ___ 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-nottingham-rfc5785bis-08
On Wed, 6 Feb 2019 at 06:39, Barry Leiba wrote: > > > > [3] Naive question: do we want a statement about reserving/agreeing to > > > never > > > allocate "example" in the .well-known space? > > > > Good question! I'm neutral on this; does anyone have strong feelings? > > I wouldn't say my feelings are strong, but I think it's unnecessary. > The reason we have IP addresses and domain names set aside for example > use is that otherwise anything we put in documents might wind up in > actual use and result in nuisance traffic or worse. If we publish an > example of .well-known in some document and decide to use "frobozz" > for the example, and "frobozz" some day winds up in actual use, what's > the harm. > > Also, how useful is it to have exactly one example string? Maybe we'd > need to assign anything that begins with "example-" as a reserved > string. And then we're not far from "X-", and we know where that got > us.[RFC6648] Fair enough. Mark used example.com-metadata in the doc, IIRC, which I think makes it pretty clear that the example space is plenty large enough. Thanks. ___ 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-idr-te-pm-bgp-15
On Thu, 13 Dec 2018 at 00:26, Les Ginsberg (ginsberg) wrote: > Erik - > > Thanx for the review. > Responses inline. > > > -Original Message- > > From: Erik Kline > > Sent: Wednesday, December 12, 2018 11:30 PM > > To: gen-art@ietf.org > > Cc: i...@ietf.org; i...@ietf.org; draft-ietf-idr-te-pm-bgp@ietf.org > > Subject: Genart last call review of draft-ietf-idr-te-pm-bgp-15 > > > > Reviewer: Erik Kline > > 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-idr-te-pm-bgp-?? > > Reviewer: Erik Kline > > Review Date: 2018-12-12 > > IETF LC End Date: 2018-12-12 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: Seems like a fairly straightforward detailing of TLVs the > meanings > > of > > which are defined elsewhere. > > > > Major issues: [obvious] A primary normative reference is itself still a > draft. > > I expect they'll get published together. > > > [Les:] The reference to draft-ietf-lsr-isis-rfc7810bis (rather than > current RFC7810) was put in at the request of the AD. > You are correct that this introduces a dependency between this document > and 7810bis and this document will remain in MISSREF state until 7810bis is > published. > As both drafts are in the review process we do not expect there to be a > significant delay. > > In any case this isn't a "major" issue is it? It seems worthwhile to have > the reference be to the newer version of 7810 - and this certainly isn’t > the only case where one document is dependent on another which has yet to > be published. > > > Not a major issue for me; I marked the document as Ready with Nits. I just felt like "major" was the section where this trivially obvious observation would belong. > > Minor issues: None. > > > > Nits/editorial comments: Some wording on Section 3 could use some > > readability > > cleanup, perhaps. > > > > [1] "represent the state and resources availability" does not somehow > scan > > well > > for me. "state and resource availability"? "state and availability of > > resources"? > > > [Les:] "state and resource availability" is fine with me. > > > [2] "are assumed to have all the required security and authentication > > mechanism" also seems like it could read more smoothly. "are assumed to > > have > > implemented all require security and authentication mechanisms..."? > > > [Les:] How about "assumed to support all the required..." > ?? > > If you are OK with the suggestions I will publish an updated version very > soon. > >Les > > Anything is fine. I think it just read ~funny~ to me, grammatically. "assumed to meet all security and authentication requirements", sounds good. > > I'm sure the editors will have better ideas. > > > > ___ 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-te-pm-bgp-15
Reviewer: Erik Kline 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-idr-te-pm-bgp-?? Reviewer: Erik Kline Review Date: 2018-12-12 IETF LC End Date: 2018-12-12 IESG Telechat date: Not scheduled for a telechat Summary: Seems like a fairly straightforward detailing of TLVs the meanings of which are defined elsewhere. Major issues: [obvious] A primary normative reference is itself still a draft. I expect they'll get published together. Minor issues: None. Nits/editorial comments: Some wording on Section 3 could use some readability cleanup, perhaps. [1] "represent the state and resources availability" does not somehow scan well for me. "state and resource availability"? "state and availability of resources"? [2] "are assumed to have all the required security and authentication mechanism" also seems like it could read more smoothly. "are assumed to have implemented all require security and authentication mechanisms..."? I'm sure the editors will have better ideas. ___ 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-op3ft-leaptofrogans-uri-scheme-03
On Tue, 13 Nov 2018 at 20:23, Dale R. Worley wrote: > > Erik Kline writes: > > Nits/editorial comments: I can't help but wonder if an example or two > > wouldn't > > round out the document. But maybe leaptofrogans: URIs/IRIs aren't amenable > > to > > constructing an example? > > I agree in principle with this. Looking at reference [IFAP], here are > two examples: > > leaptofrogans:mynetwork*mysite > leaptofrogans:my-network*MySite > > The syntax of frogan addresses is very carefully specified, but most of > the work seems to revolve around using Unicode well: Frogans are fully > internationalized, so there's a lot of work in [IFAP] specifying how to > use Unicode so that an address aligns with the intuitive sense of "a > text string". > > But beyond the fact that a frogan address is split into two parts by a > "*" character, there isn't much syntax that's easily displayed by a > series of ASCII examples. I understand about the limitations of the current RFC format w.r.t. non-ASCII characters (but I suspect you wouldn't want to wait for the new format to be readily available :-). FWIW I think those two examples would be perfectly fine. They may not seem overly expressive or especially illustrative, but including them might scratch an itch for some readers. But it's certainly not anything worth holding up publication for, IMHO. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Genart last call review of draft-op3ft-leaptofrogans-uri-scheme-03
Reviewer: Erik Kline 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-op3ft-leaptofrogans-uri-scheme-?? Reviewer: Erik Kline Review Date: 2018-11-12 IETF LC End Date: 2018-11-13 IESG Telechat date: Not scheduled for a telechat Summary: Seems perfectly fine to me, though (per nit below) one or two examples might help a reader unfamiliar with Frogans (such as myself). URI vs IRI seems consistent with my current understanding. Major issues: Minor issues: Nits/editorial comments: I can't help but wonder if an example or two wouldn't round out the document. But maybe leaptofrogans: URIs/IRIs aren't amenable to constructing an 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-netconf-rfc7895bis-06
Reviewer: Erik Kline 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-netconf-rfc7895bis-06 Reviewer: Erik Kline Review Date: 2018-06-30 IETF LC End Date: 2018-06-28 IESG Telechat date: Not scheduled for a telechat Summary: ready Major issues: none Minor issues: none Nits/editorial comments: Conceptually, the "checksum" isn't a checksum so much as just a unique identifier. The text in Section 3 text generally seems to acknowledge this (even using checksum in quotation marks), and so I'm left wondering whether "checksum" is really the best name. I've no strong opinion, just this observation, and nothing that should impede this document (I assume bike-shedding may have already occurred). Section 2, item 4 "more than one datastores" -> "more than one datastore". Section 4, I believe ietf-datastores reference can be updated to RFC 8342, if I understand things correctly. Section 4, Author list entry for Rob Wilton lacks "mailto:; before the email address. ___ 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-replay-02
Reviewer: Erik Kline Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-httpbis-replay-02 Reviewer: Erik Kline Review Date: 2018-04-23 IETF LC End Date: 2018-04-23 IESG Telechat date: Not scheduled for a telechat Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. These nits are mostly about satisfying my ignorance. Major issues: None Minor issues: None Nits/editorial comments: [1] Some bibliography are to old versions (TLS1.3 links to v21, current is v28). I assume that’ll just "fix itself" before publication. =) [2] Section 3, paragraph 1: not just session cookie, but non-zero max_early_data_size option? I couldn’t find explicit mention of max_early_data_size = 0 in TLS13v28, so perhaps it can’t be sent? [3] Section 3, paragraph LAST-1: “even if the server rejects the request” scans awkwardly to me in the context of "requests" in the first half of the sentence. “Even if the server ultimately rejects *one or more* of the requests by sending a 425...”? Perhaps I'm completely misreading something. [4] Section 4, paragraph 4: after “or if the same server accepts early data multiple times“ is there an implied “for the same session ticket” in the mind of the expected reader? Not sure if adding that is clarifying or redundant. [5] Section 6.1: “SHOULD disable early data” refers to connections toward servers (or next hops) or toward clients (or previous hops) or both? (I’m assuming the first, since doing so on a per-origin-server basis for incoming requests as they arrived would require examining SNI, but perhaps that's theoretically doable?) ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
