Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)

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

Return-Path: <alissa@cooperw.in>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA32F130F9D; Wed, 10 Oct 2018 09:54:11 -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=cYa9lkxe; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=laQ54Qcj
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 LkU6iMcpG_yN; Wed, 10 Oct 2018 09:54:08 -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 9368B130F97; Wed, 10 Oct 2018 09:54:08 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 43E1522038; Wed, 10 Oct 2018 12:54:07 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 10 Oct 2018 12:54:07 -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=+ +MIkUQq++7VVLUlFuEWr4yCBwb5avVNXvPmqBtnyGg=; b=cYa9lkxeOxLjhComF 5MSlWeolT+ddaB7IocXr9TkW6onFzD93o9W9hV7VeyKa7WKEs3LvZ7cojMkhX+Fx Kb+amKkLF65Uic8voCY1YsjVUkEr57hpf5I1bMgbMOBYACbBkMJK7Msl+RHMI+gA f5CQ+EVSrdsgo9ltZFANtwWK0hKPkAKooSFVhORtX1AvSGhekBNdHgJdt2dh/g6B ZRLT127EhcAk68ozgflxPFlNymW9O+DKwj/YMG78d6A3SPJLZ0PBh0xoN9DuUrZQ CYxN1Bri0LaYljR+NEnwm7Sk49+6lH3AhLz65rDPeEauWe9Php3nR7paKrfDy7bC U2AlA==
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=++MIkUQq++7VVLUlFuEWr4yCBwb5avVNXvPmqBtny Gg=; b=laQ54QcjpU00dIPj2yIftvU3I1h0c/QRm1eLMwng+Xy8Kr+2aVcnGLTfG J+mVgbBoc0EnkbV2h9sN6hGs16rwEu0/ZUSatEXabRSVpHUw719gWK6YOeCLAUhM DVJM698Q+4P1af5qjqpYWj84jZ5t3cKa3B/bd9K3ZrqCW8vMoXFfrv246+DaBs8s zzpHR5XNNlFRat84MauGGMSXYTWdg2bA24I6cxY4Bx/c1f0MoramhJ5zjdRzcYgm OmSzshVtPx2zle8LTkyE5UkkGkMe6K9ZgebklBAGqx6MjbG+Y1CamxSTZlusf64P EqC7wHrSpgcODbUatkEoFuzptvmXw==
X-ME-Sender: <xms:ri6-W6XFtZVCRlJZ-wtoI3TARmFqL5jzEYcmVU5tcHG2deRVB7ax7w>
X-ME-Proxy: <xmx:ri6-W2I7TGBlqg0rHwdnTiTMzaxs_3vHUHIWs-i3yFvhae3vQKfWMA> <xmx:ri6-W_rwCPvXqXnM_hfQuB7Pz6FYJ8PbzAjNKXB8BTOzKRslVOPpzg> <xmx:ri6-W0UPbQAMdmlBbr0sBFrufZ1fjcqIgDJRprsK0KtxwfdMqV25Ug> <xmx:ri6-Wy0xgyAewd5mPtyz-hIoIb3Uqi2pVVa6up2pPtMkodUHbTDBkA> <xmx:ri6-W935rq5PvPcde8VRA7kvNGL8gMHU_U1wQTs2afS5kcUWiggzoA> <xmx:ry6-WzjMiBInAuFqrcBeZtv8YZ1_fNTykVJwFm5vVisCRhzuByT71A>
Received: from rtp-alcoop-nitro5.cisco.com (nccm-cmcs-client.cisco.com [173.38.117.70]) by mail.messagingengine.com (Postfix) with ESMTPA id E5921E46B8; Wed, 10 Oct 2018 12:54:05 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <ce783a4c-e215-d564-e83c-578aa510b625@dcrocker.net>
Date: Wed, 10 Oct 2018 12:54:04 -0400
Cc: IESG <iesg@ietf.org>, draft-ietf-dnsop-attrleaf@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, dnsop-chairs@ietf.org, dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <40FE1BEA-E87D-4FF2-A096-C26DDD1C9A82@cooperw.in>
References: <153918020224.5848.13121328738608688797.idtracker@ietfa.amsl.com> <ce783a4c-e215-d564-e83c-578aa510b625@dcrocker.net>
To: Dave Crocker <dhc@dcrocker.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZRjQ6UltlgW1wcD3leGIoh96ke4>
Subject: Re: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-attrleaf-13: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Oct 2018 16:54:12 -0000

Hi Dave,

> On Oct 10, 2018, at 12:49 PM, Dave Crocker <dhc@dcrocker.net> wrote:
> 
> On 10/10/2018 10:03 AM, Alissa Cooper wrote:
>> I agree with Alexey. It seems like the expert is being asked to do the review
>> that IANA would typically do itself.
> 
> Point taken.  However, there was wg discussion about the choice and it landed on this.
> 
> I'll await either wg or iesg direction for specific text changes to the draft on this.
> 
> 
>> Please address  the Gen-ART review nits.
> 
> Did that some time ago, though I believe I did not receive a followup response:

The response below was about attrleaf-fix, not attrleaf. The Gen-ART review for attrleaf is at https://mailarchive.ietf.org/arch/msg/dnsop/dq-cwawY1UqoGJWFUxQPuWv0oPc.

Thanks,
Alissa

> 
>> -------- Forwarded Message --------
>> Subject: Fwd: Re: Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
>> Date: Wed, 26 Sep 2018 13:29:07 -0700
>> From: Dave Crocker <dcrocker@bbiw.net>
>> To: draft-ietf-dnsop-attrleaf-fix@ietf.org
>> G'day.
>> Just for completeness...
>> Absent direction to the contrary, I'm making no changes concerning the following items (with the ones that have produced changes elided):
>> (BTW, I can't find documentation that explains the sub-addressing scheme for sending to folk associated with an internet-draft, and I don't remember the details of the various choices. So I dropped the .all in case it meant the entire wg. /d)
>> -------- Forwarded Message --------
>> Subject: Re: Genart last call review of draft-ietf-dnsop-attrleaf-fix-04
>> Date: Mon, 24 Sep 2018 06:16:13 -0700
>> From: Dave Crocker <dcrocker@gmail.com>
>> To: Francesca Palombini <francesca.palombini@ericsson.com>om>, gen-art@ietf.org
>> ...
>> 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.
>> ...
>>>    +  Those registered by IANA in the "Service Name and Transport
>>>             Protocol Port Number Registry [RFC6335]"
>>> Move the end quote after Registry.
>> ok.  Good catch.
>> /// 9/26:  As I posted to the wg, these actually appear to be a bug in the xml2rfc processing tool at the IETF site.  I've made changes to the document to work around it. /d
>>>  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.
>> /// 9/26: This also appears to be a tool bug. /d
>>>> 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.
>> ...
>>>   == 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.
>> ...
>> d/
> 
> 
> 
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net