[rfc-i] draft-kuehlewind-update-tag/

Brian E Carpenter brian.e.carpenter at gmail.com
Thu Mar 26 20:34:23 PDT 2020


Joe,

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:
>>
>> ekr,
>> 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.

Stay well,
   Brian

> 
> 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.
> 
> Joe
> 



More information about the rfc-interest mailing list