Hi Martin,
> I have now filed an errata for this issue.
Ack.
> However, I remember that we had a discussion on whether we should
> accept erratas on YANG modules or not. The YANG module exist in
> various places outside of the RFC, such as the IANA site, and it won't
> be corrected there.
Yes, two thoughts:
- this erratum could marked as document update required.
- we may want to publish a -biz soon
>> In that case, there might be two issues:
>>
>> 1) the description statement excluding CA certs (mentioned before)
>> 2) `mandatory true` should be `mandatory false` ?
>
> I don't understand 2), can you elaborate?
First, let me demote (2) from a SHOULD to a MAY, since there is a workaround.
The thinking is that it may be common for deployments to use the same
"cert-to-name" strategy everywhere (e.g., IDevID certificates), and hence there
is no need to specify a "fingerprint" in order to lookup what strategy to use.
For these cases, it would be better to not specify a fingerprint at all. If
this remains "mandatory true", the best fallback would be to specify the
fingerprint for the *root* CA certs spanning the end-entity certs connecting to
that endpoint.
New issue. Why isn't "list cert-to-name" order-by user as opposed to:
"The id specifies the order in which the entries in the
cert-to-name list are searched. Entries with lower
numbers are searched first.";
I suspect that this is for SNMP compatibility, but then your earlier response
on this thread said regarding "mandatory true" and empty fingerprint values
suggested that more appropriate YANG-isms should be used, in general.
"ordered-by user" vs "ordered by id" seems like such a case.
Kent // contributor
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
