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

From: Toerless Eckert <[email-masked]>
Date: Wed, 25 Mar 2020 23:23:25 +0100

I like to solve the problem. I am not sure the proposed solution is
sufficient though.

On the nitpicking style, i am not sure that the distinction of
New MUST -> Amends New "optional" is a good way to define
the distinctions:

If i was an operator, i would primarily like to understand the
interoperability effects. We the new document be expected to
interoperate in all circumstances with the old version RFC ?
Security Amendmends certainly will the need option to kill
backward compatibility (old RFC had a now broken security scheme).

I would feel a lot easier to conclude what would need to be
done if there was a collection of different example "use cases",
and challenge the community to come up with new "use cases" where
the proposed solution does not work well enough.

I "feel" that it would be better not to try to solve our issues
nly with as few as possible tags, but also ponder what a good
amendment/extensions text in an RFC should look like.
E.g.: separate section summarising "Changes" over the prior
RFC is IMHO a good approach.

"This rfc replaces the following text in prior RFC with the
text outlined in section xx of this rfc. This impacts
interoperability as follows".

Just an example.

Cheers
    Toerless
_______________________________________________
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:59:20 -0700

> On Mar 25, 2020, at 3:24 PM, Toerless Eckert <[email-masked]> wrote:
> 
> 

IMO the latter is better guidance. We need less process, not more. ESP given we have no compliance requirements. Tags are not a solution. 

Joe

---

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

> backward compatibility (old RFC had a now broken security scheme).

That's a place where I didn't know if Amends really meant "fixes", and if we
wanted to mix mandatory fixes in with things which just clarify things.

    > the proposed solution does not work well enough.

I think that might work.
That's where the review of uses might be good.

    > interoperability as follows".

I have some additional thoughts here.
A number of people in the jabber suggested the same thing.

I want to point out that we already have a forward reference meta-data in the
DT, because documents which reference a document create that backward
reference, and we simply invert the reference.

What I think that we might need is annotation in the normative XML that
indicates that this is essentially an Updates.
I think they need to be normative, but maybe we want to split the normative
into "background reading", and "updates" section.
Not all normative references should cause forward references.

This puts all the decisions back into the WG, provides clear way to do the
text, etc.  Maybe we want a clear section header for this.
This might take a year or so to sort out and become BCP.

---

My suggestion for the IESG is that we just stop using Updates.
We can't argue of things then.

My next suggestion, regardless of what we above, that we allow WGs to go back
an annotate documents as to what kind of update they do.
Maybe this document is the right set of names, maybe some new ones would emerge.
How we store this information is open.  It could be posted as errata, or...

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