Yes, that’s “extends” and “amends” is a different case; that’s why we have two tags. Defining the tags does not remove the need or requirement to provide clear text. The draft says that but we could use even more strong language or add more concrete guidance if there is consensus for that. I would definitely be will to work on that. However, getting text in each draft consistently seems even more difficult to achieve. Also because some people have strong options about what the “updates” tag should NOT be used for but we definitely don’t have a way to enforce that currently.
Also, having text might help the problem on how it is interpreted by the reader/implementor, however it will not help with the re-occurring (useless) discussions about when to use of not use the “updates” tag. Again I don’t think we can define the new tags in a way that we don’t have any discussion at anymore but at least the discussion will be based on some definitions and I expect to have less discussions. Also my question is what’s the harm I trying it. If it doesn’t help, we stop it again. However, I think there is a chance to at least improve the situation even though we might not fix all issues entirely. > On 7. Jul 2026, at 16:14, Joel Halpern <[email protected]> wrote: > > I think you are saying that you intend "extends" for the case where a new > document modifies an existing RFC in a backwards compatible and optional > fashion. I did not get that interpretation from reading your draft. While > we could fine tune the definitions, I think the variability in language > interpretation and our proven ability to come across cases we did not > anticipate makes it far mroe effective to requre that drafts be clear rather > than slicing the updates tag. If we go that route, I have no objection to a > document which says that updates covers all cases of type X, and that any > documents using it MUST have explicit descriptions of the relationship. > > Yours, > > Joel > > On 7/7/2026 6:23 AM, Mirja Kuehlewind (IETF) wrote: >> Hi Joel, >> >> Please see below. >> >>> On 6. Jul 2026, at 21:53, Joel Halpern <[email protected]> >>> <mailto:[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]> <mailto:[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] <mailto:[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]> <mailto:[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] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[email protected]> >> > -- > 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]
