Not liking to create unnecessary noise on large public lists (really!), I trimmed the IETF off the following message. Bert W. has suggested that this was inappropriate, as the issue is a general IETF issue. Bob Braden for the RFC Editor ----- Begin Included Message ----- >From braden@ISI.EDU Tue Jan 21 13:59:39 2003 From: Bob Braden <braden@ISI.EDU> Date: Tue, 21 Jan 2003 21:59:32 GMT To: bwijnen@lucent.com, kireeti@juniper.net Subject: RE: Last Call: CR-LDP Extensions for ASON to Informational Cc: braden@ISI.EDU, iesg@ietf.org X-AntiVirus: scanned by AMaViS 0.2.1 *> *> Hi Bert, *> *> On Sat, 18 Jan 2003, Wijnen, Bert (Bert) wrote: *> *> > Yes they are from the "IETF Consensus space". *> > *> > Now can you be more specific as to why you do not consider this doc *> > ready for publication? Just for the record, although I am not technically competant to pass detailed judgment, many of Mr. Kompella's comments fit my prejudices about this document. *> *> There are a large number of nits and typos -- so much so that in my *> opinion, this document should not have been sent to IETF Last Call *> without another round of edits. However, I will ignore those and *> concentrate on the substance. This saddens me. I will go reread it. The RFC Editor DID go one round with the author (you should have seen the FIRST version!), and we judged that the result was "good enough". We are now both pleased and embarrassed when someone from the community tells us that it was NOT good enough! But we do appreciate such feedback, really. ;-) ... *> *> The main thrust of the document is the "separation of call and *> connection"; there is one short paragraph that describes this, and *> a reference to an ITU document. In my discussions with people who *> go to the ITU, I didn't hear a clear consensus on the need for this. Our gripe was that the document did not even TRY to explain what this distinction MEANS. *> An *IETF* document that describes the background, needs and how this *> is to be used would be very useful. This is especially important as *> the very next paragraph says that separation can be achieved "where *> the call set up request is always accaccompanied by a connection *> request", which (to my naive understanding) hardly is separation. *> This is an important and sticky point... what are the IETF's rights and duties with respect to the work of other standards bodies? One of the reasons the RFC Editor did not press harder was that the protocol was essentially a fait accompli and presumably documented completely and clearly by ITU-T. The only purpose of the RFC was to document the IANA registration, so fragmentary description without explanation seemed all we could expect. The RFC Editor rather hates to publish documents like this, but of course there are political realities to be served, and we understand Bert's point about duplication. Bob Braden for the RFC Editor ----- End Included Message -----