Subject: [netconf] AD review of draft-ietf-netconf-sztp-csr

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 21 Jun 2021 08:50:24 +0000

AD Review of draft-ietf-netconf-sztp-csr-03

Disclaimer, I am not a security expert and the security specific aspects
(e.g., the precise details of how the CSRs are encoded) is beyond my knowledge.
Hopefully this will be sufficiently checked by SEC DIR reviews and SEC AD,
whilst also acknowledging the expertise of the authors!

My main questions really relate to REST semantics.

1. It is always the case that the SZTP-client must do the handshake with
the server (i.e, populating the csr-support container, then getting a 400 error back,
before making the actual bootstrap request), or is it acceptable for the SZTP-client
to guess on acceptable parameters, and send a single request?  Obviously, this cannot
work in all cases, but I want to check whether it is allowed (or explicitly disallowed)
in any cases.

2. Section 2.2:
   Assuming the SZTP-server wishes to prompt the SZTP-client to provide
   a CSR, then it would respond with an HTTP 400 (Bad Request) error
   code:

I wonder whether returning a 400 "Bad Request" error is really the best return code, i.e., 
it wasn't clear to me whether this requesting the capabiltiies is really an error.
Did you consider potentially using other return codes?  Possibly:
  300 Multiple Choices,
  403 Fobidden,
  406 Not Acceptable

3. Does it make sense to recommend a default certificate-request-format that clients should
support, or does it make sense to not prioritize any particular certificate format, effectively
requiring that a generic server needs to support them all?

4. References.  RFC 3688 probably should be normative for the XML registry, noting that
RFC 6020 is normatively referenced.

Nits:

5. 
In the example data, would it helpful to add a sentence to explain
               "base64encodedvalue1=",
               "base64encodedvalue2=",
               "base64encodedvalue3="
			
Actually, given this convention is used in various places, there is a choice as to whether
to add a sentence to each example, or perhaps in the introduction.

6.
3.1.3.  Replay Attack Protection

   This RFC enables an SZTP-client to announce an ability to generate
   new key to use for its CSR.
   
"a new key"

7. In Security Considerations:
   Generating a new key each time enables the random bytes used to
   create the key to serve the dual-purpose of also acting like a
   "nonce" used in other mechanisms to detect replay attacks.
   
I wasn't clear to me what the two purposes are here.  One is acting like
a "nonce", but what is the other purpose?

8.
   In the case the SZTP-client must choose between the asymmetric key
   option versus a shared secret for origin authentication, it is
   RECOMMENDED that the SZTP-client choose using the asymmetric key
   option.
   
"In the case the" => "In the case that the ...

Terminology:
Should you add LDevID or IDevID

Potential spelling warnings:
descendent

Grammar Warnings (from tool):
Section: 2.3, draft text:
This module augments an RPC defined in [RFC8572], uses a data type defined in [I-D.ietf-netconf-crypto-types], has an normative references to [RFC2986] and [ITU.
Warning:  The plural noun "references" cannot be used with the article "an". Did you mean an normative reference or normative references?
Suggested change:  "an normative reference"

Section: 3.1.4, draft text:
Consistent with the recommendation presented in Section 9.6 of [RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input parameter to an untrusted SZTP-server. 
Warning:  The modal verb 'SHOULD' requires the verb's base form.
Suggested change:  "pass"

Section: 3.1.5, draft text:
All of the certificate request formats defined in this document (e.g., CMC, CMP, etc.), not including a raw PKCS#10, support origin authentication.
Warning:  Consider using all the.
Suggested change:  "All the"

Section: 3.1.5, draft text:
Typically only one possible origin authentication mechanism can possibly be used but, in the case that the SZTP-client authenticates itself using both TLS-level (e.g., IDevID) and HTTP-level credentials (e.g., Basic), as is allowed by Section 5.3 of [RFC8572], then the SZTP-client may need to choose between the two options.
Warning:  Did you forget a comma after a conjunctive/linking adverb?
Suggested change:  "Typically,"

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Jun 2021 14:45:03 +0000

Hi Rob,

Thank you for your review!

> whilst also acknowledging the expertise of the authors!

Ack.

> work in all cases, but I want to check whether it is allowed (or explicitly disallowed)

A handshake is not strictly always required, as:

1) it’s possible the device could automatically generate a CSR using the same certificate information as present in its IDevID certificate.  This would allow the signature on the resulting LDevID to be from the deployment’s CA infrastructure, which has value in and of itself, but the LDevID would not contain any new/different/interesting fields, and hence might have limited appeal.

2) it’s possible that the device could automatically generate unique keys and associated p10, cmc, cmp structures (i.e., every permutation of key-algorithm and request-structure the device supports), but this would be expensive on the device, especially without knowledge if the deployment’s infrastructure even cares to set an LDevID on the device.

