Mykyta Yevstifeyev | 25 Mar 07:08 2011
Picon

A question and proposal for draft-ietf-newtrk-cruft

Hello Harald and Eliot,

{Also copying this to NEWTRK mailing list}

I've recently looked at you Internet-Draft draft-ietf-newtrk-cruft (http://tools.ietf.org/id/draft-ietf-newtrk-cruft-00.txt).  At the time when you worked on it I, unfortunately, wasn't at IETF and could not witness what was happening then.  As far as I can see, this draft was issued nearly 1.5 year before WG conclusion.   I also see this document was discussed at IETF 61th meeting, but I can't find any mention of it at further meetings.  Therefore, I'd like to ask what happened that this draft did not move forward and expired?  Could you please give me a short insight in that events?

Moreover, I'd like to propose conducting the process experiment per RFC 3933 on the procedures defined in this draft; personally for me they seem interesting.  What do you think about such idea?

Mykyta Yevstifeyev
_______________________________________________
NEWTRK mailing list
NEWTRK <at> ietf.org
https://www.ietf.org/mailman/listinfo/newtrk
IESG Secretary | 17 Aug 21:50 2006
Picon

WG Action: Conclusion of New IETF Standards Track Discussion (newtrk)

The New IETF Standards Track Discussion WG (newtrk) in the General
Area has concluded.

The IESG contact person is Brian Carpenter. 

The mailing list will remain active.
.
Brian E Carpenter | 10 Aug 11:42 2006
Picon

IETF Process discussions - next steps

Here are my conclusions from the plenary discussion
and the General Area open meeting at IETF 66.

1. Conclusions from plenary discussion on Newtrk issues
(draft-carpenter-newtrk-questions-00.txt)

A clear theme in the plenary discussion in Montreal was "declare victory."
Unfortunately, in reading the notes and listening to the audio
recording, and reading subsequent emails, it is also clear that
different speakers meant different things by this phrase - anywhere
from clarifying today's standards track, through reducing it to two
or one stages, to simply sitting down and shutting up. Although
on the order of 40 people out of several hundred in the plenary
appeared to believe that formal changes to the standards process
should be made, and some people are ready to do work (thanks!)
there was no firm consensus for a given direction (as there never has
been in the Newtrk WG).

One useful observation was that there is nothing in present
rules and procedures to prevent the writing and publication
of overview standards documents ("ISDs" in Newtrk parlance),
as long as they fit into RFC 2026 rules as Applicability
Statements.

A need was observed for lightweight documentation of the real
world deployment status of individual standards, as concrete
feedback from running code. Again, no rule prevents this today,
but neither do we have guidelines as to the format, status
and indexing of such documents.

My conclusions are that:

1.1. There is insufficient pressure and energy in the community
to justify the effort of reaching consensus on formal changes
to the standards process at this time.

1.2. For complex standards where a normative or informative
overview document would be beneficial, nothing in today's
rules and procedures prevents interested parties from
writing and submitting such documents within the rules set
by RFC 2026, and such efforts should be welcomed.

1.3. The community should be encouraged to produce documentation
of deployment and interoperability of individual IETF standards,
even if there is no proposal to advance them on the standards track.
Such documents should be directed towards efforts to update
IETF standards and/or to document errata and operational issues.
A more systematic framework than today's implementation reports
would be beneficial.

1.4. The newtrk WG should be closed.

2. Conclusion from GenArea mini-BOF on IESG structure and charter.

It seemed clear in the room that people felt there was not a serious
enough problem with RFC 3710 to justify a significant effort.
There was some support for undertaking at least the first step:
  * List Tasks that Currently Gate on the IESG
in order to document whether there is in fact a problem worth
solving.

My conclusion is to ask John Leslie to lead a small team to carry out this
very specific task for the information of the community.

3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418)

It seems there is some feeling that the RFC is beginning to show
its age, and would be worth updating.

My conclusion is that the best first step is to ask Margaret
Wasserman to lead a small team to survey participants and build
a list of issues that need updating. Of course, any actual
update to RFC 2418 would then have to follow normal IETF
consensus process.

3. Conclusion from GenArea mini-BOF on mailing list management procedures.
(draft-galvin-maillists-00.txt)

It seems clear from recent experience with RFC 3683 that something
needs to happen in this area and that feelings run deep on this issue.
However, the energy to work on this in the community is limited despite
some support in the mini-BOF for doing so.

