Re: netwrk stuff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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.

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

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






_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]