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

[Mirja Kuehlewind <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
> On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <[e-mail]> wrote:
> Hi Ekr,
> 
> > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <[e-mail]> 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
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

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