Apologies for the delay.
I looked at a diff of the -32 and -34 (proposed) version. It looks great.
I appreciate the work this must have taken. I think this takes care of the
majority of my comments.
The only comment that I think I have left is a warning in the Security
Considerations about the strength of the key provisioned and the method of
provision. Perhaps something like:
"Keys generated and distributed out of band for the purposes
described in this specification are generally limited in the security they
can provide. It is essential
that these keys are selected well, and protected when
stored."
This was just a quick example I found in RFC 8018 (I modified it). If you
have better text, I'm fine with that too.
Nits:
Places where 'strong' still exist.
Section 5, para 3:
Section 7, #1 and last para:
Section 8.3 Yang module - twice in description fields.
Section 10.1, first sentence: (maybe 'more'? 'better'?)
Deb
On Wed, Oct 1, 2025 at 12:57 PM Jeffrey Haas <[email protected]> wrote:
> Deb,
>
>
> On Sep 23, 2025, at 8:41 AM, Deb Cooley <[email protected]> wrote:
>
>> > ----------------------------------------------------------------------
>> > DISCUSS:
>> > ----------------------------------------------------------------------
>> >
>> > A discuss is merely the start of a conversation.
>> >
>> > This specification is misleading as it stands today:
>> > 1. 'strong authentication': none of the mechanisms mentioned
>> are
>> > 'strong'. Please find another word/phrase to describe.
>>
>> We're aware of the irony of the choice of terminology. For purposes of
>> the document it's solely intended to be "the strong one of the pair".
>> Similarly "less computationally intensive" is overly long although somewhat
>> more precise. Our hope was we'd reach this portion of the process and
>> receive the suggested "this is what you should call it instead".
>>
>
> [DC]: a few options: 'more computationally intensive', 'keyed hash
> authentication', 'hash based authentication'. These are all long, but this
> system has so many authentication options, it is hard to choose a single
> word descriptor.
>
>
> Attached is a candidate version -34 change set that addresses this desire
> to avoid the word "strong". In particular, it chooses the "more
> computationally intensive" term and uses abbreviations MCI/LCI in places to
> try to avoid the verbosity in places. It also tries to clarify the
> concerns about discussing strength.
>
> I'll push this set to author review in github once we've processed the
> prior smaller changes. The attached diff is based on that text. If you
> have feedback that would be better addressed using github review
> procedures, I'll stage the pull request early.
>
> -- Jeff
>
>