For these reasons the authors felt it best to introduce the dialog presented in the draft.

> Did you consider potentially using other return codes?  Possibly:

I did before look at all the 4xx codes.  I was initially drawn to 412 Precondition Failed, but noted that it is specific to HTTP request header fields.   As for the others you mention, the semantics of 403 Forbidden is that the request should not be repeated, which isn’t out case, and 406 Not Acceptable regards the use of the HTTP “Accept” headers, which aren't in play here either.  That said, 300 Multiple Choices does appear to be a better if not perfect option, so I made that change in my local copy.

> requiring that a generic server needs to support them all?

No default format is possible, as it’s completely dependent on what CA infrastructure the particular deployment has.

The impact to generic servers is minimal as, for the most part, they simply pass the structure to the deployment’s CA and subsequently relay the response structure to the device.  Only if the SZTP-server wishes to inspect that contents would it then need to step up to understanding all the formats.

> RFC 6020 is normatively referenced.

Really?  I tend to disagree as I thought the litmus test for if something were normative was if it had to be understood in order to implement the RFC.

You raise an interesting point about RFC 6020 being Normative, as I see that it is NOT normative in at least one of my other drafts.  I think that it is a reasonable position that, if the RFC 6020 reference is only present in the IANA Considerations section, then it is INFORMATIVE as far as the draft as a whole goes.  Thoughts?

> to add a sentence to each example, or perhaps in the introduction.

Adding a sentence to each example would be ideal, but a ton of work, especially considering my needing to propagate it to the suite of client-server drafts as well.

Adding something like the following to the Introduction section wouldn’t be too much work:

1.3.  Conventions

   Various examples used in this document use a placeholder
   value for binary data that has been base64 encoded (e.g., 
   "base64encodeddata==“).  This placeholder value is used
    as real base64 encoded structures are often many lines
    long and hence distracting to the example being presented.

Thoughts?

>   new key to use for its CSR.

Fixed

> a "nonce", but what is the other purpose?

:laugh:  The original first purpose is, of course, to generate a new key at all, as opposed to each time.   Please provide suggested text if you still think it can be improved.

> "In the case the" => "In the case that the ...

Fixed.

> Should you add LDevID or IDevID

Maybe, but note that this draft (as with RFC 8572) carefully refers to “identity certificates”, of which IEEE 802.1AR DevIDs are mere examples of such, but by no means the only possibility.   It’s unclear if promoting such an ancillary reference to a top-level term is appropriate.  Currently, as I’m sure you’re aware, the draft has a reference (i.e., an <xref>) where these values are used…admitted, likely more times than necessary, such that I wouldn’t be surprised if the copyeditor were to eliminate all but the first references.  Thoughts? Please advise.

> Potential spelling warnings:

Fixed.

> Suggested change:  "an normative reference"

Fixed.

> Warning:  The modal verb 'SHOULD' requires the verb's base form.

Fixed.

> Suggested change:  "All the"

Fixed…and I learned something new :)

> Suggested change:  "Typically,"

Fixed.

> Rob

K.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 21 Jun 2021 15:12:04 +0000

Hi Kent,

Thanks.

Please see inline ...

> -----Original Message-----
> From: Kent Watsen <[email-masked]>
> Sent: 21 June 2021 15:45
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: [email-masked]; [email-masked]; netconf-
> [email-masked]
> Subject: Re: AD review of draft-ietf-netconf-sztp-csr
> 
> Hi Rob,
> 
> 1) it’s possible the device could automatically generate a CSR using the same
> certificate information as present in its IDevID certificate.  This would allow
> the signature on the resulting LDevID to be from the deployment’s CA
> infrastructure, which has value in and of itself, but the LDevID would not
> contain any new/different/interesting fields, and hence might have limited
> appeal.
> 
> 2) it’s possible that the device could automatically generate unique keys and
> associated p10, cmc, cmp structures (i.e., every permutation of key-algorithm
> and request-structure the device supports), but this would be expensive on
> the device, especially without knowledge if the deployment’s infrastructure
> even cares to set an LDevID on the device.
> 

