Re: Last Call: draft-iesg-sponsoring-guidelines (Guidance on AreaDirector Sponsoring of Documents) to Informational RFC
- I'm lost about why we would continue to publish Informational process RFCs (ignoring any existing pipeline of process documents remaining to be published as RFCs). To me the argument for making this one an RFC is mainly that it fits together with the two other drafts mentioned previously, which pretty clearly need to be RFCs. But it wouldn't give me any heartburn if the community consensus is to make it an ION. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 49 messages in the last 7 days. script run at: Fri Feb 9 00:53:02 EST 2007 Messages | Bytes| Who +--++--+ 12.24% |6 | 12.27% |33734 | [EMAIL PROTECTED] 10.20% |5 | 9.72% |26727 | [EMAIL PROTECTED] 6.12% |3 | 8.60% |23652 | [EMAIL PROTECTED] 8.16% |4 | 6.38% |17539 | [EMAIL PROTECTED] 6.12% |3 | 6.11% |16796 | [EMAIL PROTECTED] 6.12% |3 | 5.44% |14947 | [EMAIL PROTECTED] 4.08% |2 | 5.23% |14382 | [EMAIL PROTECTED] 4.08% |2 | 4.87% |13401 | [EMAIL PROTECTED] 4.08% |2 | 4.44% |12199 | [EMAIL PROTECTED] 4.08% |2 | 4.31% |11836 | [EMAIL PROTECTED] 4.08% |2 | 3.51% | 9655 | [EMAIL PROTECTED] 4.08% |2 | 3.11% | 8558 | [EMAIL PROTECTED] 4.08% |2 | 2.80% | 7700 | [EMAIL PROTECTED] 2.04% |1 | 3.53% | 9704 | [EMAIL PROTECTED] 2.04% |1 | 3.24% | 8899 | [EMAIL PROTECTED] 2.04% |1 | 2.44% | 6695 | [EMAIL PROTECTED] 2.04% |1 | 2.27% | 6241 | [EMAIL PROTECTED] 2.04% |1 | 2.21% | 6079 | [EMAIL PROTECTED] 2.04% |1 | 1.87% | 5151 | [EMAIL PROTECTED] 2.04% |1 | 1.83% | 5033 | [EMAIL PROTECTED] 2.04% |1 | 1.65% | 4543 | [EMAIL PROTECTED] 2.04% |1 | 1.48% | 4059 | [EMAIL PROTECTED] 2.04% |1 | 1.36% | 3735 | [EMAIL PROTECTED] 2.04% |1 | 1.33% | 3654 | [EMAIL PROTECTED] +--++--+ 100.00% | 49 |100.00% | 274919 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) Multiple Signer Clarification) to Proposed Standard
Denis == Denis Pinkas [EMAIL PROTECTED] writes: Denis Sam, Russ == Russ Housley [EMAIL PROTECTED] writes: Russ Denis: I do not consider these to be new comments. You made Russ them during WG Last Call, and there was considerable Russ discussion on the S/MIME WG mail list. In the end, you were Russ unable to gain any support for your position. Why do you Russ feel I need to respond to the same comments again? I tend to agree with Russ. Denis I do not see how it may be possible to reach a consensus if Denis a dialogue is not accepted. Russ is the editor. You said that you have already brought these issues up in the WG. It is no longer Russ's job to engage with you if he does not want to. It is the WG chairs' job to describe the reasoning for why your comments were rejected during the WG discussion and I've asked the chairs to do that. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
The title of this document is very confusing and should be revised to include the string textual convention. Seeing this last call announcement I was very puzzled why anyone thought it would be a good idea to hae a MIB for monitoring and managing all the URIs on a managed system. I was gratified to find that this is not what the document was about. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Revised I-D: draft-ietf-mipshop-cga-cba-03.txt
Christian, Thanks for your quick re-spin of this draft. I have reviewed this latest version, and it addresses all of the issues/questions I had raised. Thanks, again! -- Eric Gray Principal Engineer Ericsson -Original Message- From: Christian Vogt [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 7:10 PM To: Mipshop; ietf@ietf.org; gen-art@ietf.org Cc: Eric Gray (LO/EUS); Jari Arkko; Wassim Haddad; Vijay Devarapalli; Stefano Faccin Subject: Revised I-D: draft-ietf-mipshop-cga-cba-03.txt Hello folks, we updated draft-ietf-mipshop-cga-cba according to the comments and suggestions that Eric Gray posted on the IETF Discussion mailing list during IETF Last Call. Here is a change log (not including purely editorial items): o Reference to RFC 3972 (Cryptographically Generated Addresses) is now normative. o More detailed IANA considerations. o Fixed reference to BCP 14, RFC 2119, so that Nit Checker does no longer complain. o Clarified in Section 3.1 that CGAs do not require a public-key infrastructure, even though they make use of public-key cryptography. o Included intended status (Proposed Standard) at beginning of document. You can access the revised draft version as well as a diff against the previous version 02 at: http://doc.tm.uka.de/2007/draft-ietf-mipshop-cga-cba-03.txt http://doc.tm.uka.de/2007/draft-ietf-mipshop-cga-cba-02to03.html Best regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ ___ 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-mcwalter-uri-mib (Uniform Resource Identifier (URI) MIB) to Proposed Standard
Sam Hartman wrote: The title of this document is very confusing and should be revised to include the string textual convention. Seeing this last call announcement I was very puzzled why anyone thought it would be a good idea to hae a MIB for monitoring and managing all the URIs on a managed system. I was gratified to find that this is not what the document was about. I strongly agree with the above comments. For the title I would recommend: Textual Conventions for Representing Uniform Resource Identifiers (URIs) In the same vein, I would recommend URI-TC-MIB for the module name and uriTcMIB for the descriptor representing the MODULE-IDENTITY value. Note that these recommendations are consistent with the (non-binding) advice in Appendix C of RFC 4181 (the MIB review guidelines). //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-mcwalter-langtag-mib (Language Tag MIB) to Proposed Standard
On Thu, 8 Feb 2007, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Language Tag MIB ' draft-mcwalter-langtag-mib-01.txt as a Proposed Standard The title seems to suggest that the document defines managed objects for managing language tags, which is not the case. In order to prevent confusion, I would recommend that the title be changed to: A Textual Convention for Representing Language Tags In the same vein, I would recommend LANGTAG-TC-MIB for the module name and langTagTcMIB for the descriptor representing the MODULE-IDENTITY value. Note that these recommendations are consistent with the (non-binding) advice in Appendix C of RFC 4181 (the MIB review guidelines). //cmh ___ 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-ietf-smime-cms-mult-sign (CryptographicMessageSyntax(CMS) MultipleSigner Clarification) to Proposed Standard
Blake == Blake Ramsdell [EMAIL PROTECTED] writes: Blake OK, let me back up and explain the events as I see them and Blake try to clarify. And I am certainly welcome to any comments Blake or criticism about what my role is or how I should proceed Blake with this. Blake * My job as WG chair is to make sure that the editor (Russ) Blake has created a draft that incorporates what we consider to Blake be the rough consensus of the working group. Blake * You had some comments on this draft. Some of your Blake comments were incorporated. Some of your comments had zero Blake support from the WG members on the working group mailing Blake list. Clarifications welcome as to exactly who else Blake supported these comments. You also have a job to make sure WG last call comments are responded to and that technical issuse are addressed. For the issues Denis raised, I'm also probably going to require something stronger than No one agreed. I'd like to know why he's wrong. ___ 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
