Subject: Re: netwrk stuff

From: Todd Glassey <[email-masked]>
Date: Mon, 24 Jul 2006 08:06:39 -0700 (GMT-07:00)

-----Original Message-----
>From: Douglas Otis <[email-masked]>
>Sent: Jul 24, 2006 7:24 AM
>To: todd glassey <[email-masked]>
>Cc: IETF Discussion <[email-masked]>
>Subject: Re: netwrk stuff
>
>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.  

How so ? - this is a statement of objectivity or the lack of it more accurately.

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

There may be issues with that. One of the things that the IETF has not dealt with is the use of the IETF's processes as weapons against others with less presence or power within the IETF WG's - the problem is that not everyone here is a nice-person - some are actually really bad people who are here intentionally to screw others who don't agree with them or who have opinions that are dangerous to initiatives or the the political framework of the IETF.

Bluntly the IETF has grossly failed in being either Open or Fair and Frank these Ar what need to be addressed. The IETF's processes are best described as a twisted-fantasy through loophole land. They don't serve to make standards honest and fair but rather impossible for a mere mortal to participate with and that is more offensive to the world than the nasty language I used in describing the failures of this and the previous IETF's in coming to grips with what the IETF has become - a haven for career standards participants who need to be somewhere to justify their status within their sponsors.
>
>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 rather would need other 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Douglas Otis <[email-masked]>
Date: Mon, 24 Jul 2006 11:22:27 -0700

On Jul 24, 2006, at 8:06 AM, Todd Glassey wrote:
> On Jul 24, 2006, at 7:24 AM Douglas Otis wrote:
>>
>> 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.
>

This was attempting to describe what remains within the realm of IETF  
competency.  Attempting to define which iteration of a protocol  
(based upon the introductions of RFCs) is needed for interchange  
within some distribution, or a company's application, or some OS  
would be objective and likely lacking accuracy when done by the  
IETF.  After the software becomes fully debugged, the Current  
protocol iteration might become Stable, but prior to compliance  
testing, each company or distribution should declare which iteration  
is providing Stable interchange.  This declaration is beyond the  
competency of the IETF, and should the IETF attempt to make  
declarations of this nature, such would likely be based upon the  
information provided by dominate companies or distributions.  Here  
the IETF becomes the IVTF.  RFCs represent a continuum of change.   
What is declared as Stable by distribution X will likely be of far  
more value than a similar assertion attempted by the IETF.

>> 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.
>
> There may be issues with that. One of the things that the IETF has  
> not dealt with is the use of the IETF's processes as weapons  
> against others with less presence or power within the IETF WG's -  
> the problem is that not everyone here is a nice-person - some are  
> actually really bad people who are here intentionally to screw  
> others who don't agree with them or who have opinions that are  
> dangerous to initiatives or the the political framework of the IETF.

Not every company fairly assesses a protocol either.  There could be  
a perceived advantage thwarting innovation when there is no intent to  
commercially make use of it.  Rather than thwarting innovation, these  
efforts could be diverted onto a separate track by utilizing a  
separate tracking overlay.  This would allow the market to decide  
whether there is value in adopting the newer track.

> Bluntly the IETF has grossly failed in being either Open or Fair  
> and Frank these Are what need to be addressed. The IETF's processes  
> are best described as a twisted-fantasy through loophole land. They  
> don't serve to make standards honest and fair but rather impossible  
> for a mere mortal to participate with and that is more offensive to  
> the world than the nasty language I used in describing the failures  
> of this and the previous IETF's in coming to grips with what the  
> IETF has become - a haven for career standards participants who  
> need to be somewhere to justify their status within their sponsors.

The SRD overlay approach permits separate development tracks.  This  
multi-tracking ability might avoid some innovations being seen as a  
threat.  The specifications for email, instead of being a free list  
of RFCs, becomes a compiled set of RFCs defined as Email.3.  Imagine  
that Email.3 is commonly seen as Stable, and Email.4 is Current.   
When a small enclave wants to introduce an incompatible change based  
upon Email.3, the SRD overlay could adopt a different reference name  
such as Foo-mail.1.   The present, somewhat simplistic, view that an  
RFC is updated or replaced assumes these RFCs support just a single  
track of change.

Even assuming a single track, the present system makes declaring what  
is being used difficult.  Knowing what is involved for a particular  
protocol is only clearly defined for the present set of changes.   
Standard categories are too poorly maintained to be useful.  A fair  
amount of effort is required to determine the sequence and dates of  
the various RFC documents to determine a prior set of RFCs.  When  
development involves collaboration between other organizations, being  
able to predict a reference earlier within the process would also be  
a benefit provided by an overlay approach.

The IETF should focus upon providing serialized documents that both  
support existing protocols as well as the introduction of newer  
protocols.  There is a need for the IETF to improve upon the tracking  
of their effort.  This tracking is also likely the only change that  
will eventually be found beneficial.  To declare something a  
"standard" assumes certifications and compliance mandates.  In many  
cases, until some experience is obtained, the IETF is unable to state  
that something can be implemented from the document and that it will  
be Stable.  Should the IETF even attempt to make and revise these  
assessments?  It seems that many of these assessments are dependent  
upon the beholder.  Provide a simple serialized tracking scheme and  
then pay attention to what your favorite OS or distribution declares  
as Stable, Deprecated, or Obsolete.

The IETF can avoid some potential trouble by retaining the  
Experimental categorization within the overlay.  Until enough vetting  
ensures the protocol will not damage the Internet, retention of this  
categorization indicates how this document is to be used.  The SRD  
draft provides Core, Extension, Guidance, Companion, and Experimental  
categories to indicate the intended use of an RFC.

-Doug