Hi. Thanks for the detailed comments.
Some responses...
On 9/24/2018 3:00 AM, Francesca Palombini wrote:
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.
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.
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.
Same response.
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.
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.
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.
Same response.
An effort has been made to locate
existing drafts that do this and register the associated 'protocol'
names.
Same as previous.
Same response.
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?
OK.
+ Those registered by IANA in the "Service Name and Transport
Protocol Port Number Registry [RFC6335]"
Move the end quote after Registry.
ok. Good catch.
+ Those listed in "Enumservice Registrations [RFC6117].
Missing end quote after Registrations.
ditto.
" Signaling Trust Anchor Knowledge in DNS Security Extensions
Remove the space after the quote.
ok.
John Levine, Bob Harold, Joel Jaeggli, Ondej Sury and Paul
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.
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:
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...)
-- 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.
That actually makes no sense to me, since that would be fully redundant
with the Updates header field that is already provided.
-- 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.)
Another victim of the long lag time. I've updated the IPR template
reference. We'll see whether it's the right one...
== 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.
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
(Obsoleted by RFC 6121)
Ack. Not
