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

Michael Richardson mcr+ietf at sandelman.ca
Wed Mar 25 18:51:39 PDT 2020


Toerless Eckert <tte at cs.fau.de> wrote:
    > 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).

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.

    > 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 think that might work.
That's where the review of uses might be good.

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

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 <mcr+IETF at sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20200325/1cb84b81/attachment-0001.asc>


More information about the rfc-interest mailing list