Joel Halpern <[email protected]> wrote: > 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.
That's a good example of Amends.
The flag bit could not be allocated via IANA process (there probably wasn't
one).
(I think the ECN/DSCP/L4S bits were the same way).
And that reserved bit was, I hope, "set to zero on send, ignore on receive"
in the original document.
> 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
> / Anon> 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".
I agree that this is not good, and I don't think it's a goal of the
terminology to enable such things. When it does happen, we should be able to
express it.
If it benefits from another word, great.
(I think that mandating SNI (RFC6066) for TLS1.[012] falls into that space,
although I don't think we actually wrote that down anywhere. It just
happened a decade+ ago, that ubiquitous HTTPS without ubiquitous IPv6, was
going to require HTTPS virtual hosting for HTTPS)
> 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.
Yes, all of the OSPF extensions done via IANA process extend the base RFC.
Do they always need to say so? I think that's a WG judgement call.
The question for me, becomes: would a new implemention survive real customers
if it didn't have that extension? When it comes to doing the base-RFCbis,
would you want to roll them all up into the new base RFC?
As an example: a DHCPv4 server that did *not* implement the LDAP option 95 is
probably not an issue. A DHCPv4 server that ignored Option 108
(IPv6-preferred) would be inadequate today.
{In making up this example, I was going to contrast DNS option vs LPR server
option. But, both are actually in RFC2132, which was itself, I think a rollup
of 1533}
--
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 **
signature.asc
Description: PGP signature
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
