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]
