Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)

Adam Roach <adam@nostrum.com> Tue, 15 January 2019 23:01 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3A9130F2F; Tue, 15 Jan 2019 15:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.68
X-Spam-Level:
X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 wY6xsI3cymPf; Tue, 15 Jan 2019 15:01:05 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1FD2F130F1F; Tue, 15 Jan 2019 15:01:04 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x0FN0tHu091601 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 15 Jan 2019 17:00:57 -0600 (CST) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1547593260; bh=4xwUj0qHdoPg7bkgMyXZaruE2n6jJjxiPJ8Cs6QKDZA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=m0TZMY1LgJzZl1uKUarLIMyHrsI+Tha0jEyIbNdSVtkWdFG0MIQLDfQNCNeuzd9Nw Glyp4w/s4PoH7/ZQp1a147lSRcYtDJUyudNZqQC0gUtk6aF26UJxZ8F30sQrOhIfDZ simQ9qc+ZuF3wKEpWmOHcajlrOh13seSgRdtnHgE=
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Kent Watsen <kwatsen@juniper.net>, Benjamin Kaduk <kaduk@mit.edu>
Cc: Dave Crocker <dcrocker@bbiw.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>
References: <F526DA60-77EC-45D6-ADE0-B345020A89BF@juniper.net> <20181230003002.GC57547@kduck.kaduk.org> <5DCD6C74-7918-45AB-BEA7-2C1A020B4411@juniper.net> <20190106050255.GJ28515@kduck.kaduk.org> <35A436B3-5D57-4015-A51E-5F9A1E349D31@juniper.net> <DAC627AC-8453-41D2-B95C-BC25746E66C1@juniper.net> <cc5adc78-6751-fabf-03d2-e0c65f8a6c91@bbiw.net> <F844EDFB-3E15-47FB-A714-06363B996FC2@juniper.net> <42cddba1-9f59-f19f-176f-197f0c0c0c96@bbiw.net> <32cfe06c-8204-a63a-263d-cb5b30a7a2fc@nostrum.com> <20190110183444.GN28515@kduck.mit.edu> <0CDD631D-47A4-4478-A250-85603C653D23@juniper.net> <f9e64452-a2e1-fb18-80b1-b2c5fa9c54ac@nostrum.com> <3ABB2B04-DB2C-4E2C-86C7-40D83D440DFB@juniper.net>
From: Adam Roach <adam@nostrum.com>
Message-ID: <3d0efc38-edcd-4733-9093-884cea2733a2@nostrum.com>
Date: Tue, 15 Jan 2019 17:00:50 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <3ABB2B04-DB2C-4E2C-86C7-40D83D440DFB@juniper.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/s34L0yexfzFvr99PCiLUKFHqa8I>
Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jan 2019 23:01:07 -0000

The changes regarding DNS handling appear to be fine to me. Thanks for 
being so patient as we worked through the proper course of action here.

/a

