Subject: [netmod] RFC7950 s.11 and 9127-bis

From: tom petch <[email-masked]>
Date: Wed, 8 Dec 2021 09:50:37 +0000

The BFD WG are revising RFC9127 to add a new feature  
       if-feature "client-base-cfg-parms";
and make 
       uses base-cfg-parms {
conditional thereon in module ietf-bfd-types.  Reading and re-reading RFC7950, especially about mandatory and top-level, I am not convinced that this is legal.  The module bfd-types is imported by a number of other modules such as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be made mandatory by its usage in another module.  I raised this on the BFD list and the WG Chair tells me that this is a violation of the intent of the RFC, 7950, but that it has been reviewed by YANG doctors and is probably the best fix.

If YANG Doctors collectively say that this violation is ok, then I think that such a statement needs to appear on the Netmod WG list.

I think that there are a lot of other editorial changes needed to 9127-bis to make it legal but they can come later.  The I-D is in WG Last Call ending 20Dec2021

Tom Petch

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 08 Dec 2021 13:38:26 +0100

tom petch <[email-masked]> writes:

> The BFD WG are revising RFC9127 to add a new feature if-feature
> "client-base-cfg-parms"; and make uses base-cfg-parms { conditional
> thereon in module ietf-bfd-types.  Reading and re-reading RFC7950,
> especially about mandatory and top-level, I am not convinced that
> this is legal.

Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping is mandatory. Why do you think this might be illegal?

Lada

> The module bfd-types is imported by a number of other modules such
> as OSPF, RIP, PIM so it is also a question if e.g. a leaf can be
> made mandatory by its usage in another module.  I raised this on the
> BFD list and the WG Chair tells me that this is a violation of the
> intent of the RFC, 7950, but that it has been reviewed by YANG
> doctors and is probably the best fix.
>
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: tom petch <[email-masked]>
Date: Wed, 8 Dec 2021 17:27:39 +0000

From: Ladislav Lhotka <[email-masked]>
Sent: 08 December 2021 12:38

<tp>
Reading that section I find parts less than clear, especially about top level and mandatory.  Could a PIM eg module importing that grouping make it top level or mandatory even if it is not so in the BFD module?

I realise that such as NACM can always make part of the tree invisible so software has to be prepared for something to be missing but I am not confident of my interpretation.

Tom Petch
Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 8 Dec 2021 09:58:11 -0800

On Wed, Dec 8, 2021 at 9:27 AM tom petch <[email-masked]> wrote:

> Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping
> is mandatory. Why do you think this might be illegal?
>
> <tp>
> Reading that section I find parts less than clear, especially about top
> level and mandatory.  Could a PIM eg module importing that grouping make it
> top level or mandatory even if it is not so in the BFD module?
>
>

Yes. The refine-stmt can add or change a mandatory-stmt.
 https://datatracker.ietf.org/doc/html/rfc7950#section-7.13.2

This only affects the specific "uses" of the grouping, never the grouping
itself.

Andy

I realise that such as NACM can always make part of the tree invisible so
> software has to be prepared for something to be missing but I am not
> confident of my interpretation.
>
> Tom Petch
> Lada
>
> > If YANG Doctors collectively say that this violation is ok, then I think
> that such a statement needs to appear on the Netmod WG list.
> >
> > I think that there are a lot of other editorial changes needed to
> 9127-bis to make it legal but they can come later.  The I-D is in WG Last
> Call ending 20Dec2021
> >
> > Tom Petch

---

From: tom petch <[email-masked]>
Date: Thu, 9 Dec 2021 10:51:16 +0000

________________________________________
From: Andy Bierman <[email-masked]>
Sent: 08 December 2021 17:58

On Wed, Dec 8, 2021 at 9:27 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
From: Ladislav Lhotka <[email-masked]<mailto:[email-masked]>>
Sent: 08 December 2021 12:38

<tp>

This only affects the specific "uses" of the grouping, never the grouping itself.

<tp>

Andy, Lada,

Thanks for the responses.  Perhaps I should stop worrying.  None of the importing modules - PIM, OSPF. BGP, RIP - use refines for bfd-types but even if they did, then the conditional in new bfd-types would still be valid.

Tom Petch
Andy

Tom Petch
Lada

> [email-masked]<mailto:[email-masked]>

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Jernej Tuljak <[email-masked]>
Date: Thu, 9 Dec 2021 16:10:24 +0100

> Sorry, I don't get the problem - nothing in the "base-cfg-parms" grouping is mandatory. Why do you think this might be illegal?

RFC7950, Section 11 (Updating a Module). A change like this does not 
fall under any of the allowed revisions of definitions in a published 
module, therefore:

    Otherwise, if the semantics of any previous definition are changed
    (i.e., if a non-editorial change is made to any definition other than
    those specifically allowed above), then this MUST be achieved by a
    new definition with a new identifier.

The semantics of the original "uses" (the one Tom mentioned) change if 
an "if-feature" is added to it. You start with a reusable set of data 
definition nodes and end up with a reusable set of data definition nodes 
that are constrained by some condition.

Jernej