Re: netwrk stuff

Douglas Otis <dotis@mail-abuse.org> Mon, 24 July 2006 15:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G529X-0008Vn-Oo; Mon, 24 Jul 2006 11:15:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G529V-0008Vc-NS for ietf@ietf.org; Mon, 24 Jul 2006 11:15:25 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G51Yt-0007QK-Kp for ietf@ietf.org; Mon, 24 Jul 2006 10:37:35 -0400
Received: from a.mail.sonic.net ([64.142.16.245]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G51MF-0000uf-2g for ietf@ietf.org; Mon, 24 Jul 2006 10:24:32 -0400
Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0/8.13.7) with ESMTP id k6OEOLfK026931 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 24 Jul 2006 07:24:26 -0700
From: Douglas Otis <dotis@mail-abuse.org>
To: todd glassey <tglassey@earthlink.net>
In-Reply-To: <006301c6ad96$00278f10$ca2df604@home.glassey.com>
References: <F5AAE430-86C2-4A3F-B54E-55F658C7E3C4@muada.com> <p0623090ec0dc0577a581@[132.219.13.244]> <44C07CE4.3070007@dcrocker.net> <p06230946c0e6944bf238@[10.20.30.249]> <44C14FCE.4030903@dcrocker.net> <006301c6ad96$00278f10$ca2df604@home.glassey.com>
Content-Type: text/plain
Date: Mon, 24 Jul 2006 07:24:19 -0700
Message-Id: <1153751059.2949.124.camel@bash.adsl-64-142-13-68>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-4.fc4)
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8
Cc: IETF Discussion <ietf@ietf.org>
Subject: Re: netwrk stuff
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

On Sat, 2006-07-22 at 06:51 -0700, todd glassey wrote:

> The question as to why that initiative's process was stalled would
> have to be answered to be fair. One would have to take into
> consideration whether the underlying technologies were the issue,
> those undertaking the effort abandoned it, or whether it was the WG
> and AD who had failed to properly marshal their WG Vetters to complete
> this effort.

The completion of documents, and the closing of WGs remains within the
competence of the IETF.  Beyond describing the intended use and the
vetting initially achieved, there is little benefit derived revisiting a
document unless a change is required.  When a change is required, the
affected document should be marked as updated or replaced, where again
the intended use and the vetting initially achieved should once again be
noted.

Designations of Experimental seems to be an indication of a vetting
level.  BCP versus Information also seems to be an indication of a
document having undergone different vetting.  Clarify the initial
vetting (the related confidence the organization is willing to initially
signify). This clarification can be conveyed by noting the intended use.
Conveying how popular a particular document has become in subsequent
years has proved either outside the competence or the concern of the
IETF.

While as a matter of pride the IETF may wish to place accolades upon
popular documents, such efforts will likely be a distraction and provide
little benefit.  These efforts could be seen as attempting lead the
parade by running in front of the crowd.  While popular documents are
indicative of having done a good job, very few documents involving
popular use remain static.  

> Since the IETF has said it needs to be smart about what projects and
> initiatives it undertakes, then it should want as much assurance
> up-front as possible. That said when a formal project is proposed it
> should be well enough defined and documented, and have commitment
> formally from those who are the core of the Initiative's Vetting Team.
...

Is there some benefit derived revising documents where the intended use
has not changed?  Those deploying applications based upon these
documents will separately publish their own conclusions by way of
call-outs.  The IETF has made the call-out process difficult, and this
should be improved.   


> I think the way to address whether deprecation is some level of use in
> the world. Set a use minimum for any protocol - and anyone that falls
> below that use level - is deprecated. This way the IETF active
> standards track the Internet's tastes and desires since it is the
> Internet that the IETF is to track... But ratwould need toher than
> true deprecation - lets just change their names to "Reference and
> Active" Standards. Reference are any non-active Standards. Active
> Standards are those that are voted (did I really say that?) by the
> IESG to track the Industry's use.

This seems to suggest competency and popularity are synonymous.  There
should be at least four levels maintained by industry when using these
documents.

1) Current (development)
2) Stable (production)
3) Deprecated (still supported)
4) Obsolete (not supported)
   
Current is simply the latest.  This output may never become designated
as being Stable.  Stable indicates few issues are unresolved by several
implementations.  Deprecated indicates modes or features will no longer
be supported in future versions. Obsolete indicates that interchange is
no longer assured.

It seems the industry and not the IETF should make these
classifications.  The results of interchange testing is the determining
factor and this is not an area handled by the IETF.  There will always
be a company that does something different.  If company X happens to
have a large install base, how does that affect the ratings?  There
could be separate ratings indicated by company X.


> This review should be done annually at one of the meetings as a
> process model and the level of penetration of any protocol needs to be
> factored into the equation somehow.

Why?  What would be the benefit?  What information is used?


> > Note that we already have this policy, although it applied 
> > erratically by
> 
> In closing  lets put blame for a failed project where it belongs... in
> the WG Chair's lap. I think there is a fundamental failing in the
> mindset of the IETF and that is that "the failings of the WG Vetters
> to come to consensus documents the failure of the WG Chairs for not
> better controlling their resources or projects".

The lack of substantial benefits for pursuing a meaningless
administrative effort may explain the mindset.  Instead, the IETF should
attempt to facilitate a call-out that can easily track Current, Stable,
Deprecated, or Obsolete by each company or distribution.  Many of these
protocols involve a compilation of many RFCs.  Using an overlay as
described by the SRD draft, for example, would allow a
Name.Serial-number approach where there would be real benefits derived.

Focus on describing the intended use and providing a serialized
reference to track the evolution of the change process.  Don't spend any
time going from three levels to two or one.  The industry must be
allowed to track at least four levels of use, but leave this to the
industry.  The IETF should simply attempt to facilitate this tracking
and clarify the intended use.

-Doug







_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf