Hi Joel, Please see below.
> On 6. Jul 2026, at 21:53, Joel Halpern <[email protected]> wrote: > > As I read this, we would be conflating two different things under "amends", > one useful and in my opinion valid, and one important but in my opinion > invalid. > > The case I consider valid , and am perfectly happy just lumping in with other > uses for updates, is when a new draft / RFC defines a new behavior that was > previously prohibited. (Note that defining a new code point for something > with a registry shouldn't need an updates tag.) An example of this is > assuming the MPLS WG approves the post-stack data draft, it will redefine a > flag bit that was previously reserved (must be zero on transmission, must be > ignored on reception) to be the P bit. Implementation that do not support > the new RFC will continue to work and continue to interoperate. There is > nothing requiring implementations to support it. Yes, it updates the > existing RFC, since the existing RFC requires ignoring the bit. This kind of > change happens with a lot of our extension points that are not just > registries. This is a good example but might actually be rather a case for “extends” as I would say it uses an existing extension point. It also doesn’t really change the existing RFC because of you only implement that RFC the bit must still be 0; it rather defines something new. We should clarify this case in the draft. Maybe having some concrete examples would be good. > > The case I consider invalid, and distinct from the above, is when we are > trying to mandate that existing implementations must conform to the new RFC. Not sure that is exactly what we say. I think you cannot force anything on existing implementations. We say if you want to implement the protocol correctly, you also have to implement that new RFC. That does change your conformance to the old RFC though. That’s also what the draft says: "An implementation that conforms to the amended RFC still conforms to that RFC, even when an amendment is published. However, an implementation can, and hopefully should, of course be updated to also conform to the new RFC with the amendment. If only conformance to the new RFC is desired, obsoleting the respective RFC with a new full (bis) specification may be more appropriate and should be consider instead." However, I see that the wording used in the amends definition might sound a bit different. Maybe we shouldn’t use the word “mandatory" there and probably the “MUST also implement” isn’t the right way to go. This current text is based on the early feedback we got on how some people understand the “updates” tag today (and want to keep using it in future). However, I agree that this can be confusing as well. Based on this discussion so far, maybe we should rather talk about interoperability. I know people have concerns about this as well but the truth is that we sometimes need to do breaking changes (see further comments below). I will open an issue > I understand that we have done that. I understand why. I think it is the > wrong answer. There are often better answers short of publishing a revised > / obsoleting RFC. While there seems to be some extend of agreement that a revised RFC would be better (in some sense), the truth is that this will practically often not happen in the current process. Revising an RFC opens the whole RFC for discussion and that's an entirely different amount or work that people might not be willing or able to sign up for. That’s just the way this works in a voluntary organisation and we can’t not just ignore that. We need to provide a practical solution. > I do sympathize with suggestions to find a way to make such revisions easier. > But that is a different topic. The fact that we have done this before is > not an excuse to continue confusing people about what implementing X means. > It doesn't mean "implementing X plus the amending RFCs". Yes, that also what the draft says, see above. > > And even worse, suing the same word for those two things simultaneously > blesses the mistake of doing the later, and confuses people about which one > we mean. I have no idea how many of the 50 or so cases Suresh identified > fall into which of the two categories. Yes, as I said, your first case would be “extends” and your second is “amends”. That’s why we propose two keywords. Seems like we do agree here… > > And then I try to figure out what the extends tag is supposed to mean. I > think it is intended to say that all of the OSPF optional RFCs "extend" the > base RFC? And all of the interesting HTTP(S) headers extend the base > document? That's what registries are for. Or else we are trying to back our > way into the efforts that have gotten shot down to define the full set of > related RFCs for topic X? While a desirable effect, this is not the way to > get there. Not all extension points have registries. Like the one you described above; that's where it is useful to provide a forward reference from en existing RFC to a new one. If you have a registry you don’t have to use the tag (I guess you could); that’s for the group to discussion and decide. Also the draft only says that you can used these tags only for the specified uses, however, it does not say that you have to use it for all of these uses. After all, even if we have a good definition, there might still be cases that are not fully clear and a group needs to have a discussion. However, at least there is a definition that provides something to have a discussion about. Also I think today people make decision based on assumptions about requirements that don’t exists. Which automatically creates a mismatch between these expected requirements (e.g. mandatory to implement) and its implementation/signal to the implementor. That seems bad to me and I think that’s where the definition of the proposed tags in the draft would help. Mirja > > Yours, > > Joel > > On 7/6/2026 12:42 PM, Michael Richardson wrote: >> Eliot Lear <[email protected]> wrote: >> >> 3. RFC9914 uses both Extends and Amends, and I think we did it >> correctly. >> >> Was it easy to get right? No, but it made us think about which parts >> >> were which, how we would get around changes to base behaviour. >> >> > That it wasn't easy to get right for the authors is at least a hint >> that the >> > readers will suffer confusion. So I'm curious as to what challenges >> you had. >> >> 1. is this *just* an extension, or does it require modifications to an >> exising 6550 rule (thus amends). >> >> 2. does the rule change have an impact on existing code bases? if so, can we >> detect this and work around it? Should we? >> Is there an *extension* that could signal the new behaviour is present? >> >> > We have never said the following: >> >> >> The goal of this tag pair is to signal to anyone looking to implement >> the >> >> amended RFC that they MUST also implement the amending RFC. >> >> > And that is what causes the conformance confusion. And it's violating >> a >> > longstanding principle of our series- that once a specification is >> published, >> > it does not change, modulo errata. Here we are in effect saying the >> > opposite. >> >> But, we obsolete and deprecate things all the time. >> All sorts of ICMPs turned out to be dangerous. MUST be ignored. >> In the TLS world... 1.0,1.1, and soon 1.2. >> >> > "Updates" has the expectation that if you want to be interoperable >> with the >> > old RFC, you test against the old RFC, and if you want to be >> interoperable >> > with the update, then you must test against the update as applied to >> the old >> > RFC. >> >> Yeah, that's what Update/Amends means. >> >> >> Yes, sometimes that is true. What about it? >> >> RFC9914 definitely Amends RF6550, but there is no way I'm revising a >> 157 page >> >> document, particularly since it's still completely valid to not >> implement 9914. >> >> > If it's valid to not implement 9914, then the language in this draft is >> > wrong, and therefore you may have already introduced interoperability >> > challenges for those implementing either 6550 or 9914. If Amends is >> intended >> > to be what I think we agree Updates should have been, let's just make >> > Updates that ;-) >> >> If you want to argue that all new uses of _Updates_ will mean Update/Amends, >> I'm probably okay with that, but there are a lot of uses where that either >> isn't true, or for which there is a condition attached. >> >> > * TCP port number assignments clearly are not intended to add new >> > operations to TCP; they're just a means of identifying payload. The >> > same could be said for the media-types registry. So extends isn't >> > needed in this case. >> >> Agreed on port numbers. >> But, TCP options are not the same. >> Window scaling is a critical option to get performance over certain links, >> and we really want to widely implemented. >> >> > * SCIM schema are clearly intended to extend the functionality of >> > service. At the moment there are few such extensions, but I expect >> > that to change – rapidly– over time. Moreover, they only have >> > "specification required" as a policy. Does that require extends? >> >> It doesn't hurt you to say so. >> >> > * SMTP is a goodie. Do we really need to indicate in the meta-data >> > that extends SMTP some 25 times? An interesting side-effect in this >> > case is that when the new RFC comes out, it would have been extended >> > by old RFCs. How's that for a head twister? >> >> I hope the new document lists all the old RFCs which are extensions to SMTP, >> which have essentially become MTI. I think that's the case, but maybe it >> isn't well organized. >> >> > At the end of the day, if we need to clarify Updates: I'm totally okay >> with >> > that, and am willing to either work with this group to provide some >> text. >> > But I don't think such an update should be limited to "Updates". We >> have >> > some other issues with "Historic" and "Obsoletes" that should be >> hammered out >> > as well, when crossing streams (when it happens, it does indeed feel a >> little >> > like Ghostbusters). >> >> Yes. I strongly agree with you. >> I come back to my query in procon about whether process documents about the >> series shouldn't be something other than BCP. (procon punted on that, a "no" >> for procon) >> >> -- >> ] Never tell me the odds! | ipv6 mesh networks >> [ >> ] Michael Richardson, Sandelman Software Works | IoT architect >> [ >> ] [email protected] http://www.sandelman.ca/ | ruby on rails >> [ >> ] My working hours and your working hours may be different. >> [ >> ] Please do not feel obligated to reply outside your normal working hours >> [ >> >> >> -- >> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> ** My working hours and your working hours may be different. ** >> ** Please do not feel obligated to reply outside your normal working hours ** >> >> >> >> >> > > -- > rswg mailing list -- [email protected] > To unsubscribe send an email to [email protected]
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
