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

[Adam Roach <[e-mail]>]

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