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

From: Martin Duke <[email-masked]>
Date: Wed, 25 Mar 2020 15:41:19 -0700

What I was going to say in the queue:

Like mnot, I think Updated should mean "Amended". It may be worth it to
change the term just to create awareness to tighten the meaning.

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. That is useless. Plus the formal existence of these
categories will encourage people to use them.

If we would like better forward-tracing of standards evolution through
time, I would prefer if the datatracker and rfc-editor pages simply listed
the times the RFC was cited by other RFCs both normatively and
informatively. I think that would be sufficient and automatable.

TLDR, rename Updated to Amended, build the citation tool, and call it done.

Martin
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Mar 2020 15:57:18 -0700

-1

‘Updates’ is much more universal in meaning and already sufficient. A change to ‘amends’ is a waste of time and effort. 

> On Mar 25, 2020, at 3:41 PM, Martin Duke <[email-masked]> wrote:
> 
> Like mnot, I think Updated should mean "Amended". It may be worth it to change the term just to create awareness to tighten the meaning

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Mar 2020 10:00:49 +1100

> On 26 Mar 2020, at 9:41 am, Martin Duke <[email-masked]> wrote:
> 
> Like mnot, I think Updated should mean "Amended". It may be worth it to change the term just to create awareness to tighten the meaning.

To expand on discussion a bit -- one of the things that kept on coming up was that "updated" was never well-defined, causing this confusion. So one approach we could take would be to _define it_.  But having data about how bad the confusion is would help make the decision of whether to do that vs. mint a new term.

> 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. That is useless. Plus the formal existence of these categories will encourage people to use them.

+1.

> If we would like better forward-tracing of standards evolution through time, I would prefer if the datatracker and rfc-editor pages simply listed the times the RFC was cited by other RFCs both normatively and informatively. I think that would be sufficient and automatable.
> 

I don't think we should call it done.

To me, this is further evidence that a linearly-numbered series of archival documents as the primary source of truth is damaging. 