Okay, I'm wondering whether a sentence to that effect would be helpful, since when I read the draft, my impression was that a handshake was always expected, but perhaps I'm missing something?

> I did before look at all the 4xx codes.  I was initially drawn to 412
> Precondition Failed, but noted that it is specific to HTTP request header
> fields.   As for the others you mention, the semantics of 403 Forbidden is that
> the request should not be repeated, which isn’t out case, and 406 Not
> Acceptable regards the use of the HTTP “Accept” headers, which aren't in
> play here either.  That said, 300 Multiple Choices does appear to be a better
> if not perfect option, so I made that change in my local copy.
> 
Ack.

> No default format is possible, as it’s completely dependent on what CA
> infrastructure the particular deployment has.
> 
> The impact to generic servers is minimal as, for the most part, they simply
> pass the structure to the deployment’s CA and subsequently relay the
> response structure to the device.  Only if the SZTP-server wishes to inspect
> that contents would it then need to step up to understanding all the formats.
> 
Ack.

> Really?  I tend to disagree as I thought the litmus test for if something were
> normative was if it had to be understood in order to implement the RFC.

I guess the logic here is that you need to understand RFC 6020 to understand the registry that is having entries added (given that RFC 7950 doesn't define the registry).

But, as per below, I'll check with the IESG on this one.

> 
> You raise an interesting point about RFC 6020 being Normative, as I see that
> it is NOT normative in at least one of my other drafts.  I think that it is a
> reasonable position that, if the RFC 6020 reference is only present in the
> IANA Considerations section, then it is INFORMATIVE as far as the draft as a
> whole goes.  Thoughts?

Let me check with the IESG and get back to you on this one.  Although, perhaps worth noting that both these references are normative in RFC 8343 (and they are only referenced from the IANA registry entries).

> Adding a sentence to each example would be ideal, but a ton of work,
> especially considering my needing to propagate it to the suite of client-server
> drafts as well.
> 

Looks good.

> :laugh:  The original first purpose is, of course, to generate a new key at all,
> as opposed to each time.   Please provide suggested text if you still think it
> can be improved.

When you put it that way, it is kind of obvious ;-)

You can either leave it as is, or perhaps a small tweak (moving also) might make it clearer:

   Generating a new key each time enables the random bytes used to
   create the key to also serve the dual-purpose of acting like a
   "nonce" used in other mechanisms to detect replay attacks.

> Maybe, but note that this draft (as with RFC 8572) carefully refers to “identity
> certificates”, of which IEEE 802.1AR DevIDs are mere examples of such, but
> by no means the only possibility.   It’s unclear if promoting such an ancillary
> reference to a top-level term is appropriate.  Currently, as I’m sure you’re
> aware, the draft has a reference (i.e., an <xref>) where these values are
> used…admitted, likely more times than necessary, such that I wouldn’t be
> surprised if the copyeditor were to eliminate all but the first references.
> Thoughts? Please advise.

Okay.  I'm happy for you to leave this as is, this is pretty minor.

> > This module augments an RPC defined in [RFC8572], uses a data type
> defined in [I-D.ietf-netconf-crypto-types], has an normative references to
> [RFC2986] and [ITU.
> > Warning:  The plural noun "references" cannot be used with the article
> "an". Did you mean an normative reference or normative references?
> > Consistent with the recommendation presented in Section 9.6 of
> [RFC8572], SZTP-clients SHOULD NOT passed the "csr-support" input
> parameter to an untrusted SZTP-server.
> > All of the certificate request formats defined in this document (e.g., CMC,
> CMP, etc.), not including a raw PKCS#10, support origin authentication.

I think that "All of the" is also technically valid, but less common.  Perhaps this warning is a bit picky ...

> > Typically only one possible origin authentication mechanism can possibly
> be used but, in the case that the SZTP-client authenticates itself using both
> TLS-level (e.g., IDevID) and HTTP-level credentials (e.g., Basic), as is allowed
> by Section 5.3 of [RFC8572], then the SZTP-client may need to choose
> between the two options.

Thanks,
Rob

---

From: Kent Watsen <[email-masked]>
Date: Thu, 24 Jun 2021 15:26:21 +0000

Hi Rob,

Pruning down to just interesting bits…

> Okay, I'm wondering whether a sentence to that effect would be helpful, since when I read the draft, my impression was that a handshake was always expected, but perhaps I'm missing something?

I had an offline chat with my co-authors.   

As the YANG syntax stands, it’s possible for the SZTP-client to proactively send a CSR in it’s first message, but the value is so low that it’s almost a SHOULD NOT…and, if we’d caught it before, a “choice” statement may have been used to make it impossible (in order to simplify implementations).

That said, the first paragraph of the “description" statement for "container csr” states that a “csr” is sent in response to a “request-info” structure from the SZTP-server, which suggests that only a “csr-support” node can be proactively sent in the first message.  That only issue is that it doesn’t state that it is *only sent* in response to a “request-info” structure, leaving open a possibility that the first message MAY include both the “csr-support” *and* “csr” nodes.

Looking at just the draft-text (i.e., Ignoring the YANG), Section 2.1 says "In the order of their intended use”, which is suggestive, but the word “intended” leaves open the possibility for alternate uses.

My recommendation is to 1) remove the word “intended”, 2) add a choice statement to the YANG around the “csr-support” and “csr” nodes., and 3) strengthen the language in the last paragraph on page 4 to be more like the YANG, indicating that the “csr” node is sent only in response to a “request-info” from the SZTP-server. 

