Re: [netconf] Murray Kucherawy's No Objection on draft-ietf-netconf-trust-anchors-23: (with COMMENT)

[Kent Watsen <[e-mail]>]

Hi Murray,

Please find response inline.

Kent


> On Feb 1, 2024, at 2:47 AM, Murray Kucherawy via Datatracker <[e-mail]> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-netconf-trust-anchors-23: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netconf-trust-anchors/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Roman's DISCUSS position.
> 
> ====
> 
> Additional comments from incoming ART AD, Orie Steele:
> 
>> A "choice" statement is used to expose the various options. Each option is
> enabled by a "feature" statement. Additional "case" statements MAY be augmented
> in if, e.g., there is a need to reference a bag in an alternate location.
> 
> Reads a bit awk.

The above is a duplicate from previous comment.


> "http://example.com/ns/example-truststore-usage" prefer to see https, same
> comment regarding `.example` TLD.

I converted to “https” everywhere, per a previous comment.
Hoping to keep “example.com” as it seems still allowed and is more well-konwn.


>> Reference of a public key bag in the truststore inlucding
>         the certificate to authenticate the TLS client.
> 
> spelling.

Typo in “including” fixed.


>> Servers that wish to define alternate truststore locations
>> SHOULD augment in custom 'case' statements enabling
>> references to those alternate truststore locations.
> 
> What happens to the model, if they do not? (Why not MUST).

Good point.  Changed to a MUST.


>> A description for this bag public keys.  The intended purpose for the bag
> SHOULD be described.
> 
> Why not MUST? (or simply remove the normative).

I agree that, if the “description” field is populated, it MUST do that.
Changed to MUST.

That said, please note that the “description” field is not mandatory, which is fine because, in some deployments, the “name” field may be descriptive enough.


> I am surprised to not see any normative guidance regarding thumbprints or
> "canonical names" for certificates.

Why would this draft do that?  Are there not other drafts guiding cert best practice?

Maybe I misunderstand, does this regard the “name” field encoding a cert-value, being discussed elsewhere?


Thanks again,
Kent