[DNSOP] Artart Last Call review of draft-ietf-dnsop-structured-dns-error-12

[Paul Kyzivat <[e-mail]>]

Reviewer: Paul Kyzivat
Review result: Ready with Nits

I am the assigned ARTART reviewer for this Internet-Draft.

Document: draft-ietf-dnsop-structured-dns-error-12
Reviewer: Paul Kyzivat
Review Date: 2025-04-20
IETF LC End Date: 2025-04-28
IESG Telechat date: ?

Summary: This draft is on the right track but has open issues, described 
in the review.

ISSUES: 7
NITS:  1

Issues:

1) NIT: Section 4 - c: (contact)

This allows sips but not sip URIs. Sips is not widely used.
Please consider allowing sip URLs.

2) ISSUE: Section 4 - s: (suberror)

This field lacks a specification of its type.

It appears that "suberror" here is intended to be the same as 
"sub-error" in section 7 and "SubError" in section 11.3. Please use a 
consistent spelling throughout. And then specify here that the type of 
this field is an integer with values defined in the new IANA registry.

3) ISSUE: Section 8 - Extended DNS Error Code

The phrasing here, for both the section title and the content, is odd 
and confusing. For clarity and consistency with section 7, I suggest a 
title of "New Extended DNS Error Code Definition".

And then the body could start with: "This document defines the following 
new IANA-registered Extended DNS Error Code." The existing text will 
then require some tweaking to align with this rephrasing.

And then to avoid confusion, perhaps change the title of section 11.4 to 
"New Extended DNS Error Code Registration".

4) ISSUE: Section 9 - Examples

I fail to see how Figure 2 represents the same content as Figure 1. If 
it does, can you please explain?

5) ISSUE: Section 11.1 - New Registry for JSON Names

Some of the fields described in the text are inconsistent with the 
fields contained in Table 1: "Short Description" vs. "Description", and 
no text description of "Full JSON Name".

Also, is "Full JSON Name" appropriate? IIUC it has no role in JSON. 
Rather, it is just a human meaningful long form of the JSON Name, or 
perhaps a shorter form of the "Short Description". I suggest rethinking 
what you are calling these things.

6) ISSUE: Section 11.2 - New Registry for Contact URI Scheme

Could you please add some text describing the role and responsibilities 
of the Change Controller? What sort of changes are allowed? More than 
additions?

7) ISSUE: Section 11.3 - New Registry for DNS SubError Codes

I don't understand what you mean by "RFC8914 error code applicability".

First, what do you mean by "RFC8914 error code"? Do you mean the 
"Extended DNS Error Codes" defined in RFC8914?

Next, what do you mean by "applicability"? Do you mean the "Extended DNS 
Error Codes" for which the "SubError Codes" may be used?

Please clarify these.

Also, again, could you please add some text describing the role and 
responsibilities of the Change Controller? What sort of changes are 
allowed? More than additions?

8) ISSUE: JSON Name

Throughout the document you use "JSON Name" to describe a specific field 
in a specific JSON document format. This isn't descriptive of the 
purpose of the field. I suggest changing this to something more 
descriptive - perhaps "EXTRA-TEXT Field Name".