Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
When considering the Last Call comments, the IESG finally concluded that this document should be published as an ION. Other Last Call comments will result in editorial changes. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
This last call technically expires today. Since there were objections to only holding a two week last call, it won't be on the IESG agenda before March 8, and comments on the substance are still most welcome. I will be asking the IESG to consider whether it should be published as an ION rather than as an RFC. Brian (as General AD) On 2007-02-07 16:20, The IESG wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guidelines-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15381rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Hi. I will get to substance in a separate note, and hope others will also. In the interim, two procedural remarks... (1) This document and draft-klensin-rfc-independent-05.txt describe two pieces of the how a document that does not originate in a WG may be reviewed and published space. Each contains some text that suggests that some documents are better handled via the other path. The IAB has made a request for input on the independent document and now we have a Last Call on this one. As editor of the rfc-independent document, I am awaiting instructions from the IAB as to what, if anything, to do next, but suspect that the recommendation below would be better applied to -06 rather than -05 of that document. I strongly encourage members of the community to review the two documents side by side to ensure that everyone is satisfied that they are consistent and that any questions about the overall non-WG submission space is adequately covered by one or the other of them. I also ask, and hope others will join me in asking, that the IESG and IAB take explicit responsibility for coordinating and ensuring consistency between these two documents (and, if necessary, with draft-iab-rfc-editor). If they are not consistent enough that actions based on them are predictable, I fear we can look forward to some difficulties. It might even be useful for the two groups to coordinate titles sufficiently that someone looking for information will easily understand that the two describe somewhat parallel paths and ways in which those paths may or may not be alternatives to each other. (2) This document is not the product of a working group or of extended open discussion in the community. Version -00 was posted around the time of the San Diego meeting and received very little public discussion. The current version was posted at the beginning of this month; there has been little discussion of it either (at least on public lists -- as the Acknowledgements suggest, I've had some input into it via private discussions). The document does not even indicate a mailing list on which it can be discussed. One presumes that comments could have been sent to the IESG by those who happened to read the I-Ds, but that is a one-way communications path. If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION, not an Informational RFC. If they intend it to be definitive information for the community, especially information that they expect to reference as to why something is or is not possible or whether procedures are being followed, a two-week Last Call is, IMO, inappropriate and inconsistent with the spirit of the provisions in RFC 2026. john --On Wednesday, 07 February, 2007 10:20 -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Frank, Don't they also set the pubreq bit in the I-D tracker ? Very possibly, but that is just a progress tracking issue. I agree we need a progress tracking mechanism, but that isn't the underlying point here, which IMHO is to get the author in discussion with the appropriate AD. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Frank On 2007-02-10 01:07, Frank Ellermann wrote: ... I don't like this draft, send publication request to secretariat is more attractive than spamming ADs. You probably need to understand what happens when someone does that. The Secretariat simply forwards the note to the IESG. After a while, the IESG Chair will (with luck) have handled everything that looks urgent, and will take a glance at draft-smith-my-new-idea and make an uninformed guess that it fits the smurf Area. (So far, elapsed time is a couple of weeks wait plus 3 minutes attention.) The IESG Chair will send a note to one or both smurf ADs saying Can you have a look at this?. And then the process proposed by draft-iesg-sponsoring-guidelines actually starts - probably with another wait until one of those ADs has handled everything that looks urgent. It makes a lot more sense, IMHO, for the author to decide that her work fits the smurf Area and write directly to the ADs. In either case, the first real step is for those ADs to look at the draft and respond to the author. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Brian E Carpenter wrote: send publication request to secretariat is more attractive than spamming ADs. You probably need to understand what happens when someone does that. Yes, I haven't tested it yet. The Secretariat simply forwards the note to the IESG. Don't they also set the pubreq bit in the I-D tracker ? After a while, the IESG Chair will (with luck) have handled everything that looks urgent, and will take a glance at draft-smith-my-new-idea and make an uninformed guess that it fits the smurf Area. Doesn't sound good, I thought it would hit a tracker exception or something after a while (if nobody feels like looking at it). The IESG Chair will send a note to one or both smurf ADs saying Can you have a look at this?. The Chair could appoint... http://www1.tools.ietf.org/group/iesg/trac/wiki/IesgWhips ...for stuff stuck in procedural corners. Getting the pubreq flag is important, it won't go away unless the author gives up, or it's transformed to do not publish / RFC published. then the process proposed by draft-iesg-sponsoring-guidelines actually starts - probably with another wait until one of those ADs has handled everything that looks urgent. But without the AD shopping mentioned in the draft, what I called AD spamming: One of the two ADs has to do something visible in the I-D tracker, like enter revised ID needed or start a last call. Or note it as dead, or if that's allowed maybe demote it to AD is watching - when the authors agree. So far I thought that authors create this pubreq flag, for individual I-Ds, or otherwise the WG Chairs representing some consensus of their WG. With the proposed procedure it's apparently the IESG creating any pubreq flag, and you can block this important step in a rather obscure (= invisible in the tracker) procedure, roughly reflecting nobody feels like caring about the I-D. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Jari Arkko wrote: I would be happy to sponsor a ternary bit draft, but only on April 1 :-) IETF replaces 'bits' by 'tits', [EMAIL PROTECTED], it could be a case where April 1st is no good excuse. What I don't like in your draft is the (apparent) personal veto right for the AD. Authors (hopefully) have an idea about their topic, but they don't need to be procedural experts. They don't need to know what an area is, if it has a catchall WG or not, and who the area directors are if it has no such WG. They decide when their memo is ready to be published as RFC, and what follows should be a simple procedure: Send a publication request to the IESG (maybe to a public list), get a responsible AD, work it out. The IESG or AD could tell them that the memo belongs to an existing WG, that it's not in a shape to waste the time for an IESG evaluation with it, and maybe that it's anyway hopeless. It's okay if there are shortcuts for authors knowing precisely which area and AD they want, but generally authors shouldn't need to know this. If the IESG refuses to pick a responsible AD for a memo the author should have a right to appeal. With some chance authors would see that their appeal will be decided by the same group who refused to deal with their text in the first place, and don't try this. But maybe they want this situation on public record, because then the community can check what's going on - oh, Leibniz didn't speak Chinese and erroneously stated there are only 64 trigrams for six bits or whatever the problem might be. [catchall WGs in some areas] the draft says relatively little about this, because there are different situations. Some areas have a general purpose area working group with chairs and an ability to produce documents just like any other WG. I certainly didn't know this before I read your I-D, it could be a good idea. Or not, depending on the catchall WG, if they refuse to consider anything NIH. What if they don't like it, but the authors still insist on an evaluation ? Can they appeal then ? What if the AD does not like it personally, but admits that it's not as bad as the famous ternary bits ? As with regular WG submissions, the document has to pass the responsible AD's review. Otherwise it goes back to the WG or the authors. That's apparently a side effect of the must vote YES rule. One part of it is clear, don't waste the time of the complete IESG if the memo isn't in a shape for serious considerations. But it's a bad rule if the AD only doesn't like the memo, while others could think it's okay. With your draft you'd introduce a third point of failure - before potential post Last Call RFC editor note or AUTH48 mutilations of a draft - a single AD can veto and kill anything as it pleases him or her. Ask another AD ? Your draft tries to block that escape hatch. Try independent ? John's draft tries to block that too. Last solution, authors should start with independent if they're not interested in arbitrary AD decisions. If they try individual they'd be doomed if that fails. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Frank, On 2007-02-09 17:04, Frank Ellermann wrote: Jari Arkko wrote: I would be happy to sponsor a ternary bit draft, but only on April 1 :-) What I don't like in your draft is the (apparent) personal veto right for the AD. Authors (hopefully) have an idea about their topic, but they don't need to be procedural experts. They don't need to know what an area is, if it has a catchall WG or not, and who the area directors are if it has no such WG. They decide when their memo is ready to be published as RFC, No, that is not their decision. They decide that they would *like* the document to be published as an RFC. And frankly if someone's understanding of the IETF is such that they can't even decide which Area is likely to be appropriate, I have to wonder why they think they are ready to publish via the IETF. and what follows should be a simple procedure: Send a publication request to the IESG (maybe to a public list), get a responsible AD, work it out. That doesn't actually work. Sending a message to a group of very people is roughly like sending it to /dev/null. That's exactly why we want to change this. The IESG or AD could tell them that the memo belongs to an existing WG, that it's not in a shape to waste the time for an IESG evaluation with it, and maybe that it's anyway hopeless. It's okay if there are shortcuts for authors knowing precisely which area and AD they want, but generally authors shouldn't need to know this. Disagree, see above. If the IESG refuses to pick a responsible AD for a memo the author should have a right to appeal. Actually, the way we interpret RFC 2026, there is always a right to appeal, whatever we write in this document. With some chance authors would see that their appeal will be decided by the same group who refused to deal with their text in the first place, and don't try this. That's why there is a 2nd level of appeal. But maybe they want this situation on public record, because then the community can check what's going on - oh, Leibniz didn't speak Chinese and erroneously stated there are only 64 trigrams for six bits or whatever the problem might be. Sure, a public record is good. [catchall WGs in some areas] the draft says relatively little about this, because there are different situations. Some areas have a general purpose area working group with chairs and an ability to produce documents just like any other WG. I certainly didn't know this before I read your I-D, it could be a good idea. Or not, depending on the catchall WG, if they refuse to consider anything NIH. That's why we also have Independent Submission, I think. What if they don't like it, but the authors still insist on an evaluation ? Can they appeal then ? What if the AD does not like it personally, but admits that it's not as bad as the famous ternary bits ? As with regular WG submissions, the document has to pass the responsible AD's review. Otherwise it goes back to the WG or the authors. That's apparently a side effect of the must vote YES rule. One part of it is clear, don't waste the time of the complete IESG if the memo isn't in a shape for serious considerations. But it's a bad rule if the AD only doesn't like the memo, while others could think it's okay. True, if the NomCom appoints bad ADs... With your draft you'd introduce a third point of failure - before potential post Last Call RFC editor note or AUTH48 mutilations of a draft - a single AD can veto and kill anything as it pleases him or her. No, the draft introduces nothing new at that stage - it's only the very first step that is changed from what's been done for many years. Ask another AD ? Your draft tries to block that escape hatch. Perhaps for ternary arithmetic, but not for something that really belongs to another Area. Try independent ? John's draft tries to block that too. No Last solution, authors should start with independent if they're not interested in arbitrary AD decisions. If they try individual they'd be doomed if that fails. No, in fact a common reply from an AD might be to recommend independent submission if the work is interesting but really outside IETF scope. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
- Original Message - From: Brian E Carpenter [EMAIL PROTECTED] To: Frank Ellermann [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Thursday, February 08, 2007 10:12 AM Subject: Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC On 2007-02-08 01:25, Frank Ellermann wrote: John C Klensin wrote: If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION Not publishing it at all is an alternative. It would send an unmistakable message to wannabe-authors, that they should use the independent path, unless they're a friend of a friend of an AD. That is a complete mischaracterization. The intent in publishing this (and doing so in parallel with draft-klensin-rfc-independent) is to make it much clearer to authors when they should choose one path and when they should choose another. Brian I agree that that should be the objective but I do not think that the four documents (*) collectively achieve it. The impression created, exaggerating slightly, is that WG submissions matter, individual submissions we have to put up with and independent submissions we would rather not mention. There should be one document that is the starting point for those considering the RFC and IETF processes, one that gives an even-handed treatment of the available routes to varying outcomes, and this is not it. The nearest is draft-klensin-rfc-independent-05.txt and that is where I would point anyone. We may then want separate process documents helping people down their chosen path and draft-iesg-sponsoring-guidelines (assuming that it is accurate, I am not well placed to judge) would fulfil that secondary role. Nor is this new. I have been active here for over five years (and yes I read the website and Tao before starting) but it was only in 2005 that I realised that 'independent' and 'individual' were two different things, and it is John Klensin that I have to thank for making me aware of it. Nothing the IAB or IESG had produced in the previous five years had brought out the distinction. Likewise, it took several years to understand that the phrase 'RFC Editor' carries overtones way beyond the task of editing something on its way to being an RFC. Nothing wrong with giving the phrase a special meaning, but it should be explained in more places. Tom Petch (*) on reflection, I think that there are more like 14 documents in this problem space. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Well, when the question (ION v. informational) came up within the IESG's discussion of the document, this is what I offered: On the ION v. RFC question -- I think this is *really* teetering on the edge! I've copied below the relevant section of draft-iab-rfc-editor-03. On the one hand, this document very clearly does not change the outcome of publish/don't publish decisions by the IESG (approvals). From that perspective, I think it describes a process and could reasonably be an ION if the IESG so desires. On the other hand, however, it does provide guidance and opinions about how proposed documents should be handled in individual or independent streams. Put another way: it's normative for the individual part of the IETF stream of RFCs. From that perspective, it should be published as an informational RFC as part of the suite of RFCs that provide the definition of the RFC series. In brief: if it's just IESG process within stated boundaries of IETF-stream documents, it can be an ION. If it affects the substance of what fits in that stream, I believe it fits under the umbrella of draft-iab-rfc-editor. Per the latter document, the IAB gets a say in determining community consensus when it comes to changing RFC series documents. The IAB isn't about to monitor IESG process pages (IONs); it'd have to be an RFC. So -- which is it? (I'm updating draft-iab-rfc-editor now, as it has finished its 4-weeks call for input; I'd like to know if I'm referencing an RFC-to-be or not :-) ). Leslie. P.S.: Again, copying the relevant bit from draft-iab-rfc-editor-03: From draft-iab-rfc-editor-03: 5.1. RFC Approval Processes Processes for approval of documents (or requirements) for each stream are defined by the community that defines the stream. The IAB is charged with the role of verifying that appropriate community input has been sought and that the changes are consistent with the RFC Series mission and this overall framework. The RFC Editor is expected to publish all documents passed to it after appropriate review and approval in one of the identified streams. 5.1.1. IETF Document Stream The IETF document stream includes IETF WG documents as well as individual submissions sponsored by an IESG area director. Any document being published as part of the IETF standards process must follow this stream -- no other stream can approve Standards track or Best Current Practice (BCP) RFCs. Approval of documents in the IETF stream is defined by o the IETF standards process (RFC2026, [3], and its successors). Daigle Internet Architecture Board Expires July 15, 2007[Page 14] Internet-Draft draft-iab-rfc-editor-03January 2007 o the IESG process for sponsoring individual submissions (RFC , [9]). Changes to the approval process for this stream are made by updating the IETF standards process documents. John C Klensin wrote: --On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman [EMAIL PROTECTED] wrote: John Sure. But my point in that area was obviously not clear. John Prior to the announcement of the Last Call, there was no That sort of depends on what's going on here. Is Jari's draft an internal procedure of the IESG sent out for community review because the IESG believes it has an obligation to seek input on its procedures and to document them? If so, then a two week last call seems fine? Alternatively, is this an IETF community process document that will bind the IESG in the future unless it is updated by the community? If so, then it should be a BCP and a four week last call. My understanding was that RFC 2026 was normative here (although it says basically nothing) and that the IESG was documenting its procedures. If the community believes that this topic is important enough that it should be a community decision not an IESG decision, that seems entirely fine to me. But then this should not be an informational document. Sam, I think we pretty much agree, and that is why my initial note wasn't much more aggressive. But it raises the issue that others have raised: if this meets the criteria for IETF documenting its procedures and, as you have described it above, informational, then why not publish it as an ION given that series was designed for just those sorts of things?Please take that as a question, not a position, but it is a very serious one. More generally, and independent of this particular document, it seems to me that, with IONs in the mix, publishing something that is informational about IESG procedures requires some explanation. Procedural BCPs do not, IONs do not, but informational documents of this variety have now become sort of an odd case. And, IMO, if something that could reasonably be published as an ION is proposed for publication as an Info RFC instead, then that ought to imply a decision that serious community discussion is in
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Personally I've been convinced that this document definitely should not be an informational RFC. It should either be an ion or a bcp at the community's choice based on how much review they want when the IESG decides to change things. It doesn't make sense to me for the IETF to publish informational documents about the RFC stream that are normative. It makes sense I understand why the IAB does so, and that's the best mechanism we have for that purpose today. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Hi Tom, There should be one document that is the starting point for those considering the RFC and IETF processes, one that gives an even-handed treatment of the available routes to varying outcomes, Right. If you are thinking in terms of an educational document, I'm not sure sure we have one yet. But draft-iab-rfc-editor describes the different RFC streams (IETF, IRTF, independent, ...) and points to related process documents, see its Section 5. and this is not it. Indeed, and it is not meant to be. The nearest is draft-klensin-rfc-independent-05.txt and that is where I would point anyone. We may then want separate process documents helping people down their chosen path and draft-iesg-sponsoring-guidelines (assuming that it is accurate, I am not well placed to judge) would fulfil that secondary role. Having separate process documents for each path is the plan. Draft-iesg-sponsoring is intended to fulfill the secondary role. Draft-klensin-rfc-independent also has a secondary role, talking about the independent submissions. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Frank, What I don't like in your draft is the (apparent) personal veto right for the AD. Authors (hopefully) have an idea about their topic, but they don't need to be procedural experts. They don't need to know what an area is, if it has a catchall WG or not, and who the area directors are if it has no such WG. The draft says that if you do not know which AD to contact you can talk to the Gen AD first. But any AD or even a fellow IETFer would surely be glad to help with such matters, and guide people towards the right WG / Area / AD. In any case, at the end of the day there is going to be someone who has to decide whether a particular proposal fits the purpose of the WG, the IETF or the RFC series. This someone can be the people in the WG, the sponsoring AD, the RFC Editor depending on what kind of a submission we are talking about, but there is always someone. And as Brian noted, if this someone misuses their power for personal reasons or some other reason, we have an appeals process. I'm not sure there's fundamentally any other way to handle this. And for IETF documents, that someone is just handling the beginning of the process and the proposal has to go through more review from the community. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
--On Friday, 09 February, 2007 13:20 -0500 Leslie Daigle [EMAIL PROTECTED] wrote: Well, when the question (ION v. informational) came up within the IESG's discussion of the document, this is what I offered: On the ION v. RFC question -- I think this is *really* teetering on the edge! I've copied below the relevant section of draft-iab-rfc-editor-03. On the one hand, this document very clearly does not ... Leslie, I really don't care. I can see some advantages to having draft-iab-rfc-editor and the other two published as sequential RFCs and am sort of leaning that way. If it isn't, then draft-iab-rfc-editor is going to need to send people off looking for IONs, which seems mildly uncomfortable. If you go that route I would suggest that Jari put some words into sponsoring-guidelines that make it an _initial_ procedure under the new RFC Ed structure of draft-iab-rfc-editor. Those words should make it clear that the IESG can revise by ION: I'd hate to see the publication of this thing as an RFC (to make the iab-rfc-... package coherent) force the IESG to make new RFCs to tune its internal rules and procedures, especially since history tells us that the most likely outcome of _that_ is ignored rules. I'm sympathetic to Sam's comment about BCPs and _firmly_ believe that it should apply in general. This, however, is an odd enough case that it might justify an exception. As usual, I don't believe that procedural notions, especially semi-informal ones, should prevent us from doing the right thing. Another option of course would be for the IAB to cut a deal with the IESG to publish all three of these as BCPs but without the IESG messing with the contents of what are really IAB documents. Probably that could be done by the IESG delegating consensus-determination for the two draft-iab- pieces to the IAB and agreeing, in advance, to accept the IAB's decision. Something like that would actually make a lot of sense to me. My major objection was to the two-week Last Call. I think, as a matter of taste, openness, and precedent, that any document which is headed for RFC publication at the request of the IESG, regardless of category, should get a four-week Last Call (announced as a four-week Last Call, not two weeks and maybe extended) unless it emerges from a formally open process with clear opportunities for community input and discussion on every posted version, such as from a WG.This is not about what the IESG is required to do --protocol-lawyering 2026 is, IMO, really not interesting and could easily lead to appeals that reach the ISOC Board-- but about what it should do. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
A couple of comments, with the understanding that Brian and are in substantial agreement about all of this and complete agreement about the things I've left out. --On Friday, 09 February, 2007 17:44 +0100 Brian E Carpenter [EMAIL PROTECTED] wrote: ... That's apparently a side effect of the must vote YES rule. One part of it is clear, don't waste the time of the complete IESG if the memo isn't in a shape for serious considerations. But it's a bad rule if the AD only doesn't like the memo, while others could think it's okay. True, if the NomCom appoints bad ADs... IMO, it is also why we have a recall procedure, no matter how hard it is to invoke. There is, IMO, a difference between an AD who periodically exerts bad judgment (even if there is community consensus that the judgment is bad) and an AD who becomes abusive. If a single AD does not like a document, but the rest of the IESG is happy with it, there are always ways to work that out (and I note that there are two ADs in every area now) and appeals as a backup. If an AD is so opposed as to become abusive, despite generally IESG agreement that the document is ok, then I would guess that that particular AD's opposition will rarely be an isolated case of difficult behavior and the broader problem becomes worth solving. ... Ask another AD ? Your draft tries to block that escape hatch. Perhaps for ternary arithmetic, but not for something that really belongs to another Area. Or, presumably, that could be handled by anther AD in the same area. If the nomcom has done a competent job, and both ADs in an area are opposed to a document, then either the doc author has a problem or... Try independent ? John's draft tries to block that too. No No. We shall see what that draft says when the IAB gets finished with it, but the restrictions there very much have to do with not having failed IETF documents bounced over without some critical work. Individual submissions are not IETF documents in that sense, so there should really be no issue. As a piece of free and very general advice, and speaking personally (not for the RFC Editor or the Ed Board), if I tried to take a document, individually, to some AD and got hard pushback, I'd assume that pushback would reappear when the RFC Editor sent the document over for RFC 3932 review. And then, before taking the document in under independent, I'd advise editing/ revising it to make it as IESG-proof as possible. That would involve making sure it didn't sound like a standards-track protocol spec, didn't ask for IANA actions, and, if the reason for the AD rejection was because the document was critical of an IETF decision or direction, it was clearly written as a balanced critical analysis rather than a proposal that someone could point to and say evil. ... john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
On Fri, 09 Feb 2007 21:57:58 +0200 Jari Arkko [EMAIL PROTECTED] wrote: In any case, at the end of the day there is going to be someone who has to decide whether a particular proposal fits the purpose of the WG, the IETF or the RFC series. This someone can be the people in the WG, the sponsoring AD, the RFC Editor depending on what kind of a submission we are talking about, but there is always someone. And as Brian noted, if this someone misuses their power for personal reasons or some other reason, we have an appeals process. I'm not sure there's fundamentally any other way to handle this. And for IETF documents, that someone is just handling the beginning of the process and the proposal has to go through more review from the community. Right. The IETF is not a general-purpose publishing house for networking documents. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Jari Arkko wrote: And as Brian noted, if this someone misuses their power for personal reasons or some other reason, we have an appeals process. I'm not sure there's fundamentally any other way to handle this. Nor me. Forcing them to either vote Yes for a document they don't really like, or refuse an IESG evaluation, that could be a dilemma for the AD. And finding an AD where that situation is unlikely could be an difficult for authors - if they know this potential dilemma. [Brian also mentioned:] | in fact a common reply from an AD might be to recommend | independent submission if the work is interesting but really | outside IETF scope. Maybe the draft should say so at the end of the 4th paragraph in chapter 3, where it talks about BoFs and WGs. Or at the end of chapter 5. I don't like this draft, send publication request to secretariat is more attractive than spamming ADs. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Frank, Not publishing it at all is an alternative. And this is what we should do, if the community feels that way. However ... It would send an unmistakable message to wannabe-authors, that they should use the independent path, unless they're a friend of a friend of an AD. I personally feel fairly strongly that the individual submission option is very useful for the IETF community -- along with the usual WG submissions and the independent submissions via the RFC Editor. The reasons are described in the draft, but relate to situations where non-WG proposals are useful to the IETF community and require IETF and IESG review. By the way, the draft explicitly states that being friends with an AD is NOT a reason for a draft to be sponsored. From what I can see this is also the process that we follow. If not, please complain! Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? Thanks again for raising these questions. Jari John C Klensin kirjoitti: Hi. I will get to substance in a separate note, and hope others will also. In the interim, two procedural remarks... (1) This document and draft-klensin-rfc-independent-05.txt describe two pieces of the how a document that does not originate in a WG may be reviewed and published space. Each contains some text that suggests that some documents are better handled via the other path. The IAB has made a request for input on the independent document and now we have a Last Call on this one. As editor of the rfc-independent document, I am awaiting instructions from the IAB as to what, if anything, to do next, but suspect that the recommendation below would be better applied to -06 rather than -05 of that document. I strongly encourage members of the community to review the two documents side by side to ensure that everyone is satisfied that they are consistent and that any questions about the overall non-WG submission space is adequately covered by one or the other of them. I also ask, and hope others will join me in asking, that the IESG and IAB take explicit responsibility for coordinating and ensuring consistency between these two documents (and, if necessary, with draft-iab-rfc-editor). If they are not consistent enough that actions based on them are predictable, I fear we can look forward to some difficulties. It might even be useful for the two groups to coordinate titles sufficiently that someone looking for information will easily understand that the two describe somewhat parallel paths and ways in which those paths may or may not be alternatives to each other. (2) This document is not the product of a working group or of extended open discussion in the community. Version -00 was posted around the time of the San Diego meeting and received very little public discussion. The current version was posted at the beginning of this month; there has been little discussion of it either (at least on public lists -- as the Acknowledgements suggest, I've had some input into it via private discussions). The document does not even indicate a mailing list on which it can be discussed. One presumes that comments could have been sent to the IESG by those who happened to read the I-Ds, but that is a one-way communications path. If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION, not an Informational RFC. If they intend it to be definitive information for the community, especially information that they expect to reference as to why something is or is not possible or whether procedures are being followed, a two-week Last Call is, IMO, inappropriate and inconsistent with the spirit of the provisions in RFC 2026. john --On Wednesday, 07 February, 2007 10:20 -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
On 2007-02-08 01:25, Frank Ellermann wrote: John C Klensin wrote: If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION Not publishing it at all is an alternative. It would send an unmistakable message to wannabe-authors, that they should use the independent path, unless they're a friend of a friend of an AD. That is a complete mischaracterization. The intent in publishing this (and doing so in parallel with draft-klensin-rfc-independent) is to make it much clearer to authors when they should choose one path and when they should choose another. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
John, On 2007-02-08 00:02, John C Klensin wrote: Hi. I will get to substance in a separate note, and hope others will also. In the interim, two procedural remarks... (1) This document and draft-klensin-rfc-independent-05.txt describe two pieces of the how a document that does not originate in a WG may be reviewed and published space. Each contains some text that suggests that some documents are better handled via the other path. The IAB has made a request for input on the independent document and now we have a Last Call on this one. As editor of the rfc-independent document, I am awaiting instructions from the IAB as to what, if anything, to do next, but suspect that the recommendation below would be better applied to -06 rather than -05 of that document. I strongly encourage members of the community to review the two documents side by side to ensure that everyone is satisfied that they are consistent and that any questions about the overall non-WG submission space is adequately covered by one or the other of them. Exactly right. These documents (and draft-iab-rfc-editor) need to interlock and that is why they are open for review at the same time. I also ask, and hope others will join me in asking, that the IESG and IAB take explicit responsibility for coordinating and ensuring consistency between these two documents (and, if necessary, with draft-iab-rfc-editor). If they are not consistent enough that actions based on them are predictable, I fear we can look forward to some difficulties. It might even be useful for the two groups to coordinate titles sufficiently that someone looking for information will easily understand that the two describe somewhat parallel paths and ways in which those paths may or may not be alternatives to each other. That is the intention; and we can indeed look at the titles in that light. (2) This document is not the product of a working group or of extended open discussion in the community. Version -00 was posted around the time of the San Diego meeting and received very little public discussion. The current version was posted at the beginning of this month; there has been little discussion of it either (at least on public lists -- as the Acknowledgements suggest, I've had some input into it via private discussions). The document does not even indicate a mailing list on which it can be discussed. One presumes that comments could have been sent to the IESG by those who happened to read the I-Ds, but that is a one-way communications path. Well, the Last Call message suggested this list. And with one rather small difference, the draft only attempts to describe current practice. [The difference is that it calls for a publication request to be sent to a single AD and not to the IESG as a whole.] If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION, not an Informational RFC. We discussed this and reached the opposite conclusion, mainly because of the point you raise above: consistency with two other documents that will definitely be RFCs. But it was a close decision. If they intend it to be definitive information for the community, especially information that they expect to reference as to why something is or is not possible or whether procedures are being followed, a two-week Last Call is, IMO, inappropriate and inconsistent with the spirit of the provisions in RFC 2026. If we believed it modified or did violence to 2026, it would need to be a BCP itself with a whole other style of review. But since its intent is much milder, a normal LC seemed enough. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
--On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko [EMAIL PROTECTED] wrote: Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? Sure. But my point in that area was obviously not clear. Prior to the announcement of the Last Call, there was no indication to the community that this document should be considered and discussed, much less where. There is no working group charter, no history of open discussion, and so on. And _that_ calls for a four-week Last Call, not two weeks. regards, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
John, Sure. But my point in that area was obviously not clear. Prior to the announcement of the Last Call, there was no indication to the community that this document should be considered and discussed, much less where. Right. We weren't ready for a very wide discussion with the earlier revision, it had too many obvious problems. I hope the right discussion forum is now clear. There is no working group charter, no history of open discussion, and so on. And _that_ calls for a four-week Last Call, not two weeks. But its Informational. My read of RFC 2026 says that the 4 week case applies to Standards Track only. In any case, if it turns out that we get too little feedback or there's significant controversy, I'm sure Brian will consider what that means for successful end of the last call... Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
John, On 2007-02-08 13:16, John C Klensin wrote: --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko [EMAIL PROTECTED] wrote: Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? Sure. But my point in that area was obviously not clear. Prior to the announcement of the Last Call, there was no indication to the community that this document should be considered and discussed, much less where. There is no working group charter, no history of open discussion, and so on. And _that_ calls for a four-week Last Call, not two weeks. The rules require a 4 week last call for non-WG standards actions, which this isn't, so the tracker automatically generated a 2 week last call. But I assure you that discussion will not be truncated arbitrarily as a result (i.e. I do not intend to rush this onto the IESG agenda for Feb. 22). Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
But its Informational. My read of RFC 2026 says that the 4 week case applies to Standards Track only. rfc 2026 says what must be done in some cases - it does not say what can not be done in the cases it does not cover - specifically, RFC 2026 in no way would block a 4-week last call for an informational RFC - note that RFC 2026 does not require any last call for informationals fwiw - I agree with John - this doc warents a longer last call because it does impact how part of the IETF process will work and the draft did not get vetted in a normal working group process Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Scott, rfc 2026 says what must be done in some cases - it does not say what can not be done in the cases it does not cover - specifically, RFC 2026 in no way would block a 4-week last call for an informational RFC - note that RFC 2026 does not require any last call for informationals Right, I didn't mean to imply there was an upper limit. Its always a judgment call. fwiw - I agree with John - this doc warents a longer last call because it does impact how part of the IETF process will work and the draft did not get vetted in a normal working group process That's a fair statement. I believe Brian just told us that he's not in a rush, so he's not cutting the discussion off too early. But its his call if he officially changes the last call period. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
On 2007-02-08 14:05, Scott O. Bradner wrote: But its Informational. My read of RFC 2026 says that the 4 week case applies to Standards Track only. rfc 2026 says what must be done in some cases - it does not say what can not be done in the cases it does not cover - specifically, RFC 2026 in no way would block a 4-week last call for an informational RFC - note that RFC 2026 does not require any last call for informationals fwiw - I agree with John - this doc warents a longer last call because it does impact how part of the IETF process will work and the draft did not get vetted in a normal working group process As I said, this won't be rushed through. Let's see if there are any comments of substance though. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
John == John C Klensin [EMAIL PROTECTED] writes: John --On Thursday, 08 February, 2007 03:34 -0500 Jari Arkko John [EMAIL PROTECTED] wrote: Thanks for your note John. Let me also emphasize the need for these two drafts to be synchronized. Last calling draft-iesg at this time was made in part because we wanted to get the two in sync. I think we are more or less in sync but the remaining input should come from the community. As for the list to use for discussion -- sending mail to the iesg list only would indeed be one way. The discussion list we are on right now seems more suited, no? John Sure. But my point in that area was obviously not clear. John Prior to the announcement of the Last Call, there was no That sort of depends on what's going on here. Is Jari's draft an internal procedure of the IESG sent out for community review because the IESG believes it has an obligation to seek input on its procedures and to document them? If so, then a two week last call seems fine? Alternatively, is this an IETF community process document that will bind the IESG in the future unless it is updated by the community? If so, then it should be a BCP and a four week last call. My understanding was that RFC 2026 was normative here (although it says basically nothing) and that the IESG was documenting its procedures. If the community believes that this topic is important enough that it should be a community decision not an IESG decision, that seems entirely fine to me. But then this should not be an informational document. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Jari Arkko wrote: please complain! That was the complaint, the draft is from an IESG POV, and it explains how to deal with confused authors claiming that a single bit is enough to count to three or similar cases. But it doesn't address the POV of authors who want to get an evaluation of their I-D. The first step is clear, figure out the area, if that's unclear ask the General AD. After that if the area has a catchall crackpot WG try to get a review there, at some point in time ask the Chair(s) to adopt the I-D. Is that still correct ? If the area has no catchall crackpot WG try to get reviews on a related IETF or other list, at some point in time ask one of the ADs. If that AD agrees to support it there will be a Last Call or not - depending on the intended status, or the decision of that AD to last call it anyway. But what if the AD doesn't like it ? Not all drafts try to introduce ternary bits. Apparently ADs are forced to vote [Yes] (at least initially) if they sponsor a document. What if they don't like it, but the authors still insist on an evaluation ? Can they appeal then ? What if the AD does not like it personally, but admits that it's not as bad as the famous ternary bits ? Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
--On Thursday, 08 February, 2007 10:19 -0500 Sam Hartman [EMAIL PROTECTED] wrote: John Sure. But my point in that area was obviously not clear. John Prior to the announcement of the Last Call, there was no That sort of depends on what's going on here. Is Jari's draft an internal procedure of the IESG sent out for community review because the IESG believes it has an obligation to seek input on its procedures and to document them? If so, then a two week last call seems fine? Alternatively, is this an IETF community process document that will bind the IESG in the future unless it is updated by the community? If so, then it should be a BCP and a four week last call. My understanding was that RFC 2026 was normative here (although it says basically nothing) and that the IESG was documenting its procedures. If the community believes that this topic is important enough that it should be a community decision not an IESG decision, that seems entirely fine to me. But then this should not be an informational document. Sam, I think we pretty much agree, and that is why my initial note wasn't much more aggressive. But it raises the issue that others have raised: if this meets the criteria for IETF documenting its procedures and, as you have described it above, informational, then why not publish it as an ION given that series was designed for just those sorts of things?Please take that as a question, not a position, but it is a very serious one. More generally, and independent of this particular document, it seems to me that, with IONs in the mix, publishing something that is informational about IESG procedures requires some explanation. Procedural BCPs do not, IONs do not, but informational documents of this variety have now become sort of an odd case. And, IMO, if something that could reasonably be published as an ION is proposed for publication as an Info RFC instead, then that ought to imply a decision that serious community discussion is in order, not just comments on a collection of IESG decisions. Put differently, I think the existence of IONs implicitly raises the bar on Info publication of procedural docs, especially ones that are just IESG statements of IESG procedures. I think that is essentially the same question that Spencer and others have raised. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Hi Frank, That was the complaint, the draft is from an IESG POV, and it explains how to deal with confused authors claiming that a single bit is enough to count to three or similar cases. I would be happy to sponsor a ternary bit draft, but only on April 1 :-) But it doesn't address the POV of authors who want to get an evaluation of their I-D. The first step is clear, figure out the area, if that's unclear ask the General AD. Right. After that if the area has a catchall crackpot WG try to get a review there, at some point in time ask the Chair(s) to adopt the I-D. Is that still correct ? If the area has no catchall crackpot WG try to get reviews on a related IETF or other list, at some point in time ask one of the ADs. Right. But the draft says relatively little about this, because there are different situations. Some areas have a general purpose area working group with chairs and an ability to produce documents just like any other WG. Other areas (like INT) have only a discussion forum that is not intended for detailed protocol development. In the latter case the ADs are likely to get more individual submission proposals. And the authors may not even be the active parties. ADs may and sometimes do solicit specifications for some purpose, such as fixing a bug or updating an aging crypto algorithm. If that AD agrees to support it there will be a Last Call or not - depending on the intended status, or the decision of that AD to last call it anyway. Right. But what if the AD doesn't like it ? Not all drafts try to introduce ternary bits. Apparently ADs are forced to vote [Yes] (at least initially) if they sponsor a document. What if they don't like it, but the authors still insist on an evaluation ? Can they appeal then ? What if the AD does not like it personally, but admits that it's not as bad as the famous ternary bits ? As with regular WG submissions, the document has to pass the responsible AD's review. Otherwise it goes back to the WG or the authors. ADs can always decline to sponsor a given document, based on usefulness to the community, expertise, etc. There is no guarantee that all suggestions will be taken on. Appeals procedures apply just like they do for other contributions. Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
On Wednesday, February 07, 2007 10:20:54 AM -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC This document looks good to me. However, I am compelled to ask why it should be published as an Informational RFC instead of as an ION. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
And we should ask this question every time we see an informational process RFC last call... The best reason to publish a process document as an RFC is because it will be a BCP (IONs aren't BCPs). Since this one won't be a BCP, and given that guidance could change over time, I'd think an ION is more reasonable. Thanks, Spencer On Wednesday, February 07, 2007 10:20:54 AM -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC This document looks good to me. However, I am compelled to ask why it should be published as an Informational RFC instead of as an ION. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
Hi. I will get to substance in a separate note, and hope others will also. In the interim, two procedural remarks... (1) This document and draft-klensin-rfc-independent-05.txt describe two pieces of the how a document that does not originate in a WG may be reviewed and published space. Each contains some text that suggests that some documents are better handled via the other path. The IAB has made a request for input on the independent document and now we have a Last Call on this one. As editor of the rfc-independent document, I am awaiting instructions from the IAB as to what, if anything, to do next, but suspect that the recommendation below would be better applied to -06 rather than -05 of that document. I strongly encourage members of the community to review the two documents side by side to ensure that everyone is satisfied that they are consistent and that any questions about the overall non-WG submission space is adequately covered by one or the other of them. I also ask, and hope others will join me in asking, that the IESG and IAB take explicit responsibility for coordinating and ensuring consistency between these two documents (and, if necessary, with draft-iab-rfc-editor). If they are not consistent enough that actions based on them are predictable, I fear we can look forward to some difficulties. It might even be useful for the two groups to coordinate titles sufficiently that someone looking for information will easily understand that the two describe somewhat parallel paths and ways in which those paths may or may not be alternatives to each other. (2) This document is not the product of a working group or of extended open discussion in the community. Version -00 was posted around the time of the San Diego meeting and received very little public discussion. The current version was posted at the beginning of this month; there has been little discussion of it either (at least on public lists -- as the Acknowledgements suggest, I've had some input into it via private discussions). The document does not even indicate a mailing list on which it can be discussed. One presumes that comments could have been sent to the IESG by those who happened to read the I-Ds, but that is a one-way communications path. If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION, not an Informational RFC. If they intend it to be definitive information for the community, especially information that they expect to reference as to why something is or is not possible or whether procedures are being followed, a two-week Last Call is, IMO, inappropriate and inconsistent with the spirit of the provisions in RFC 2026. john --On Wednesday, 07 February, 2007 10:20 -0500 The IESG [EMAIL PROTECTED] wrote: The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
John C Klensin wrote: If the IESG intends this document to merely represent the particular procedures they intend to follow within the range of alternatives over which they believe they have discretion, then it should probably be published as an ION Not publishing it at all is an alternative. It would send an unmistakable message to wannabe-authors, that they should use the independent path, unless they're a friend of a friend of an AD. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: draft-iesg-sponsoring-guidelines (Guidance on Area Director Sponsoring of Documents) to Informational RFC
The IESG has received a request from the Internet Engineering Steering Group (iesg) to consider the following document: - 'Guidance on Area Director Sponsoring of Documents ' draft-iesg-sponsoring-guidelines-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-iesg-sponsoring-guidelines-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15381rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