We'd be better served if the documents that most people referred to were what's called "consolidated acts" in legislation. The source documents would still be available and immutable, but not primary references (unless there's a dispute about the consolidation). 

That implies that we'd need a new kind of WG output -- one that "patches" existing documents. Not hard, but requires some conventions and discipline by the authors. That patch could then be applied and the resulting consolidation published by the RFC Editor, or someone else. And both the original document and the patch would still be available separately, for when that matters.

The problem in all of this is that brand of "RFC numbers" has been built up over the year, and people are conditioned to use them as the primary reference. Giving the consolidated documents their own numbers is pointless, because they should be stable, not changing every time there's a new patch.

STD and friends seem to have failed. A tentative suggestion -- still publish RFC *numbers* for archival documents, but publish RFC *names* -- e.g., RFC-HTTP -- for consolidated documents that *can* be updated over time.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Joe Touch <[email-masked]>
Date: Wed, 25 Mar 2020 16:07:56 -0700

> On Mar 25, 2020, at 4:01 PM, Mark Nottingham <[email-masked]> wrote:
> 
> 

Agreed, but that’s why we have roadmap and architecture of X docs. It’s never as simple as just a set. 

Joe

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 25 Mar 2020 23:12:37 +0000

From: rfc-interest <[email-masked]> On Behalf Of Martin Duke
Sent: 25 March 2020 22:41
To: [email-masked]
Subject: [rfc-i] draft-kuehlewind-update-tag/

Like mnot, I think Updated should mean "Amended". It may be worth it to change the term just to create awareness to tighten the meaning.
[RW]
+1 to Updated meaning Amended, but I think that we could keep the tag name the same, but just specify exactly what its behaviour is.

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. That is useless. Plus the formal existence of these categories will encourage people to use them.
[RW]
I like the idea of “Extends” but not “Extended By”.  I.e. I think that it is useful for an RFC to indicate which base spec it is extending, but I don’t think that the base spec needs to indicate which optional RFCs it has been extended by.

If we would like better forward-tracing of standards evolution through time, I would prefer if the datatracker and rfc-editor pages simply listed the times the RFC was cited by other RFCs both normatively and informatively. I think that would be sufficient and automatable.
[RW]
I see “Extends” as something different to Normative reference.

Regards,
Rob

Martin

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Mar 2020 00:24:51 +0100

Point 1: Whats a native english speakers explanation why "Amended" is
significantly better than "Updated"

For example, in IP multicast, we have this bible document RFC1112,
where the rfc1112bis i would like to write (time perrmitting ;-)
would mostly consist of removing 50% of the doc which specifies 
what we would now call IGMPv1 - an obsolete protocol. To me,
this rfc1112bis would well be characterized with the word "Updated",
but not the word "Amended", because to me (non-native speaker),
"Amended" sound a bit like "there is more" (not a lot less).

Point 2: I am not sure the distinction between Amended and Extended is
going to work well, because i can esily see a single follow-up RFC
to do both. There may be one section, where a MUST statement
refers and changes behavior that existed in the reference RFC
and is therefore an "Amendment" MUST. Then there is a second
feature introducing a new feature, which for this RFC is a MUST,
so... how would i even distinguish these two MUST ? And it seems
that a single Amendment MUST "kills" 20 new MUSTs that are
Extensions.

Cheers
    Toerless

On Wed, Mar 25, 2020 at 11:12:37PM +0000, Rob Wilton (rwilton) wrote:
> I like the idea of ???Extends??? but not ???Extended By???.  I.e. I think that it is useful for an RFC to indicate which base spec it is extending, but I don???t think that the base spec needs to indicate which optional RFCs it has been extended by.
> 
> I see ???Extends??? as something different to Normative reference.
> 
> Regards,
> Rob
> 
> 

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Mar 2020 00:39:58 +0100

Btw: My example is not what i actually wanted to do, the 'bis'
of course typically means you have all the text and fully replace
the prior RFC. So let me correct the example:

if instead of a 'bis' document, one would do a
document that just has a sentence "sections X, Y, Z of reference
RFC are obsole and MUST NOT be implemented".

Thats what i think is an Update, but doesn't sound like an "Amendment"
to me.

Cheers
    Toerless

---

From: Joseph Touch <[email-masked]>
Date: Wed, 25 Mar 2020 16:46:36 -0700

> On Mar 25, 2020, at 4:24 PM, Toerless Eckert <[email-masked]> wrote:
> 
> significantly better than “Updated"

I’d start by asking that speaker to explain amended, emended, and updated.

Nuanced speakers will appreciate the difference; for most, IMO, “updated” covers everything needed and is much more commonly used. That helps for non-native speakers.

> "Amended" sound a bit like "there is more" (not a lot less).

Amended can mean “puts right” or “updates” too. The 18th Amendment (literally) to the US constitution removed the right to manufacture and consume alcohol; the 21st Amendment restored it. 

In a sense, the first removed a right by adding a restriction, the second restored a right by undoing the first one in its entirety. Both are amendments, both figuratively and by name.

> that a single Amendment MUST "kills" 20 new MUSTs that are

All good reasons to just say “updates”.

Why are we spending more cycles on this??

Joe

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Mar 2020 00:54:05 +0100

Thanks, Joe,

The Amendments to the US constitution is a good counter example
for my mis-understanding of it being "more". Thanks.

So the logic seems to be "Amended" would NOT have a clear difference
in meaning over "Updated" unless you try to go into gory
details. The main reason for changing words is to support a
change in semantic.

Then i am be fine with the change in word, but not the currently
proposed semantic.

Cheers
    Toerless

On Wed, Mar 25, 2020 at 04:46:36PM -0700, Joseph Touch wrote:
> > significantly better than ???Updated"
> 
> I???d start by asking that speaker to explain amended, emended, and updated.
> 
> Nuanced speakers will appreciate the difference; for most, IMO, ???updated??? covers everything needed and is much more commonly used. That helps for non-native speakers.
> 
> Amended can mean ???puts right??? or ???updates??? too. The 18th Amendment (literally) to the US constitution removed the right to manufacture and consume alcohol; the 21st Amendment restored it. 
> 
> All good reasons to just say ???updates???.
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 25 Mar 2020 23:57:04 +0000

> -----Original Message-----
> From: Toerless Eckert <[email-masked]>
> Sent: 25 March 2020 23:25
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: Martin Duke <[email-masked]>; [email-masked]
> Subject: Re: [rfc-i] draft-kuehlewind-update-tag/
> 
[RW]
I'm not sure that "Amended" is significantly better than "Updated".

I think that the reason why a new term was suggested was to allow "updated" to have an ambiguous meaning but give "amended" a precise meaning.

I would just stick with the "Updated" tag but define/clarify its meaning going forward.

> 
> For example, in IP multicast, we have this bible document RFC1112, where
> the rfc1112bis i would like to write (time perrmitting ;-) would mostly
> consist of removing 50% of the doc which specifies what we would now call
> IGMPv1 - an obsolete protocol. To me, this rfc1112bis would well be
> characterized with the word "Updated", but not the word "Amended", because
> to me (non-native speaker), "Amended" sound a bit like "there is more"
> (not a lot less).
> 
> going to work well, because i can esily see a single follow-up RFC to do
> both. There may be one section, where a MUST statement refers and changes
> behavior that existed in the reference RFC and is therefore an "Amendment"
> MUST. Then there is a second feature introducing a new feature, which for
> this RFC is a MUST, so... how would i even distinguish these two MUST ?
> And it seems that a single Amendment MUST "kills" 20 new MUSTs that are
> Extensions.
[RW]
I think that it would be fine for an RFC to both "Update/Amend" (if it is changing existing functionality) and also "Extend" (if it extends the base spec with new functionality).

Thanks,
Rob

> > +1 to Updated meaning Amended, but I think that we could keep the tag
> name the same, but just specify exactly what its behaviour is.
> >
> before the text starts. That is useless. Plus the formal existence of
> these categories will encourage people to use them.
> > [RW]
> > I like the idea of ???Extends??? but not ???Extended By???.  I.e. I
> think that it is useful for an RFC to indicate which base spec it is
> extending, but I don???t think that the base spec needs to indicate which
> optional RFCs it has been extended by.
> >

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Mar 2020 00:56:13 +0000

Hiya,

On 25/03/2020 23:00, Mark Nottingham wrote:
> To me, this is further evidence that a linearly-numbered series of
> archival documents as the primary source of truth is damaging.
FWIW, I'm unconvinced. And skeptical.

But, if that were worth discussing, it'd challenge a
very fundamental tenet of the RFC series, and would
surely therefore be worth at least it's own thread
where you or someone would collate and present your
evidence in some detail?

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Mar 2020 12:02:11 +1100

> On 26 Mar 2020, at 11:56 am, Stephen Farrell <[email-masked]> wrote:
> 

Because I have limited time to devote to this, and it's just an idea. If you don't like it, fine, but don't discard it because I don't meet your arbitrary bar for how to engage.

Thanks,

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 26 Mar 2020 01:07:03 +0000

Hiya,

On 26/03/2020 01:02, Mark Nottingham wrote:
>> But, if that were worth discussing, it'd challenge a very
>> fundamental tenet of the RFC series, and would surely therefore be
>> worth at least it's own thread where you or someone would collate
>> and present your evidence in some detail?
> 
> Because I have limited time to devote to this, 

Very much understand that!

> and it's just an idea.

Sorry, I interpreted "further evidence" as indicating
you'd been more actively collating that kind of thing.
If not, that's fine, my misinterpretation.

> If you don't like it, fine, but don't discard it because I don't meet
> your arbitrary bar for how to engage.

Discard and arbitrary are slightly negative terms, but
anyway, I wasn't saying you were wrong, I was only
doubting you were right:-)

