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

On Mon, Mar 9, 2020 at 10:42 AM Mirja Kuehlewind <ietf@kuehlewind.net>
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!
>
> > On 29. Feb 2020, at 14:50, Eric Rescorla <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <
> suresh.krishnan@gmail.com> wrote:
> > Hi Ekr,
> >
> > > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <ekr@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.
>

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

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

Yes.

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

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
>
>
>
> >
> > -Ekr
> > _______________________________________________
> > rfc-interest mailing list
> > rfc-interest@rfc-editor.org
> > https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
>