Re: [Last-Call] Last Call: <draft-ietf-dnsop-extended-error-14.txt> (Extended DNS Errors) to Proposed Standard

[Donald Eastlake <[e-mail]>]

Hi Wes,

On Mon, Mar 30, 2020 at 4:35 PM Wes Hardaker <[e-mail]> wrote:
>
> Donald Eastlake <[e-mail]> 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   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> --
> Wes Hardaker
> USC/ISI