Cheers,
S.

> 
> Thanks,
> 
> -- Mark Nottingham   https://www.mnot.net/
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Mar 2020 21:55:28 -0400

> categories will encourage people to use them.

I am generally in agreement with you.

    > informatively. I think that would be sufficient and automatable.

What if we had two kinds of normative reference?

    > TLDR, rename Updated to Amended, build the citation tool, and call it done.

... so that the citation tool could link forward intelligently.
Otherwise RFC793-like issue can occur for many documents.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Joseph Touch <[email-masked]>
Date: Wed, 25 Mar 2020 20:21:32 -0700

On Mar 25, 2020, at 4:54 PM, Toerless Eckert <[email-masked]> wrote:
> ...
> details.

Doesn’t help even if you do.

Amended means changed (presumably for the better).

Updated literally means ‘newer’.

Even native-speaking English nit-pickers would have a hard time arguing the difference, except when trying to fit a crossword clue.

> The main reason for changing words is to support a
> change in semantic.

In that regard, it fails.

What PROBLEM is driving this?

Can we please STOP burning person-hours on this sort of nonsense?

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 25 Mar 2020 23:40:31 -0400

The problem was to my mind very clearly stated.  We burn person-hours 
figuring out what we mean each time any document gets tagged this way. 
We want the relationship tags, so we can find things.  But our current 
"updates" tag has multiple meanings, so people get very confused.

