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

Hi, Brian,

> On Mar 26, 2020, at 8:34 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> Joe,
> 
> On 27-Mar-20 16:01, Joseph Touch wrote:
>> 
>> 
>>> On Mar 26, 2020, at 6:43 PM, Brian E Carpenter <brian.e.carpenter@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.

Then fix the way it is applied. A bug is a bug. New process doesn’t automagically fix bugs.

> 
>> 
>>> 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?

What’s the point? Why the nuance?

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

Really? So basically outgoing IESG members get to throw “work bombs” on the incoming IESG and the rest of us?

How about at least showing us a few examples where it actually matters AND would be unambiguous to determine.

Joe
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest