Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and COMMENT)

Warren Kumari <warren@kumari.net> Tue, 09 October 2018 17:56 UTC

Return-Path: <warren@kumari.net>
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 E40FB128CB7 for <dnsop@ietfa.amsl.com>; Tue, 9 Oct 2018 10:56:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 dKpTvHRu5Bm3 for <dnsop@ietfa.amsl.com>; Tue, 9 Oct 2018 10:56:49 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFD31274D0 for <dnsop@ietf.org>; Tue, 9 Oct 2018 10:56:49 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id 189-v6so2775507wmw.2 for <dnsop@ietf.org>; Tue, 09 Oct 2018 10:56:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4Q1TP+ME2rsiivTO72BllTr/RfUNB52rRnxDEERF0jw=; b=YPY8bH2OD2yLOWrmmOgp7nH4AFy3rOm8BPILqbe0HrB8zLk5P+DxxR8P5otZtjbPZ/ 1ic3Cml4BzqSRlSjD4lvvnEeSvhvTSf7f04nbL6eu5N5kLlDu2y8TN4oqqHWa3wCCv7g gx322XIzepdxlLBdttPzaI0heUF1CijOaX2+09MQAvYBniWEbWpIkvbJr6kqASZZHefF 5ntLwruS0ozP8VxINSeXzjvUeb2x8PjBHIRn3sZmNgpg6Vmzx++twyEku5KncV9RhcWX LgFIaExK1oOIg2edHeiLupBo7c/ioXlq5c+xdykxdp9bDSIM4q9x6o7hhbMDOTgqeYBM mPGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4Q1TP+ME2rsiivTO72BllTr/RfUNB52rRnxDEERF0jw=; b=m5Hlb0/7WxUYUqKiHrlkRpQHq+Nt7WNZFWhzOUb5QuF+ib577aCKY6VQ+YrJecLqih stOdcQOsam2ZEQ1N8EBA/NBfNyQeJ0jqf6y1K2cCzVJdTFlG7ElAolL5DzY5I4JlGzo2 7n3vppvxRD6Y6bc0yY5uH894B5dGT8ciRQgqGkVj1zcBmsOZ5dOjqjIUrhvm/fFHB1xx uaQobykxrgNBSZJKJxKHf9+H9KV0A3wGmCOvtXEg20IQRvDD9y47uXsLddWAwY+AcBpx 6wJpbuqbDC1w3eJpDOKeWRp9E5pYoE8z+L9OvF5lqEqW/0yiCMzCzCQTXrOPIVbz+9kA qevg==
X-Gm-Message-State: ABuFfohYKJ8khQq45hOvFRQUX3TWd1C0sN5lBByi1NSDGdBl2EvLCKdE A8usn/0e6ZoI0l4zQdH3eg6Lz7rEH6R+poYAseK/iA==
X-Google-Smtp-Source: ACcGV607MwU8+Xggk57S6KW/35grmcJ42sx496WkxeoBTfxE9C7ss2/XICmHoLPh8D1fWJRCBwpf++/HcdFhnisBCi0=
X-Received: by 2002:a1c:ee8d:: with SMTP id j13-v6mr2801579wmi.125.1539107807347; Tue, 09 Oct 2018 10:56:47 -0700 (PDT)
MIME-Version: 1.0
References: <153905130877.18723.10309754622387806714.idtracker@ietfa.amsl.com>
In-Reply-To: <153905130877.18723.10309754622387806714.idtracker@ietfa.amsl.com>
From: Warren Kumari <warren@kumari.net>
Date: Tue, 9 Oct 2018 13:56:10 -0400
Message-ID: <CAHw9_i+EP+QqQadxOQJ8qOQx7E+X9-UxiYsm=Qkam+sYFkRwiQ@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: The IESG <iesg@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, Benno Overeinder <benno@nlnetlabs.nl>, dnsop <dnsop@ietf.org>, draft-ietf-dnsop-attrleaf@ietf.org, DNSOP Chairs <dnsop-chairs@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000020dd710577cf7605"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/JqK1FFBH1rzntXeV-QRCcCdxrYo>
Subject: Re: [DNSOP] Adam Roach's Discuss on draft-ietf-dnsop-attrleaf-13: (with DISCUSS and 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: Tue, 09 Oct 2018 17:56:53 -0000