One choice would be to explicitly document all the meanings we use it 
for, and say "this is what it means.  Sorry."

We could, I suppose, pick a single definition for "updates" and say that 
from here on, that is what it means.  This has the drawback of leaving 
outside folks confused as they will not know know of any flag day of 
meaning change.  And leaves us with no coverage for the other meanings.

We could make up new terms, and try to specify more clearly their 
meaning.  We then document that older documents used "updates" with a 
range of meanings, and newer documents use "foo" and "bar" with the 
following definitions that the community (presumably) has agreed and 
which are more clear.  (Nothing is perfect, it is human language.)  That 
is, as I understand it, what the document in front of us attempts to start.

I am sure that there are other choices.  (We are much too clever.)  But 
I would prefer not to stick my head in the sand and pretend something 
that regularly causes this much confusion is just fine.

Yours,
Joel

---

From: Joseph Touch <[email-masked]>
Date: Wed, 25 Mar 2020 20:49:58 -0700

> On Mar 25, 2020, at 8:40 PM, Joel M. Halpern <[email-masked]> wrote:
> 
> The problem was to my mind very clearly stated.  We burn person-hours figuring out what we mean each time any document gets tagged this way. We want the relationship tags, so we can find things.  But our current "updates" tag has multiple meanings, so people get very confused.

Any of the proposed new tags arguably applies to many different things. What’s the difference between extends and changes? When does a change affect compatibility - only when it causes a failure or when it causes a change of any kind?

These are “angels on the head of a pin” discussions. The only solution to understanding how one doc updates another is a *discussion* in that doc. No single set of terms will capture the nuances necessary to decide what parts of an update are critical vs. not. That’s a responsibility of the updates doc author. Thinking a tag will solve that problem is naive.

To be clear, I wish we did have some rigor here. Something that said “hey, to spec a protocol, provide a FSM”. But we don’t.

For decades, some even asserted (incorrectly) that the API of a protocol wasn’t part of its spec and was out of scope (an *implementation* of an API might be, but 793 has a good example of one that is necessary and not implementation details).

“Updates” means just that - it affects the base document in a way that MIGHT be hazardous to ignore. That means you need to read the doc to find out why, to what extent, and how that affects what you want to do.

There is no shortcut here.

> I am sure that there are other choices.  (We are much too clever.)  But I would prefer not to stick my head in the sand and pretend something that regularly causes this much confusion is just fine.

I’m not ignoring the problem. I’m just not naive enough to believe a handful of tags fixes it either.

Joe

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Mar 2020 11:14:27 -0500

On 3/25/2020 6:00 PM, Mark Nottingham wrote:
> To expand on discussion a bit -- one of the things that kept on coming up was that "updated" was never well-defined, causing this confusion. So one approach we could take would be to_define it_.

I think that having 50 years of haphazard use of the term has thoroughly 
salted that particular patch of ground. We need a new term, and that's 
what Mirja's document proposes.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 26 Mar 2020 11:18:11 -0500

> Can we please STOP burning person-hours on this sort of nonsense?

The problem is that the IESG keeps having to rehash this discussion on a 
document-by-document basis, which wastes the IESG's time. This is 
happening at the same time as the community is begging the IESG to 
figure out ways to lower ADs' workload so as to make it more attractive 
to a wider set of candidates.

There is a straight line between those two points.

/a

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Mar 2020 09:53:50 -0700

Well, it seems like this assumes without much evidence that having three
separate metadata types won't just triple the amount of rehashing.

It seems like there are at least two much simpler fixes:

