Thanks for the comments. I (believe I) have addressed the issues raised here,
except for the one wrt augments. Wrt to augments, it is not clear to me what
when statement you'd like to see since this augment doesn't depend on the value
of another leaf node or the protocol-type etc. Or is is just a question of
moving up the if-feature statements?
Regards,Reshad.
On Friday, October 22, 2021, 04:38:00 AM EDT, t petch <ie...@btconnect.com>
wrote:
On 21/10/2021 23:06, Jeffrey Haas wrote:
> Tom,
>
> I've not hit "publish" yet...
>
>> On Oct 21, 2021, at 7:39 AM, t petch <ie...@btconnect.com> wrote:
>>
>> On 20/10/2021 22:00, Jeffrey Haas wrote:
>>>
>>>> On Oct 20, 2021, at 4:58 PM, Mahesh Jethanandani <mjethanand...@gmail.com>
>>>> wrote:
>>>>> On Oct 20, 2021, at 1:53 PM, Jeffrey Haas <jh...@pfrc.org
>>>>> <mailto:jh...@pfrc.org>> wrote:
>>>>>
>>>>> There's also a note in the nits that the security considerations netconf
>>>>> boilerplate is pointing to older RFCs, but I haven't seen updated
>>>>> boilerplate issued?
>>>>
>>>> See Section 3.7.1 of RFC 8407 here
>>>> <https://datatracker.ietf.org/doc/html/rfc8407#section-3.7.1>.
>>>
>>> Thank you, Mahesh.
>>>
>>> Addressing this would close the remaining nits.
>>
>> Manwhile ...
>>
>> Unless and until you register with IANA, you do not have a YANG module!
>
> Is there a bit of IANA boilerplate we're missing for the yang module?
Yes, see RFC8407 Appendix A
>>
>> The web reference is ood and insecure
>
> Previously discussed and blessed.
Well I see ADs raising DISCUSS when http: is used and not https: and I
think it a shame to create work for ADs!
And the life of tools.ietf.org can be measure in days, so ditto
>> The title in the 'reference' clause is not that of the I-D
>
> Which reference? The "RFC YYYY"?
No. The title is 'Unsolicited BFD for Sessionless Applications'. The
YANG reference clause has 'A YANG Data Model for BFD Unsolicited' Not
the same.
>> The text in the running footing is so long that it merges with prefix and
>> suffix thereof
>
> This one will get resolved via RFC publication along with the RFC Editor.
>
>>
>> YANG augment are commonly accompanied by a 'when' to restrict their
>> application.
>
> The augmentations are gated on if-feature. Is that not-sufficient?
>
> In the case where the feature is supported, these augmentations are
> unconditionally expected to be present.
Yes; probably a question of taste. I like having the feature as a
boolean always present which can then be tested with a when. I have
seen YANG doctors argue against the proliferation of feature statements.
Also, the recommended pattern is usually
augment ...
conditional ...
as opposed to
augment ..
container or some such ...
conditional....
Tom Petch
> -- Jeff
>
> .
>
