[rfc-i] Feedback solicited: Update tags draft

Mirja Kuehlewind ietf at kuehlewind.net
Mon Mar 9 10:42:31 PDT 2020


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 <ekr at rtfm.com> wrote:
> 
> 
> 
> On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <suresh.krishnan at gmail.com> wrote:
> Hi Ekr,
> 
> > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <ekr at rtfm.com> 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
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest



More information about the rfc-interest mailing list