Brian E Carpenter
brian.e.carpenter at gmail.com
Thu Mar 26 20:34:23 PDT 2020
On 27-Mar-20 16:01, Joseph Touch wrote:
>> On Mar 26, 2020, at 6:43 PM, Brian E Carpenter <brian.e.carpenter at gmail.com> wrote:
>> On 27-Mar-20 06:44, Eric Rescorla wrote:
>>> You and the proponents should feel free to do so. However, at present, the situation is that this proposal doesn't have anything like consensus (and yes, that's because a number of us are of the opinion that no action is needed) and so the burden on the proponents is to try to build that.
>> It doesn't have consensus, but the question (when it gets to Last Call) is whether it has rough consensus.
>> fwiw I agree that there is a manifest problem with ambiguous use of Updates and I think that the proposed solution is good.
> How about giving us some concrete examples? Or perhaps the authors could (should)?
Yes, I would prefer to leave that to recent IESG members. Any examples in my
mail archive would be quite old.
However, I will quote what the IAB opined in RFC6709:
> 1. Modifications or extensions to the underlying protocol. An
> extension document should be considered to update the underlying
> protocol specification if an implementation of the underlying
> protocol would need to be updated to accommodate the extension.
The problem, I think, is uses of "Updates" in extension documents that
do not match that definition.
>> On 26-Mar-20 11:41, Martin Duke wrote:
>>> But I dislike the idea of having "Extends" and "See Also". I foresee foundational documents (like RFC 793) with a few pages of RFC references before the text starts.
>> I very much doubt it. At the moment RFC793 shows:
>> "Updated by: 1122, 3168, 6093, 6528"
>> Whether those are amendments or extensions I don't know.
> And that’s part of the point. It isn’t clear. It never will be.
> What does
>> Certainly it's incomplete; for example RFC7474 amends RFC793.
> How so? It doesn’t even cite it or use the term “TCP”. You meant RFC7414 maybe?
Yeah, brain meltdown possibly brought on by mandatory self-isolation.
I meant 791, which is updated (amended) by 7474, so a completely
bogus example. Sorry.
>> And so what anyway? If an important RFC like 793 is amended or extended by 50 RFCs, that should definitely be in the metadata.
> 7414 doesn’t itself update or emend anything. It lists things that update, emend, or do both to 793.
> Draft-tsvwg-udp-options - does what?
> - it extends UDP with options
> - but it also alters UDP to prohibit UDP length values that 786 allows
> Is that extends or emends?
Both. Why would it be a problem to use both tags if they both apply?
> I’d really llke to see a list of *ALL* current “updates” and a proposed disposition to each as whether it uniquely and unambiguously extends or emends (or see also).
That's a ridiculous amount of work to suggest. There 1017 RFCs that carry the "Updates" tag, and 861 occurrences of "Updated by", according to the RFC index of yesterday.
> If the authors can’t present that, then they have failed to demonstrate that their “solution” is a step in the right direct.
> We’ll wait.
More information about the rfc-interest