Re: [tsvwg] When to use Updates -- was: SCTP NAT support, draft-stewart-natsupp-tsvwg-00

[Alfred Hönes <[e-mail]>]

The discussion circles around a 'simple' open question --

    When is "Updates" appropriate?

Sadly, it indeed is a very open question whether that is
an _open_ question at all!

A few observations and conclusions below.


a)  The RFC Editor

As recalled by Section 3.1 of RFC 5741,
  "Updates" is defined in RFC 2223 ...
and...
  "Other types of relationships may be defined by the RFC Editor
   and may appear in future RFCs."

Arguably, the RFC Editor is given an important role by the IAB
wrt RFC metadata relations.
==> If in doubt, you might refer (or defer) to the RFC Editor.

"Instructions to Request for Comments (RFC) Authors", the
"successor of RFC 2223",
  <http://www.rfc-editor.org/rfc-editor/instructions2authors.txt>
states in Section 2.11:

|   Updates
|
|      Specifies an earlier document whose contents are modified or
|      augmented by the new document.  The new document cannot be
|      used alone, it can only be used in conjunction with the
|      earlier document.

That's the current definition, yet apparently not always enforced
by the RFC Editor, in order to avoid conflict with the RFC stream
"gatekeepers".   :-)

IMO, "cannot be used alone, can only be used in conjunction with
the earlier document" is a prudently chosen clause specifying a
criterion that can be decided upon in a rather objective manner.

Note that the previous definition in RFC 2223 was much more
complicated and open to controversial exegesis, and that the
current definition calls for much more widespread use of the
relation than supported by those favoring the old definition.


b)  The IESG

Because of the role given to the RFC Editor by the IAB, I rather
sceptically observe a recent IESG effort that might collide with
the above.

Quoting from recent IESG minutes:


<http://www.ietf.org/iesg/minutes/2009/narrative-minutes-2009-10-22.html>
---- snip ----
|IESG Narrative Minutes
|
|Narrative Minutes of the IESG Teleconference on 2009-10-22.
|These are not an official record of the meeting.
|
|...
|
|4.Review of Action Items from last Telechat
|
|...
|
|  o   Lars Eggert and Ron Bonica to propose text for determining
|      when one document updates another.
|      Ron: in progress
|      Lars: I need to reply to Ron's draft
|
|...
|
---- snip ----

.
.  (skipped)
.

... and the two most recent narrative minutes posted ...


<http://www.ietf.org/iesg/minutes/2009/narrative-minutes-2009-12-17.html>
---- snip ----
|IESG Narrative Minutes
|
|Narrative Minutes of the IESG Teleconference on 2009-12-17.
|These are not an official record of the meeting.
|
|...
|
|4.Review of Action Items from last Telechat
|
|...
|
|  o   Lars Eggert and Ron Bonica to propose text for determining
|      when one document updates another.
|      Ron: no progress
|
|...
|
---- snip ----


<http://www.ietf.org/iesg/minutes/2010/narrative-minutes-2010-01-07.html>
---- snip ----
|IESG Narrative Minutes
|
|Narrative Minutes of the IESG Teleconference on 2010-01-07.
|These are not an official record of the meeting.
|
|...
|
|4.Review of Action Items from last Telechat
|
|...
|
|  o   Lars Eggert and Ron Bonica to propose text for determining
|      when one document updates another.
|      Amy: Lars not here; Ron...
|      Lars: (just got on): still in progress
|
|...
|
---- snip ----


To sum up:  work in progress; overload on IESG ...    :-)


According to personal experience, the authors-in-charge seem to
favor rather sparse use of "Updates"; there are other ADs much
more in favor of using that metadata relation (in lack of more,
established metadata relations for RFCs that allow to express a
finer granularity of relationship between documents) ubiquitously
whenever implementers of an old document should be made aware of
the existence of a new document, so that they can at least take
appropriate provisions in planning for future support of new
features, even if they do not care implementing these now.
In other words, these ADs favor the RFC Editor definition.

So realistically you should not expect IESG consensus on a draft
IESG statement soon; opinions will change and will have to settle
after the new ADs have been seated at IETF.

As soon as the IESG comes out with a draft statement, there will
most likely happen a flame war on the IETF main list, a few famous
folks and the "add-on" value lists (hoho, ambiguous language!) will
step in, etc., until everybody is exhausted and the Secretariat
needs additional disk space for mailing list archival.  :-)


c)  Conclusion

So come back with that 'simple' question next year (or later),
unless you have a strong opinion and want to firmly state:
"We take on this position for that draft, and we will defend
that decision in the IESG."


Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: [phone], Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
+------------------------+--------------------------------------------+