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

[Kent Watsen <[e-mail]>]

>> 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.

      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).

      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   ;)


More reasons why it may be a more correct to say DNS-SD is NOT used:

  1) This draft doesn't use any PTR records, since PTR records 
     are more oriented for human-in-the-loop.  Instead, the draft 
     effectively hardcodes the PTR response to be the device's
     serial number.

     FWIW, this within itself is likely not that big of a deal, since 
     RFC 6763 allows that zero PTR are returned.


  2) The draft's definition of some of the contents of the TXT records
     overalps with SRV information, in conflict with RFC 6763:

     RFC 6763 §6.3 says:

      "The target host name and TCP (or UDP) port number of the service
       are given in the SRV record.  This information -- target host 
       name and port number -- MUST NOT be duplicated using key/value
       attributes in the TXT record."

     But this isn't the case in this draft.  If a device gets a device-
     specific response (i.e., TXT RRs from <sn>._sztp[._tcp].example.com)
     then it is NOT supposed to query for the device-independent SRV
     records.


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?


>> In short, unless we're making radical changes to zerotouch so that it no 
>> longer uses RFC 6763, there is no valid path forward other than 
>> registering a corresponding service in the IANA table cited above (such 
>> as "sztp").

Right, maybe this draft shouldn't say it's using RFC 6763?
That said, happy to keep it as is as well, if that's okay...

Thanks,
Kent


> /a
> 
> ____
> [1] draft-ietf-netconf-zerotouch §4.2.1: "Devices claiming to support 
> DNS as a source of bootstrapping data MUST first query for 
> device-specific DNS records using DNS-SD [RFC6763]"
> 
> [2] RFC 6763 §6: "Every DNS-SD service MUST have a TXT record in 
> addition to its SRV record, with the same name"
> 
> [3] draft-ietf-dnsop-attrleaf §2: "Only global underscored names are 
> registered in the IANA Underscore Global table."
> 
> [4] draft-ietf-dnsop-attrleaf §4.3 defers authority for SRV/_tcp to RFC 
> 2782 and authority for TXT/_tcp to RFC 6763.
> 
> [5] RFC 6763 §7: "The first label of the pair is an underscore character 
> followed by the Service Name [RFC6335]."
> 
> [6] RFC 6335 §10, which is too long too reasonably quote here.
> 
> [7] RFC2782 §"The format of the SRV RR"; see definition of "Service", 
> with STD 2/RFC 1700 -> RFC 3232 -> iana.org
> 
>