On 1/11/19 5:10 PM, Kent Watsen wrote:
> Hi Adam, Benjamin, and Dave,
>
>    I just posted -28 to address this last COMMENT.
>    Please review to see how it can be improved.
>
>    The draft no longer says it uses DNS-SD and it
>    now registers "_sztp" in DNS Underscore Global
>    Scoped Entry Registry.
>    
>    Here's a direct link to updated/new sections:
>     - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-4.2
>     - https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-28#section-10.7
>
>
> Adam,
>
>    I added text about this draft not using DNS-SD.
>
>    Also, after reviewing RFC6763, copied over the
>    recommendation that mDNS SRV responses also
>    include address (A and AAAA) records.  This was
>    the only thing I can find of merit after searching
>    for both the strings "multicast" and "mdns".  Was
>    there something else you had in mind?
>
>
> Thanks,
> Kent
>
>
> -----Original Message-----
> From: Adam Roach <adam@nostrum.com>
> Date: Thursday, January 10, 2019 at 5:00 PM
> To: Kent Watsen <kwatsen@juniper.net>, Benjamin Kaduk <kaduk@mit.edu>
> Cc: Dave Crocker <dcrocker@bbiw.net>, Alexey Melnikov <aamelnikov@fastmail.fm>, The IESG <iesg@ietf.org>, "draft-ietf-netconf-zerotouch@ietf.org" <draft-ietf-netconf-zerotouch@ietf.org>, "netconf-chairs@ietf.org" <netconf-chairs@ietf.org>, NETCONF Working Group <netconf@ietf.org>
> Subject: Re: [Netconf] Benjamin Kaduk's Discuss on draft-ietf-netconf-zerotouch-25: (with DISCUSS and COMMENT)
>
> On 1/10/19 2:09 PM, Kent Watsen wrote:
>>>> I don't think this is right. Draft-ietf-netconf-zerotouch is explicitly
>>>> using DNS-SD procedures [1]. In turn, DNS-SD absolutely mandates the
>>>> presence of both SRV and TXT records with the same name [2]. So the
>>>> names need to match.
>>> Whoops, that's totally an error on my part.  If we're explicitly doing
>>> DNS-SD, then there's "nothing to see here".
>>>
>>> Sorry for missing that.
>> No, wait, I think that the draft's stating that it uses DNS-SD procedures
>> may be in error.  It might be more correct to say that it uses DNS in the
>> following two separate/distinct ways (in order of device-processing):
>>
>>      1) A lookup for device-specific data (for the TXT RRs)
>>
>>         Currently is this:<serial-number>._sztp._tcp.example.com
>>         But maybe should be: <serial-number>._sztp.example.com ???
>>
>>         Returns TXT records (no SRV records) supplying bootstrapping
>>         data.
>
> Aha! Okay, I had missed this in my read of the zeroconf document. I
> think I just saw "DNS-SD" and made certain assumptions. If this is the
> procedure you've specced out, then you can't use a TXT record with the
> _tcp global underscored name (since its use has to be consistent with
> the procedures spelled out in RFC 6763). The use of
> <serial-number>._zrtp.example.com would be fine, and would call for a
> registration in the attrleaf registry.
>
>
>>         Only if this lookup fails (not in addition to), then the
>>         device moves to (2), in conflict with RFC 6763 §6.3 says:
>>
>>           "DNS-SD uses DNS TXT records to store arbitrary key/value pairs
>>            conveying *additional* information about the named service."
>>           (emphasis mine)
>>
>>
>>      2) A traditional SRV lookup (per RFC 2782, not DNS-SD, right?)
>>
>>         Example: _szpt._tcp.example.com
>>
>>         Returns SRV records (no TXT or PTR records) supplying
>>         traditional service info (address, port, priority, weight).
>
> Kind of? The issue here is that 2782 uses normal DNS lookup procedures,
> while zerotouch uses mDNS lookup procedures (if I've read things
> correctly). Doing mDNS with SRV records using _tcp but *not* using
> DNS-SD ends up stepping on DNS-SD's toes, at least a little bit. I
> suppose as long as "szpt" is registered in the service table (which is
> required for 2782 use), there's no practical risk of collisions.
>
>
>>         FWIW, technically, SZTP defines an application-level protocol
>>         on top of RESTCONF, which is on top of HTTPS, but I don't
>>         think anyone is suggesting this:
>>
>>             _sztp._restconf._http._tls._tcp.example.com   ;)
>
> I hate to admit that there's (kind of) precedent there, but it's *bad*
> precedent resulting from a misreading of 2782, and not something I'd
> encourage. :)
>
> <snip>
>
>
>> Note that the WG didn't know about draft-ietf-dnsop-attrleaf until just
>> now in the IESG review.  We were shoe-horning in DNS-SD as it the closest
>> fit.  But now that draft-ietf-dnsop-attrleaf is brought to our attention,
>> perhaps it makes more sense to define a top-level "_sztp" attribute for
>> the device-specific bootstrapping data?
>
> FWIW, before attrleaf, the accepted approach was to land-grab a label
> and naïvely hope that no one ever tried to grab the same label twice. In
> any case, even with attrleaf (and based on your clarifications above), I
> think the <serial-number>._sztp.example.com formulation for TXT is
> correct. With attrleaf, it's even more clearly so.
>
> All of that said, you'll need to put additional language in here about
> using SRV with mDNS, but *NOT* using DNS-SD procedures. I'd advise
> copying and modifying appropriate passages from DNS-SD as the basis for
> such language. Also, please be certain to be very clear about the
> relationship between this mechanism and DNS-SD.
>
> /a
>
>