Issues with Letter of Invitation for IETF72
Hi Folks, I requested a letter of Invitation for the Dublin Meeting and I noticed the following issues. * I cannot register first and then come back for the letter of invitation. I get the following error You will need to register for the IETF meeting prior to requesting a letter of invitation. Once you have registered for the IETF meeting, you will be prompted to request the letter of invitiation. There should be a form here instead that should ask for my registration number. * There are two Questions about Nationality and Passport Issuer Country. The country I pick under Nationality shows up under the Address. In my case this is not correct. I do not know how these fields are being used, but the labels need to be clarified. Thanks Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Issues with Letter of Invitation for IETF72
Suresh, Thank you for your email. We are looking into these issues right now and will advise you, and the community, as soon as we have made the necessary repairs. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: [EMAIL PROTECTED] Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ On 4/8/08 8:52 AM, Suresh Krishnan [EMAIL PROTECTED] wrote: Hi Folks, I requested a letter of Invitation for the Dublin Meeting and I noticed the following issues. * I cannot register first and then come back for the letter of invitation. I get the following error You will need to register for the IETF meeting prior to requesting a letter of invitation. Once you have registered for the IETF meeting, you will be prompted to request the letter of invitiation. There should be a form here instead that should ask for my registration number. * There are two Questions about Nationality and Passport Issuer Country. The country I pick under Nationality shows up under the Address. In my case this is not correct. I do not know how these fields are being used, but the labels need to be clarified. Thanks Suresh ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
Hi, I agree with Russ. I think the trust and the IAOC have a bit different focus and it makes sense at times have a different chair for the different positions. This does not mean that we couldn't go in the future back to the common IAOC/Trust chair, but currently the work split would make sense. Cheers, Jonne. On 4/7/08 10:45 PM, ext Russ Housley [EMAIL PROTECTED] wrote: The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Jonne Soininen Nokia Siemens Networks Tel: +358 40 527 46 34 E-mail: [EMAIL PROTECTED] ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
As one of the 2 PR-action'ed persons, let me respond to these assertions. I was subject of a PR-Action in fall of 2005 because I did three things: 1) I asked for honesty in the sources of claims in the controverial spamops document. The discredited source was SORBS, which falsely claims address blocks used by Av8 Internet (130.105/16 and 198.3.136/21) are hijacked. They have done this since 2003, and know of the mistake. SORBS is connected to Paul Vixie and Dave Rand. 2) I asserted that RFC 3979 applied to DNS drafts, which had not made the proper disclosures required under RFC3979. Steven Bellovin (then chair of the IPR Working Group falsely stated that RFC3979 wasn't the policy of the IETF. ISOC Atty Contreras later refuted Bellovin's false claim. I was right. The drafts have not made the proper disclosures. This activity is similar to the deception by Russ Housley with the TLS-AUTHZ document. (Housley also voted on my PR-Action) 3) I attempted to discuss problems with Stateful Anycast Stability on DNSOP. Even though DNSOP was the proper forum for this discussion, I was bluntly told to drop the subject by then Area Director David Kessens. Kessens was associated with Paul Vixie and ISC through several connections. Vixie was advocating Anycast, and stood to lose money if problems were revealed. Since then, experimental data confirms the problems with Stateful Anycast. I've been vindicated on all three issues of the PR-Action. There was no misconduct on my part. Since then, I have been banned from the GROW, IPR, and DNSEXT Working Groups: -- I was banned from GROW for opposing draft-ietf-grow-anycast (Kessens) that implied that stateful anycast was stable, and stated that per packet load balancing (PPLB) was pathological. My opposition was steam rolled. As Sam Hartman wrote in his evaluation record: I believe that the IESG did not follow a process consistent with how we handle other documents and that the divergences from our normal process created an unacceptably closed process. As such, I am abstaining on this document as I cannot support its publication under the process that was used. The area director described the process used as hard ball. He said that because of the history of the document he was pushing back against changes both from the IESG and late last call comments more so than usual. By history, I suspect that he meant both the fact that this document has already been subject to an appeal and the fact that the document has been under development for a long time. I think that the area director chose to play hard enough ball that the process can no longer be considered open and that the IESG erred in supporting this process and approving the document. -- I was banned from IPR Working group. I am president of the LPF, an anti-patent organization founded by Richard Stallman. The LPF represents the views of many GNU supporters and many famous people in computer science. I was banned for working to fix the problems that enabled Russ Housley to deceive the IETF on IPR disclosure, yet receive no penalty. -- I was banned from the DNSEXT Working Group (namedroppers) which I have participated in since about 1990. I was banned because I opposed the author assigned to a revived axfr-clarify draft. This draft was involved in a prior scam by Paul Vixie et al 'clarifying' the AXFR protocol in 2002. The draft proponents claimed the draft had no wire protocol changes. However, it was discovered by Dr. Bernstein that the draft did include protocol changes. It was also discovered that BIND had already implemented changed protocol with detection for the old protocol. This scam was discovered and originally opposed by Dr. Dan Bernstein, the author of a major DNS server implementation. In 2002, Bernstein's email was blocked, subjected to forged unsubscriptions, etc. The draft was dead until recently, when Vixie and affiliates revived the document. I objected to assigning the document to authors affiliated with the previous abuse of Bernstein. None of these represent any sort of obstruction to legitimate work. Paul Vixie seems to be the center of the abuse against me, using his resources at NANOG, ISOC, and ARIN, and SORBS to interfere with my business and to promote his own economic interests. Others also have economic motives to harm me (e.g. Housley to prevent his being held accountable for patent disclosure violations.) These efforts at improper and unjustifiable censorship are presently the subject of legal contacts between my lawyer and their lawyers. These efforts to censor persons for economic purposes contradict the bylaws and charters of each of the organizations, and violate US laws. It will not stand. SORBS operator Matthew Sullivan has stated his intent to cause AV8 Internet to spend money to sue people who would lose but have no money to pay damages. But I do agree that the efforts at censorship are indeed a waste of time.
RE: [HOKEY] EMSK Issue
Is this saying that inter-domain handoff is not supported? My understanding is that ERX supports inter-domain use, no? I understand the restriction for other uses though (such as OTA Provisioning). -Original Message- From: Charles Clancy [mailto:[EMAIL PROTECTED] Sent: Saturday, April 05, 2008 2:59 PM To: Narayanan, Vidya Cc: Glen Zorn; ietf@ietf.org; [EMAIL PROTECTED]; Bernard Aboba Subject: Re: [HOKEY] EMSK Issue Narayanan, Vidya wrote: How about the following text for applicability: It must be noted that any application of EAP keying material to other usages such as handoffs, IP mobility or other applications is only feasible when those services are provided either by or through the provider handling network access. It is also only feasible when those usages only occur over EAP-capable interfaces. Hence, deriving USRKs or DSUSRKs for usages other than those facilitated by the network access provider is NOT RECOMMENDED. Sounds good to me. -- t. charles clancy, ph.d. eng.umd.edu/~tcc electrical computer engineering, university of maryland ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
ops-dir review of draft-ietf-lemonade-convert-17.txt
Hi, I have reviewed draft-ietf-lemonade-convert-17.txt as part of the Operations and Management directorate effort. These comments were primarily written for the benefit of the OM area directors. Document editors and WG chairs should treat these comments just like any other last call comments. CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences or its settings. I have no experience with IMAP commands. I will review this as best I can, and I request that another ops-dir reviewer with IMAP experience also review this document. 1. Is the specification complete? Can multiple interoperable implementations be built based on the specification? The basics appear to be complete and interoperable. It may be a common IMAP convention to allow optional parameters to commands. Response formats seem to be quite variable. It makes me a little concerned about interoperability to have optional elements. 2. Is the proposed specification deployable? If not, how could it be improved? I have no experience deploying MIME extensions, so cannot make a judgement on this. Deployment considerations are not discussed much in the document. 3. Does the proposed approach have any scaling issues that could affect usability for large scale operation? Each request asks the server to perform a conversion, which could be resource intensive. Could lots of requests from one client create a denial of service attack? 4. Are there any backward compatibility issues? The SIZE command has some backwards compatibility issues, described in section 8. 5. Do you anticipate any manageability issues with the specification? Manageability is not discussed in this document. I do not know if there would be anything new required as a result of this extension, but it might be useful for an operator to be able to tell how often this extension is being used and by whom and the number of errors, to help detect abuse and performace-impacting situations. 6. Does the specification introduce new potential security risks or avenues for fraud? The security considerations section covers these fairly well. Detailed review: section 6 Specifying any non leaf section part requires that the server know how to convert a multipart message, for instance into a PDF document. is ambiguous. Can the client request force a REQUIREMENT on the server (so 'requires' should be 'REQUIRES', or does this mean that making such a request to a server that doesn't know how to do the conversion will fail? (and presumably return an error code). In either case, thi stext should be modified to be clear and unambiguous. esp with regard to the RFC2119 keyword. s/convertions/conversions/ should the examples of header conversions be modified to use example.com rather than siroe.com? Such request REQUIREs that the server decode any encoded words seems to conflict with These parameters are non-trivial, and converting them without reformatting the header is not always going to be possible. So shouldn't this be a SHOULD? And I would expect some langugae that says something about what an implementer is required to support. The specification should define the requirement at implementation-time, not the act of a client making a request at runtime. The server ought to endeavour to - should we add ought to endeavour to RFC2119 as keywords? ;-) seriously, can we change this to RFC2119 terms? I have concerns abotu interoperability in the preservation of headers; there seems to be lots of MAY options in the preservation recommendations. There are a number of uses of may and requires and other keywords; Can those be capitalized (or changed), so it is clear these are all meant to convey the RFC2119 semantics. Some of the may usage would be better stated as might. It is important the encoded words be left as encoded words as to do otherwise may alter the semantics of structured headers. Can this be phrased in RFC2119 terms? There are a number of non-RFC2119 expressions of requirements or recomendations in this document, and this document should be gone through thoroughly to make sure they are converted to appropriate RFC2119 keywords. Watch for encourage, discourage, section 7 s/Note, that according/According/ I am not sure I understand why the example is needed here. Is this an example of additional optional parameters? Does this one sentence rule really require an example? The example apparently is not about the required charset parameter. Most of the text in section 7 is about mandatory-to-implement charset support, so should that go into section 7.1? section 8.3 discusses performance problems and suggests that clients should be considerate of performace implications of the SIZE command, and the text discourages a large number of
Re: Proposed Revisions to IETF Trust Administrative Procedures
Russ, The IETF Trust was set up as an instrument -- a naturally limited scope. The specific task you identify below (paying attention to items) could reasonably be addressed as Harald suggested. Giving the Trust a chair is at least a step towards acknowledging it as a separate organization (beyond instrument), and one could then examine whether the IAOC members are, in fact, the right people to populate it (for example). It certainly opens the doors to mission creep. My point, which I think is in line with something John Klensin said earlier, is that even though the current IAOC _intends_ this as a simple administrative change, the fact is it's a structural change that is open to be taken many places by future IAOCs and IETF communities, also of good intent. Given that, it would be nice to understand 1/ that the IAOC has considered this, and 2/ why other solutions are not considered viable. Leslie. P.S.: Also -- good luck with ever having a small meeting -- with 4 Chairs in the room, you'll be looking for end-tables pretty soon ;-) --On April 7, 2008 3:45:16 PM -0400 Russ Housley [EMAIL PROTECTED] wrote: The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed Revisions to IETF Trust Administrative Procedures
Leslie wrote: Giving the Trust a chair is at least a step towards acknowledging it as a separate organization ... I suppose you could interpret things this way, but that is not my view. Since its creation back in December 2005, all meetings of IETF Trustees have been convened and chaired by the IAOC Chair. As such, I think we have always had execute an administrative role of chairing IETF Trust meetings, and we've generally referred to that person as the Trust Chair in minutes and on the IETF Trust website. The recent posting of some new words for the Trust Administrative Procedures was an attempt to bring that document up to date, to reflect a desire amongst the current IAOC to load share the running of IAOC meetings and IETF Trust meetings by having two different people convene those meetings, and drive progress. That's it. Our intent is absolutely not to encourage mission creep. The above being said, it is quite clear from the excellent comments posted by several people on this topic that the Trustees have more work to do before the job of revising the text on the Administrative Procedures document is done. For example, John Klensin commented on some of the text in paragraph 12 that says If at any time the IAOC ceases to exist, the Trustees then in office shall remain in office That text is not new nor a proposed change to any existing Trust procedure. Those words are original text from December 2005. I am happy John took note of them in this round of discussions, as I don't think they exactly express what the Trustees intended for this clause to say. Best Regards, Ed Juskevicius -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leslie Daigle Sent: Tuesday, April 08, 2008 4:15 PM To: Russ Housley; IETF Discussion Cc: Harald Alvestrand Subject: Re: Proposed Revisions to IETF Trust Administrative Procedures Russ, The IETF Trust was set up as an instrument -- a naturally limited scope. The specific task you identify below (paying attention to items) could reasonably be addressed as Harald suggested. Giving the Trust a chair is at least a step towards acknowledging it as a separate organization (beyond instrument), and one could then examine whether the IAOC members are, in fact, the right people to populate it (for example). It certainly opens the doors to mission creep. My point, which I think is in line with something John Klensin said earlier, is that even though the current IAOC _intends_ this as a simple administrative change, the fact is it's a structural change that is open to be taken many places by future IAOCs and IETF communities, also of good intent. Given that, it would be nice to understand 1/ that the IAOC has considered this, and 2/ why other solutions are not considered viable. Leslie. P.S.: Also -- good luck with ever having a small meeting -- with 4 Chairs in the room, you'll be looking for end-tables pretty soon ;-) --On April 7, 2008 3:45:16 PM -0400 Russ Housley [EMAIL PROTECTED] wrote: The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
I hope that other IAOC members will share their thoughts too. Here are mine. Right now, the IETF Trust is faced with more work than usual. The IPR WG has placed a significant task on the IETF Trust. Yet, all of the usual IAOC activities need to go forward on the usual schedule. The reason that I support this action it to ensure all of these tasks stay on track. We've already seen the need for an extra teleconference in April to make that happen, and I'm sure there will me more as the license text begins to be drafted. As others have already said, separate chairs seems like the right thing to the people serving on the IAOC right now. That may not be the desire in a year. I do not see this flexibility as a problem or a slippery slope. Russ At 04:14 PM 4/8/2008, Leslie Daigle wrote: Russ, The IETF Trust was set up as an instrument -- a naturally limited scope. The specific task you identify below (paying attention to items) could reasonably be addressed as Harald suggested. Giving the Trust a chair is at least a step towards acknowledging it as a separate organization (beyond instrument), and one could then examine whether the IAOC members are, in fact, the right people to populate it (for example). It certainly opens the doors to mission creep. My point, which I think is in line with something John Klensin said earlier, is that even though the current IAOC _intends_ this as a simple administrative change, the fact is it's a structural change that is open to be taken many places by future IAOCs and IETF communities, also of good intent. Given that, it would be nice to understand 1/ that the IAOC has considered this, and 2/ why other solutions are not considered viable. Leslie. P.S.: Also -- good luck with ever having a small meeting -- with 4 Chairs in the room, you'll be looking for end-tables pretty soon ;-) --On April 7, 2008 3:45:16 PM -0400 Russ Housley [EMAIL PROTECTED] wrote: The IAOC and the IETF Trust have different focus. The idea behind the separate chair is to make sure that someone is paying attention to the items that need to be handled by each body in a timely manner. It is simply a mechanism to help ensure that noting is falling between the cracks. Russ --On April 4, 2008 11:50:23 AM +0200 Harald Alvestrand [EMAIL PROTECTED] wrote: After considering the comments so far, I think I disagree with having a separate Trust chair. The idea behind making the IAOC be the Trustees was, among other things, to make sure that we didn't create yet another nexus of control in the labyrinth of committees; I understood the legal existence of the Trustees as something different (in name) from the IAOC to be strictly something we did for legal purposes If the IAOC chair is overburdened by having to manage the IAOC in two different contexts, get him (or her) a secretary. I agree with John's comment that leaving the current trustees in charge on dissolution of the IAOC is inappropriate; for one thing, that also removes all the recall mechanisms. Figure out something else to do in this case. Harald ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
On Apr 8, 2008, at 1:14 PM, Leslie Daigle wrote: Giving the Trust a chair is at least a step towards acknowledging it as a separate organization (beyond instrument), and one could then examine whether the IAOC members are, in fact, the right people to populate it (for example). It certainly opens the doors to mission creep. Russ asked IAOC members to contribute. OK, here I am. It actually is a separate organization. It has separate meetings, separate minutes, and a separate membership - all trustees are IAOC members, and one certainly hopes that all IAOC members will agree to sign the form that makes them trustees, but that is not a requirement of IAOC membership. Specifically the chair of the trustees is *not* identified as the chair of the IAOC in the current procedures or in the trust - rather, meetings are convened by any trustee who happens to be present. Is that a problem? Well, it's not a big one, but it does seem odd. There are two logical ways to fix this. One is to identify the set of trustees with the IAOC - same committee, same chair, same meetings, same minutes. The other is to recognize the difference and decide that it's OK - the chair of the trustees might be the same as the chair of the IAOC but doesn't have to be, but leave the meetings, minutes, and committee separate as they are now. We chose the second, being the least change, and are suggesting it to the IETF community. ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART Last Call review of draft-ietf-rserpool-threats-09
(Oops, sent from wrong account--sorry for the repeat.) I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-rserpool-threats-09 Reviewer: Ben Campbell Review Date: 2008-04-08 IETF LC End Date: 2008-04-14 IESG Telechat date: (if known) Summary: This document is not ready for publication. It may or may not be on the right track, depending on the answer to my first comment. Comments: --General: It is not clear to me what this draft seeks to accomplish. Without being an expert in RSerPool, it is not clear to me if the draft intends to offer requirements for new security mechanisms into the RSerPool protocol itself, or to offer guidance to implementors on how to securely implement the protocol. If the former, then it is vague in many places, but is probably on the right track. However, would this mean that the other rserpool documents currently in last call will need significant changes indicated by _this_ draft? That is, if this draft progresses then the other are by definition not ready? (I fully admit not knowing the details of those drafts.) If the latter, then it is not helpful in its current form, as the offered requirements say nothing about what mechanisms to use. I will offer more details below The document does not use normative language, nor does it reference RFC 2119. I know normative language is not always required for informational RFCs, but it seems appropriate for this document, since it offers up important security requirements. It seems like a lot of references are missing (e.g. ENRP, ASAP, etc.) --Specific Comments: Section 1: The purpose of the draft is not clear from the introduction (See general comment above). It would be nice to see a background paragraph describing what RSerPool is. There is a quick mention in the abstract, but the document should be complete without the abstract. The introduction needs some references. (Actually, as far as I can tell the entire document is devoid of references.) Section 1.1: Definitions for internal agent and external agent would be helpful. Section 2.1.2: The first sentence is a sentence fragment. This occurs in many of the Effect sections--I am not going to repeat this comment each time, but please proofread for this. The RFC Editor will probably fix it, but it's always nice to save them work. Section 2.2.2: The attack is characterized as a DoS. The described attack allows data interception, which makes it a lot more than a DoS attack. Section 2.3.2 s/hacker/attacker (throughout the document.) Section 2.3.3 This section needs more discussion. Is it possible for an authenticated PE to send misinformation about another PE? Is this also an authorization issue? Section 2.4.3: Authorized to do what? I can infer that from the previous section, but the requirement should be explicit. Section 2.5.3 Is this really just an authentication issue? Is it enough to know the identities? Are there authorization decisions here? Section 2.5.3: What does the attacker need to do to accomplish this attack? Section 2.6.3 Is this advice to the implementor? If so, the document should describe what mechanism to use to authenticate the server. Or is the intent to say that the RSerPool protocol does not provide such a mechanism and needs to do so? Section 2.8.3: Same question about mechanism as in my previous comment. Section 2.9.1: I do not know the RSerPool details, but I would assume that if PE A could take over for PE B for a given user, the user would have to have the same trust relationship with PE B as for PE A. Is the point of this section to say that RSerPool does not require this and should? Section 2.9.2: The Effect section seems to simply restate the Threat section. What are the actual consequences of the attack? Section 2.9.3: Are you saying that RSerPool fails to give tools so that a user can establish the correct trust relationships with the new server when failing over and needs them? Or do you mean to say that implementation should use certain tools to do this? If the second, please call out the mechanism. Section 2.10.1: Is this one threat, or three different threats? 2.10.2: What are the consequences of corrupt information in this case? 2.10.3: Section needs more specifics. Which interfaces need integrity mechanisms? I can probably infer that from the Threat and Effect sections, but a requirement should state it explicitly. 2.12.-1 and 2.12.2: The organization of these sections is confusing, and not consistent with that of the earlier sections. It is not clear to me how the effects line up with the threats. That is, is effect a. related to threat a., or is it related to all listed
Re: IETF Last Call for two IPR WG Dcouments
Thanks Ray, that is reassuring. I don't think this decreases the need for the -outbound document to be as clear as possible about what the IETF needs are, though. /Simon Ray Pelletier [EMAIL PROTECTED] writes: In their April 3, 2008 meeting, the IETF Trustees discussed the outbound-IPR document, and found no issues with the advice given in the document. More specifically, the Trustees intend to invite comments from the community, via the ietf discussion list, prior to issuing any new licenses. The comment period(s) will begin as soon as proposed text for licenses have been drafted or selected. The Trustees will not make any final decisions on licenses stemming from the outbound-IPR document until after taking the communities' feedback into account. For the Trustees, Ray Pelletier Trustee Ted Hardie wrote: I agree with Joel. We're trying to give instructions to the Trust that cover the broadest possible user base; calling out specific licenses or user bases either appears to privilege them or adds no value at all. Suggesting to the Trustees that they consider specific licenses or, even better, pointing their lawyers at the potholes others have hit would be very useful. But this draft is not the place to do it. I believe the document is the place to do it. This is the only document were the IETF explains how the Trust should write its outgoing software license for code in RFCs. Useful considerations for that process should go into the document. My proposed text does not suggest specific licenses. That is a misunderstanding. Simon, The list of potentially useful considerations in this arena is both long and ever-changing. Imagine, for a moment, that I suggested that the Trust survey the legal departments of every organization which had sponsored a nomcom-eligible participant in the IETF over the past 3 years asking, if the proposed license was usable by their organization. In some lights, this is a pretty reasonable suggestion. These are organizations with a demonstrated interest in our output, and surveys can be a useful tool even when response rates are low. Why not confirm that we are meeting the needs of core participants? The answer, basically, is that we want the output to be usable by anyone, and privileging the people who pay kind of misses the point. We are giving instructions to the Trust to do the best job they can in making sure that the output is usable by anyone for any purpose, no matter whether they belong to group A, group B, or won't know for many years that they'll have an interest at all. As for how to get in touch with them, trustees of the trust are the IAOC. The IAOC's membership is listed here: http://iaoc.ietf.org/members_detail.html I am sure they will listen carefully to your concerns and will consider the issues you raise. regards, Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Proposed Revisions to IETF Trust Administrative Procedures
--On Tuesday, 08 April, 2008 16:30 -0400 Ed Juskevicius [EMAIL PROTECTED] wrote: ... The above being said, it is quite clear from the excellent comments posted by several people on this topic that the Trustees have more work to do before the job of revising the text on the Administrative Procedures document is done. For example, John Klensin commented on some of the text in paragraph 12 that says If at any time the IAOC ceases to exist, the Trustees then in office shall remain in office That text is not new nor a proposed change to any existing Trust procedure. Those words are original text from December 2005. I am happy John took note of them in this round of discussions, as I don't think they exactly express what the Trustees intended for this clause to say. ... Ed, Both the IAOC and then the Trust were conceived and defined on the assumption that they were to isolate administrative functions and thereby relieve not only the IESG and IAB but the community from having to monitor them in detail. Speaking only for myself, I've been following that assumption, trusting you folks to do what needs to be done and to do so within the parameters and procedures laid out in the defining documents. While I'm certain there was no malice involved, I find it deeply troubling that a note that was supposed to be about something else turned up original text in a procedures document that is inconsistent with one of those defining documents, the Trust Agreement. I hope it doesn't add significantly to the workload, but I hope the IAOC will its practices for verifying consistency between its procedures and actions (and those of the Trust) and those defining documents. john ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Random Network Endpoint Technology (RNET)
My name is Chad Christopher Giffin. My nickname is (typo). I have been a member of the internet community since 1994. The following posting is a proposal for a protocol that would allow anonynimity to a user on the internet. Please evaluate the proposal and provide any and all feedback. -- Random Network Endpoint Technology (RNET) RNET provides anonymity to those who need it. To wit: one is assigned a static IPV6 address (out of a block of IPV6 addresses set aside for this purpose, possibly a subnet for this purpose.) The assigned address may only be communicated with by hosts that it the assigned address initiated contact with. Routing to this address is setup by the RNET Host by first having transmitted an RNET Route Request, with encrypted component (by the RNET Global Key), direct to the Target Host (The host with which it wishes to communicate with.) All routers in between the RNET Host and the Target Host verify the key used by the RNET Host generating the request. If the key is found to be valid, the route is added to the routers' route table. RNET Route Entries are comprised of RNET Host Address, Target Address and (per individual router) Gateway Address. They also include a Route Decay. An RNET Route allows ONLY traffic between the RNET Host and the Target Host. Upon instantiation of an RNET Route, a Route Decay timer is assigned to the RNET Route entry in the routing table. This timer is reset upon each reception of a packet upon this route path. If the timer expires, the RNET Route entry is discarded. Two errors may occur: (1) The RNET Host has used an invalid key, or (2) the RNET Host requested a route entry that conflicts with a previously made route entry. Error 1: If an invalid key is detected, an error message of INVALID KEY is sent to the RNET Host. Any routers in the path of that error message (that obviously supported the route registration) have their RNET Global Key invalidated. Each othese routers will discard the RNET Route entry. Error 2: If a conflict is found in RNET Route entries, an error of DUPLICATE ROUTE is generated. It is transmitted to the RNET Hosts involved in the incident. All routers between the router that generated the error and the RNET Hosts involved in the incident (including the router that generated the error) will drop any and all routes for the RNET Host address. A packet will be transmitted to the RNET Centralized Server that details the RNET Host Address, Target Address and Gateway Address by any and all routers who receive or generate a DUPLICATE ROUTE error. THIS ERROR IS CONSIDERED SERIOUS: The result is that the RNET Centralized Server will initiate a cascade reaction in the network resulting in the invalidation of the RNET Global Key. This is accomplished by having the RNET Centralized Server send an INVALID KEY message to any and all connected routers. Each router that receives an INVALID KEY error is to forward such error to any attached routers (with exception to the one it received the error from.) The result is simple. All routers will eventually received the propagated INVALID KEY message. All routers will invalidate their RNET Global Key. A router or RNET Host that receives an INVALID KEY error message is required to contact the RNET Centralized Server to acquire the newly generated RNET Global Key. All members of RNET, be they a router or host are registered with RNET. They each have an individual key used to confirm their identity. Each member of RNET has his name, key and contact information registered with RNET. RNET Global Keys will only be given to RNET members who can be verified. All RNET Hosts will be allowed to generate RNET Route entries to the RNET Centralized Server wether or not they have the valid RNET Global Key. (This allows all RNET Hosts to acquire a key. Without this exception, an RNET Host would not be able to communicate with anyone.) All DUPLICATE ROUTE errors and the Global Key changes they incur result in an email being sent to all RNET Members (Routers and Hosts) that detail the date, time, RNET Host address, Target Address and all gateways involved. It is expected that all members in RNET cooperate and participate, where required, to assist in the detection of any entity who attempts to hijack an RNET Host address (the only reason why a DUPLICATE ROUTE error would occur.) For this reason, all relevant information that results in a Global Key change is sent to all RNET Members. The following changes need be made to the IP Version 6 Protocol Logic, in routers, in order to impliment this technology: 1) encryption routines 2) recognization of RNET Route Requests 3) generation and recognization of RNET errors 4) routing table modifications NB: the RNET Host address may be stored in the host address of the route entry. The Target
Re: Proposed Revisions to IETF Trust Administrative Procedures
--On Tuesday, 08 April, 2008 14:25 -0700 Fred Baker [EMAIL PROTECTED] wrote: On Apr 8, 2008, at 1:14 PM, Leslie Daigle wrote: Giving the Trust a chair is at least a step towards acknowledging it as a separate organization (beyond instrument), and one could then examine whether the IAOC members are, in fact, the right people to populate it (for example). It certainly opens the doors to mission creep. Russ asked IAOC members to contribute. OK, here I am. It actually is a separate organization. It has separate meetings, separate minutes, and a separate membership - all trustees are IAOC members, and one certainly hopes that all IAOC members will agree to sign the form that makes them trustees, but that is not a requirement of IAOC membership. Specifically the chair of the trustees is *not* identified as the chair of the IAOC in the current procedures or in the trust - rather, meetings are convened by any trustee who happens to be present. Is that a problem? Well, it's not a big one, but it does seem odd. There are two logical ways to fix this. One is to identify the set of trustees with the IAOC - same committee, same chair, same meetings, same minutes. The other is to recognize the difference and decide that it's OK - the chair of the trustees might be the same as the chair of the IAOC but doesn't have to be, but leave the meetings, minutes, and committee separate as they are now. We chose the second, being the least change, and are suggesting it to the IETF community. Fred, I think I have to agree with where I think Leslie is headed here. Either the Trustees really are the IAOC members, with the separation merely being a formality required by the way the Trust was set up, or the Trust is a separate entity in fact as well as in legal theory. That same entity, plus or minus official roles and legalism model is your first logical way above and what I think the IETF thought it was agreeing to. If it is the second, then we should be having a discussion about whether the IETF wants a separate cast of characters, rather than making IAOC members automagically Trustees. More specifically, I may be missing something, but I can see only the following cases: (i) The workload of the Trust and IAOC combined has turned out to be larger than expected and has gotten too high. That is what I think Russ's note implies when he says ...faced with more work than usual. The IPR WG has placed a significant task on the IETF Trust. Yet, all of the usual IAOC activities need to go forward on the usual schedule If there aren't enough available cycles, then taking one of the same people and designating him or her as Trust Chair won't help with anything but (maybe) better knowledge about what is falling through the cracks. There still won't be enough cycles because no cycles have been added. If this is the problem, then we ought to be looking at a proposal to constitute the Trustees in some other way so as to bring in different people and more cycles, not a proposal to just pass some more titles around. (ii) There are enough cycles, but there is an organizational / tracking problem. Here I think I agree with Harald. If the problem is simply tracking, that is a secretarial task. Maybe the secretariat can do it. Maybe the Trust needs an Exec Director similar to the long-time IAB role of the same name. Note that either of those approaches would presumably add cycles and that the potential for conflict of interest if the Secretariat gets involved with managing the IAOC presumably does not exist with the Trust. But creating a Trust Chair who can track and advocate for getting work done on Trust issues while you also have a IAOC Chair who tracks and advocates for getting work done --done by exactly the same people-- on IAOC issues... well, I do not yet understand why that would be helpful. (iii) While functions differ, the two organizations are really the same. Nonetheless, there is a desire to create a new function and title here for reasons I, at least, still don't understand. For example, to the extent to which the Trust is separate from the IAOC, perhaps there is a need for a coordination role and that might require the two Chairs to sit down regularly and prioritize the work. But, if that is the plan, then the two Chairs take on real authority, which we have been assured that neither really has. So this case confuses me. john ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed Revisions to IETF Trust Administrative Procedures
John, On 2008-04-09 12:55, John C Klensin wrote: --On Tuesday, 08 April, 2008 16:30 -0400 Ed Juskevicius [EMAIL PROTECTED] wrote: ... The above being said, it is quite clear from the excellent comments posted by several people on this topic that the Trustees have more work to do before the job of revising the text on the Administrative Procedures document is done. For example, John Klensin commented on some of the text in paragraph 12 that says If at any time the IAOC ceases to exist, the Trustees then in office shall remain in office That text is not new nor a proposed change to any existing Trust procedure. Those words are original text from December 2005. I am happy John took note of them in this round of discussions, as I don't think they exactly express what the Trustees intended for this clause to say. ... Ed, Both the IAOC and then the Trust were conceived and defined on the assumption that they were to isolate administrative functions and thereby relieve not only the IESG and IAB but the community from having to monitor them in detail. Speaking only for myself, I've been following that assumption, trusting you folks to do what needs to be done and to do so within the parameters and procedures laid out in the defining documents. While I'm certain there was no malice involved, I find it deeply troubling that a note that was supposed to be about something else turned up original text in a procedures document that is inconsistent with one of those defining documents, the Trust Agreement. Let's expand the quotation from the current, unamended Trust procedures slightly: If at any time the IAOC ceases to exist, the Trustees then in office shall remain in office and determine the future of the Trust in accordance with the Trust Agreement. I agree there's a drafting error - it should say If at any time the IAOC ceases to exist, the Trustees then in office shall remain in office SOLELY IN ORDER TO determine the future of the Trust in accordance with the Trust Agreement. That was certainly the intent. Brian I hope it doesn't add significantly to the workload, but I hope the IAOC will its practices for verifying consistency between its procedures and actions (and those of the Trust) and those defining documents. john ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-mipshop-4140bis (Hierarchical Mobile IPv6 Mobility Management (HMIPv6)) to Proposed Standard
The IESG has received a request from the Mobility for IP: Performance, Signaling and Handoff Optimization WG (mipshop) to consider the following document: - 'Hierarchical Mobile IPv6 Mobility Management (HMIPv6) ' draft-ietf-mipshop-4140bis-02.txt as a 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 [EMAIL PROTECTED] mailing lists by 2008-04-22. Exceptionally, comments may be sent to [EMAIL PROTECTED] 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-ietf-mipshop-4140bis-02.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=15898rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
