Dave,
While we are pretty much in agreement, three observations, one
based on Scott's "default no objection" observation.
(1) I think you are right that there are two issues with an
independent submission, one of which is the notion of support
that doing something is a good idea. And I agree that, for WG
efforts, we pretty much sort that issue out at charter time so
it would take strong evidence at Last Call time to be persuasive
that the community is not interested. For that part, I agree
with you on the "default no" part -- either the community cares
enough that the document should be part of our corpus of
standards-track materials, or it doesn't and "no objection"
doesn't seem to be a good option (even though the appropriate
threshold for "cares enough" might be debated). But there is
also the set of issues associated with "given that we are
interested, it is technically adequate, does it solve the stated
(or implied) problems, and similar questions". And, for that
piece, I think Scott's default "no objection" is about the right
target: it is reasonable for the community, as it figures out
how to allocate resources, to say "this is worth doing, looks
close enough, and we trust the people who have done the work
sufficiently".
(2) It is orthogonal to the issues you have raised, but I
believe that barriers to approval to something that is intended
to replace something that is deployed and working should be
higher than the barrier for a new piece of work in a new area of
application with no potential for screwing things up. One could
try to further grade that (or not) based on degree of backward
compatibility in applications and use. I think that treating
"replacement of different protocol or procedure or model" as
needing a higher degree of certainty than "new work" is what the
IETF has done all along without ever being explicit about it as
a principle. But it seems important to flag in this case.
(3) Finally, there is apparently a procedural oddity with this
document. The people who put it together apparently held
extended discussions on the ietf-languages mailing list, a list
that was established largely or completely to review
registrations under 3066 and its predecessors. My
understanding at this point is that their good-faith impression
was that the discussions on that list were essentially
equivalent to those of a WG. As a result, they came into this
Last Call process believing that their document ought to be
treated very much like a WG one with the presumption that all of
the relevant people were aware of their efforts and on their
list and hence that their consensus on the document should
create a "default yes" to both of the key questions that you
identify. I think that conclusion is wrong, precisely because
they didn't have the benefit of the struggles about scope and
charter details, and the announcements that the effort was going
on, that invariably accompany a WG formation process. And I
know of at least a case or two of IETF participants who would
have felt obligated to carefully track a WG chartered to replace
3066 who were not sufficiently aware of this effort to track it
except as an evolving individual submission draft. The
question of how that process confusion arose, and whether we are
doing the right things in cases like this, might be something
the community should examine at some point, but it is largely
independent of how this document should be treated going forward.
regards and best new year's wishes,
john
--On Thursday, 06 January, 2005 09:02 -0800 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
> On Thu, 06 Jan 2005 11:04:54 -0500, John C Klensin wrote:
>> Peter, as soon as we get to "valid concerns that deserve
>> attention", we remove the proposed document, I believe, as a
>> candidate for BCP.
>
> That pretty much applies to all specifications. A Last Call
> that produces any sort of serious "concern" that folks feel
> should be taken seriously means that the document is not yet
> ready for approval.
>
> It occurs to me that a Last Call for an independent submission
> has an added requirement to satisfy, namely that the community
> supports adoption of the work. We take a working group as a
> demonstration of community support. (However we used to
> pressure for explicit statements during Last Call.) My
> feeling is that an independent submission MUST show
> significant support during Last Call.
>
> In other words, a working group document getting IETF Last
> Call has something of a Default Yes. And independent
> submission needs to be Default No.
>
> And, indeed, I haven't seen much support for the document
> under discussion.
>
>
> d/
> --
> Dave Crocker
> Brandenburg InternetWorking
> +1.408.246.8253
> dcrocker a t ...
> WE'VE MOVED to: www.bbiw.net
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf