Hi Wes, On Mon, Mar 30, 2020 at 4:35 PM Wes Hardaker <wjhns1@xxxxxxxxxxxxx> wrote: > > Donald Eastlake <d3e3e3@xxxxxxxxx> writes: > > > My apologies for getting in some minor comments so late. I do not > > suggest any technical changes. However, at least to my eye, there are > > some little glitches and editorial changes I would suggest. > > Thanks for the detailed review, comments and suggestions Donald. > Responses inline below. Any thing *not* mentioned below should consider > accepted :-) A few of the editorial changes I left unchanged as well, > since I suspect the RFC Editor will likely make the final call on > whether commas are needed in certain spots when you and I disagree on > whether they're needed or not. OK. Thanks for accepting so many of my suggestions. > The full diff of changes from applying your changes can be found here: > https://github.com/wkumari/draft-wkumari-dnsop-extended-error/commit/adcd34da305737e57964676cd1376263e8803239 > > > [deletion of the rfc editor note] > > I left this in, since it easily flags where help is needed. > > > (SERVFAIL, NXDOMAIN, REFUSED, -and even- NOERROR, etc) > > You removed "and even" but I'm leaving it in, since there was a lot of > discussion around NOERROR and how that seemed odd to people. The > extract "and even" text helps calls needed attention to it, IMHO. OK. > > "Because long EXTRA-TEXT fields may trigger truncation, > > which is undesirable given the supplemental nature of > > EDE." > > I left this sentence as a hybrid of what you suggested (removing most of > the second half), leaving in the supplemental component since I believe > that also is a subtle thing that should be called out. Maybe others > believe your text is better though? > > I left in your suggested "on the ... [IANA] web page as follows:", but > I'm not sure that's the right text either. We want the creation of a > registry, which *happens* to be listed on a web page as well. Generally, IANA likes quite specific instructions/requests. If IANA has any problem with the instructions/request, they will let us know. > I also do not add the "reserved" section since the IANA ranges were > discussed extensively and the current number ranges are the result of a > consensus I didn't want to have one person change without a lot of > backup agreement. This is the only serious problem I see. The assignment policy/status will have to be specified for every value. I agree that I should not be specifying the status of the range that was omitted and for which I suggested "reserved". Given this gaping hole in the IANA Considerations, I imagine that the IESG will impose a policy for that range or, alternatively, the IESG and/or IANA will bounce the draft back to the WG get this filled in. Thanks again, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e3e3@xxxxxxxxx > -- > Wes Hardaker > USC/ISI -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