- Stop using Updates or any other such metadata entirely
- Replace Updates with "See Also" and have it explicitly have no semantics
at all

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2020 13:03:17 -0400

On Mar 26, 2020, at 12:53 PM, Eric Rescorla <[email-masked]> wrote:
> - Replace Updates with "See Also" and have it explicitly have no semantics at all

Another solution that would work: stop publishing RFCs.  :)

I really don’t see what the objection to this is.  If it works, we win.  If it doesn’t work, I don’t think we’re any worse off.  You assume that having three types will triple the rehashing, but there’s no real justification for that assumption.  Does a hash table make things slower?  This is sort of analogous: instead of one bucket, you have multiple buckets, each with a clearly defined meaning.  Even if it doesn’t dramatically improve things, it probably won’t make them significantly worse.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2020 13:10:45 -0400

(I always listen when Joel speaks, he rarely speaks for fun)

    > figuring out what we mean each time any document gets tagged this way.

I agree strongly with this as the problem statement.

    > We could make up new terms, and try to specify more clearly their meaning.
    > We then document that older documents used "updates" with a range of
    > meanings, and newer documents use "foo" and "bar" with the following
    > definitions that the community (presumably) has agreed and which are more
    > clear.  (Nothing is perfect, it is human language.)  That is, as I understand
    > it, what the document in front of us attempts to start.

There is a further choice which there wasn't time/place to talk about
yesterday.    I would like WGs that have the time, to be able to go back and
clarify what their Updates actually mean.

If we are going to do a survey, we basically need to do that *anyway*.

    > I am sure that there are other choices.  (We are much too clever.)  But I
    > would prefer not to stick my head in the sand and pretend something that
    > regularly causes this much confusion is just fine.

+1
(We could have a moritorium on the IESG talking about Updates.)

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Mar 2020 13:14:42 -0400

Joseph Touch <[email-masked]> wrote:
    > Any of the proposed new tags arguably applies to many different
    > things. What’s the difference between extends and changes? When does a
    > change affect compatibility - only when it causes a failure or when it
    > causes a change of any kind?

It's great that you agree that we have to stop wasting hours on this :-)

Your proposal:
    > The only solution to understanding how one doc updates another is a
    > *discussion* in that doc.

    > “Updates” means just that - it affects the base document in a way that
    > MIGHT be hazardous to ignore. That means you need to read the doc to
    > find out why, to what extent, and how that affects what you want to
    > do.

I wonder if you can recognize that this might not be the only way it has been
used in the past.  Maybe those uses were in error, but you've picked a
particular definition that wasn't always applied.

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Mar 2020 10:19:04 -0700

> On Mar 26, 2020, at 9:18 AM, Adam Roach <[email-masked]> wrote:
> 
> 

There is no shortcut here.  The proposal swaps one term for multiples, which only serves to create more ambiguity. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Mar 2020 10:25:49 -0700

> On Mar 26, 2020, at 10:14 AM, Michael Richardson <[email-masked]> wrote:
> 

I do. Adding terms doesn’t make that more clear or useful. Updates means changes of any nature that do not replace the prior RFC in its entirety.  

If that isn’t obvious to any English speaker, then these nuanced other terms that subdivide that category further definitely will not help. 

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Mar 2020 10:25:52 -0700

> I really don’t see what the objection to this is.  If it works, we win.
> If it doesn’t work, I don’t think we’re any worse off.  You assume that
> having three types will triple the rehashing, but there’s no real
> justification for that assumption. Does a hash table make things slower?
> This is sort of analogous: instead of one bucket, you have multiple
> buckets, each with a clearly defined meaning.  Even if it doesn’t
> dramatically improve things, it probably won’t make them significantly
> worse.
>

As I said in my initial mail, the first rule of holes is "stop digging".

-Ekr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 26 Mar 2020 13:32:08 -0400

On Mar 26, 2020, at 1:25 PM, Eric Rescorla <[email-masked]> wrote:
> As I said in my initial mail, the first rule of holes is "stop digging”.

Again not really an actionable comment, though, unless the first rule of code optimization is to never optimize.

What all of these “rules” mean is that you don’t have solid data to back up your opinion—it’s just your opinion. There’s nothing wrong with that, and you might be right, but you can’t end a debate by expressing an opinion.

