Subject: Re: [Netconf] notes to draft-ietf-netconf-zerotouch-14

From: Radek Krejčí <[email-masked]>
Date: Tue, 1 Aug 2017 14:03:52 +0200

Hi Kent,

Dne 26.7.2017 v 19:06 Kent Watsen napsal(a):
> draft-ietf-netconf-zerotouch-14
>
> - section 7.2 seems as, kind of, duplication ofsection 6.3
>
> <KENT> True, but the one in 6.3 includes e.g. the "NMS" to tie it into the workflow examples in Section 6.  There is a separate discussion regarding if Section 6 should be moved to the Appendix, since it's not normative, but some prefer it in the draft.  My only thought here is that, if Section 6 were moved to the Appendix, would it then be okay to keep this workflow?

currently, 7.2 seems to be normative (device ... MUST support ...), but is it really the intention? I mean, are there some interoperability (or other) issues when device does not follow (or somehow modify) the boot sequence? Since 6.3 and 7.2 describe the same part of the process, why one is supposed to be normative and the other non-normative? But after all, I'm actually fine with keeping 7.2 in document, I'm just trying to simplify readers' life :)

>
> - IDevID - not sure if the draft expects something about its uniqueness. From my perspective, vendor is actually allowed to put the same IDevID into all its devices and there will not be any (security) issue, right? It just means that bootstrap server cannot distinguish such device so they all get the same data. Or am I missing something? Anyway, I would appreciate some explicit note about IDevID uniqueness.I know that in the most cases there is some unique number hardcoded in the device, but in some cases the device can miss something like this and then vendor would have to modify the software of each of them.
>
> <KENT> IDevID is defined by IEEE 802.1AR-2009 as an X.509 certificate that encodes "globally unique per-device identifiers".  In particular, it's a 2-tuple of a manufacturer-id field and a serial-number field.  Two devices claiming to have the same IDevID would be a security issue, as one could then impersonate the other.  All this to say, IDevID is very much unique and also very much a hardware thing.  That said, since the IDevID is being used to enable a device to authenticate itself to a bootstrap server, for which options may exist.  For instance, while not described by the draft, because it's not technically *zero* touch, a software-based solution could prompt the installer for something like a password that the device uses to authenticate itself to the bootstrap server with instead...

ok, maybe extending the draft text this way would help to understand it. Maybe just extend description in 1.2:

... as the secure device identifier ... -> ... as the globally unique secure device identifier ...

>
> - at several places there is a note about sending notification about the bootstrap process to the bootstrap server. I was wondering how RESTCONF client is sending notification to the RESTCONF server, finally at one place there is note that it sends "notification" action, so then I was clear, but naming action "notification" maybe confusing :)It would be great if some other name could be used for that.
>
> <KENT> yes, this was mentioned by others as well, but your idea to rename the action is new.  I think the action was called "progress-notification" before, which I had shortened for brevity.  Other ideas might be "bootstrap-status" or maybe "status-update".  Do you have a suggestion?

I would prefer to use some verb form - update-status, report-status, change-status

