Re: New Version Notification for draft-leiba-3777upd-eligibility-03.txt
Russ has asked that SM and I pare down the proposal for a 3777 update, back down to my original one that just adds the IAOC and the ex-officio roles to the exclusion list. After talking with SM, I have re-posted a slightly edited version of that original proposal (below), and we have decided that either SM or SM and I will re-propose the other changes at a later time. For now, the -03 version is just the original proposal: add the IAOC and the two IAB ex-officio positions (IAB Executive Director and IRTF Chair) to the current list of who RFC 3777 excludes from eligibility to volunteer for NomCom. Further comments on this limited proposal are welcome and encouraged. Barry (and SM) On Fri, Sep 14, 2012 at 12:57 PM, wrote: > > A new version of I-D, draft-leiba-3777upd-eligibility-03.txt > has been successfully submitted by Barry Leiba and posted to the > IETF repository. > > Filename:draft-leiba-3777upd-eligibility > Revision:03 > Title: Update to RFC 3777 to Clarify Nominating Committee > Eligibility of IETF Leadership > Creation date: 2012-09-14 > WG ID: Individual Submission > Number of pages: 4 > URL: > http://www.ietf.org/internet-drafts/draft-leiba-3777upd-eligibility-03.txt > Status: > http://datatracker.ietf.org/doc/draft-leiba-3777upd-eligibility > Htmlized:http://tools.ietf.org/html/draft-leiba-3777upd-eligibility-03 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-leiba-3777upd-eligibility-03 > > Abstract: >RFC 3777 specifies that "sitting members" of the IAB and IESG "may >not volunteer to serve on the nominating commitee". Since that >document was written the IAOC was formed, and that body is not >covered by RFC 3777. There is also uncertainty about whether ex- >officio members and liaisons are included as "sitting members". This >document clarifies those situations.
Re: Last Call: (Prefer Header for HTTP) to Proposed Standard
At 11:44 14-09-2012, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Prefer Header for HTTP' as Proposed Standard 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 2012-10-12. Exceptionally, comments may be I took a quick look at the draft. In the Abstract: "This specification defines an HTTP header field that can be used by a client to request that certain behaviors be implemented by a server while processing a request." The "request that certain behaviors be implemented by a server" sounds odd. The "employ" from the Introduction section is a better fit. In Section 2: "A server that does not recognize or is unable to comply with particular preference tokens in the Prefer header field of a request MUST ignore those tokens and MUST NOT stop processing or signal an error." Suggested text: A server that does not recognize or is unable to comply with particular preference tokens in the Prefer header field of a request MUST ignore those tokens and continue processing instead of signalling an error. In Section 4.1: "Registration requests consist of the completed registration template below, typically published in an RFC or Open Standard (in the sense described by Section 7 of [RFC2026])." Is it necessary to get into the details of the Specification Required policy? "Permanent and readily available public specification" would be better than the reference to RFC 2026. BTW, the RFC 5023 informative reference is missing. Regards, -sm
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
I don't think that the Note Well note has much to do with what Joe started talking about we have had this discussion before quite a few years ago (pre tools) I suggested moving "expired" IDs to an "expired IDs" directory rather than removing them from the IETF public repository as well as posting all the old expired IDs in the same directory (changing only the filename to prepend "expired-") seemed like a good idea to me & to many other people, for the reasons people find the tools ID archive useful & the IESG at the time said to move ahead Steve Coya started the (long) process f pulling the old IDs from backup tapes as he was finishing that process a new IESG was seated and the new IESG was not as in favor of the idea and wanted a fuller mailing list discussion (there had been a short discussion when I proposed the idea) there were a few people (Joe was one) that felt that IDs were published under the rights implied in rfc 2026, which said that IDs expired, and, thus, the IETF did to have the right to not remove them (there fact that other repositories existed did not change the IETF's rights in their opinion - in at least one case someone (I think Bill Manning) sent letters to some of those archives asking that their ID be removed) with support from the then IETF lawyer, I suggested that there be a way for a ID author to request that their ID be removed from the expired IDs directory but that idea did not carry the day and the expired IDs directory idea died then, at some later point, the tools function showed up - I do not think I was still on the IESG at that point so I do not know if the IESG discussed the question I think this is a very useful service (for history of how the technology evolved and for prior art searches in patent cases) and think that pretending that anything published on the Internet ever quite goes away is not realistic. Scott On Sep 14, 2012, at 1:35 AM, Joe Touch wrote: > Note well, as you noted well, does not go back to the beginning of all IDs.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On Fri, Sep 14, 2012 at 07:24:12AM -0700, tglassey wrote: > > For instance - how do you deal with an ID which was originally > published under one set of IP rights and another later one - or a > derivative work which is published under a separate set of rights - > which functionally contravenes or sets aside those original rights > authorizations? > > This is a serious issue. Indeed, it is, and if anybody would provide examples where we've had this problem, I would be standing in line to argue that indeed we need to make a policy and write stuff down. Instead, the best anyone comes up with is (1) artificial examples of stuff that might happen someday maybe if someone does something wrong and (2) one-off cases that are incredibly tricky anyway. In response to (1), I say this is a problem we don't have. We have a poor track record with protocols for which there is no obvious immediate need (indeed, even when there's an obvious immediate need, we often screw it up). Why would policy be different? In response to (2), I say that hard cases make bad law. They're all going to be exceptions anyway. A -- Andrew Sullivan a...@anvilwalrusden.com
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 10:35 PM, Joe Touch wrote: Note well, as you noted well, does not go back to the beginning of all IDs. I.e., this is a tangled mess of different copyrights, different note wells, etc., and it's not as simple as "it's the IETF's right" to do anything except - maybe - going forward with a new copyright statement for IDs. Joe On 9/13/2012 10:10 PM, Martin Rex wrote: I think Joe is right here. What the real issue is is simply that you have no actual way of proving #7 and this process is so bad it fails to meet the basic IP Licensing Process Rules that *** ALL *** commercial and academic providers are tied to in the real world so this is more of the IETF's actions about its ability to create RIGHTS in a legal sense for anyone to anything it cannot formally prove it has legal power of attorney over. If you dont own it - granting a third part rights to something over an electronic transport is actually a criminal act AFAIK. Todd 10.3.1. All Contributions 7. The contributor represents that there are no limits to the contributor's ability to make the grants acknowledgments and agreements above that are reasonably and personally known to the contributor. By ratifying this description of the IETF process the Internet Society warrants that it will not inhibit the traditional open and *>free access to IETF documents for which license and right have *>been assigned according to the procedures set forth in this *>section, including Internet-Drafts and RFCs. This warrant is *>perpetual and will not be revoked by the Internet Society or its *>successors or assigns. So which specific part of "including Internet-Drafts and RFCs" and "This warrent is perpetual" caused your impression that there was a time-limit on an I-D contribution? -Martin btw. rfc2026 10.3.1 (2) looks like an explicit non-policy for dissemmination or termination of dissemination to me: 2. The contributor acknowledges that the ISOC and IETF have no duty to publish or otherwise use or disseminate any contribution. I would be OK with a single person from (IESG member or IETF Chair) quickly decides about suspending dissemination of a document based on personal judgement and that the IESG wiggles out by themselves an informal procedure (rather than a formal policy) for safeguarding the process (from bias and abuse). This cuts into their time budget and seems to not be a concerningly frequent occurence to spend much polish on it at this point. - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2221 / Virus Database: 2437/5267 - Release Date: 09/13/12 -- //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 9:23 PM, Joe Touch wrote: There were times when there were no rights granted explicitly, at least. I indicated the three ranges in a previous mail. Joe On 9/13/2012 8:40 PM, John Levine wrote: I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Can you give a concrete example of an I-D with this problem? I don't ever recall a time when the grant of rights to the IETF had a time limit. For instance - how do you deal with an ID which was originally published under one set of IP rights and another later one - or a derivative work which is published under a separate set of rights - which functionally contravenes or sets aside those original rights authorizations? This is a serious issue. Todd R's, John - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2221 / Virus Database: 2437/5267 - Release Date: 09/13/12 -- //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
On 9/13/2012 8:40 PM, John Levine wrote: I'm not sure I understand this analogy. Are you saying that there are IPR issues related to making expired drafts available? Yes. Depends on the IDs, when they were authored, and which version of the boilerplate they contain. Can you give a concrete example of an I-D with this problem? I don't ever recall a time when the grant of rights to the IETF had a time limit. They dont - and this is the problem. It means that there is no revision control in the license and NO ONE HAS TO USE OR IMPLEMENT ANY SPECIFIC SET OF SERVICES. It also means that there is no way to pull anything - even stolen or unauthorized materials once licensed. Todd R's, John - No virus found in this message. Checked by AVG - www.avg.com Version: 2012.0.2221 / Virus Database: 2437/5267 - Release Date: 09/13/12 -- //Confidential Mailing - Please destroy this if you are not the intended recipient.
Re: Draft IESG Statement on Removal of an Internet-Draft from the IETF Web Site
--On Thursday, September 13, 2012 23:59 + John Levine wrote: > Censorship? Sheesh. >... > As I think I've said several times before, if we think the > IESG would start gratuitously deleting stuff, we have much > worse problems than any policy statement could solve. +1 Exactly. The jump from "what do we do with the range of seemingly-legitimate request from an outside party to remove a document from public view" to "if give flexibility, the IETF might use it to start removing (or censoring) documents they don't like" seems incredible to me. john
