Subject: Minor nit from shepherd writeup to resolve for BFD unsolicted

From: Jeffrey Haas <[email-masked]>
Date: Wed, 20 Oct 2021 10:46:40 -0400

$ pyang --ietf --max-line-length 69 ietf-bfd-unsolicited\@2021-10-15.yang 
[email-masked]:17: warning: imported module "ietf-bfd" not used
[email-masked]:22: warning: imported module "ietf-bfd-ip-sh" not used
[email-masked]:128: warning: line length 71 exceeds 69 characters

The following line needs to be split:
         "BFD IP single-hop interface unsolicited top level container";

---

From: Reshad Rahman <[email-masked]>
Date: Wed, 20 Oct 2021 18:19:36 +0000 (UTC)

Also, starting from rev-04 (I think) we incorrectly have RFC9127 as the reference for the revision. I will change it back to YYYY.
  revision 2021-10-15 {
     description "Initial revision.";
     reference "RFC 9127: A YANG data model for BFD unsolicited";
   }

    On Wednesday, October 20, 2021, 10:47:05 AM EDT, Jeffrey Haas <[email-masked]> wrote:  
 
 $ pyang --ietf --max-line-length 69 ietf-bfd-unsolicited\@2021-10-15.yang [email-masked]:17: warning: imported module "ietf-bfd" not [email-masked]:22: warning: imported module "ietf-bfd-ip-sh" not [email-masked]:128: warning: line length 71 exceeds 69 characters
The following line needs to be split:         "BFD IP single-hop interface unsolicited top level container";

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Oct 2021 20:30:14 +0200

I did added RFC9127 based on Jeff information (in many places of XML as
comment)

Fixed reference in the YANG to accommodate new number.

Fell free to comment it out so RFC editor can quickly adjust :)

Best,
R.

On Wed, Oct 20, 2021 at 8:19 PM Reshad Rahman <[email-masked]> wrote:

> Also, starting from rev-04 (I think) we incorrectly have RFC9127 as the
> reference for the revision. I will change it back to YYYY.
>
>   revision 2021-10-15 {

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 20 Oct 2021 16:53:46 -0400

9127 is the RFC-to-be.  I think that's likely to stay.

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?

-- Jeff

> On Oct 20, 2021, at 2:30 PM, Robert Raszuk <[email-masked]> wrote:
> 
> I did added RFC9127 based on Jeff information (in many places of XML as comment)
> 
> On Wed, Oct 20, 2021 at 8:19 PM Reshad Rahman <[email-masked] <mailto:[email-masked]>> wrote:
> On Wednesday, October 20, 2021, 10:47:05 AM EDT, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> [email-masked] <mailto:[email-masked]>:17: warning: imported module "ietf-bfd" not used
> [email-masked] <mailto:[email-masked]>:22: warning: imported module "ietf-bfd-ip-sh" not used
> [email-masked] <mailto:[email-masked]>:128: warning: line length 71 exceeds 69 characters
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 20 Oct 2021 13:58:04 -0700

> On Oct 20, 2021, at 1:53 PM, Jeffrey Haas <[email-masked]> wrote:
> 

See Section 3.7.1 of RFC 8407 here <https://datatracker.ietf.org/doc/html/rfc8407#section-3.7.1>.

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 20 Oct 2021 17:00:27 -0400

> On Oct 20, 2021, at 4:58 PM, Mahesh Jethanandani <[email-masked]> wrote:
> 
> 
> 
>> On Oct 20, 2021, at 1:53 PM, Jeffrey Haas <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Thank you, Mahesh.  

Addressing this would close the remaining nits.

-- Jeff

---

From: t petch <[email-masked]>
Date: Thu, 21 Oct 2021 12:39:54 +0100

> Addressing this would close the remaining nits.

Manwhile  ...

Unless and until you register with IANA, you do not have a YANG module!

The web reference is ood and insecure

The title in the 'reference' clause is not that of the I-D

The text in the running footing is so long that it merges with prefix 
and suffix thereof

YANG augment are commonly accompanied by a 'when' to restrict their 
application.

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 21 Oct 2021 18:06:11 -0400

Tom,

I've not hit "publish" yet...

> On Oct 21, 2021, at 7:39 AM, t petch <[email-masked]> wrote:
> 

Is there a bit of IANA boilerplate we're missing for the yang module?

> The web reference is ood and insecure

Previously discussed and blessed.

> The title in the 'reference' clause is not that of the I-D

Which reference?  The "RFC YYYY"?

> 
> 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.

-- Jeff

---

From: t petch <[email-masked]>
Date: Fri, 22 Oct 2021 09:37:50 +0100

> Is there a bit of IANA boilerplate we're missing for the yang module?

Yes, see RFC8407 Appendix A

> 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

> 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.

> 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

> .

---

From: Reshad Rahman <[email-masked]>
Date: Mon, 25 Oct 2021 18:45:07 +0000 (UTC)

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 <[email-masked]> wrote:  

Tom Petch