Subject: [yang-doctors] RFC 9127-bis question - impact of reference clauses in an import statement

From: Jeffrey Haas <[email-masked]>
Date: Thu, 9 Dec 2021 17:12:07 -0500

[Reference message to issue in thread:
https://mailarchive.ietf.org/arch/msg/rtg-bfd/Ajo-ku8EJxiEnZjdkRfdzGIg59A/ ]

YANG doctors,

The BFD Working Group is trying to move forward on the RFC 9127-bis work
that was previously discussed with you.  I believe there is consensus in how
we will move forward on the modification to the common configuration
grouping and its associated feature statement.  This strategy was previously
communicated to you all.

This is a question about what we put in the -bis document.  Previously, the
thinking was we did a full re-issue.  Tom Petch, in the thread cited above,
notes that we minimally can't do part of this because there are modules
already delegated to IANA.

The discussion about the what the internet-draft text should include from
RFC 9127 or not lead to a question I had: Would it not be sufficient to
simply issue an update to the ietf-bfd-types module where all of the impact
is isolated?

Tom's argument is that the form of the import, which contains references to
RFC 9127, suggest we really want a re-issue so we point to the proper new RFC.

As an example, from module ietf-bfd:
 :  import ietf-bfd-types {
 :    prefix bfd-types;
 :    reference
 :      "RFC 9127: YANG Data Model for Bidirectional Forwarding
 :       Detection (BFD)";
 :  }

As best I am able to tell from RFC 7950, § 7.21.4, reference is partially
meant to be informational.  If it was normative, an update to any module
imported by another with a reference would require an update.

Note that this isn't an import by revision.

My question is thus what are the rules to issue module updates in such
circumstances?

Tom and the BFD YANG authors are copied to make sure I haven't
misrepresented the situation.

-- Jeff

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 9 Dec 2021 16:28:41 -0800

And it it helps, here are the set of diffs w.r.t. RFC 9127 that we are proposing. You might want to ignore the boiler template and the Section name changes, which we will get the RFC editor to fix.

> On Dec 9, 2021, at 2:12 PM, Jeffrey Haas <[email-masked]> wrote:
> 
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

Mahesh Jethanandani
[email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Dec 2021 10:38:03 -0500

Dear YANG doctors,

A wonderful end of year holiday gift would be to ship the fix to RFC 9127.

Please answer the question below.

-- Jeff

---

From: Martin Björklund <[email-masked]>
Date: Tue, 14 Dec 2021 17:20:42 +0100 (CET)

Hi,

> > imported by another with a reference would require an update.

Correct.

> > My question is thus what are the rules to issue module updates in such

In the general case this happens as soon as you publish an update to
an published module that is already used.  This is fine.

What makes this case special is that you plan to (re)publish modules
with references to the document that you are replacing.

I'm not sure that this is a YANG doctors question... it seems more of
a procedural issue.

> > misrepresented the situation.

I noted in the diff that Mahesh sent that you have:

  revision 2021-12-07 {	
    description	
      "9127-bis.";	
    reference	
      "RFC XXXX: YANG Data Model for Bidirectional Forwarding	
                 Detection (BFD).";	
  }

The description needs to be updated.

Also, the description statement in ietf-bfd-types should be updated to
use the new TLP (with "Revised BSD" instead of "Simplified BSD").

... but then the rest of the modules will have the old language.  I
don't know if this is acceptable or not.

Would it be possible to avoid the problem by not doing a full
9127bis, but just publish an RFC with a new version of ietf-bfd-types?

/martin

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 14 Dec 2021 11:24:13 -0500

Martin,

> 9127bis, but just publish an RFC with a new version of ietf-bfd-types?

Tom seemed to think that was not acceptable.  

If this is the acceptable way to handle this, it's likely preferable.

-- Jeff

---

From: t petch <[email-masked]>
Date: Tue, 14 Dec 2021 16:59:17 +0000

> Tom seemed to think that was not acceptable.

Tom here,

The point of the update is to provide a feature so that the published 
modules (e.g. five such in RFC9127) can stop having deviations, a 
laudable aim.

But if the five published modules reference RFC9127 while importing 
bfd-types, then the import (no revision) will pick up the latest 
bfd-types from 9127-bis and so the feature will be available to them, no 
deviation needed.

What will be wrong, for the next five years or so, will be that anyone 
looking at those five modules in RFC9127, the latest version for those 
five, will see the import of bfd-types with reference to RFC9127 and 
will know that that is what they were tested with, developped with, and 
so will know that the feature should not be used because it is not in 
the referenced RFC9127 for the import; it might work they will think but 
should we risk it?  (The issue of import and its reference was much 
discussed during the development of YANG - it is there for guidance, 
like a SHOULD not a MUST).

My alternative is to publish 9127-bis without the IANA module because 
that is done and dusted, with the new bfd-types with its feature and 
updating the other five to reference 9127-bis in the import reference to 
show that it is ok to use the feature in the context of those five modules.

That will call for 10 or so more lines of change in 9127-bis to update 
the five import reference and to ask IANA to update the reference in 
IANA Considerations for 9127-bis for those five modules to point to 9127-bis

Tom Petch

> .

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 14 Dec 2021 10:19:44 -0800

Hi Tom,

> On Dec 14, 2021, at 8:59 AM, t petch <[email-masked]> wrote:
> 
> The point of the update is to provide a feature so that the published modules (e.g. five such in RFC9127) can stop having deviations, a laudable aim.
> 
> But if the five published modules reference RFC9127 while importing bfd-types, then the import (no revision) will pick up the latest bfd-types from 9127-bis and so the feature will be available to them, no deviation needed.
> 
> What will be wrong, for the next five years or so, will be that anyone looking at those five modules in RFC9127, the latest version for those five, will see the import of bfd-types with reference to RFC9127 and will know that that is what they were tested with, developped with, and so will know that the feature should not be used because it is not in the referenced RFC9127 for the import; it might work they will think but should we risk it?  (The issue of import and its reference was much discussed during the development of YANG - it is there for guidance, like a SHOULD not a MUST).

By that argument, the protocol drafts (BGP, OSPF, ISIS, RIP etc.) that are importing ietf-bfd-types module without a revision, should also be referencing rfc9127-bis, and not rfc9127. They should also be updated. That includes both unpublished drafts, drafts that are in RFC editor queue, and drafts that have been published as RFCs.

Which begs the question that I think Jeff was asking - what is the recommendation for updating modules that import modules that undergo a revision?

Thanks.

> 
> My alternative is to publish 9127-bis without the IANA module because that is done and dusted, with the new bfd-types with its feature and updating the other five to reference 9127-bis in the import reference to show that it is ok to use the feature in the context of those five modules.
> 
> That will call for 10 or so more lines of change in 9127-bis to update the five import reference and to ask IANA to update the reference in IANA Considerations for 9127-bis for those five modules to point to 9127-bis

Mahesh Jethanandani
[email-masked]

---

From: t petch <[email-masked]>
Date: Wed, 15 Dec 2021 09:47:50 +0000

> Which begs the question that I think Jeff was asking - what is the recommendation for updating modules that import modules that undergo a revision?

The point here is that we have RFC9127 with seven modules, five 
importing bfd-types from therein, so if we upgrade bfd-types to provided 
needed funtionality then it behoves us to make clear IMHO that this 
upgrade is ok for the other five, which can be done by changing the 
import reference to be 9127-bis and not RFC9127, a one line, 
documentation change in each of the five modules (which unfortunately 
then need a new revision, date, IANA Considerations but that is business 
as usual).

What other WG do is up to other WG.  Let's make this I-D right.

Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 15 Dec 2021 08:24:37 -0500

Tom,

On Wed, Dec 15, 2021 at 09:47:50AM +0000, t petch wrote:
> importing bfd-types from therein, so if we upgrade bfd-types to
> provided needed funtionality then it behoves us to make clear IMHO
> that this upgrade is ok for the other five, which can be done by
> changing the import reference to be 9127-bis and not RFC9127, a one
> line, documentation change in each of the five modules (which
> unfortunately then need a new revision, date, IANA Considerations
> but that is business as usual).
> 

Your position is understood.

Martin basically states this is a procedural question:
: What makes this case special is that you plan to (re)publish modules
: with references to the document that you are replacing.
: 
: I'm not sure that this is a YANG doctors question... it seems more of
: a procedural issue.

"Special" implies this is a variance from expectations.

The advice being solicited from the YANG doctors is what expectations are.  

Martin (and others), is the republish solely to update references unusual?

-- Jeff

---

From: Martin Björklund <[email-masked]>
Date: Wed, 15 Dec 2021 15:39:44 +0100 (CET)

Hi,

> Martin (and others), is the republish solely to update references unusual?

I have never seen such an update.

Also note that the intention with the reference statement is to refer
to the spec that was current at the time the reference statement was
written.  Since there is no import-by-revision, we are explicitly
prepared to handle newer versions of the imported module (provided the
module follow the upgrade rules).

I think this can be compared to references in RFCs.  If RFC A has a
reference to RFC B, A doesn't have to be updated if B is updated.

/martin

---

From: Reshad Rahman <[email-masked]>
Date: Thu, 16 Dec 2021 22:43:27 +0000 (UTC)

Hi,
    On Wednesday, December 15, 2021, 09:40:05 AM EST, Martin Björklund <[email-masked]> wrote:  
 
 Hi,

<RR> And in the case of 9127-bis, the modified grouping is not used by any of the modules in that document (only in the "routing" YANG documents).So spinning a new revision for these BFD modules just for the sake of updating the reference seems "wasteful". But I have no idea if there are any rules/guidelines for this kind of change.
Regards,Reshad (no hat).
/martin

---

From: t petch <[email-masked]>
Date: Tue, 21 Dec 2021 10:13:13 +0000

> <RR> And in the case of 9127-bis, the modified grouping is not used by any of the modules in that document (only in the "routing" YANG documents).So spinning a new revision for these BFD modules ju…

End of WG LC and I await a consensus call from the chairs.

I see three options.  The worst one is the present I-D, neither flesh 
nor fowl.

Publishing something that is clearly not a bis but just includes a new 
bfd-types is not so bad but for me leaves a confusing trail behind it. 
The two versions of bfd-types will only be a few months apart so I am 
comfortable that the later one can be regarded as current when the 
others were written, which, as Martin says, is what the reference 
statement means.  It will mean that RFC9127 has references to RFC9127 
for bfd-types while other modules from other WG will have reference a 
version of a few months later which will cause some to scratch their 
heads in future and wonder what has gone wrong here.

Publishing a genuine 9127-bis with the IANA module excised and the 
references updated so that everyone uses the same reference is to me the 
clearest statement of what is available and should be used from now on.

Tom Petch

---

From: Reshad Rahman <[email-masked]>
Date: Wed, 22 Dec 2021 04:13:13 +0000 (UTC)

On Tuesday, December 21, 2021, 05:13:24 AM EST, t petch <[email-masked]> wrote:

<RR> Ack (we discussed this). But note that irrespective of what we do in BFD, some modules in other WGs may/will still refer to 9127, so some confusion will remain in that regard.
<RR2> Would 9127-bis obsolete or update 9127? I think it has to be update.I can live with this approach although it still irks me to spin a new module revision just for the sake of updating a reference is overkill and potentially confusing in a different way. Maybe that's only because it's not usually done.   
A 4th option would be like option 3 but to only change references where needed. That was my preferred option but since we do have to change the references in ietf-bfd-mpls, it would seem odd to change 1 module and not the others. Regards,Reshad (no hat).
Tom Petch

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 22 Dec 2021 13:40:30 -0500

> End of WG LC and I await a consensus call from the chairs.

And Happy Holidays to you as well!

> I see three options.  The worst one is the present I-D, neither
> flesh nor fowl.
> 
> Publishing something that is clearly not a bis but just includes a
> new bfd-types is not so bad but for me leaves a confusing trail
> behind it. The two versions of bfd-types will only be a few months
> apart so I am comfortable that the later one can be regarded as
> current when the others were written, which, as Martin says, is what
> the reference statement means.  It will mean that RFC9127 has
> references to RFC9127 for bfd-types while other modules from other
> WG will have reference a version of a few months later which will
> cause some to scratch their heads in future and wonder what has gone
> wrong here.
> 
> references updated so that everyone uses the same reference is to me
> the clearest statement of what is available and should be used from
> now on.

The delays in iteration as we've sought out the wisdom of the YANG doctors
has meant we've not seen progress in the Working Group mail list.  That
said, you - as the sole party really expressing much opinion - have
continued to see that involvement with them.

For the Working Group as a whole, this call ends in "No Consensus".  The
authors are currently proceeding with a full update to RFC 9127 as a -bis
largely following the discussed pattern of "keep the bulk of the contents,
remove the IANA section, update the references".

Also for the Working Group as a whole, we did not get much response from the
YANG doctors and had a single response from Martin Björklund.  He didn't see
a strong reason to re-issue the full RFC.  That said, he also considered our
desire to do so to be a "procedural" one.

Given the lack of strong opinions at this time, the authors have been given
latitude to do their next version as they please.  That was discussed above.

Once we have a full update, we'll re-open the WGLC and target mid January to
attempt to get broader IETF involvement.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 22 Dec 2021 13:42:01 -0500

[Note - re-send to fix bfd list address issue.]

-- Jeff

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 22 Dec 2021 21:08:11 +0000

I support proceeding as Jeff suggests. I'm confident other BFD WG members would agree and the lack of other opinions is due to everyone feeling this was a done deal. 
Thanks,
Acee

On 12/22/21, 1:42 PM, "yang-doctors on behalf of Jeffrey Haas" <[email-masked] on behalf of [email-masked]> wrote:

    -- Jeff