Thoughts?

> Let me check with the IESG and get back to you on this one.  Although, perhaps worth noting that both these references are normative in RFC 8343 (and they are only referenced from the IANA registry…

Ack, I will wait for your response on this item.

>>    long and hence distracting to the example being presented.

Applied.

>   "nonce" used in other mechanisms to detect replay attacks.

Applied.

> Okay.  I'm happy for you to leave this as is, this is pretty minor.

Leaving as is for now, but on the fence and would welcome thoughts from others.

K.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 24 Jun 2021 17:17:43 +0000

Hi Kent,

From: Kent Watsen <[email-masked]>
Sent: 24 June 2021 16:26
To: Rob Wilton (rwilton) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD review of draft-ietf-netconf-sztp-csr

Hi Rob,

1. It is always the case that the SZTP-client must do the handshake with
the server (i.e, populating the csr-support container, then getting a 400
error back,

before making the actual bootstrap request), or is it acceptable for the
SZTP-client

to guess on acceptable parameters, and send a single request?  Obviously,
this cannot

work in all cases, but I want to check whether it is allowed (or explicitly
disallowed)

in any cases.

For these reasons the authors felt it best to introduce the dialog presented in
the draft.

Thoughts?

I’m not sure.  It feels less RESTful (at least to me) to not allow the data to be provided as a single message, even if in practice that might not make sense in most (almost all) cases.  If you were using a separate YANG RPC to send the crs-support and get the request-info then only including the crs node in the bootstrapping data RPC then I would have no complaints.  I.e., it only feels strange to handle a transactional dependency within the data structures of a single RPC on what is nominally a stateless API.

Also, worth noting that using a separate YANG RPC to transmit the capabilities avoids the need to return an error.  It could just return success with the required information.  Was this approach considered at all, and would this be too big a change?  I’m not trying to create extra work for you, or delay this document …

If a separate RPC to get the capabilities in undesirable or infeasible then changing to a choice seems reasonable, but I would probably suggest keeping “intended” and probably keeping the language on page 4 somewhat open, i.e., not strictly locking it down to doing a handshake.

4. References.  RFC 3688 probably should be normative for the XML
registry, noting that

I didn’t really get a strong answer from other ADs on this.

Some of us felt that a normative reference is appropriate (because you need to understand the meaning of the registry that is being updated), and nobody objected to that characterization, but equally, some ADs didn’t think that Informative is necessarily wrong and it is probably not worth worrying about.

My recommendation is to make them normative, because that is what has been done for other RFCs with YANG modules (and consistency is good), and I don’t see any other ADs objecting to this approach.  I would regard this as the path of least resistance.

Thanks,
Rob

Nits:

5.

Actually, given this convention is used in various places, there is a choice as
to whether

Adding something like the following to the Introduction section wouldn’t be
too much work:

1.3.  Conventions

Thoughts?

Looks good.

Applied.

Applied.

Terminology:

Thanks,
Rob

K.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 24 Jun 2021 20:53:00 +0000

Rob,
 
> If a separate RPC to get the capabilities in undesirable or infeasible then changing to a choice seems reasonable, but I would probably suggest keeping “intended” and probably keeping the language…

I’m unsure it it makes sense to be concerned about the RESTfulness of this API.  Yes, it uses RESTCONF, but that is more out of convenience than any inherent need or desire for the API to be "RESTful”.  For instance, note that never could HTTP caches be used, as each message is distinct from any other.

That said, the “get-bootstrapping-data” RPC *is* idempotent, as the same POST (get-bootstrapping-data) returns the same response (assuming the server isn’t updated by an operator in the interim).  This is true also for when sending the “csr-support” and “csr” nodes, as described in the current document.   Of course, the idempotency of a YANG “rpc” statement isn’t that meaningful, relative to a RESTCONF "POST” used to edit configuration (e.g., like <edit-config>)…it’s likely fair to say that YANG RPCs are generally NOT RESTful.

Regarding using a separate RPC (returning a 2XX),  yes it was considered, however note that it is impossible for a generic device to anticipate what the specific deployment’s CA infrastructure will require in terms of 1) if *any* CSR is desired (most often not) and 2) when desired, what key-algorithm and CSR-attributes to use (rarely would the nearly-empty CSR a device could proactively send be viable).  