On Mon, Oct 8, 2018 at 10:15 PM Adam Roach <adam@nostrum.com> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-dnsop-attrleaf-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I'm glad to see this registry finally being set up, and want to thank
> everyone
> who helped get the document ready. I understand that this has been a large
> archaeological undertaking, and that the relatively small size of the
> document
> belies the large amount of actual work that went into it.
>
> I have one top-level concern about the registry, a handful of proposed
> corrections to the initial table, and some very minor editorial nits. I
> present
> the following feedback in that order.
>
> ---------------------------------------------------------------------------
>
> I have some very strong concerns about the handling for the "URI" RRTYPE.
> As far as I can tell, the entries in the initial table were formed by
> starting
> with the entries in
> https://www.iana.org/assignments/enum-services/enum-services.xhtml,
> adding the
> most popular entries from
> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml,
> ("dccp", "sctp", "tcp", and "udp") and removing "web".
>
> Please note that it is entirely possible that I've missed an important
> detail
> here, and am merely confused.
>
> My top-line concern is that, while the table established by this document
> appears to intend to be a strict superset of the Enumservices table, there
> are
> no instructions of any kind to the IANA that would result in these tables
> remaining in sync -- that is, when a new service is added to the
> "Enumservice
> Registrations" table, one might presume that it needs to also appear in the
> new registry established by this document.
>
> I would imagine this could be handled either by asking the IANA to add
> instructions to the "Enumservice Registrations" table indicating that a
> corresponding entry must be added to this one; or simply by including the
> contents of that table by reference rather than by value into this one. I'm
> pretty agnostic about which approach is taken.
>
>
>
I will be on a plane during this telechat (actually, I hope to have landed
before the telechat, but no guarantees, etc.)

I'm OK with either of the above solutions (and hope that Dave is as well).
W


> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Related to the topic in my DISCUSS, I have three very closely related
> comments:
>
> Comment 1: Was the removal of "web" intentional?
>
> Comment 2: These initial entries misspell "xmpp" as "xmp"
>
> Comment 3: Is it envisioned that all future URI entries in this table will
> reference RFC 7533? That doesn't quite seem right. My instinct is that it
> would
> serve the users of this registry better if:
>
>  - _iax refers to RFC 6315
>  - _acct refers to RFC 7566
>  - All other enumservice-based URI entries in the current table refer to
>    RFC 6118
>  - RFC 7533 is mentioned elsewhere in the document as the reason
> enumservices
>    appear in the table.
>
> ---------------------------------------------------------------------------
>
> RFC 6763 §6 says:
>
>    Every DNS-SD service MUST have a TXT record in addition to its SRV
>    record, with the same name, even if the service has no additional
>    data to store and the TXT record contains no more than a single zero
>    byte.
>
> It's worth noting that RFC 6763 limits its use strictly to the use of
> "_tcp" and
> "_udp" -- all non-TCP transports are coded as "_udp". So I believe the
> following
> entries need to be added:
>
>               | TXT        | _tcp             | [RFC6763]  |
>               | TXT        | _udp             | [RFC6763]  |
>
> ---------------------------------------------------------------------------
>
> RFC 4386 §2 defines Global SRV records for _ldap, _http, and _ocsp. So:
>
>               | SRV        | _ldap            | [RFC4386]  |
>               | SRV        | _http            | [RFC4386]  |
>               | SRV        | _ocsp            | [RFC4386]  |
>
> ---------------------------------------------------------------------------
>
> Regarding the existing entry:
>
>               | SRV        | _tls             | [RFC6733]  |
>
> RFC 6733 uses this name non-normatively in an example, as an intermediate
> target while resolving an NAPTR record, and it is clearly a site-local
> decision rather than a protocol element. I do not believe this should be
> construed as reserving the name; its use in this context is clearly, in the
> words of this document's introduction, "a matter of operational convention,
> rather than defined protocol semantics."
>
> ---------------------------------------------------------------------------
>
> §1.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.
>
> ---------------------------------------------------------------------------
>
> §4.1:
>
> >  o  The table is to be maintained with entries sorted by the first
> >     column (RR Type) and, within that, the second column (_Node Name).
>
> Minor nit: I suggest that this document would be improved by sorting the
> table
> in §4.3 in this order as well.
>
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf