[Gen-art] Re: Genart last call review of draft-ietf-dhc-addr-notification-11
Hi Mallory, Thank you for pointing those typos out, they will be fixed in the next version of the draft. On Wed, May 8, 2024 at 3:31 AM Mallory Knodel via Datatracker wrote: > > Reviewer: Mallory Knodel > 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-dhc-addr-notification-?? > Reviewer: Mallory Knodel > Review Date: 2024-05-07 > IETF LC End Date: 2024-04-30 > IESG Telechat date: 2024-05-16 > > Summary: This document is well written and clear. > > Major issues: None. > > Minor issues: None. > > Nits/editorial comments: > > Two very brief spelling/grammar replacements: > > s/re-start/restart > s/IA-Address/IA Address > > > -- Cheers, Jen Linkova ___ 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-v6ops-dhcp-pd-per-device-07
t; Page 13, 1st bullet item, 1st sentence: change the “an” before “unique” to > “a”. > > Page 13, 2nd bullet item, last sentence: append a comma after “Therefore”. > > Page 13, 1st paragraph after the bullet items, 2nd sentence: change > “depened” > to “depend”. > > Page 13, section 12, 1st bullet item, 1st sentence: append an apostrophe > after > “devices”. > > Page 14, 6th bullet item, 1st sentence: change “clients” to “clients’”. > > Page 14, 7th bullet item, 2nd sentence: I’d strike “like” and “it” without > losing any meaning. > > Page 14, section 13, 1st paragraph, 2nd sentence: append a comma after > “threat”. > > Page 15, section 15, 2nd paragraph, 2nd sentence: change “rate limits” to > “rate-limits”. > > Page 16, section 16, 2nd sentence: append a comma after “temporary > address”. > > Page 16, section 16, 4th sentence: change “host’s” to “host”. > > Page 16, 1st bullet item, 1st sentence: change “muliple” to “multiple”. > > Page 16, 1st bullet item, 2nd sentence: append a comma after “result”. > > Page 16, 2nd bullet item: insert a space between “[RFC4193]” and “and”. > Append > a comma after “together”. > > Page 16, 1st paragraph after bullet items, 2nd sentence: delete “the” > before > “network resources”. > > Page 16, 2nd paragraph, 2nd sentence: insert “the” before “amount of”. > > Page 16, 2nd paragraph, 3rd sentence: append a comma after “perform ND > proxy”. > > Page 16, 2nd paragraph, 4th sentence: delete “a” before “single”. > > Page 16, 2nd paragraph, last sentence: append a comma after “case”. Change > “implict” to “implicit”. > > Page 20, acknowledgements: append a comma after “input”. Change > “contribution” > to “contributions”. > > > > -- Cheers, Jen Linkova ___ 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-6man-grand-04
On Mon, Jun 21, 2021 at 8:16 PM Dan Romascanu wrote: > Yes, a paragraph in the Introduction explaining the structure of the document > and especially the place(s) where normative text can be found would be > useful. If you add these you may consider deleting other such references > spread in the text. I'll add the following to the very end of the Introduction: "This document updates the Neighbor Discovery protocol to avoid packet loss in the scenario described above. Section 4 discusses the changes and analyses the potential impact, while normative changes to [RFC4861] are specified in Section 6. -- SY, Jen Linkova aka Furry ___ 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-6man-grand-04
Hi Dan, Thanks a lot for reviewing the document! On Fri, Jun 18, 2021 at 4:00 AM Dan Romascanu via Datatracker wrote: > Nits/editorial comments: > > 1. In Section 3 the Normative Language with capitalizations is used to > describe > requirements from solutions. This seems quite unnecessary, and certainly > cannot > be verified for conformance. Yes, Michael Scharf made the same comment. -05 will have the text updated to remove the normative language. >2. I would suggest moving or copying the first > sentence in Section 6 (that says that all normative text in the memo can be > found in this section) in the Introduction section. To be honest, I'm not sure how to fix that text into the Introduction. The Intro section talks about the problem statement and does not refer to the document structure. At the same time Section 4 already says that all normative text could be found in section 6. Do you think we need another paragraph in Introduction (or another section, 1.3?) explaining the document structure? Or do I misunderstand your suggestion? -- SY, Jen Linkova aka Furry ___ 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-rtgwg-enterprise-pa-multihoming-08
Hi Pete, On Tue, Jul 2, 2019 at 8:47 AM Pete Resnick wrote: > It's not just that the address selection is for new connections, though > that is certainly true. It's also the question of who is doing what: > Hosts figure out the address for default address selection, and > applications are the ones that do the selecting (whether it is to choose > the host default or choose a different one). Part of what the document > is missing is use of the word "default", at least in a few places. So, > in -09, a couple of suggestions: > > In the Abstract, change "select appropriate source addresses" to "select > appropriate default source addresses". Done! > In the Introduction, you have: > > Section 6 discusses existing and proposed > mechanisms for hosts to select the source address applied to > packets. > It also discusses the requirements for routing that are needed to > support these enterprise network scenarios and the mechanisms by > which hosts are expected to select source addresses dynamically > based > on network state. > > Hosts definitely don't select the source address to be applied to any > given packet; that's (at best) an application thing. Also, "dynamically" > here seems to imply "during the life of the connection", but that's > certainly not what you meant. Something like this seems better: > > Section 6 discusses existing and proposed mechanisms for hosts to > select the default source address to be used by applications. > It also discusses the requirements for routing that are needed to > support these enterprise network scenarios and the mechanisms by > which hosts are expected to update default source addresses based > on network state. Done, thanks for suggesting the text. > Again, hosts pick default addresses for applications to use, and > applications pick the addresses that packets will use. OK, I guess we are just using different terminology here... For me 'a host' is a whole element connected to the network, including all subsystems and applications running. Until your email I was thinking about an application as an element of a host. If I got you right, when the draft says 'host' you read it as 'network stack on a host', right? > How about this? : > > "It should be noted that [RFC6724] only defines the behavior of IPv6 > hosts to select default addresses that applications and upper-layer > protocols can use. Applications and upper-layer protocols can make their > own choices on selecting source addresses. The mechanism proposed in > this document attempts to..." I've updated that paragraph: "It should be noted that [RFC6724] only defines the behavior of IPv6 hosts to select default addresses that applications and upper-layer protocols can use. Applications and upper-layer protocols can make their own choices on selecting source addresses. The mechanism proposed in this document attempts to ensure that the subset of source addresses available for applications and upper-layer protocols is selected with the up-to-date network state in mind. The rest of the document discusses various aspects of the default source address selection defined in [RFC6724], calling it for the sake of brevity "the source address selection". I hope that the last sentence makes the rest of the document less confusing. What do you think? > I'd also suggest taking a look through the rest of section 6 for use of > the word "host" and see if the word "default" needs to be inserted > somewhere after it (like "...hosts to choose the correct *default* > source address"), or if it needs to be changed to "application". I've updated a number of places as well. > Nice. If it were me, I'd add a forward pointer to mptcp in 8.3 as > another mechanism (in addition to BGP) to deal with the problem. It is there: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3 > >> My suspicion is that section 7.3 underestimates the availability > >> (current and > >> future) of multipath transport. > You can have the half empty glass; I'll take the half full one. ;-) As per Magnus's suggestion, I've updated the text to mention that PA-based multihoming and MP transport could benefit from each other: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-11#section-8.3 -- SY, Jen Linkova aka Furry ___ 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-rtgwg-enterprise-pa-multihoming-08
Hi Pete, Thanks for reviewing the draft - not the shortest one...;) On Wed, Jun 5, 2019 at 1:42 AM Pete Resnick via Datatracker wrote: > I found this overall to be an excellent document with clear technical > explanations that even an upper-layer knucklehead like me could understand. > However, there a couple of issues could use more discussion. I put them as > "Minor issues", in that they're not showstoppers, but I do think they're > important and hope you'll be able to address them. > > Minor issues: > > Throughout, but particularly in section 5, this document refers to "hosts" > doing address selection. To be fair, so does RFC 6724, but 6724 is referring > to > *default* address selection. In reality, *applications* do address selection > on > a host; the host stack will only do address selection if the application > requests a default address. That works well for the scenarios in 6724, but in > this document, for example section 5.2.3, I'm not so sure. The idea that a > host > would receive an ICMP destination unreachable and re-arrange its address > selection seems at least an incomplete picture: An application with a (normal, > non-multi-path) TCP connection to a remote application is not able to "try > another source address to reach the destination"; the source address is > already > set for that TCP connection, so the only choice is to close the connection > entirely. If the application chooses to re-establish the connection with a > default address, yes, the host stack could then give a new default address > back > to the application, but this is hardly the dynamic and quickly adjusting > process that the document seems to be envisioning. Oh. Very good point - looks like I assumed that it's obvious and did not mention it anywhere explicitly. Yes, all address selection processes mentioned are for new connections. And indeed the applications/upper-layers could override the default address selection algorithm.. I've added some text to clarify. In particular: 1) Section 6: https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#page-24 First we look at how a host is currently expected to select the source and destination address with which it sends a packet for a new connection. 2) Section 6.1 https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.1 "It should be noted that [RFC6724] defines the default behaviour for IPv6 hosts. The applications and uppler-layer protocols can make their own choices on selecting source addresses. However the mechanism proposed in this document attempts to ensure that the subset of source addresses available for applications and upper-layer protocols is selected with the up-to-date network state in mind." > I don't think the above invalidates the core of the document or requires some > grand rewrite. But I do think some clarification is in order, saying that the > mechanisms described help with the *default* address selection, and some short > discussion of the limitations for what applications can (and more importantly > cannot) do with these mechanisms would be useful. I've added Section 6.7 - Solution Limitations https://tools.ietf.org/html/draft-ietf-rtgwg-enterprise-pa-multihoming-09#section-6.7 If you could review and let me know if it addresses your concern, it would be great! > My suspicion is that section 7.3 underestimates the availability (current and > future) of multipath transport. Apple is using it now in production, and Linux > already has it in their implementation. I think this is actually a reasonable > possible solution in the future, and I would be a little more optimistic than > the WG in this section. I've added "(even if new releases of operating systems get multipath protocols support there will be a long tail of legacy hosts)." to clarify my lack of optimism.. > Nits/editorial comments: > > Two editorial bits in section 1: > >This document defines routing requirements for enterprise multihoming >using provider-assigned IPv6 addresses. We have made no attempt to >write these requirements in a manner that is agnostic to potential >solutions. Instead, this document focuses on the following general >class of solutions. > > Is that second sentence right? If you are giving a general class of solutions, > that seems agnostic to the particular solution. Just a bit confusing. Updated. > >A host SHOULD be able respond dynamically... > > Do you mean "is expected to" instead of "SHOULD"? "SHOULD" seems overdone. Fixed, thanks! -- SY, Jen Linkova aka Furry ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
