Info/exptl RFCs [Re: Killing old/slow groups - transition thinking)

[Fred Baker]

At 03:08 PM 12/16/2002 -0600, Pete Resnick wrote:
>  I object to the "combination of review and process review" whereby we 
> get "whatever other comments the IESG might have." Where in 2026 (or any 
> other document) does the IESG have the responsibility to give technical 
> review to such documents?

I think you're over-estimating what they actually do. The comments usually 
come down to "we don't recommend that you publish this", or "we have no 
problem with you publishing it", or something along that line.

For example: in http://ftp.ietf.org/iesg/iesg.2002-09-19,

12. The IESG had no problem with the publication of Assignment of the
     'OAM Alert Label' for MPLS Operation and Maintenance (OAM)
     functions <draft-ohta-mpls-label-value-03.txt> as an Informational
     RFC. Secretariat to convey to RFC Editor.

13. The IESG had no problem with the publication of Asynchronous
     Transfer Mode (ATM) Package for the Media Gateway Control Protocol
     (MGCP) <draft-rajeshkumar-mgcp-atm-package-07.txt> as an
     Informational RFC. Secretariat to convey to RFC Editor.

14. The IESG had no problem per se with the publication of Per Hop
     Behaviors Based on Dynamic Packet States
     <draft-stoica-diffserv-dps-01.txt> as an Experimental Protocol, but
     Thomas and Allison are to prepare an IESG Note.

Occasionally, as in this last, they will insert an "IESG note", which is 
some comments that the IESG had on a document. Concerning <stoica>, Thomas 
and Allison haven't conveyed to me what the IESG note might be, but I 
suspect that it is something along the lines of some considerations that 
users of the facility might take into account in order to be interoperable 
with other specifications that are in fact standardized. Of the 3432 
published RFCs, 81 (2.36%) have IESG notes. A few examples:

RFC 1505:
     IESG Note

        Note that a standards-track technology already exists in this area
         [11].

RFC 1693:
     IESG Note:

        Note that the work contained in this memo does not describe an
        Internet standard.  The Transport AD and Transport Directorate do not
        recommend the implementation of the TCP modifications described.
        However, outside the context of TCP, we find that the memo offers a
        useful analysis of how misordered and incomplete data may be handled.
        See, for example, the discussion of Application Layer Framing by D.
        Clark and D. Tennenhouse in, "Architectural Considerations for a New
        Generation of Protocols", SIGCOM 90 Proceedings, ACM, September 1990.

RFC 2965:
     IESG Note

        The IESG notes that this mechanism makes use of the .local top-level
        domain (TLD) internally when handling host names that don't contain
        any dots, and that this mechanism might not work in the expected way
        should an actual .local TLD ever be registered.

Those comments don't read to me as if the IESG did the level of review or 
exchange with these authors that it does with working groups - sending the 
documents back with specific edit or acceptance instructions and so on. But 
they read to me as observations that I as a user or implementor of the RFC 
might want to know. I really don't see the problem here that you seem to see.