Hi Dale,
> On Jan 29, 2024, at 2:15 PM, Dale R. Worley <worley@xxxxxxxxxxx> wrote:
>
> Kent Watsen <kent+ietf@xxxxxxxxxx> writes:
>> [...]
>
> All of the fixes look good to me and require no comment, except the
> following items:
>
>>> Table 1: Label to RFC Mapping
>>>
>>> In -28, this caption appears visually to be the caption of both the
>>> dependency diagram at the top of page 5 and the label-to-RFC mapping
>>> table at the bottom of page 5, and so probably should be amended to
>>> describe both of them together.
>>
>> s/Label in Diagram to RFC Mapping/Label to RFC Mapping/
>>
>> Good enough?
>
> Since the title on the table in -28 already is "Label to RFC Mapping", I
> think you didn't write here what you meant.
Whoops - I had that backwards. Was supposed to be:
s/Label to RFC Mapping/Label in Diagram to RFC Mapping/
>>> 3.10. The "ietf-crypto-types" YANG Module
>>>
>>> The title of this section seems to be uninformative given that 'The
>>> "ietf-crypto-types" YANG Module' is the subject of the entire
>>> document. Is this title what was intended?
>>
>> For the most part, yes, I see your point.
>> Maybe s/The/For the/ or s/The/Regarding the/?
>>
>> In any case, be aware that there exists an IETF-defined template
>> for the Security Considerations section that is to be used for each
>> YANG module defined in a draft. So, if a draft defines the three
>> modules: ietf-foo-common, ietf-foo-client, and ietf-foo-server, the
>> Security Considerations section contains the three subsections:
>>
>> The "ietf-foo-common" YANG Module
>> The "ietf-foo-client" YANG Module
>> The "ietf-foo-server" YANG Module
>>
>> Each containing an instance of the template for that YANG module.
>
> Ah, yes, and having this section hierarchy:
>
> Security Considerations
> The "ietf-foo-common" YANG Module
> The "ietf-foo-client" YANG Module
> The "ietf-foo-server" YANG Module
>
> is quite clear. ... Even setting the title of the section to
> "3.10. Security considerations for the the "ietf-crypto-types" YANG
> Module" reads oddly as a subsection of "Security
> considerations". ... What you *mean* is "RFC 8407 security
> considerations section template", but that's too long. Perhaps
> "Security considerations template"? "Template for the
> "ietf-crypto-types" YANG Module"?
Now says "Template for the "ietf-crypto-types" YANG Module” (in all nine drafts)
> And there's an oddity that although 3.10 is the instantiated template
> from RFC 8407/BCP 216 section 3.7.1, the draft doesn't reference RFC
> 8407/BCP 216. Could you add e.g. [RFC 8407] as a reference at the very
> beginning of 3.10?
I added the following sentence to the top of each such section (in all nine drafts)
<t>This section follows the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>
>>> Some of the readable data nodes defined in this YANG module may be
>>> considered sensitive or vulnerable in some network environments. It
>>> is thus important to control read access (e.g., via get, get-config,
>>> or notification) to these data nodes. These are the subtrees and
>>> data nodes and their sensitivity/vulnerability:
>>>
>>> The use of "These" in the last sentence does not have an unambiguous
>>> referent as I read it. Perhaps "These subtrees/data nodes have these
>>> particular sensitivities/vulnerabilities:" Similar considerations
>>> apply to the last sentence of:
>>>
>>> Some of the operations in this YANG module may be considered
>>> sensitive or vulnerable in some network environments. It is thus
>>> important to control access to these operations. These are the
>>> operations and their sensitivity/vulnerability:
>>
>> This text comes from the aforementioned template. That said, I agree
>> that it's not great. Perhaps, even better, "*The following* subtrees and
>> data nodes have particular sensitivities/vulnerabilities"?
>
> Yes, your version is clearer.
Fixed (in all nine drafts)
> (And the template should be updated that
> way, too!)
Maybe you can file an Errata against RFC 8407?
>
> Dale
PS: edits are in my local copy - not published yet…
Kent
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