FWIW, if an out-of-band RPC were used, most of the time it would be a roundtrip for a no-op.  The in-band approach currently described is ideal in that it only consumes extra resources when needed.

That said, it does little harm for the draft to say (in addition to supporting the “in-band” mechanism) “a device MAY obtain the ‘request-info’ through an out-of-band mechanism outside the scope of this document”.  If this resolves your concern, then it’s an easy thing to add, and it may (to your point) provide some flexibility.  I think that it is consistent with your last paragraph above.  

I still think we should put “csr-support” and “csr” under a "choice” though, as the use-case for sending both at the same time is very small and it seems wrong to encourage/suggest it’s a good idea or to ask servers to have to support the case.

> My recommendation is to make them normative, because that is what has been done for other RFCs with YANG modules (and consistency is good), and I don’t see any other ADs objecting to this approach.…

Regarding "because you need to understand the meaning of the registry that is being updated”, “you" only refers to IANA, right?   I don’t think SZTP-client and/or SZTP-server developers need to know about IANA registries to implement the document, right again?   Consistency is good, yes, but not when consistently-wrong  ;)   [I’m speaking theoretically here, not to any particular group of people] 

This is not something I care to block on, but I do want Normative references to adhere to the principle of they are for  *implementors* (which doesn’t include IANA, IMO).  Related, there’s also the XML Registry (RFC 3688); should all documents publishing a YANG module have a Normative reference due to an IANA instruction?  [PS: some RFCs exist (i.e., published) already having RFC 3688 as Informative…I wouldn’t by surprised if some also exist having RFC 6020 as Informative, but a quick search didn’t find any]

BTW, other drafts in your queue have "Informative” set for RFC 6020, and one (netconf-notification-capabilities) incorrectly references RFC 7950 instead of RFC 6020 (As shepherd, I apologize for missing it, but it’s one thing to test if all the references provided are accurate [i.e., the doc *does* have a normative dependency on 7950], and another to see if any references were missing altogether…i.e., finding the gaps).

PS: there’s a separate email thread (Reuse of SZTP-CSR YANG definition in BRSKI-AE) regarding this document that is pending your feedback.  Ideally I can collect that and thus apply all updates in one shot.

K.

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 25 Jun 2021 10:51:08 +0000

Hi Kent,

Thanks for the extra details/explanation.  Please see inline …

Sent: 24 June 2021 21:53

Rob,

I hadn’t picked up on that nuance, and I agree that this makes an out of band approach less efficient and less helpful.

Not necessary.  I’m happy with your explanation as to why having it inband pragmatically makes more sense.

Agreed.

My understanding is more along these lines:

To fully understand everything in the RFC (i.e., definition of a normative reference), a reader of the RFC would need to understand what is meant by the draft adding an entry to a registry.  I.e., I’m not saying that a normative reference is needed to understand the act of adding a field to a registry, but it is necessary to understand the significance of why that matters.  In this case, the author should understand that adding an entry to module name registry means that it should be a (hopefully globally) unique name for that module and not defined in another RFC with an entirely different definition.  I.e., it should be possible to fetch the module from a reputable source by (name, revision) without having to extract it from the RFC (which would be required if it was not uniquely named).

A separate argument is that this document logically has a dependency on that IANA registry existing, and often those dependencies between documents are often indicated as normative references to indicate the dependency.

Note, there is also a bit of text in section 3.1 of RFC 8216 which indicates that a reference to the RFC definition the registry is expected, but not what sort of reference that should be.

