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@xxxxxxxxxxxx> 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 lastcall, 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf