Subject: Re: Make it a Proposed Method rather than Proposed Standard [Re: When is an idea a good idea?]

From: Hector Santos <[email-masked]>
Date: Sat, 01 Feb 2014 12:41:15 -0500

Hi Chris,

How does the IETF feel about having "multiple standards" of the same 
thing, in other words, redundancy?

I don't think we generally want that, and I don't think we want "bad" 
ideas becoming standards because it becomes harder and costly to undue.

However, we do need to document them too as well to allow people to 
try them out.  So if the authors don't wish to make it, EXPERIMENTAL, 
BCP or INFORMATIONAL,  a better option is to further it as a Proposed 
Method rather than get bounce around, wasting so much time as a 
Proposed Standard where Rough Consensus decisions is more problematic 
than ever before.  Keep in mind there is also the "politics" part of 
it too of getting things pushed and supported. Once a proposed 
standard starts, you might as well "forget" about other possible 
solutions.  They might not be allowed.  However, I am seen them also 
used to weaken and even destroy PS efforts - raises doubt, etc, which 
is good when it shouldn't had been a PS in the first place.

A PM would be easier I feel to pursue with less "politics," IMO.  A 
lesser peer review process. Experimental and informational are too 
weak.  If we took "Best" out of BCP, then perhaps a CP would be closer 
to a PM or Internet Method (IM).  It just isn't the only, close-ended 
standard.

Perhaps it should be made clearer that a BCP or Proposed Standard is 
not absolute in the IETF as far as solutions are concern.  The 
suggestion is to provide a way to document strong multiple solutions 
which may not necessary the "standard" or "best" solution.

Personally, I would write more documents, get involved more with PM 
documents. PS are too hard. Too stressful and time consuming and the 
others, like BCP is just the wrong category. Maybe take away the B 
from CP and we got it. :)

Thanks for your feedback.

-- 
HLS

On 1/29/2014 5:29 AM, Dearlove, Christopher (UK) wrote:
> I'm not sure more categories is what we want.
>
> I have observed all of the following (not at the same time, though some were) from people not familiar with the IETF and RFCs, although invested in or using RFCs:
> - Assuming that all RFCs are standards.
> - Assuming that only Standards matter, that Proposed Standards and Draft standards aren't important.
> - Assuming that Draft Standard is a category below Proposed Standard.
> - Recognising that there are standards and not-standards, but not distinguishing in any way between Standard, Draft Standard and Proposed Standard (calling all of them Standards).
> - Just plain confused.
>
> (And the concept of BCP is probably completely unknown to anyone thinking any of the above.)
>
> Another category isn't going to help here.
>

---

From: John C Klensin <[email-masked]>
Date: Sat, 01 Feb 2014 14:22:37 -0500

--On Saturday, February 01, 2014 12:41 -0500 Hector Santos
<[email-masked]> wrote:

> Hi Chris,
> 
> How does the IETF feel about having "multiple standards" of
> the same thing, in other words, redundancy?
> 
> I don't think we generally want that, and I don't think we
> want "bad" ideas becoming standards because it becomes harder
> and costly to undue.
> 
> However, we do need to document them too as well to allow
> people to try them out.  So if the authors don't wish to make
> it, EXPERIMENTAL, BCP or INFORMATIONAL,  a better option is to
> further it as a Proposed Method rather than get bounce around,
> wasting so much time as a Proposed Standard where Rough
>...

Hector,

While "proposed method" may be better terminology, this most
recent explanation sounds to me as if you are reinvention what
"Proposed Standard" was supposed to be, with "real"
standardization (and recommendations about adoption, non-test
deployment, and use) coming only with "Draft Standard".  Sadly
that hasn't worked for many years.  One could debate whether it
ever really worked consistently.

>From observations of a number of standards bodies that do work
in so-called "high technology" areas (not just networking), part
of the problem is that companies are most likely to send
design-level engineers with real product involvement to meetings
when the technology is still new and being designed.  Once there
is a design and organizations have made a commitment to
production-quality implementations, deployment, aales and
marketing, or operations, the tendency is for those the time of
those design-level engineers to be considered too valuable to
spend on standardization and participation shifts toward those
whose roles have more to do with protecting company interests,
worrying about process rather than technology details, and doing
the kind of fine-tuning and second-guessing that are often
described in terms of second (or third) system effects.   

That pattern is independent of whatever one calls the first
stage in the process -- the folks with the most design knowledge
and experience participate actively early-on (if at all) and
things evolve after that toward professional standardizers over
time.

The IETF has been much more successful than average at avoiding
or minimizing that pattern (although I think we are worse at it
than we were a few decades ago when Internet fundamentals were
still being designed and tested).  But the tendencies are there
and I think it is extremely unlikely that fiddling around with
names will have little lasting effect.

best,
   john

---

From: Abdussalam Baryun <[email-masked]>
Date: Sun, 2 Feb 2014 11:27:25 +0100

> thing, in other words, redundancy?

How many? It depends on the use case, so for one use case the IETF SHOULD
have a one decision proposal.

> ideas becoming standards because it becomes harder and costly to undue.

There may be bad ideas backed by experts and evaluated good just because
presented by experts or known persons.

>
> However, we do need to document them too as well to allow people to try
> them out.  So if the authors don't wish to make it, EXPERIMENTAL, BCP or
> INFORMATIONAL,  a better option is to further it as a Proposed Method
> rather than get bounce around, wasting so much time as a Proposed Standard
> where Rough Consensus decisions is more problematic than ever before.

IMHO making it start as method directly may be allowed only in the general
area. For other areas any new method should start as informational and
passed then updated to method proposal. Any informational method need an
approved standard pointed to.

> Keep in mind there is also the "politics" part of it too of getting things
> pushed and supported. Once a proposed standard starts, you might as well
> "forget" about other possible solutions.  They might not be allowed.
>  However, I am seen them also used to weaken and even destroy PS efforts -
> raises doubt, etc, which is good when it shouldn't had been a PS in the
> first place.

We SHOULD solve the politics problem in IETF because it is a BAD behaviour
as you mentioned its influences. The general area should solve that by
new BCPs.

> A PM would be easier I feel to pursue with less "politics," IMO.  A lesser
> peer review process. Experimental and informational are too weak.

IMHO, They are not weak, that is part of politics may be as well.

>   If we took "Best" out of BCP, then perhaps a CP would be closer to a PM
> or Internet Method (IM).  It just isn't the only, close-ended standard.

Agree but it needs some new process procedure.

>
> Perhaps it should be made clearer that a BCP or Proposed Standard is not
> absolute in the IETF as far as solutions are concern.

Disagree.

> The suggestion is to provide a way to document strong multiple solutions

You may mean strong possible multiple solutions related to possible
applicability statements.

no solution method proposed only if it is related to an
IETF standard or BCP. Each method should need informational document
related passed the updated to method.

> others, like BCP is just the wrong category. Maybe take away the B from CP
> and we got it. :)

Yes agree,

>> I have observed all of the following (not at the same time, though some
>> were) from people not familiar with the IETF and RFCs, although invested in
>> or using RFCs:
>> - Recognising that there are standards and not-standards, but not
>> distinguishing in any way between Standard, Draft Standard and Proposed
>> Standard (calling all of them Standards).
>> - Just plain confused.
>>