[procon] Re: Conclusion of the last call on draft-ietf-procon-2026bis-08

["Salz, Rich" <[e-mail]>]

I am going to comment on the items where the chairs asked for feedback. I am not going to comment where the Chairs marked the item as editorial, or if I have no opinion, or if my opinion is “whatever the WG decides"

2. Brian Carpenter's and Simon Josefsson’s comments on relation to 2418bis, their review/publication timing, and obsoleting text

I would prefer to see 2026bis declared done and then the WG focus on 2418bis. Close this WGLC, let the AD review it if they want, and but do not send it to the IESG until 2418bis has had its WGLC. That way if a new interaction between the two documents is discovered, we can “pull back” 2026bis and make any fixes that are needed.  It would have been nice to publish 2026bis this calendar year, but given the importance of keeping the two drafts aligned, that seems unlikely so best to give up that goal and move on.

3. Brian Carpenter’s comments about references.

> About deleting RFC 1311 reference. This seems more substantial, and we’ve received feedback against this change. Comments?

I think I was against it, but if the WG feels the definition in the 2026bis draft is good enough, I’m fine with removing it; upon re-reading, 1311 is more obsolete than useful. If we delete it, I we should mark 2026bis as obsoleting 1311.

> About referencing RFC editor URLs. These relate to potentially needing to reference https://www.rfc-editor.org and https://www.rfc-editor.org/authors/rfc-style-guide/ and not only RFC 9920 and RFC 7322. Again, also some feedback against. Thoughts?

I have a slight preference to minimizing external URL references, but it’s even smaller for sites that we control.

5. Brian Carpenter’s comments about experimental/Informational RFCs

> Brian raises the issue that the text in Section 4.1 misses a central sentence from RFC 8789 about needing to establish IETF consensus for RFCs in the IETF stream. The text clearly needs to be in line with the already published RFC. A similar sentence does appear a the end of Section 8.1.2 but that section does not cover the experimental/informational documents.

In the editor’s copy the last sentence now says: "In no event shall a document be published on the IETF Stream without IETF consensus.”

> Individual submissions for Exp/Inf also going through IESG review: That is correct. Is there an RFC that says this?

Discussed earlier [1],[2]

6. Brian Carpenter’s comments about Internet Drafts.

> Whether to use the term expired vs. inactive. The suggested change does not appear to match current practice. We’ve also received feedback against this change.

I am against this change because it does not match our current practice, which has been controversial at times. Also, there are over 300 uses of “expired” in the datatracker source (yes, some are function names, but they should also be changed if we do this).

> Removing the reference to RFC 7311: RFC 7311 is referenced in any case elsewhere in the document. There’s also some feedback against this change.

You mean 7322. The WG should decide this issue and the links mentioned above.

7. Brian Carpenter’s suggestion about the term elective vs. optional in ASes

> Editorial, but the term elective has been used in past RFCs. Again, some feedback against this change.

A needless change so I am opposed.

8. Brian Carpenter’s suggestion about the experimental section talking about other streams

> It does talk about them. Today’s stream structure is documented in RFC 7841. Should this be reflected in the text? Or is the note about experimental RFCs also coming from other streams useful information that should stay?

I think if the other streams want Experimental, they should define it and this draft should only talk about the IETF stream.

9. Brian Carpenter’s suggestion to say who assigns historic status or determines consensus

> These are substantive changes, though aligned with what the current practice is. Or are there RFCs that say this? Do we want to specify this?

They are part of the standards track (Section 6 and section 6.2), which is why they have the awkward name “Maturity level.” Note that Sec 6 points to Sec 8 for all the maturity levels here, and the editor’s copy says in section 8.1, that any standards action must be approved by the IESG.

There is the larger issue that 8789 only implied that the IESG determines IETF consensus, but at least it only has to be fixed once: either 8789bis (open an errata) or at the end of 8.1 add “as determined by the IESG.”

11. D. J. Bernstein’s concerns about document exceeding charter limits

> We have asked our AD to provide his view on this matter. As you can tell from the above list, there are other issues where the same question may apply.

Looking forward to seeing his note.

12. Chairs’ observations

> Given some of the discussion, we believe the document would benefit from a changes section that lists the source of each change (outside of purely editorial ones).

At this point in time, I am not willing to do this. There are 161 commits that would have to be examined and compared against the source material and a rationale created. If this is a defense measure to forestall appeals, it would not work. Even if the intent is to be helpful to the overall IETF community, it is more time and effort than I can spend on this volunteer effort. You’ll have to find another co-author, or perhaps the AD will spend money to hire the RPC to do it.

[1] https://mailarchive.ietf.org/arch/msg/procon/QLqMTrjwTiq4OX_FM04hMG2zhhw/
[2] https://mailarchive.ietf.org/arch/msg/procon/KVBeD1uspZHKKqoaFgO1_Unobxk/