Skip to main content

DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
draft-ietf-dnsop-attrleaf-fix-07

Yes

Warren Kumari

No Objection

(Alexey Melnikov)
(Alvaro Retana)
(Ben Campbell)
(Deborah Brungard)
(Eric Rescorla)
(Ignas Bagdonas)
(Martin Vigoureux)
(Suresh Krishnan)

Note: This ballot was opened for revision 04 and is now closed.

Warren Kumari
Yes
Adam Roach Former IESG member
No Objection
No Objection (2018-10-08 for -04) Sent
Echoing comments from my review of draft-ietf-dnsop-attrleaf: I believe this
document needs to also include RFC 6763 and RFC 4386; and that it should not
include RFC 6733. Please see that review for details.

---------------------------------------------------------------------------

§1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

Minor nit: please consider using the boilerplate from RFC 8174.

---------------------------------------------------------------------------

§§2.1 and 2.2:

>  An effort has been made to locate existing drafts that
>  do this, register the global underscored names, and list them in this
>  document.

I think this text ("list them in this document") is left over from before this
document was split from draft-ietf-dnsop-attrleaf.

---------------------------------------------------------------------------

§2.3:

This ties back to my discuss on draft-ietf-dnsop-attrleaf, and needs to be
changed in a way that is consistent with however that issue is resolved. The
current list of entries added by draft-ietf-dnsop-attrleaf strongly implies that
the contents of https://www.iana.org/assignments/enum-services were
automatically imported into the namespace created by the Underscore Global
Registry by the simple existence of RFC 7553. If that's the case, it seems that
the following text in this document...

>  For any document that specifies the use of a "URI" RRset

...doesn't capture the real process here. As RFC 7553 will continue to exist
into the future, it seems that the trigger is addition of new Enumservice
entries, rather than the explicit specification of a new URI RRset.

---------------------------------------------------------------------------

§3.1:

>  The specification for a domain name under, which an SRV [RFC2782]
>  resource record appears, provides a template for use of underscored

Nit: "...a domain name, under which..."

---------------------------------------------------------------------------

§3.2:

As a very minor nit, the cited original text for RFC 6117 §4.1 kind of blends in
with the text of this document. I would propose indenting it as was done with
the rest of the quoted content in this section.

---------------------------------------------------------------------------

§3.3:

>  consumes all names beginning with the string "_ta-", when using the
>  NUL RR in the query.

Nit: I believe the record type is called "NULL" rather than "NUL".
Alexey Melnikov Former IESG member
No Objection
No Objection (for -04) Unknown

                            
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (2018-11-21) Sent
Thank you for addressing my DISCUSS and COMMENT.
Alvaro Retana Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Benjamin Kaduk Former IESG member
No Objection
No Objection (2018-10-10 for -04) Sent
I support Alissa's Discuss points (and in particular would think that this document
would be fine as Proposed Standard).

One other comment, in  Section 3.1:

Why is the new text only placing a "SHOULD be registered" requirement, as
opposed to MUST?
Deborah Brungard Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Eric Rescorla Former IESG member
No Objection
No Objection (for -04) Not sent

                            
Ignas Bagdonas Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Martin Vigoureux Former IESG member
No Objection
No Objection (for -05) Not sent

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2018-10-10 for -04) Sent
I don't quite understand why it was seen as beneficial by the group that this doc has been split up, however, BCP does not seems adequate for this part of the doc anymore (maybe PS instead as it updates some PS docs?).

Also, I think that the OLD/NEW style is not really necessary in most cases as simply a sentence/reference to the registry is added.
Spencer Dawkins Former IESG member
(was Discuss) No Objection
No Objection (2018-10-10 for -04) Sent
My previous position was a "plea for clue Discuss" about three MUSTs that appeared in the document, and Dave pointed out to me that those MUSTs will be removed in the next version of this document, because there is already a MUST in the underlying specification that this one is providing usage guidance for. 

Thank you for the speedy feedback!
Suresh Krishnan Former IESG member
No Objection
No Objection (2018-10-10 for -05) Sent for earlier