What might be a more actionable rule would be “don’t optimize until you need to,” which I think we have all taken to heart by this point in our careers.  I think you think we don’t need to optimize here; clearly the authors think we do.

A way forward is probably not going to involve someone convincing everyone else to have the same opinion.   Can we maybe do an exercise of analyzing some set of past RFCs to see how we think this document would apply to them?  That might help us to collect more data, so that we don’t just have to rely on opinion.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Mar 2020 10:44:16 -0700

On Thu, Mar 26, 2020 at 10:32 AM Ted Lemon <[email-masked]> wrote:

> What all of these “rules” mean is that you don’t have solid data to back
> up your opinion—it’s just your opinion. There’s nothing wrong with that,
> and you might be right, but you can’t end a debate by expressing an opinion.
>
> What might be a more actionable rule would be “don’t optimize until you
> need to,” which I think we have all taken to heart by this point in our
> careers.  I think you think we don’t need to optimize here; clearly the
> authors think we do.
>
> A way forward is probably not going to involve someone convincing everyone
> else to have the same opinion.   Can we maybe do an exercise of analyzing
> some set of past RFCs to see how we think this document would apply to
> them?  That might help us to collect more data, so that we don’t just have
> to rely on opinion.
>

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.

-Ekr

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Mar 2020 14:45:58 -0400

(Resend.)

Joe, we all know that the formal words we use do not have the same 
meaning that they do in English.  Our standards are not, effectively, 
"requests for comment".  They are standards.
We also know by observation that other people have understood "Updates" 
in ways that are different from how you understand it.  Claiming that 
the meaning as used for metadata on RFCs is "obvious to any English 
speaker" is contradicted by the observable facts.

Yours,
Joel

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 26 Mar 2020 19:56:41 +0100

I would appreciate if we would first or at least also work on guidance
for what needs to go into an "update to RFCXXXX" section for new
documents. Once we are clear about at the things that should be
said (how prir doc is changed, what impact on interop thia
results in, ..), it will be a lot easier to figure out if there are simple
classifications that could go into metadata. Then its yet a third
step whether we should try to expand/proliferate on our rather
old metadata approach or go with newer approaches like what Mcr
suggested.

Cheeers
    toerless

On Thu, Mar 26, 2020 at 02:45:58PM -0400, Joel M. Halpern wrote:
> (Resend.)
> 
> Joe, we all know that the formal words we use do not have the same meaning
> that they do in English.  Our standards are not, effectively, "requests for
> comment".  They are standards.
> We also know by observation that other people have understood "Updates" in
> ways that are different from how you understand it.  Claiming that the
> meaning as used for metadata on RFCs is "obvious to any English speaker" is
> contradicted by the observable facts.
> 
> Yours,
> Joel
> 
> > > > ???Updates??? means just that - it affects the base document in a way that
> > I do. Adding terms doesn???t make that more clear or useful. Updates means changes of any nature that do not replace the prior RFC in its entirety.
> > 
> > If that isn???t obvious to any English speaker, then these nuanced other terms that subdivide that category further definitely will not help.
> > 
> > Joe
> >

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 26 Mar 2020 15:13:45 -0400

Actually, I have generally found that our practices for document content 
regarding updates are pretty good.
And to the degree they can be improved (I presume they can) that seems 
quite separate from the problem that the proposers have asked about. 
And it seems to me that the problem they have raised is one worth solving.

Yours,
Joel

PS: And our document content for updating documents does not engender 
the same kind of confusion and perpetual discussion.

---

From: Joe Touch <[email-masked]>
Date: Thu, 26 Mar 2020 13:21:16 -0700

All true but then all reasons why nuanced definitions to dive into overlapping sub cases isn’t helpful. 

A single word or phrase is never enough. 

Joe

> On Mar 26, 2020, at 11:45 AM, Joel Halpern Direct <[email-masked]> wrote:
> 
> Joe, we all know that the formal words we use do not ahve the same meaning that they do in English.  Our standards are not, effectively, "requests for comment".  They are standards.
> We also know by observation that other people have understood "Updates" in ways that are different from how you understand it.  Claiming that the meaning as used for metadata on RFCs is "obvious to any English speaker" is contradicted by the observable facts.
> 
> Yours,
> Joel
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2020 14:43:55 +1300

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.

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. Certainly it's incomplete; for example RFC7474 amends RFC793. And so what anyway? If an important RFC like 793 is amended or extended by 50 RFCs, that should definitely be in the metadata.