This is not something I care to block on, but I do want Normative references to adhere to the principle of they are for  *implementors* (which doesn’t include IANA, IMO).  Related, there’s also the XML Registry (RFC 3688); should all documents publishing a YANG module have a Normative reference due to an IANA instruction?  [PS: some RFCs exist (i.e., published) already having RFC 3688 as Informative…I wouldn’t by surprised if some also exist having RFC 6020 as Informative, but a quick search didn’t find any]
I also do not intend to block the document on this point.  But I don’t think that normative references are just for implementors, they also define anything that is required to be stable for the published standard to be stable, i.e., to avoid relying on something that could change under our feet.
On the XML registry question, the answer is yes.   I’m suggesting that all documents that update registries should normatively reference the document that defines the registry.
More generally, I’m not entirely sure that the split between normative and informative references is that helpful and seems to cause more discussion that it is worth.  I would really prefer that there were 3 categories of references (or perhaps one of the existing categories are split into 2).

  1.  Docs that an author is recommended to read before reading this doc.
  2.  Docs that this document relies on for this specification to be correct.
  3.  Other related docs that readers of this document might find helpful.
Today, I see that normative references cover both (1) and (2), but for most readers I suspect that is only (1) that is really useful to them.  FWIW, I would put the 6020 and 3688 references into the second category.
Another question that comes up are references for optional features (which according to the current rules need to be normative).  If these are features that readers are unlikely to care about, then again I see them as fitting into (2) rather than (1).
I suspect that most RFCs today, handle the split between (1) and (2) in an adhoc way, by having the introduction describe briefly reference the docs that fit into (1).

BTW, other drafts in your queue have "Informative” set for RFC 6020, and one (netconf-notification-capabilities) incorrectly references RFC 7950 instead of RFC 6020 (As shepherd, I apologize for missing it, but it’s one thing to test if all the references provided are accurate [i.e., the doc *does* have a normative dependency on 7950], and another to see if any references were missing altogether…i.e., finding the gaps).
Thanks.  I think that I picked up on this in my AD review.

PS: there’s a separate email thread (Reuse of SZTP-CSR YANG definition in BRSKI-AE) regarding this document that is pending your feedback.  Ideally I can collect that and thus apply all updates in one shot.
Sorry, I had missed this thread.  I’ve now replied.
Thanks,
Rob

K.

---

From: Kent Watsen <[email-masked]>
Date: Mon, 28 Jun 2021 19:36:29 +0000

Hi Rob,

> Thanks for the extra details/explanation.  Please see inline …

<snip>

> I hadn’t picked up on that nuance, and I agree that this makes an out of band approach less efficient and less helpful.

No problem.

> Not necessary.  I’m happy with your explanation as to why having it inband pragmatically makes more sense.

Okay.

> I still think we should put “csr-support” and “csr” under a "choice” though, as the use-case for sending both at the same time is very small and it seems wrong to encourage/suggest it’s a good idea…

Update made the to my local copy.  

> My understanding is more along these lines:

<big snip>

> I suspect that most RFCs today, handle the split between (1) and (2) in an adhoc way, by having the introduction describe briefly reference the docs that fit into (1).

Agreed, but it is not for now  ;)

I just move RFC 3688 to Normative (RFC 6020 was already Normative)

> Sorry, I had missed this thread.  I’ve now replied.

I’ll post an update with both sets of changes. 

In the meanwhile, here's the Git commit: https://github.com/netconf-wg/sztp-csr/commit/1bb76e45163ec6a9d06657dcf689798e4409c712

> Rob

Cheers,
Kent

---

From: Kent Watsen <[email-masked]>
Date: Tue, 29 Jun 2021 20:49:22 +0000

Hi Rob,

Since been spinning on the below thread since we had it and am wondering if if would be best to ask for an HTTP expert review?   Please advise.

The reason being is that a close reading of "300 Multiple Choices" suggests that it’s used by an HTTP-server to indicate when there are multiple choices for a resource, whereas in this exchange, the “csr-support” node in the client’s POST effectively indicates that *it* has multiple choices for the server to choose from…

I’m beginning to wonder to the document might need to define a custom HTTP status code to properly indicate the semantics of the response…

Kent // contributor

---

From: Kent Watsen <[email-masked]>
Date: Tue, 29 Jun 2021 20:54:16 +0000

s/Since been/I’ve been/

K.

> On Jun 29, 2021, at 4:49 PM, Kent Watsen <[email-masked]> wrote:
> 
> Hi Rob,
>