My conclusion is, as experiments under draft-hartman-mailinglist-experiment
are possible immediately, there is no urgency to start an organized
effort right now - but it should be considered over the coming
months. Meanhwile I would like to ask Jim Galvin to update
his draft according to the discussion, for future reference.

A suggestion was made during the meeting to rapidly declare RFC 3683
obsolete.

     Brian Carpenter
     General Area Director

.
Brian E Carpenter | 10 Jun 09:20 2006
Picon

Re: Fwd: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]

FYI

-------- Original Message --------
Subject: [Fwd: I-D ACTION:draft-carpenter-newtrk-questions-00.txt]
Date: Sat, 10 Jun 2006 09:17:29 +0200
From: Brian E Carpenter <brc <at> zurich.ibm.com>
Organization: IBM
To: IETF discussion list <ietf <at> ietf.org>

I invite the IETF community to read this draft and discuss the choices
it suggests, between now and the Montreal IETF.

     Brian

-------- Original Message --------
Subject: I-D ACTION:draft-carpenter-newtrk-questions-00.txt
Date: Fri, 09 Jun 2006 15:50:01 -0400
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Questions about the standards track
	Author(s)	: B. Carpenter
	Filename	: draft-carpenter-newtrk-questions-00.txt
	Pages		: 10
	Date		: 2006-6-9
	
    This document sets out some thoughts about three possible directions
    for further work on the evolution of the IETF standards track.  Its
    purpose is to stimulate community discussion leading to a choice
    between these three directions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-newtrk-questions-00.txt

.
Brian E Carpenter | 12 Apr 09:34 2006
Picon

[Fwd: I-D ACTION:draft-carpenter-rfc2026-critique-01.txt]

FYI. There is an HTML version, rather easier to read, at
http://www.geocities.com/be1carpenter/draft-carpenter-rfc2026-critique-01.html

    Brian

-------- Original Message --------
Subject: I-D ACTION:draft-carpenter-rfc2026-critique-01.txt
Date: Tue, 11 Apr 2006 18:50:01 -0400
From: Internet-Drafts <at> ietf.org
Reply-To: internet-drafts <at> ietf.org
To: i-d-announce <at> ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: A Personal critique of RFC 2026
	Author(s)	: B. Carpenter
	Filename	: draft-carpenter-rfc2026-critique-01.txt
	Pages		: 29
	Date		: 2006-4-11
	
This document is a personal critique of RFC 2026, the current
    description of the IETF standards process, based on the author's
    experience in various IETF roles.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-rfc2026-critique-01.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/i-d-announce

John C Klensin | 9 Apr 17:21 2006

Re: Re: I-D ACTION:draft-klensin-norm-ref-01.txt

Hi.

I was asked a question offlist that I want to respond to here
instead, and respond more broadly than the original question
that was asked...

As Brian suggested, with more insight than I consciously had, my
intention in generating this document and experimental proposal
was to write the most narrow proposal possible that would, de
facto, remove the downward normative reference as a blocking
factor without making any fundamental change in our model or
assumptions.   I think broader changes are needed, albeit
changes that still fall within the general two or three step
model (whether that should be done away with is another
question).  The ISD proposal was (and is) addressed to exactly
that broader issue, but, for many reasons, has gone nowhere.
Many of those reasons have come close to causing me to despair
that we can make any standards track changes at all absent
radical changes to how we do things, but suggestions about such
radical changes haven't gone anywhere needed.

So I decided to see if we could fix this one, small, problem
that people were claiming is a exception by doing so in a very
narrow way.  

When I first started doing work that was explicitly identified
as standards-producing, I was told that there were two famous
ways to kill an idea without every attacking its substance.
Attacks on substance could be dealt with by logic, discussion,
or, if necessary, voting.  But these two, unless they were
recognized for what they were -- and perhaps not then -- were
not susceptible to such reasonable approaches.  They were:

	(i) Produce an alternate proposal that was equivalent
	except for a few details, then try to shift the
	discussion to the alternate proposal, avoiding any
	discussion of the original or serious efforts to bring
	them together.  This way, the WG (or whatever) ends up
	with one subset discussing one proposal, and another
	subset discussing the other.  Neither actually progress.
	
	(ii) Start adding features or small changes, each one
	individually beneficial or at least harmless.  When
	enough such features are added, point out that the
	result has become so inflated and complex as to become
	unacceptably complex, or unacceptable without additional
	work (such as the addition of profiles) which would,
	itself be unacceptable.  This second technique actually
	had a name, "how to kill a shark", based on the system
	for shark-killing that involved a hollow harpoon, a
	hose, and an air compressor or a harpoon carrying a
	large charge of highly-compressed gas that would be
	released after impact (details are left to the
	imagination).