"See Also" would rarely be needed, I think, and its usage would be curated
by the IESG.

Stay well,
     Brian

---

From: Joseph Touch <[email-masked]>
Date: Thu, 26 Mar 2020 20:01:12 -0700

> On Mar 26, 2020, at 6:43 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> ekr,

How about giving us some concrete examples? Or perhaps the authors could (should)?

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

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

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

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 27 Mar 2020 16:34:23 +1300

Joe,

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

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

> 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

---

From: Joseph Touch <[email-masked]>
Date: Thu, 26 Mar 2020 20:48:51 -0700

Hi, Brian,

> On Mar 26, 2020, at 8:34 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Joe,
> 

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

> Both. Why would it be a problem to use both tags if they both apply?

What’s the point? Why the nuance?

> 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

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 27 Mar 2020 09:10:08 -0400

(wearing no hats, personal opinion only)

> On Mar 26, 2020, at 1:10 PM, Michael Richardson <[email-masked]> wrote:

Fully support this. The main reason the IESG talks about this a lot is because ADs question the use of the tag. In the absence of mutable documents and since we tried multiple times to see if there could be clarity in the community about what “updates” means and failed, we could just accept that it’s an unclear tag and stop discussing it. We could even document the moratorium in an IESG statement.

Alissa

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 26 Mar 2020 14:44:52 -0400

Joe, we all know that the formal words we use do not ahve the same 

Yours,
Joel

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 27 Mar 2020 12:06:51 -0400

Hi all,
  Going over the thread some folks including EKR, Martin, Mark, and Joe have asked for some support numbers for this. I just want to provide an update that I am working on some numbers on a bunch of recent RFCs to get some rigor into this. As you may imagine this is a time consuming task (I have to read at least the Abstracts and Introductions and potentially more of hundreds of RFCs) that I estimate to take around 20+ hours for me to do. So bear with me until this happens.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 27 Mar 2020 12:17:51 -0400

Hi Joe,

> On Mar 26, 2020, at 11:48 PM, Joseph Touch <[email-masked]> wrote:
> 
> Hi, Brian,
> 

Huh? There is a reason there are two outgoing IESG members writing this. 

1) We have seen this issue come up several times there is an Updates tag in a draft up for IESG eval during our 4 year term
2) Mirja and I picked up this task exactly because we were outgoing and did not want this to be seen as pushed by the IESG on the community.

If you had followed the discussion on RFC Interest before when we introduced the draft for discussion

https://www.rfc-editor.org/pipermail/rfc-interest/2020-February/011203.html

I *had specifically* added this note to the mail:

"NOTE: Even though we are both sitting members of the IESG, we have written this draft solely as members of the community and we will no longer be IESG members if and when this draft progresses"

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

i agree with you that this is a reasonable ask. Your original ask of going through *ALL* current updates was (IMHO) not, and that is what I think Brian was responding to.

Thanks
Suresh

---

From: Joseph Touch <[email-masked]>
Date: Fri, 27 Mar 2020 09:44:48 -0700

> On Mar 27, 2020, at 9:17 AM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi Joe,
>> ...

"Several times” is a poor threshold for a wide-ranging process update.

> 2) Mirja and I picked up this task exactly because we were outgoing and did not want this to be seen as pushed by the IESG on the community.

Then you needed to wait until you were out of office, IMHO. 

Above, you point out that this is being written because of your context as IESG members. You can’t (IMO) believably claim that and then claim this is individual at the same time.

> i agree with you that this is a reasonable ask. Your original ask of going through *ALL* current updates was (IMHO) not, and that is what I think Brian was responding to.

Let me be a little more specific in the range of “a few” to “all”. How about enough to warrant this sort of change?

1) how many times did this come up vs other contentious issues at the IESG level?
	the IESG is inherently contentious - being across many areas of expertise and often seeing issues late in the development process when they’re outside their area

2) is there any metric of success here?
	the IESG is never going to “not” need to debate issues such as this; that is their role

