Re: individual submission Last Call -- default yes/no.

Harald,
This does not discuss the language tags comment. This case however provides 
some experience. The real problem I see is the increased need of Practice 
Documentation. RFC 3066 is a BCP yet it introduces issues (and the proposed 
RFC 3066bis does more) which are not established but proposed or even 
modified practices, without the proper debate with other areas some 
consider as concerned (IDN, OPES, Web Services, architecture, etc.) what an 
IAB approved charter would have warranted. In this case there is also the 
oddity of a private list bearing responsibilities on the IANA.

You say this may happen when the matter has not been considered being worth 
a WG. I have nothing to object to that. But I can document that in this 
particular case I sent you a private mail a few months ago asking guidance 
on the way to organize a WG. You did not signaled me your "ietf" list. I 
can also only note this is a consistent position with the IAB/IESG, since 
RFC 3869 does not even allude to the matter. That some's positions are more 
equal than other is a feature of 1st generation networks, so I will not 
object. But I suggest this calls for a better WG proposition track. In this 
case a WG would have saved time and harassment (I am used to be insulted 
and I have no problem with it, should it help).

IRT the need of PB documentation. This case shows that there would have 
been no problem and full consensus if the "BEST" as documented in RFC 
2026.5.1 could have been replaced by a "DOCUMENTED" or by a "SUGGESTED". 
This made me a supposed "main" and "odious" and "gerrymandering" etc... 
"opponent" of the draft. Should the author have been able to present a DCP 
for what is already in use, and an SCP for what he proposes, we would now 
considered how to continue further, may be along the working protocol I 
documented.

I can quote many other areas where such a SCP/DCP use could lead to a 
progressive practice aggregation or transition and innovation.
Regards.
jfc

At 10:46 07/01/2005, Harald Tveit Alvestrand wrote:

>[note - this note does NOT talk about the language tags document]
>Recent standards-track/BCP RFCs that came in as individual submisssions 
>(you can tell this from the draft name in the rfc-editor.xml file):
>
>RFC 3936 - draft-kompella-rsvp-change
>RFC 3935 - draft-alvestrand-ietf-mission
>RFC 3934 - draft-wasserman-rfc2418-ml-update
>RFC 3915 - draft-hollenbeck-epp-rgp
>RFC 3912 - draft-daigle-rfc954bis
>
>Apart from draft-alvestrand, I don't remember any of these causing much of 
>a stir at Last Call. Still, I think the decision to advance them was 
>appropriate.
>The usual case for an individual submission is, I think:
>
>- there are a number of people who see a need for it
>- there are a (usually far lower) number of people who are willing to work 
>on it
>- someone thinks that this isn't controversial enough for a WG, isn't work 
>enough that the extra effort of setting up a WG is worth it, is too 
>urgently needed to wait for a WG to get up to speed, or other version of 
>"doesn't fit with our WG process
>- nobody's significantly opposed to getting the work done
>
>A "default no" doesn't seem like a correct procedure here.
>
>              Harald
>
>
>
>--On 6. januar 2005 10:48 -0800 Dave Crocker <dhc2@dcrocker.net> wrote:
>
>>>    However the reason
>>>   why many things come in as individual submissions is that the community
>>>   doesn't care much.
>>
>>I sure hope you are very, very wrong.
>>
>>If the community does not care much, then I do not see the purpose in
>>making it an IETF standard.
>>
>>A standards process is primarily about gaining community support for a
>>common way of doing something.
>>
>>
>>So if the IESG is satisfied enough to put out a last
>>>   call, and nobody responds -- it doesn't have community support -- the
>>>   default community position shouldn't be "no" but "no objection".
>>
>>That's a default 'yes'.
>>
>>We already have a problem with producing specifications that no one uses.
>>A default 'yes' on outside submissions makes it likely we will get lots
>>more.
>>
>>
>>
>>d/
>>--
>>Dave Crocker
>>Brandenburg InternetWorking
>>+1.408.246.8253
>>dcrocker  a t ...
>>WE'VE MOVED to:  www.bbiw.net
>>
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf
>
>
>
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf
>

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