If we can't make this type of change because we need to first
agree about the status of experimental documents, about whether
the standards track should be stripped down on one or zero
steps, whether there should be any such thing as a normative
reference, etc., then I suggest that we are in far more serious
trouble than anything that has been suggested in newtrk will
solve.

     john

.
Thomas Narten | 5 Apr 20:13 2006
Picon

Re: Re: I-D ACTION:draft-klensin-norm-ref-01.txt

> This draft proposes the following:

>    o  A note is included in the reference text that indicates that the
>       reference is to a document of a lower maturity level, that some
>       caution should be used since it may be less stable than the
>       document from which it is being referenced, and, optionally,
>       explaining why the downward reference is appropriate.

> I would like to suggest a simpler alternative:  require that the downref
> be noted at last call time (both WG last call and IETF last call), not
> in the document itself.  This is in keeping with current practice of
> not discussing standardization status of a document in the document
> itself.  Moreover, such notes can become obsolete, since it is always
> possible that a downref target will eventually be advanced.

Without necessarily taking a position on either of these, I'll note
that putting it only in the LC effectively means that readers of the
(RFC) document will never realize there is a downref, when maybe they
should.

Thomas
.
rfc-editor | 30 Mar 01:19 2006

RFC 4450 on Getting Rid of the Cruft: Report from an Experiment in Identifying and Reclassifying Obsolete Standards Documents


A new Request for Comments is now available in online RFC libraries.

        
        RFC 4450

        Title:      Getting Rid of the Cruft: 
                    Report from an Experiment in Identifying 
                    and Reclassifying Obsolete Standards Documents 
        Author:     E. Lear, H. Alvestrand
        Status:     Informational
        Date:       March 2006
        Mailbox:    lear <at> cisco.com, 
                    harald <at> alvestrand.no
        Pages:      11
        Characters: 23822
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-newtrk-decruft-experiment-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4450.txt

This memo documents an experiment to review and classify Proposed
Standards as not reflecting documented practice within the world
today.  The results identify a set of documents that were marked as
Proposed Standards that are now reclassified as Historic.  This memo provides information for the
Internet community.

This document is a product of the New IETF Standards Track Discussion
Working Group of the IETF.

INFORMATIONAL: This memo provides information for the Internet community. 
It does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 

help: ways_to_get_rfcs. For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

.
Brian E Carpenter | 23 Mar 23:33 2006
Picon

Draft genarea minutes for review

http://www3.ietf.org/proceedings/06mar/minutes/genarea.txt

(Used these lists as the most relevant apart from the ietf list.)

    Brian
John C Klensin | 23 Mar 18:32 2006

draft-ietf-newtrk-docid-00.txt

Scott,

Would it be appropriate to initiate the sequence of events
leading to an IETF Last Call on this document?  Since it seems
to be intertwined with issues techspec has on its agenda, it
would be useful to see if we can reach consensus and move on it
on a timeframe consistent with theirs.

thanks,
       john
.
Spencer Dawkins | 16 Mar 16:47 2006

Some "standards" really are one-level standards...

I was looking back at my own Gen-ART reviews recently 
(http://www.alvestrand.no/ietf/gen/art/gen-art-by-reviewer.html), and 
noticed a common thread on several reviews that I wanted to mention.

The following is NOT about one-level versus two-level standards tracks, as 
we have been discussing them, so please clear memory before reading 
further...

We have been using Proposed Standard for things like registry creation and 
the Lemonade profiles, mostly because we don't know what else to use, and 
this leaves with the slightly embarrassing situation that we're creating 
"Proposed Standards" that CAN'T advance (if someone creates two registries, 
that would be a BAD thing, right?).

Scott Bradner has called BCPs "one-shot standards" when he gives the IETF 
Overview tutorial, so I'm pretty sure I know what we SHOULD be using, but we 
use BCPs for so many unrelated types of documents that we've kinda stopped 
using them for "one-shot standards".

JohnK published draft-ietf-newtrk-sd-00.txt about a year ago, which proposed 
moving the process documents that we often publish a BCPs to a separate 
series. This expired draft would make BCPs a reasonable place to publish 
documents that we want to receive "standards-track review", if we un-expire 
it and do something with it.

Maybe one more hallway conversation topic at the Anatole?

Thanks,

Spencer 

.

Gmane