> -----Original Message----- > From: Paul Hoffman [mailto:[EMAIL PROTECTED] > Sent: Tuesday, April 05, 2005 2:07 PM > To: Tim Bray; Scott Hollenbeck > Cc: atom-syntax@imc.org > Subject: Re: AD Review Comments and Questions: > draft-ietf-atompub-format-07 > > > At 9:26 AM -0700 4/5/05, Tim Bray wrote: > >>Section 7.1: what process is the IESG supposed to use to > review registration > >>requests? Please see section 2 of RFC 2434/BCP 26 for > mechanisms that might > >>be used and please specify one in the document. > > > >Paul, care to take the lead on this? -Tim > > Nope. Scott: can you be more specific about your question? Section > 7.1 seems pretty clear to me, but I'm possibly missing something.
As described in 2434, "IESG Approval", "though the IESG has discretion to request documents or other supporting materials on a case-by-case basis". I'd really like to see some guidance in the document to describe what the IESG should look for. We're not atom experts, so it's going to be hard to determine what we should and shouldn't approve. Another paragraph will help future IESGs understand what they need to consider when reviewing requests. > At 1:04 PM -0400 4/5/05, Scott Hollenbeck wrote: > >There needs to be both text explaining why IETF practice > isn't being used > > Good. > > >and there needs to be an identified URI. > > Bad. > > > We don't need the URI *right now*, > >but I want it in the document BEFORE I bring the document to > the IESG for > >review. Explanatory text will suffice for last call purposes. > > Just to be clear: you are asking us to get the final URI for the > namespace *before* the IESG has approved of the document. That means > that it is really, really likely that some implementers will write > and deploy code based on the draft that is going to the IESG, not > waiting to see if the IESG demands changes for the wire protocol or > the MUSTs and SHOULDs. > > Do you really want that (he asks pejoratively)? Hmm. Part of the problem is that there is no "normal" editing opportunity once the document is in the hands of the IESG. The editors can make changes as a result of IESG review, or in auth48, but those changes are supposed to be directed. Auth48 changes are supposed to be editorial only. This is clearly a normative situation. The other part of the problem is that you're asking the IESG to review a specification that is incomplete without that little detail, and what's in there now looks very obviously non-standard. If you want to pursue a course of action that is similar to what was done with the IDN prefix [1] you're going to have to be a bit more clear about why the spec is incomplete. I'm OK with that, but please add text to the document to explain what needs to be done, who will do it, and when it needs to be done. Include a note that says "this paragraph to be removed by the RFC Editor" if appropriate. If this all means that the URI will be provided to the RFC Editor when they ask for it to finish the document, fine -- just say so. -Scott- [1] I'll let Paul explain this reference if anyone asks.