Joe

---

From: Joseph Touch <[email-masked]>
Date: Fri, 27 Mar 2020 09:50:05 -0700

+1

Less is more. If this sort of process change is sufficient, it seems a much less disruptive change than upending the currently very simple document marking set.

Joe

> On Mar 27, 2020, at 6:10 AM, Alissa Cooper <[email-masked]> wrote:
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 27 Mar 2020 18:21:11 +0100

Hi all,

Having an IESG agreement to “give up” and not have further discussion about this could probably improve the situation but I don’t think it would make all of the time spent on discussions and explanations go away entirely because the confusion remains.

In my time as AD I would sometimes put a comment in my ballot saying something like “maybe this document should up RFCXXX” just because I thought that would be inline with other documents that have used the update tag and as a minor attempt to increase maybe consistency. The intention was only to make sure the authors have considered it. I usually got two kind of replies: either “yes, we didn’t know what to do and are happy to do whatever the IESG recommends” or alternatively a very strong opinion that this was extensively considered by the group and the way it is proposed is the only right way to handle it. Both replies are problematic as the first one is a request for guidance and the second one would warrants some clarification that (while it’s fine that every groups decides about it) there is no absolute right or wrong here and different groups treat this differently. So my assumption is that even if the IESG doesn't “provoke” that discussion it will not go away.

I mentioned this briefly at the beginning of my presentation in gendispatch but to provide more background: The IESG already tried to address the problem by proposing an IESG statement to clarify that the updates tag merely provides a link but otherwise brings no defined obligations with it, see [1]. The feedback we got from the community at that time was that they would prefer a clear definition. So Suresh and I took this up and are proposing this as members of the community (of course with the background that we are well aware of any IESG discussions related to this topic that happen in the last 4 years).

We did discuss “just” defining the updates tag but based on the list feedback and various different uses and strong feeling about the use of it, I think that would just upset a lot of people, so we decided for defining new tag. I think the current ongoing discussion on the list again show that many people believe the know exactly what the updates tag means while other people have a similar strong feeling about a different meaning of it. Having that said we are of course open to alternative proposals or changes to the current proposal!

Mirja

[1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE/

> On 27. Mar 2020, at 14:10, Alissa Cooper <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Mar 2020 11:03:39 +1300

On 27-Mar-20 16:48, Joseph Touch wrote:
...
> What’s the point? Why the nuance?

Personally, I don't think that the difference between:
"You need to write some new code."
and
"You need go and fix your old code."
is just a nuance. Product managers may view these as two totally
different matters with different business implications.

    Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Mar 2020 15:44:46 -0700

> On Mar 27, 2020, at 3:03 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Personally, I don't think that the difference between"You need to write some new code."
> and

Right.  Adding features means just adding code.  Right.  

Must be sunny there.  

Joe

---

From: Jeffrey Yasskin <[email-masked]>
Date: Fri, 27 Mar 2020 15:54:56 -0700

On Fri, Mar 27, 2020 at 9:45 AM Joseph Touch <[email-masked]> wrote:

> 2) Mirja and I picked up this task exactly because we were outgoing and
> did not want this to be seen as pushed by the IESG on the community.
>
>
> Above, you point out that this is being written because of your context as
> IESG members. You can’t (IMO) believably claim that and then claim this is
> individual at the same time.
>

I feel like this part of the discussion is crossing the boundaries set in
https://tools.ietf.org/html/bcp54#section-2 into personal attacks. Mirja
and Suresh wrote this draft trying to improve how the IETF works based on
their own experiences, and while they might or might not be proposing the
right solutions or have supported their proposal well enough to convince
everyone, they're not throwing bombs or otherwise behaving inappropriately.

It might be useful to let this sit for some cooldown period (for example
while Suresh reads a bunch of RFCs) before inflaming things more.

Thanks,
Jeffrey

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Mar 2020 13:57:33 +1300

> Right.  Adding features means just adding code.  Right.  

Ultimately, yes. If the base protocol has hooks for extensibility and the base code is well designed, that is. But regardless, in corporate software, it may mean having the software touched by the team in Banaglore vs the team in North Carolina, or whatever. These really are different things.

> Must be sunny there.  

Yes, thanks, it is!

   Brian