===
Section 2.2
You have this text: Some implementation may choose to convey it inside a script
(e.g., SZTP's "pre-configuration-script")
I'd like to see a reference to RFC 8572 here on where this is defined. I
realize I'm being pedantic here, but there are a number of SZTP documents, and
I think having a reference helps.
I added the sentence "SZTP onboarding information is described in Section 2.2 of [RFC8572].” to the end of that paragraph. Is this what you had in mind?
Perfect. That's exactly what I was looking for.
===
Module's main description:
You mention SZTP's 'onboarding-information' response, but this isn't a formal
YANG node. That node is conveyed-information. Is it worth clarifying that
here in the module description like you did in draft text in section 2.2? I
have the same comment in the description of "container csr". The quoted and
hyphenated "onboarding-information" might make one think that there is a node
that contains this.
'onboarding-information’ *is* a formal node - it is described here: https://datatracker.ietf.org/doc/html/rfc8572#section-2.2.
Just the same, I converted “ ‘onboarding-information’ ” to “onboarding information” (without the hyphen or single quotes, as it is also defined as a term that way in RFC 8572.
The clarification "onboarding-information" (encoded inside the "conveyed-information" node)" found in 2.2 was/is to help the reader with the following example snippet that doesn’t actually show the "onboarding-information” node because it is hidden inside the “base64encodedvalue==“ value. Makes sense?
{"ietf-sztp-bootstrap-server:output" : {
"reporting-level": "verbose",
"conveyed-information": “base64encodedvalue =="
}
}
Ah, I had my head buried in the YANG modules, and I didn't read the RFC8572 text closely enough. I had missed the "conveyed-info" module. Regardless, I think the module update is fine.
In leaf cert-req-info's description:
The word “another” (with respect to the 400 Server Error) doesn’t follow here
unless one refers to the csr-support presence container above. I think
dropping it might make this text a bit less confusing (or copying similar text
from the csr-support node’s description.
Replaced “another 400 (Bad Request) response” with "a 400 (Bad Request) response containingvanother 'request-info' structure.”
Better?
Yes. Well, it's better in the diff. You have a typo above :-).
Thanks!
Joe
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