> [email-masked]
>
> - onboarding-information/boot-image/* - is it necessary to have it mandatory? I can imagine use cases when there is no boot image and the only bootstrap dataneeded is the configuration anydata content.
>
> <KENT> I think that it needs to be mandatory because how scripts are written and configuration is constructed may depend on the version of software running on the device.  Of course, if the software running on the device already matches the expected software-version, then the software-update progress would be a no-op.  Maybe we could provide the match as a regex instead to, for instance, say that any minor-version of a specific major-release is okay  (see next comment)

ok, but then it is software version / release, boot-image seems confusing to me. I would be fine with keeping the name for the container, but descriptions should be more general - "boot image" can be just a software package in a repository and hash-algorithm does not make sense then. ok, it can be augmented with key to verify repository/package, but the name could be even git hash and then what is the mandatory hash-algorithm?

> - onboarding-information/boot-image/name - there is a note about regexp - no, the naming convention can very vary for different vendors/use cases, keep it without pattern
>
> <KENT> The idea of the regex is to be able to match any vendor-specific format.  For instance, for JUNOS, I might write "17.2R[1-4].*" to match all 17.2-based 'R' release between 1 and 4.

ok, I misunderstood it, I actually thought you want to add pattern to its string type. There can be an issue with selecting regexp variant (there will be always someone willing to use a different one). Since the value is highly device/software-specific (I can't imagine using the same value for JUNOS and CISCO IOS), I would probably avoid precise specification of the regexp format and prefer just to mention regexp possibility in description but let the regexp support implementation-specific.

> [email-masked]
>
> - /device/unique-id - is the unique really necessary? I mean ID is widely understood as unique and in the schema it is defined as key, so I believe that just id would be fine
>
> <KENT> this field-name is a somewhat a holdover from before.  Since then, the draft has essentially turned to using "serial number" as its unique id (per DevID).  But, since serial-numbers may not be unique across manufacturers, a unique-id may be to be constructed using the 2-tuple [manufacturer, serial-number].  It is up to each manufacturer to determine if this is needed for themselves.

ok, probably I should study harder about the DevID, IDevID and serial numbers differences because I'm getting lost :)

Radek

---

From: Kent Watsen <[email-masked]>
Date: Fri, 4 Aug 2017 01:32:44 +0000

Hi Radek,

>> <KENT> True, but the one in 6.3 includes e.g. the "NMS" to tie it
>> into the workflow examples in Section 6.  There is a separate 
>> discussion regarding if Section 6 should be moved to the Appendix,
>> since it's not normative, but some prefer it in the draft.  My only
>> thought here is that, if Section 6 were moved to the Appendix,
>> would it then be okay to keep this workflow?
>
> currently, 7.2 seems to be normative (device ... MUST support ...),
> but is it really the intention? I mean, are there some interoperability
> (or other) issues when device does not follow (or somehow modify)
> the boot sequence? Since 6.3 and 7.2 describe the same part of the
> process, why one is supposed to be normative and the other non-
> normative? But after all, I'm actually fine with keeping 7.2 in
> document, I'm just trying to simplify readers' life :)

Others have raise questions regarding Section 6, e.g. if it should be in
the Appendix or not.  I agree that this segment seems repetitive, but
the question for you is, is it helpful, in a non-normative sense, towards
understanding the solution as a whole, or is it truly unhelpful altogether?
Please advise.

> - IDevID - not sure if the draft expects something about its uniqueness.
>
> From my perspective, vendor is actually allowed to put the same IDevID
> into all its devices and there will not be any (security) issue, right?

The IDevID must be globally unique - IEEE 802.1AR says so.  If devices
were allowed to have same ID, they could impersonate each other, which
would be a security violation.

> It just means that bootstrap server cannot distinguish such device so
> they all get the same data. Or am I missing something? Anyway, I would
> appreciate some explicit note about IDevID uniqueness. I know that in
> the most cases there is some unique number hardcoded in the device, 
> but in some cases the device can miss something like this and then
> vendor would have to modify the software of each of them.

Are you discussing ietf-zerotouch-bootstrap-server:device/unique-id or
something else?  To prime the pump, so to speak, the DevID spec says:

  7.2.8 subject

  The DevID subject field shall uniquely identify the device associated
  with the particular DevID credential within the issuer’s domain of
  significance. The formatting of this field shall contain a unique
  X.500 Distinguished Name (DN). This may include the unique device
  serial number assigned by the manufacturer or any other suitable
  unique DN value that the issuer prefers. In the case of a third-
  party CA or a standards certification agency, this can contain the
  manufacturer’s identity information.  The subject field’s DN encoding
  should include the “serialNumber” attribute with the device’s unique
  serial number.

> ok, maybe extending the draft text this way would help to understand
> it. Maybe just extend description in 1.2:
>

Done.

>> - at several places there is a note about sending notification about
>> the bootstrap process to the bootstrap server. I was wondering how
>> RESTCONF client is sending notification to the RESTCONF server,
>> finally at one place there is note that it sends "notification"
>> action, so then I was clear, but naming action "notification" maybe
>> confusing :)It would be great if some other name could be used for
>> that.
>
>> <KENT> yes, this was mentioned by others as well, but your idea to
>> rename the action is new.  I think the action was called "progress-
>> notification" before, which I had shortened for brevity.  Other
>> ideas might be "bootstrap-status" or maybe "status-update".  Do you
>> have a suggestion?
>

Verb-form for RPC/action names are goodness.  I wonder if rfc6187bis 
should say anything about it.  As for the name itself, I don't think
"status" connotes the right meaning.  Here, the device is providing
a progress update...so how about "update-progress"?

>>> - onboarding-information/boot-image/* - is it necessary to
>>> have it mandatory? I can imagine use cases when there is no
>>> boot image and the only bootstrap data needed is the
>>> configuration anydata content.
>
>> <KENT> I think that it needs to be mandatory because how scripts
>> are written and configuration is constructed may depend on the
>> version of software running on the device.  Of course, if the
>> software running on the device already matches the expected
>> software-version, then the software-update progress would be a
>> no-op.  Maybe we could provide the match as a regex instead to,
>> for instance, say that any minor-version of a specific major-
>> release is okay  (see next comment)
>
> ok, but then it is software version / release, boot-image seems
> confusing to me. I would be fine with keeping the name for the
> container, but descriptions should be more general - "boot image"
> can be just a software package in a repository and hash-algorithm
> does not make sense then. ok, it can be augmented with key to
> verify repository/package, but the name could be even git hash
> and then what is the mandatory hash-algorithm?

I'm not following you entirely here.  I'm purposely using boot-image
(as opposed to software-image) as I'm trying to differentiate the
OS-software from optional packages that might be installed on top
of the OS.  But even then, it's not just the OS (e.g., linux), but
some software build that includes the OS + some core set of packages
that is ultimately represented as a software build version (e.g.,
17R3.1b3).

>>> - onboarding-information/boot-image/name - there is a note about
>>> regexp - no, the naming convention can very vary for different
>>> vendors/use cases, keep it without pattern
>>
>> <KENT> The idea of the regex is to be able to match any vendor-
>> specific format.  For instance, for JUNOS, I might write 
>> "17.2R[1-4].*" to match all 17.2-based 'R' release between 1 and 4.
>
> ok, I misunderstood it, I actually thought you want to add pattern
> to its string type. There can be an issue with selecting regexp
> variant (there will be always someone willing to use a different
> one). Since the value is highly device/software-specific (I can't 
> imagine using the same value for JUNOS and CISCO IOS), I would
> probably avoid precise specification of the regexp format and
> prefer just to mention regexp possibility in description but let
> the regexp support implementation-specific.

Okay, but before getting to the details of a regex format, we should
discuss if it's a good idea at all.  The safest (most conservative)
thing is to always have an exact match (no regex).  Allowing the 
value to encode a range of revisions means that matches might occur
more often (e.g., 17.2R[1-4]), thereby negating the need for the
device to download/install a new boot-image, but it has the cost of
something going wrong.  For instance, maybe 17.2R4 broke compatibility
in some way that causes the bootstrap to fail.  Of course, in 
production environments, I'd expect all the variations supported by
the regex expression to be tested and, of course, a regex can also
be a simple string for those that don't want the ambiguity.  Thoughts?

>>> - /device/unique-id - is the unique really necessary? I mean ID
>>> is widely understood as unique and in the schema it is defined
>>> as key, so I believe that just id would be fine
>>
>> <KENT> this field-name is a somewhat a holdover from before.  
>> Since then, the draft has essentially turned to using "serial
>> number" as its unique id (per DevID).  But, since serial-numbers
>> may not be unique across manufacturers, a unique-id may need to
>> be constructed using the 2-tuple [manufacturer, serial-number].
>> It is up to each manufacturer to determine if this is needed
>> for themselves.
>
> ok, probably I should study harder about the DevID, IDevID and
> serial numbers differences because I'm getting lost :)

It is pretty involved, but reading 802.1AR-2009, which defines the
DevID, is highly recommended for LC reviewers of this draft.

Thanks again,
Kent

---

From: Radek Krejčí <[email-masked]>
Date: Mon, 7 Aug 2017 17:13:54 +0200

Hi Kent,

> understanding the solution as a whole, or is it truly unhelpful altogether?

Section 6 is definitely helpful, so please keep it at least at appendix. Even with section 6 in appendix, I don't think that 7.2 should be necessary - even in case the sequence is modified, the zerotouch mechanism can be still used by the device and there will be no interoperability issue. It is very helpful to have some description how the author believed it should work (sec 6/appendix), but I believe that in this case it can be "just" inspiration for developers, not something that MUST be supported.

> a progress update...so how about "update-progress"?

ok, goodand also good point about rfc6187bis

> that is ultimately represented as a software build version (e.g.,

It's just a naming issue. In my understanding, "image" is a complete set of software, so when applied I'm getting the complete sw environment from some template/sample. So it fits for products provided as boxes (e.g. home router, NAS, ...), but there are use cases when the NETCONF server is just an additionally installed software. So, the boot-image is just the NETCONF server (optionally together with some other software tightly connected with it) package to be updated and then the "image", as I understand it, does not fit much.But probably just clarifying the intention in description would be enough.

> be a simple string for those that don't want the ambiguity.  Thoughts?

as I stated - let it implementation-specific, so allow generic strings. In this case the client must know the server details anyway, since it specifies the compatible version of the server's software so it should know how the specific string will be evaluated by the server.

Radek

---

From: Kent Watsen <[email-masked]>
Date: Mon, 14 Aug 2017 23:46:33 +0000

Hi Radek,

> Section 6 is definitely helpful, so please keep it at least at 
> appendix. Even with section 6 in appendix, I don't think that
> 7.2 should be necessary - even in case the sequence is modified,
> the zerotouch mechanism can be still used by the device and there
> will be no interoperability issue. It is very helpful to have 
> some description how the author believed it should work 
> (sec 6/appendix), but I believe that in this case it can be
> "just" inspiration for developers, not something that MUST be
> supported.

I moved Section 6 to the Appendix.

But I think that Section 7.2 is needed.  This section defines the
high-level execution logic.  But maybe it's overstating things?  
For instance:

1) Rather than keying off "factory default configuration", we
could more generally say "when it's configured" and then, 
separately, say that the factory-default MUST configure it.  This
changes the device from needing to check if *any* config change
happened to the device just needing to check if zerotouch is
enabled (a much simpler test).

2) Also, the current logic might come off looking more linear 
than it should be.  For instance, a device may be manually-
provisioned at any time and, as soon as it does, the zerotouch
logic should switch off (not necessarily wait until all the
sources for bootstrapping data have been checked).

What do you think, is it salvageable?  ;)

> ok, goodand also good point about rfc6187bis

Changed to "update-progress".

Andy, if you're watching, what do you think about adding an RPC/action
naming recommendation to rfc6187bis?

> It's just a naming issue. In my understanding, "image" is a
> complete set of software, so when applied I'm getting the 
> complete sw environment from some template/sample. So it fits
> for products provided as boxes (e.g. home router, NAS, ...), 
> but there are use cases when the NETCONF server is just an 
> additionally installed software. So, the boot-image is just 
> the NETCONF server (optionally together with some other 
> software tightly connected with it) package to be updated
> and then the "image", as I understand it, does not fit much.
> But probably just clarifying the intention in description
> would be enough.

No, we are talking about boxes that have, e.g., IDevID
certificates.  In some interpretations, this might apply
to virtual devices (i.e., running inside a hypervisor)
with virtual IDevIDs, but the technology to do that isn't
built into the hypervisors yet.  I think that "image" or
"boot-image" is exactly right here.

> as I stated - let it implementation-specific, so allow generic
> strings. In this case the client must know the server details
> anyway, since it specifies the compatible version of the
> server's software so it should know how the specific string
> will be evaluated by the server.

Oh, sorry, that wasn't clear.  So, you're saying that each vendor
may have their own fancy-match syntax, or none at all, but it's
always a vendor-specific format?  Or do you mean that we should
mandate an exact string-match every time?

Kent