Hi John,

> On Jan 15, 2025, at 12:23 AM, John Scudder <[email protected]> wrote:
> 
> Hi Mahesh,
> 
> (And hoping not to tread on Éric’s toes here…)
> 
>> On Jan 14, 2025, at 11:55 AM, Mahesh Jethanandani <[email protected]> 
>> wrote:
> …snip…
>>>>> 2. While the YANG security considerations boilerplate update request seems
>>>>> otherwise reasonable, the desired format creates a MISREF.  This is a more
>>>>> general issue than just this specific document and is unlikely to be an
>>>>> intended side effect.  We await his advice on how to reconcile that issue.
>>>> 
>>>> What aspect creates a MISREF? The contents of the template or where the 
>>>> template reside? The latter can be an informative reference. No?
>>> 
>>> Your request was to "adjust my text to reflect those changes".  The updated
>>> document and section referenced leads with content in its CODE, again:
>>> 
>>> "This section is modeled after the template described in Section 3.7
>>> of [RFCAAAA]."
>>> 
>>> We call this sort of thing "boilerplate" because the expectation is you work
>>> from the content verbatim rather than "by inspiration".  
>>> 
>>> If your request is "go ahead and replace RFCAAAA with the current version of
>>> the draft text and cite it informationally, but otherwise use that format" -
>>> I can do so.  However, what I would expect the procedure to be is to copy
>>> the RFCAAAA and cite the draft normatively which would create a MISREF until
>>> the document is published as an RFC.
>> 
>> The problem we have is that the template text in Section 3.7 of RFC 8407 is 
>> wrong. For example, it cites Secure Shell (SSH) as [RFC6242], which is 
>> incorrect. SSH is [RFC4252], whereas RFC6242 is “Using the NETCONF Protocol 
>> over Secure Shell (SSH)." That is what the template in rfc8407-bis is trying 
>> to correct. 
>> 
>> RFCAAAA has been cited as informative [1] by plenty of documents, but none 
>> of them are RFCs as yet. Besides, some cite it normatively also. As such, I 
>> will have to defer to the more experienced ADs on this thread to see if they 
>> think that it can be cited informatively. If not, then unfortunately, we 
>> have no option but to go with MISSREF as the only option.
>> 
>> Cheers.
>> 
>> [1] 
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/referencedby/ 
>> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/referencedby/__;!!NEt6yMaO-gk!E6k-wR_DYu5u4K9ljHWxBOyFuuGz-t61gbVF-Gu5H9oXtRwx2JRNLadN9-u_MFFkcoXIC75MSUbgQDGOCPUx$>
> I think you mean “references the draft” not RFCAAAA. Let’s take a look at 
> https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/ 
> <https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-topo-yang/> since that 
> recently passed IESG review and therefore is presumably “good enough”. I 
> guess your suggestion that the present draft should emulate that one in terms 
> of its citation style. For convenience, here’s what that one has:
> 
> “This section is modeled after the template described in Section 3.7 of 
> [I-D.ietf-netmod-rfc8407bis 
> <https://www.ietf.org/archive/id/draft-ietf-ccamp-otn-topo-yang-20.html#I-D.ietf-netmod-rfc8407bis>].”
> 
> In other words, what Jeff said:
> 
>>> If your request is "go ahead and replace RFCAAAA with the current version of
>>> the draft text and cite it informationally, but otherwise use that format" -
>>> I can do so.  
> 
> 
> AFAICT from trying to unpack this conversation, yes that is your request, yes 
> the IESG has approved documents with that citation style, yes Jeff should go 
> ahead and do that. Please yell if that’s not right.

That was my suspicion too, but I did not think of checking the RFC Editor queue 
for an example. Thanks for confirming.

Cheers.

> 
> —John


Mahesh Jethanandani
[email protected]






Reply via email to