[Netconf] zerotouch issues found while preparing -20

[Kent Watsen <[e-mail]>]

All,

I'm trying to get -20 out now, but ran into a couple issues:


1) can't support the remote-id & circuit-id parameters

In looking to see how to support DHCPv6, I noticed that the ability for the DHCP client to learn the relay parameters (i.e. remote-id & circuit-id) is not supported.  I asked the DHC WG, which confirmed this understanding (see link below).  This being the case, we should remove the "remote-id" and "circuit-id" input parameters from the get-bootstrapping-data RPC.  That is:

   module: ietf-zerotouch-bootstrap-server
     rpcs:
       +---x get-bootstrapping-data
          +---w input
             +---w untrusted-connection?   empty
             +---w os-name?                string
             +---w os-version?             string
-            +---w remote-id?              string
-            +---w circuit-id?             string
             +---w nonce?                  string

Link to the DHC WG email thread:
  https://mailarchive.ietf.org/arch/msg/dhcwg/SufOgBpLedIpQVpBwZu3FCWSM5s.  

Assuming there are no objections, I'll remove these two input parameters from the to-be-posted -20 draft.



2) 'hardwareModuleName' is not guaranteed in 802.1AR-2009

Looking at 802.1AR-2009, it turns out that the 'hardwareModuleName' field is optional.  This being the case, we should add a "hw-model" parameter to the get-bootstrapping-data RPC.  That is:

   module: ietf-zerotouch-bootstrap-server
     rpcs:
       +---x get-bootstrapping-data
          +---w input
             +---w untrusted-connection?   empty
+            +---w hw-model?               string
             +---w os-name?                string
             +---w os-version?             string
             +---w nonce?                  string

      leaf hw-model {
        type string;
        description
          "This optional input parameter enables a device to
           communicate to the bootstrap server its vendor specific
           hardware model number.  This parameter may be needed 
           when the device's IDevID certificate does not include
           the 'hardwareModelName' value in its subjectAltName
           field, as is allowed by 802.1AR-2009.";
        reference
          "IEEE 802.1AR-2009: IEEE Standard for Local and
             metropolitan area networks - Secure Device Identity";
      }

Assuming there are no objections, I'll add this input parameter to the to-be-posted -20 draft.



PS: I'm still waiting for yang-data-ext to be adopted, in order to resolve the rc:yang-data LC issue.  I just pinged the NETMOD chairs on it again...


Thanks,
Kent