Subject: Re: [rfc-i] Feedback solicited: Update tags draft

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 9 Mar 2020 18:33:08 +0100

Hi Julian,

We added a note in the new version just submitted:

https://datatracker.ietf.org/doc/draft-kuehlewind-update-tag/

Mirja

> On 29. Feb 2020, at 09:40, Suresh Krishnan <[email-masked]> wrote:
> 
> 
>> On Feb 27, 2020, at 3:56 PM, Julian Reschke <[email-masked]> wrote:
>> 
>> On 27.02.2020 00:52, Suresh Krishnan wrote:
>>> Now with a link to the draft :-)
>>> 
>>> https://tools.ietf.org/html/draft-kuehlewind-update-tag-01
>>> 
>>> Thanks
>>> Suresh
>> 
>> You may want to mention that this requires changes to the xml2rfc
>> vocabulary (RFC 7991).
> 
> Thanks Julian. Will add this in the next revision.
> 
> Regards
> Suresh
> 
> _______________________________________________
> rfc-interest mailing list
> [email-masked]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> 

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 9 Mar 2020 18:42:31 +0100

Hi Ekr,

We just submitted a new version and I tried to add a note about conformance, however, not sure we can say much in this draft. Please see also below for further comments!

> On 29. Feb 2020, at 14:50, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <[email-masked]> wrote:
> Hi Ekr,
> 
> > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <[email-masked]> wrote:
> > 
> > At present, I am not in favor of these changes.
> > 
> > We already spend quite a bit of time debating which tags should apply when compared to the (IMO marginal) value of these tags, and this seems likely to make that worse. 
> > 
> > The "amended" tag in particular seems like a workaround for our refusal to simply update RFCs when they are wrong. The first rule of holes to stop digging.
> 
> The option to bis the RFCs will still exist and the IESG can still guide people to do that. The goal of the Amended tag is to point implementers to other RFCs that are mandatory to implement. Right now Updates is being used both for optional extensions as well as for mandatory changes and the goal is to disambiguate this.
> 
> I'm not talking about -bising the RFC. I'm talking about re-publishing
> with the same RFC #.

I think that is really a broader topic for discussion and will probably require a whole bunch of changes to how we work and publish. The IESG started some discussion about living documents and I think there are many open questions. But I really think this is mostly an independent discussion to what is proposed in the draft.

> 
> More generally, I don't really understand what you think "mandatory"
> means. 
> 
> Consider two cases:
> 
> 1. We publish an RFC X with a clear mistake. For instance, it allocates
>    two code points, A and B, and then in the text it says A=1 and
>    B=2 but in the IANA considerations it says A=1, B=1
> 
> 2. We publish an RFC X with an algorithm we later determine to be bad.
>    For instance it says to use a parameter 2 but we later determine
>    that 2 is bad and 3 would be better.
> 
> In the former case, I would argue that the RFC correctly read had the
> code points A=1 B=2 and thus in order to be conformant with RFC X, you
> need to adopt B=2.

Yes and I think these things are often rather errata.
> 
> However, what would you say in the latter case?  Older implementations
> continue to be conformant with RFC X, but just not with RFC Y, which
> you publish later. So, what does "mandatory" mean in this case? The
> problem here, as usual, is the failure to have some way to refer to
> the concept of the protocol rather than the concept of the RFC.

This part I tried to clarify in the draft. Extending/amending does not change the existing RFC. That means if someone's implementation conform to that RFC, it still does so even when a new amending RFC is published. However, with amend there is now an explicit recommendation that implementations should also update to confirm to the new RFC. 

The other option would be to bis a spec and obsolete the old one. However, even if an RFC is obsoleted, old implementation that conform to that RFC will still only conform to that RFC and not magically change. Similar as proposed for “Amends”, there however is a stronger expectation that those implementations need to change. 

Mirja

> -Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Mar 2020 10:45:16 -0700

On Mon, Mar 9, 2020 at 10:42 AM Mirja Kuehlewind <[email-masked]>
wrote:

> Hi Ekr,
>
> We just submitted a new version and I tried to add a note about
> conformance, however, not sure we can say much in this draft. Please see
> also below for further comments!
>
> > > We already spend quite a bit of time debating which tags should apply
> when compared to the (IMO marginal) value of these tags, and this seems
> likely to make that worse.
> > >
> > > The "amended" tag in particular seems like a workaround for our
> refusal to simply update RFCs when they are wrong. The first rule of holes
> to stop digging.
> >
> > The option to bis the RFCs will still exist and the IESG can still guide
> people to do that. The goal of the Amended tag is to point implementers to
> other RFCs that are mandatory to implement. Right now Updates is being used
> both for optional extensions as well as for mandatory changes and the goal
> is to disambiguate this.
> >
> I think that is really a broader topic for discussion and will probably
> require a whole bunch of changes to how we work and publish. The IESG
> started some discussion about living documents and I think there are many
> open questions. But I really think this is mostly an independent discussion
> to what is proposed in the draft.
>

I don't agree. This draft seems like a clunky fix for what is broadly the
same problem.

> Yes and I think these things are often rather errata.

Yes.

> This part I tried to clarify in the draft. Extending/amending does not
> change the existing RFC. That means if someone's implementation conform to
> that RFC, it still does so even when a new amending RFC is published.
> However, with amend there is now an explicit recommendation that
> implementations should also update to confirm to the new RFC.
>

> The other option would be to bis a spec and obsolete the old one. However,
> even if an RFC is obsoleted, old implementation that conform to that RFC
> will still only conform to that RFC and not magically change. Similar as
> proposed for “Amends”, there however is a stronger expectation that those
> implementations need to change.
>

These seem like extremely fine distinctions that are not going to be at all
useful in practice. I am having trouble seeing how we would meaningfully
use them to guide our implementation.

-Ekr

Mirja