Subject: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04

From: Francesca Palombini <[email-masked]>
Date: Mon, 24 Sep 2018 03:00:19 -0700

Reviewer: Francesca Palombini
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://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-attrleaf-fix-04
Reviewer: Francesca Palombini
Review Date: 2018-09-24
IETF LC End Date: 2018-09-25
IESG Telechat date: Not scheduled for a telechat

Summary:

This draft is basically ready for publication, but has nits that should be
fixed before publication.

Major issues:

N/A

Minor issues:

N/A

Nits/editorial comments:

I give some proposal for clarification here, feel free to take them or leave
them. The idnits tool however produced several output, I would suggest to fix
those before publication.

   The use of underscored node names is specific to each RRTYPE that is
   being scoped.

As an non-expert in the area, I would have appreciate a ref to a document
introducing RRTYPE.

   This section provides a generic approach for changes to existing
   specifications that define straightforward use of underscored node
   names, when scoping the use of a "TXT" RRset.

Same for "TXT" RRset.

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

Since the effort has been done, I would have appreciated the full list here.

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

Same as previous comment.

   An effort has been made to locate
   existing drafts that do this and register the associated 'protocol'
   names.

Same as previous.

3.1. and 3.2. is the formatting of the updated sections (after "And is to be
updated to the new text:") wanted? Why not use the same format as in 3.3., with
OLD and NEW?

   +  Those registered by IANA in the "Service Name and Transport
            Protocol Port Number Registry [RFC6335]"

Move the end quote after Registry.

   +  Those listed in "Enumservice Registrations [RFC6117].

Missing end quote after Registrations.

   " Signaling Trust Anchor Knowledge in DNS Security Extensions

Remove the space after the quote.

 John Levine, Bob Harold, Joel Jaeggli, Ond&#345;ej Sury and Paul

In Acknowledgements, one name is not encoded correctly.

>From running the idnits tool (https://tools.ietf.org/tools/idnits/), several
comments, warnings and one error were raised, which I snipped and pasted below
as a summary:

  -- The draft header indicates that this document updates RFC****, but the
  abstract doesn't seem to mention this, which it should. (see
  https://www.ietf.org/id-info/checklist) --> I see that the abstract generally
  mentions "the existing specifications that use underscore naming", but I
  think to make this correct, it should explicitely list them as well.

  -- The document seems to lack a disclaimer for pre-RFC5378 work (See the
  Legal Provisions document at https://trustee.ietf.org/license-info for more
  information.)

  == Unused Reference: several documents are included in the list of
  references, but no explicit reference was found in the text --> if my
  editorial comments are taken, they should fix this one.

  ** Downref: Normative reference to an Informational RFC: RFC 7553

  -- Obsolete informational reference (is this intentional?): RFC 3921
     (Obsoleted by RFC 6121)

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Sep 2018 06:16:13 -0700

Hi.  Thanks for the detailed comments.

Some responses...

> As an non-expert in the area, I would have appreciate a ref to a document

The term is basic to DNS, with RFC 1035 cited in the first sentence of 
the Introduction:

      "Original uses of an underscore character as a domain node name
       [RFC1035] prefix, which creates a space for constrained
       interpretation of resource records, were specified without the
       benefit of an [IANA-reg] registry."

Once such a citation has been included, is a document expected to repeat 
the citation for every term used from it?  The implication is that 
someone reading this sort of document is not expected to have basic DNS 
familiarity?

However this did cause me to look for the first use of "RRTYPE" and I 
discovered that RFC 1035 has "RR TYPE" but not "RRTYPE". I'm not sure 
where first use without the space started.

>     names, when scoping the use of a "TXT" RRset.

Same response.

> Since the effort has been done, I would have appreciated the full list here.

This is the 'fix' document, not the registry definition document.  The 
latter is cited in the first paragraph of this document's Introduction:

       "A registry has been now defined, and that document
        discusses the background for underscored domain name use
        [Attrleaf]."

That's where the list is provided.

> Same as previous comment.

Same response.

>     existing drafts that do this and register the associated 'protocol'

Same response.

> updated to the new text:") wanted? Why not use the same format as in 3.3., with

OK.

> Move the end quote after Registry.

ok.  Good catch.

> Missing end quote after Registrations.

ditto.

> Remove the space after the quote.

ok.

> In Acknowledgements, one name is not encoded correctly.

I believe this as a bug in the xml2rfc generator used by the tools site, 
for text format, since the correct text is produced by an xml to html 
generator.

> comments, warnings and one error were raised, which I snipped and pasted below

What's most interesting here is that the document passed IDNits during 
submission!  (Apparently nits only works on txt documents and I only 
submitted an xml version; I'd guess the submission process does not 
general a txt version on the fly, for nits to inspect...)

>    think to make this correct, it should explicitely list them as well.

That actually makes no sense to me, since that would be fully redundant 
with the Updates header field that is already provided.

>    Legal Provisions document at https://trustee.ietf.org/license-info for more

Another victim of the long lag time.  I've updated the IPR template 
reference.  We'll see whether it's the right one...

>    editorial comments are taken, they should fix this one.

This actually poses an interesting challenge.  The references are used 
in the Updates header field, but apparently IDNits does not look there.

>    ** Downref: Normative reference to an Informational RFC: RFC 7553

That document is a specification.  This document modifies it.  No matter 
it's standards track status, it is a normative reference to this document.

>    -- Obsolete informational reference (is this intentional?): RFC 3921

Ack. Not intentional; just an error introduced by 12 years of lag time...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Sep 2018 12:24:47 -0700

>> Move the end quote after Registry.

Interesting. Just discovered that this probably qualifies as a bug in 
the xml2rfc processor tool at the IETF site.

(I only submitted the xml, which I think is formally ok.)

Here's the xml for that paragraph:

                     <t>Those registered by IANA in the "<xref
                           target="RFC6335">Service Name and Transport
                           Protocol Port Number Registry</xref>" The
                        underscore is prepended to the service
                        parameters to avoid collisions with DNS labels
                        that occur in nature, and the order is reversed
                        to make it possible to do delegations, if
                        needed, to different zones (and therefore
                        providers of DNS).</t>

(I'm changing the xml to avoid this bug for the next version.)

d/

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 26 Sep 2018 22:08:35 +0200

Hi Dave,

Responding only to the xml2rfc issue, not to the document content:

>                         needed, to different zones (and therefore

I think xml2rfc does the right thing.  The quotes are provided by
you, the author, not the processor, and you've enclosed the element
completely in the quotes:

  "<xref target="RFC6335">
	Service Name and Transport Protocol Port Number Registry
   </xref>"

which as expected gives the <xref/> expansion enclosed in quotes:

  "Service Name and Transport Protocol Port Number Registry [RFC6335]"

The expansion of the <xref/> does not, and should not, change because
it's surrounded it by quotes.

If this was wanted:

    "Service Name and Transport Protocol Port Number Registry" [RFC6335]

this should have been specified:

  <xref target="RFC6335">
	"Service Name and Transport Protocol Port Number Registry"
  </xref>

xml2rfc is not a do-what-I-mean-not-what-I-say piece of code quite yet ,;-)

	Henrik

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Sep 2018 19:11:04 -0700

Henrik,

Thanks for the quick followup...

> completely in the quotes:

yeah, sorry.  played with the combinatorials a bit more and agree.

> xml2rfc is not a do-what-I-mean-not-what-I-say piece of code quite yet ,;-)

well, now, that's something to work on.

d/