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

Alissa Cooper <alissa@cooperw.in> Wed, 10 October 2018 15:00 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C9130F47; Wed, 10 Oct 2018 08:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=Q4JeBeLb; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X0CIEJ7g
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD-7rR-2QHBc; Wed, 10 Oct 2018 08:00:13 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3232130F79; Wed, 10 Oct 2018 08:00:12 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2CFC621D45; Wed, 10 Oct 2018 11:00:12 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 10 Oct 2018 11:00:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=q TOpTDm4PwFbYPvJkw8eaaV4KadJtfnppgn6jKYZkJE=; b=Q4JeBeLbVZVebrM16 IbIbNPpPeKYrmekRODcVp2f92HISFqjLyRezcj8aNUxzyEdnS8C7W2Y/TjxhDXLF dOkNo65tSX9iRYsmf60j/WL9qMJiDqH3LpcCfCMWu/po0DXytiBRv1PPdbLhIBRr Dns8dOBVgKkqS2wwQ0MGVQqfnRHuu/q1SH5XULT7jDGtCwLVc2Vjls3dQ5lnivjf FB4UZpTp8/B6dieuyJbjSe0hcdAuaaEwt7Ce8/Nds9oqCuQYzy5wh3s6iV60HzjZ vXvE2TigREj2ffzGu55XzOWYPXkfKx9b9rpgsQeTvjIDoctIkKcUt8PP8lgx7ZrM WpFhg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=qTOpTDm4PwFbYPvJkw8eaaV4KadJtfnppgn6jKYZk JE=; b=X0CIEJ7gQ8vDwOEY0o79rTrayZ0VfN9HHOE84Lc2IGPdkO6PE6b1K6bf7 OKA0/DfOnXRWHkqIzcf+OTUli9+vZV2VhPPBd/bGmExn4m1M0aG3U+fzVh2ctxXF Wiwj1FI+Ro66eryO/pEYT94gbJxNDHkdss1ZkQiWNT7J0laBJq+sYoQO8reT0/Ln nrj7dUvSF4FmsrUlsxmR+8tITAI/DY1r82u+Pu+GCw0UiYfTYCAnvisppxV7mU/b v8/8Owo0/3ks1pgDXBVewv2MO0Y+P7irdrL0puWyydvjP2DdxEhNvNtE31PTu1ji +MxAx6h6YsZCKZ6PoI3DCG7wT0m2A==
X-ME-Sender: <xms:-xO-W_abLNLXugXvTAMD639OI2DYwEZ48y04kLTDucoPrr0ZzrtcGA>
X-ME-Proxy: <xmx:-xO-W2ZUMYzxjCnVRxSgwp8z_OJReroqbsJBI0whEQLiXX0Hj-A6Nw> <xmx:-xO-W6oHsvAcGJ5NhZvJ64BpWE8FbNEF6Maj9c2EcmAd8G2HLw6lhg> <xmx:-xO-W-BceoZ3EmWkPrDA8GijaE1oTyemXTKGW6Ffodexm6OKPD4g7Q> <xmx:-xO-W7rNLuM_lXB3tpT2pvrEL1GT5fwEGOo9eaV7onxjFsB_smENNw> <xmx:-xO-W_BFe9--7ZV3xYexa5qsVjAEDdCU_EOwpqVW6WYl50gZZSIKDw> <xmx:_BO-WwtTrJxEhKs5lO2kffLLebicO4T48Kv56suaLJD9uqfLxjP3Vw>
Received: from rtp-alcoop-nitro5.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id 11AC3E4074; Wed, 10 Oct 2018 11:00:11 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <b8adca70-da9e-697d-c80f-c3f3de9aaf37@gmail.com>
Date: Wed, 10 Oct 2018 11:00:10 -0400
Cc: General Area Review Team <gen-art@ietf.org>, dnsop@ietf.org, draft-ietf-dnsop-attrleaf-fix.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1BA796A2-C715-4ED1-B1B4-859CCC89C9CF@cooperw.in>
References: <153778321966.28052.14784074370899947199@ietfa.amsl.com> <b8adca70-da9e-697d-c80f-c3f3de9aaf37@gmail.com>
To: Dave Crocker <dcrocker@gmail.com>, Francesca Palombini <francesca.palombini@ericsson.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ASJnYAZ-a_ztTNvxJb5mDWSlXhY>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2018 15:00:17 -0000

Francesa, thanks for your review. Dave, thanks for your responses. I entered a DISCUSS ballot based on the issue raised about unused citations.

Typically the abstract does contain an explanation of the document(s) being updated. In this case the list is so long that I’m not sure it’s worth it.

Alissa

> On Sep 24, 2018, at 9:16 AM, Dave Crocker <dcrocker@gmail.com> wrote:
> 
> 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, Ond&#345;ej 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 intentional; just an error introduced by 12 years of lag time...
> 
> d/
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art