Today, as there is no definition of the “updates” tag, the only thing that is for sure is that it provides a forward reference from an existing RFC to a new RFC. I think that’s what you want in your case (as there is no registry) and that's why you should use “updates”. When you say below “updates” is not appropriate what do you base this on…? The point that people think “updates” implies more than that is why we have continuous discussions about it, as the one right now.
> On 7. Jul 2026, at 08:13, Brian Rosen <[email protected]> > wrote: > > Joel > > In my draft, I added a new interface. It’s optional. It doesn’t use anything > that was previously unused. It’s an entirely new interface that provides > some useful information the existing interface doesn’t provide. > > The draft also adds a new parameter. There is no registry for parameters, and > there doesn’t need to be. The design of the protocol allows parameters to be > added without changing something the original document said. > > So this document doesn’t change anything about the existing document. > Implementations of the original document continue to interwork. > > “Updates” is not appropriate in my opinion, and others. But some argue that > you might want to know about this document if you implement the original. > Since there is no other tag, like “Extends”, they want to use “Updates”. Do > you agree? > > And, I’m opposed to requiring that a mandatory change to a document needs a > full rewrite (‘bis’) and thus “Obsoletes”. An “Amends” tag should be > sufficient. I think you are saying “Updates” is not appropriate, and I agree. > > Brian > >> On Jul 6, 2026, at 9:23 PM, 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. >> >> 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. >> 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. 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". >> >> 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. >> >> 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. >> >> 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] -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
