RE: IETF tree URL registration procedure incomplete

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry-

I support your proposal.

In general, clearer process is always good.

And, to the extent that IETF is actually endorsing a document (as is 
implied by it being registered in the IETF tree - does this need 
clarification, too?), then IETF should indeed have great control over 
the content, and provide detailed technical review and approval.  
This could also be done by stating that IETF tree submissions be 
Standards track only, but perhaps that overconstrains your intent 
with that tree.

All this, as long as there is still *some* home for the unreviewed, 
hairbrained, [insert adjective here] schemes.  This seems required in 
light of the URIREG mechanism to permit external entities editorial 
and revision control over schemes registered in the "alternative 
tree", even if they were first reviewed by IETF.

Regards,
	Mike

At 11:34 AM 8/25/99 PDT, Larry Masinter wrote:
>In particular, it has been argued that the IETF process
>for publication of Informational RFCs does not require
>technical review. In 
>
>http://www.ietf.org/mail-archive/ietf/Current/msg05318.html
>
>Michael Dolan argued, in regard to draft-zigmond-tv-url-02.txt:
>
>"The continued insistence that this draft obtain technical review 
>and approval either in or out of IETF is not required under the 
>Informational process.  So, there simply is no requirement to change 

>the draft technically based on comments here or in W3C or anywhere 
>else.  Continued references to current and past mail threads on the 
>(lack of) technical merits are just not relevant unless someone can 
>explain why this draft requires a special review process."
>
>I think we might want to make sure that 
>draft-ietf-urlreg-procedure-07.txt says that the URL review process
>is an ongoing activity of the IETF, and any Informational
>RFC which purports to register an IETF tree URL is subject
>to technical review. It would be useful if the resulting BCP
>were listed as "Updates RFC 2026", so that there's no question
>about the applicable process.
>
>
>
> 
>
>
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBN8Q93yl9dIG/haQGEQKmwACfcleCmZwrAmcKbKtSu6D7qbHKO5IAn3GF
NjXhQCHhpbUdvENDn8LPt12j
=3Glx
-----END PGP SIGNATURE-----

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122