ietf
[Top] [All Lists]

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

2005-01-07 11:18:17
Looking at the recent announcements of I-Ds, I think we will get a
substantial number of URI/URL related drafts in the coming months which
will also test this procedure.  Their revision numbers are clocking up
so they are being discussed but not AFAICS on any IETF-related list. And
these seem to be standards track.

I am in the 'default no' camp.

Tom Petch

----- Original Message -----
From: "Harald Tveit Alvestrand" <harald(_at_)alvestrand(_dot_)no>
To: "Dave Crocker" <dcrocker(_at_)bbiw(_dot_)net>; <ietf(_at_)ietf(_dot_)org>
Sent: Friday, January 07, 2005 10:46 AM
Subject: Re: individual submission Last Call -- default yes/no.


[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

.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


<Prev in Thread] Current Thread [Next in Thread>