Re: Important Information about IETF 76 Meeting Registration
Hi Alissa, At 08:04 01-09-2009, Alissa Cooper wrote: This entire thread is perfectly illustrative of why the IETF needs a privacy policy. Without one, it is entirely unclear how the data collected about IETF participants is used, disclosed and protected, whether that data is part of an experiment or not. While the supplemental information about the RFID tagging experiment (http://www.ietf.org/meeting/76/ebluesheet.html ) is helpful, it is not complete (for example, how long the RFID- captured data is stored in electronic form is not disclosed), and nothing equivalent exists (to my knowledge) for other kinds of data about IETF participants, like registration data. From the above webpage: - The data will be printed and archived along with the paper blue sheets - The data will NOT be distributed to anyone other than the IAOC, IAD, the Secretariat and the host team that is organizing and supporting this experiment - The data will be available for use if subpoenaed It summarizes the use of the data after the meeting. There is already a retention policy document and it may contain the answer to your question. I don't have any concerns about this experiment. In our protocol development work, many of us try very hard to design privacy and security features in from the outset, whether we're designing a highly experimental prototype or a core protocol. The same should be true for the design of data collection mechanisms and practices associated with IETF meetings. You asked a similar question about a privacy policy a few weeks ago. As we talking about IETF meetings, the question can be viewed from a different angle. One of the goals of the Internet Standards Process is openness and fairness. Participation in the IETF is open, i.e. anyone can join in. We can already find out who are the contributors in a Working Group as there are open discussions on the relevant mailing list and there is a publicly accessible archive of the discussions. The Working Group sessions (at a meeting) are not that different. Everything a person says in a Working Group session is not private. For the process to be transparent, the list of individuals that are there also should not be considered as private. In practice, the IETF offers you a some leeway. Nobody will coerce you to sign the attendance list. If you are going to the mic, you do have to identify yourself. If you have any other concerns, please read the messages posted by Doug Ewell and Tony Hain on this thread on how to restrict what information is collected about you. A list of session attendees is useful for: (a) capacity planning (size of the meeting room to accommodate the number of participants) (b) catering (c) session scheduling (d) cross-area participation The Area Directors and Working Group Chairs might have a rough idea about item (d). The IETF can gain a better view of (d) if the information is collected in electronic form. I'll comment on Steve Crocker's questions: (i) Do we need access controls on the information? If the electronic process mimics existing practices, it is easier to publish the information. That is already done for the meeting attendees list. Note that this model may not be appropriate for other organizations. (ii) Do we need an ability to edit information that's been collected if it's inaccurate? The meeting registration form has a field for the Name to appear on badge. That can be used throughout the meeting. The Working Group attendance collected during the session can be verified by the participants in the room. Set up a procedure where they can contact the IETF Secretariat to correct any errors they find. (iii) Do we need more flexibility in the information stored in the record, e.g. a distinct email address for each working group? Some people prefer not to provide an email address (see bluesheet spam discussions over the last few years). Some people may be using a distinct email address for each working group for ease of sorting or filtering. Provide the ability for the participant to edit the email address. It is better not to publish these email addresses to avoid rehashing the spam discussions. At 07:10 01-09-2009, Dave CROCKER wrote: An important datum in human studies is how humans react to things. Taking such a dismissive stance towards reactions to the RFID announcement ensures missing important information about acceptability to the target population. Agreed. It is useful to know how many participants opted out of the experiment and why they did so. For example, was it because there was a misunderstanding about how the experiment works or what information is collected? It is better to address this informally instead of having a form asking the person why they are opting out. I avoided the question of proximity tracking and the time the participant spends in a session as my comments on items (i) to (iii) would be
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
All, I value the independence of the Independent Submission stream and IRTF Stream from the IETF (including the IESG). Indeed, both the RFC series and the acceptance of independent RFCs long pre-date even the existence of the IETF. I prefer that the IESG NOT have or assert the authority to mandate additions to Independent Stream or IRTF Stream documents. The existing approach where the IESG MAY request an IESG note is more than sufficient for cases where a non-IETF document is making an end-run around the IETF standards activities. We have lots of operational experience that this works well enough, so there is no obvious reason for the current approach to change. Robert Elz's notes from earlier today on this topic seem sensible, as do Joel Halpern's notes on this topic over the past several days. Yours, Ran Atkinson r...@extremenetworks.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Tuesday, September 01, 2009 16:37 +0300 Jari Arkko jari.ar...@piuha.net wrote: Robert, the IESG should not be making any kind of technical review of independent submissions Right, and we are not. - the reason the review was even permitted ... was to allow work that was submitted independently but which was directly in the same area as IETF work to be merged, and all considered together. That is indeed the primary goal of the 3932 and 3932bis. I.e., promote independent work, but allow a check in the exceptional case that it collides with IETF work. And that is, again, the answer to the question you raised. In the context of Headers and Boilerplates, the stream is identified. Many will pay attention or learn to do so. Others will not, but, for them (regardless of their motivation), there is no evidence that notices in obvious front-matter boilerplate will be noticed either. If members of the IESG have technical issues with a document, let them raise them as interested, skilled, and persuasive individuals as both the current and proposed revised versions of 3932, and your comment above indicate that they should. If they have major philosophical disagreements, let them write critical commentary, with explanations and details, and see if they can get them published as RFCs. Independent of their ability to use the IETF Track to self-publish, I have never, in the history of the RFC Series, seen the RFC Editor turn down a competently written and clear criticism of another document -- IMO, in the last decade or two, there have been far too few such submissions. Conversely, independent of technical substance, if the document is not clear enough about what it is --from the text-- tell the RFC Editor (ISE) and thereby promote a discussion with the authors about changes to make the document more clear. If the ISE ignores that advice, we quite frankly have a more serious problem. But I've never, and I mean never, seen that happen. To rephrase what others have said, attaching derogatory notes without explanations or specific attribution is the act of lazy people who either cannot or will not take responsibility for making document-specific comments that can either be attributed to those making them or that have been through enough process to represent IETF consensus. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and theoptional/mandatory nature of IESG notes
Original Message - From: John C Klensin john-l...@jck.com Sent: Monday, August 31, 2009 4:33 PM --On Monday, August 31, 2009 16:29 +0300 Jari Arkko jari.ar...@piuha.net wrote: I would like to get some further input from the community on this draft. ... And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. a) is my preference. I am not persuaded by references to history, that the RFC Editor function came first - cuckoos do take over nests (not that the IETF is a cuckoo:-) I do think it is a question of checks and balances, that being able to submit and have reviewed an RFC, independently of the views of the current IESG, is a valuable outlet for ideas and not one I want to see compromised. John, below, outlines an appeal mechanism which allows the IESG to take the issue to the IAB should it consider that justified and, assuming you agree that that is possible, then I see no case for anything other than a) Tom Petch Jari, I've said this before, but not during the recent Last Call, so, to get a note on the record... Any IESG note or comment, exceptional or otherwise, has always (always == since the IESG was created and long before it started writing notes) been an recommendation to the RFC Editor. That position is reflected in long-term precedent, in RFC 4844, and in the new RFC Editor Model document. Under the new model, should the RFC Editor decide to not accept a proposed IESG note, the IESG can raise the issue with the RSE and, if necessary, with the IAB, presumably causing a wider community review of the proposed note itself. That level of protection (which goes beyond that historically available) should be both necessary and sufficient for the IESG's purposes. Procedurally, should the IESG wish to change that position, I believe it would require the approval of the IAB (because it changes the RFC Editor role and relationship) and a review of the Headers and Boilerplates document, the RFC Editor Model document, and perhaps some of the statements of work associated with the new RFC Editor contracts and appointments. I have reason to believe that the IAB would insist on community review before granting such approval, so trying to change things in this area at this late date is not consistent with rapid progress and may be inconsistent with having a fully-functional RFC Editor function in place at the beginning of January. More broadly, as the community has discussed extensively, the IESG should not have the right to deprecate or denigrate the contents of any document from another stream without broad community consensus. Nothing in any community-approved IETF procedural document from RFC 2026 forward gives the IESG such authority (or authority for doing much of anything else other than steering/managing) without community approval and consensus. Even the claim in the original version of 3932 that a document has not been reviewed in the IETF is inappropriate unless such review has actually not occurred (whether or not consensus was reached). So I believe that your clarifying change was, in fact, editorial and that it should remain. ... regards, 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
Re: Current ietf e-mail delays
Stefan, If you find out what's up I'd be curious to know what the issue is/was. My delays are in the more range over the last couple of days. spt Stefan Santesson wrote: I and others have experienced unusually long delays from posting messages to various ietf mailing lists lately. 4-5 hours delivery time or more is not uncommon. Anyone else having the same issue or any idea what the problem is? /Stefan ___ 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Russ, I think that it is absolutely critical that the IETF be able to attach a note to an RFC and that this note not simply be a recommendation. We can believe all we want that the IETF stream is just one stream and that all other streams are independent. However, the RFC process is very tightly tied to the IETF, and I think it is reasonable for the IESG to be able to raise a note in an exceptional circumstance. I believe that this serves as an important check on the independent stream, just as the independent stream is supposed to serve as an important check on the IETF stream. Part of my thinking is motivated by my belief that the IETF has more structures in place and a broader community of people reviewing its work than the independent stream. I fully understand that there are people who are involved/interested in the independent stream who are not involved in the IETF. I believe that independent+ietf is a broader community than IETF alone. (We assume that it is a significantly broader community; I've never been given data to back up that assumption, but I'm happy to hold it for the moment.) However I doubt that community is sufficiently broader that it should be able to overrule the IETF. Even if the community was sufficiently broader, I'm still not sure that I would be comfortable with it being able to overrule the IETF of a comment that the IETF wanted to place on an independent stream document. However, the IESG is not the IETF. I'd personally be happy to ignore that and assume it would all work out. I'd also be happy with a mechanism where the IESG could propose a note, and the RFC editor had the option of accepting the note or asking the IESG to last-call its note within the IETF community. I would not consider it acceptable if the note were purely advisory. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Tuesday, September 01, 2009 09:55 +0200 pasi.ero...@nokia.com wrote: Joel M. Halpern wrote: If the ISE / RSE is unreasonable, the IAB will slap the editor and say stop doing that. There is no equivalent process if we reverse the structure. Yes, there is. If the IESG would request/recommend a particularly bad IESG note, this decision can be appealed just like any other IESG decision. The IAB would then determine if the IESG acted appropriately or not. On the other hand, if the ISE/RSE decides to publish a document without an IESG note even if the IESG requested/recommended it, this decision cannot be effectively appealed (since the RFC already came out, and can't be really recalled). Although I'm not expecting this really to happen very often (if ever), from checks-and-balances viewpoint I would support (b) from Jari's email (in other words: RFC Editor cannot unilaterally ignore a note requested by IESG, but has to take it to the IAB via the usual appeal procedures). Pasi, A comment and then a suggested middle position. I've been watching what we now call the Independent Submission Process for far longer than there has been an IETF. I've seen it as an insider for a large fraction of two decades -- as an AD, an IAB member and then chair, as an editorial board member, and now as an IAB member again. During that period, I've never seen an RFC Editor abuse the process by ignoring legitimate input. Bob Braden may be able to provide an inside view --not in his present role of RFC Editor but as the very-long-time IAB Exec Director -- of what happened before 1992, but my educated guess is that instances of RFC Editor ignores input during that time were also about zero. During the same period, I'd seen behavior I consider abusive from ADs or the IESG many times -- attempting to prevent publication of documents with which they had personal/ emotional disagreements that they were unwilling or unable to explain in public, asking for publication holds on documents for multiples of years, insisting that the RFC Editor not move forward until the IESG responds in some way and then not responding for months and months, demanding changes that would significantly weaken the document or change its meaning, and so on. Many of those problems have been resolved by negotiation, but some have not. RFC 3932, and its limitation on technical review, was a huge improvement over its predecessors in that regard, but we've heard multiple ADs over the years claim that they can redefine any disagreement about a document into either a technical issue or a technical one (whichever is needed) if they care enough and especially if they can define the boundary (which they also have insisted that the IESG has the unilateral right to do). In principle, the IAB could appoint a new ISE to take over in January who would adopt a policy of abusiveness. But I think I can speak for the ACEF membership and the IAB if I say that we don't intend to do that... and that the IAB would expect the RSE to move fairly quickly, with the IAB's backing, to correct the attitudes involved if it occurred anyway. So trying to make IESG notes mandatory on documents originating in another stream for the reasons you cite above is solving a problem we've never had at the risk of making a problem worse that we've had several times. That strikes me as bad engineering at best. And insisting that the RFC Editor invoke a formal appeals procedure in case of disagreement with the IESG about an Independent Submission would, as Olaf points out, largely undo the efforts of the last few years to clearly separate the different streams. It would be as sensible to say that IESG notes should be sufficiently exceptional that the IESG would need to consult the IAB and get permission before sending any such note-request to the ISE. I suspect that such a provision would not make either the IESG or the IAB very happy. However, if your concern is really to make sure that there is a timely appeal path, I have a suggestion that might be acceptable to everyone without causing unfortunate side-effects. We simply require that, if the ISE receives input from the IESG requesting specific changes to a document (specific changes including, but not limited to, so-called IESG Notes) and the ISE and authors decide to not incorporate those proposed changes, the ISE is required to explain to the IESG, in writing, why not and allow a reasonable period of time for the IESG to respond. If it felt it were necessary, the IESG could then open a further discussion, ask the RSE to mediate, or launch a formal request for IAB review. Consistent with other provisions in RFC 4846, either the IESG or the ISE could, at their discretion, make the correspondence (the request and response) public. The one restriction I'd impose on this is that reasonable time not be more than a few weeks... again, there has been abuse in that area in the past and re-enabling such abuse
Re: Last Call: draft-turner-deviceowner-attribute (Device OwnerAttribute) to Informational RFC
Andrew, Thank for taking the time to review the draft. Responses inline. spt Andrew Sciberras (GMAIL) wrote: Hello I have a few minor comments: 1. The definition of the deviceOwner attribute in section 2 indicates: IDENTIFIED BY id-deviceOwner This should be updated to reflect the text in Appendix A: IDENTIFIED BYid-aa-KP-deviceOwner I'll update the oid name. 2. The ASN.1 definitions (section 2 and appendix a) of DeviceOwner contain the following: numericCountry INTEGER ( SIZE (0...999), The ASN.1 (X.680) notation for a range separator is .. rather than an ellipsis. The syntax of the numericCountry choice should be changed to this: numericCountry INTEGER ( SIZE (0..999), As somebody else pointed out SIZE constraints can't be applied to INTEGER. It needs to be numericCountry INTEGER (0..999). 3. The matching rule is defined to be: This rule returns a TRUE if and only if the DeviceOwner value exactly matches the presented value. By exactly do you mean that case is sensitive for the Printable Strings? I.e. AU will not match au? Yes that's what it means. But now that you ask I think something like caseIgnoreMatch The rule returns TRUE if the strings are the same length and corresponding characters are identical except possibly with regard to case is probably more appropriate. 4. The ID indicates that no IANA considerations are required since the identifiers are already registered. It would be preferable if the attribute type and matching rule definitions were registered with the IANA LDAP descriptors registry. After some discussions with Kurt Zeilenga, I think we're not going to register the attributes. I originally thought we could just say something like the attribute could be used here, there, and everywhere an attribute can be used. I was unaware of the hoops to jump through to claim that it could be used in LDAP. I think it could be used in an LDAP directory but we're going to target these attributes for public key and attribute certificates. If we end up needing to include these in a directory, then we'll update this spec to add the required text to put them in a directory (schema, transfer syntax, etc.). I'll modify the intro to say this: This document specifies the Device Owner attribute. This attribute may be included in locations or protocols that support ASN.1 attribute definitions to indicate the country or group that owns the device. NOTE: This document does not provide LDAP equivalent schema specification as this attribute is targeted at public key certificates [RFC5280] and attribute certificates [RFC3281bis]. This is left to a future specification. Regards, Andrew Sciberras -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Friday, 31 July 2009 9:52 PM To: IETF-Announce Subject: Last Call: draft-turner-deviceowner-attribute (Device OwnerAttribute) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'Device Owner Attribute ' draft-turner-deviceowner-attribute-01.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-28. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-turner-deviceowner-attribute-01.t xt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=177 56rfc _flag=0 ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John == John C Klensin john-i...@jck.com writes: John However, if your concern is really to make sure that there John is a timely appeal path, I have a suggestion that might be John acceptable to everyone without causing unfortunate John side-effects. We simply require that, if the ISE receives John input from the IESG requesting specific changes to a John document (specific changes including, but not limited to, John so-called IESG Notes) and the ISE and authors decide to John not incorporate those proposed changes, the ISE is required John to explain to the IESG, in writing, why not and allow a John reasonable period of time for the IESG to respond. If it John felt it were necessary, the IESG could then open a further John discussion, ask the RSE to mediate, or launch a formal John request for IAB review. Consistent with other provisions in John RFC 4846, either the IESG or the ISE could, at their John discretion, make the correspondence (the request and John response) public. John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. Sam, If you have a specific complaint about the functioning of the RFC Editor, please bring it out on the rfc-interest list. I don't know what kind of abuse you think we are open to, but I would certainly like to hear it. Bob Braden I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. ___ 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: Non-smoking rooms at the Hiroshima venue?
Hi all, On Tuesday 01 September 2009 19.30.04 Michael StJohns wrote: As of today, I was only able to book a twin room SMOKING at 19,000y at the ANA - there are no singles at the lower rate. [snip] Could you also comment on the mix of rooms that the agreement covers? E.g. how many singles, doubles, etc? I find it problematic that less than 18 hours after registration opens, we're already out of the lower cost rooms and the non-smoking rooms. Sigh. Problematic... yep. Shoulda booked a smoking room yesterday :-( I'll let Alexa and team see if this is going to be the way it is or if we can get more small rooms. The difference in price is non-negligible. Cheers, David ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
RFC 5620 calls for the appointment of an RFC Series Advisory Group, to be appointed by the IAB, and a Independent Submissions Stream Editorial Board (ISSEB for now), which serves at the pleasure of the ISE. This was reviewed and approved by the community. I presume with cognizance of the existing rules about the authority over the Streams. I presume you are concerned about the membership of the ISSEB. Given that this stream is specifically not an IETF stream, I do not see why it would make sense for the membership to be appointed by the IETF community, through its nomcom designates. With regard to appeals, are you asking for an ability to appeal an IAB decision about the RFC Editor? Presumably, a procedural appeal could be made to the ISoC Board of Trustees, if the IAB had not followed documented procedures. But otherwise, we are back to the issue of undermining the Independence of the Independent Stream. Remember, all of these documents are Experimental or Informational. Yours, Joel Sam Hartman wrote: John == John C Klensin john-i...@jck.com writes: John However, if your concern is really to make sure that there John is a timely appeal path, I have a suggestion that might be John acceptable to everyone without causing unfortunate John side-effects. We simply require that, if the ISE receives John input from the IESG requesting specific changes to a John document (specific changes including, but not limited to, John so-called IESG Notes) and the ISE and authors decide to John not incorporate those proposed changes, the ISE is required John to explain to the IESG, in writing, why not and allow a John reasonable period of time for the IESG to respond. If it John felt it were necessary, the IESG could then open a further John discussion, ask the RSE to mediate, or launch a formal John request for IAB review. Consistent with other provisions in John RFC 4846, either the IESG or the ISE could, at their John discretion, make the correspondence (the request and John response) public. John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-klensin-iaoc-member-00.txt
--On Tuesday, September 01, 2009 18:06 -0400 Leslie Daigle les...@thinkingcat.com wrote: I'm having troubles reconciling a couple of things: 1/ Recent discussion (different draft) on the importance of the IAOC implementing IETF (and IAB) policy and admin requirements; not having the IAOC *setting* those requirements; 2/ Suggesting that the IAB IETF Chairs should not be on the IAOC. Leslie, Let me try a little different perspective on this because I see both different issues and a more complex set of tradeoffs than your note implies. First and most important, the draft doesn't say the IETF and IAB Chairs cannot serve on the IAOC. It eliminates that function as a _requirement_ of their roles. If the people holding those positions, in conjunction, respectively, with the IESG or IAB conclude that the Chairs have the time to do the job well and are, in your words, in a unique position..., then nothing prevents them from _deciding_ to preserve the status quo. The problem is that we are turning those roles into full time (or more) jobs. I believe the IETF Chair role has already passed that point and that the IAB Chair one is rapidly moving in that direction. That is not, IMO, healthy for the IETF because, while we may get lucky sometimes, in general people who can take on full-time-or-more, IETF-uncompensated, IETF roles are different from those of us who need to perform day jobs while doing IETF work in whatever fractional time, or spare time, is available. Requiring that the roles be full time reduces the number of possible candidates, which reduces Nomcom choices, etc. It also tends to reinforce all of the trends that lead to isolation of the IESG and IAOC from the community (I'll avoid explaining that hypothesis at length unless it becomes necessary). And the document explicitly allows the IAB and/or IETF Chair to sit in on IAOC meetings and teleconferences if (i) the IAB or IESG decide to appoint someone else to the more permanent positions (people who are expected to participate actively and consistently) and (ii) the relevant Chair decides, possibly on the advice of other IAOC members but without any requirement for IAOC consensus agreement, that attendance when a specific matter is being discussed is important. So the only differences between what you are arguing and what the document suggests are: -- You apparently think that the participation in the IAOC and Trustees of the two Chairs is so important --always-- that, if time is limited, they need to put those responsibilities ahead of everything else. The document proposes to let the individuals involved and the bodies on which they serve make that decision in a way that best serves the community and to review it as they deem necessary. -- While I certainly agree that there are some issues that will come before the IAOC and/or Trustees in which the direct involvement of one or both Chairs is important, I don't believe that is true of every discussion and every decision. Again, I think that decision should be left to the relevant individuals (who are free to look at IAOC or Trustee agendas and decide to sit in), to the relevant bodies, and to the IAOC (who can always specifically invite participation in a particular discussion), while your position effectively takes those decisions and turns them over to an organizing document. -- Conversely, some decisions and discussions of the IAOC and Trustees may involve topics for which the the IETF and IAB Chairs are neither particular qualified or particularly interested. Certainly Nomcoms are not considering in-depth financial planning skills or great experience with IPR issues (or interest in either) as primary considerations in selecting IETF Chairs or IAB members (and I would hope that they would continue to avoid doing that). Again, it seems to me to be better to let the incumbents in those roles sort out the tradeoffs and best choices with their respective bodies than to force a choice in the organizing documents. Having people in the IAOC and Trustee positions who want to do them and have the bandwidth to do so should strengthen those bodies (whether those people are the Chairs or not), rather than risking having a disinterested Chair serving because it a job that cannot be escaped. Finally, and I believe that the above arguments stand whether or not you believe this (and the choice is up to the IESG and IAB in any event), I have trouble accepting the unique position argument until we believe that those two people are serving on the IAOC/Trustees as individuals with no obligation to consult with the relevant bodies. I don't read BCP 101 as contemplating that and would find it extremely problematic if interpreted that way. If they are actually expected to represent the perspectives of the IAB and IESG, as I believe, then the Chairs aren't inherently more uniquely qualified than any other member of those bodies or, in principle, a non-member liaison who maintains a
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Sam, On 2009-09-03 05:53, Sam Hartman wrote: ... 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole I'm certainly in favour of transparency in the process of setting up the Independent stream's editorial board. I could see value in an open call for nominations. However, you're asking for it to be set up in way that's very different from the typical editorial board for a scholarly journal or the typical technical programme committee for a scholarly conference. It seems to me that the editor needs to have the final say in the membership, because s/he needs to be able to work well with all the board members. Also, I have no idea how to define the community for the Independent stream. ISOC members? RIR members? ICANN community? ACM? BCS? IEEE? Where would it end? Brian N.B. I am a member of the current RFC Editorial Board, by invitation from the current RFC Editor. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi Peny, Thank you for reviewing this draft. Please see my comments below. Regards, Yaron -Original Message- From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of Peny Yang Sent: Wednesday, September 02, 2009 17:18 To: ietf@ietf.org Cc: IPsecme WG Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard Sorry, I should cc IPsec mail list. Comments are sent again. Hi, floks: I have two comments on the draft of IKEv2 Session Resumption: 1) Sorry, I have to talk about my concern on the new IKE_SESSION_RESUME. In WG last call, actually I made this comment. However, no feedback was given, maybe because my comment was a little late for WG last call. So, I just copy it here again as a comment for IESG last call. Well, we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution is specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: - RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. - Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: - some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's an issue of implementation. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. [YS] I see the merits of extending IKE_SA_INIT to support resumption, and in fact an early version of our work did exactly that. But the working group gave us a clear direction to use a separate exchange, and this is where we disagree: I believe we did have a strong WG consensus that the implementation benefits of having a separate exchange (i.e. not overloading even more the non-trivial IKE_SA_INIT exchange) outweigh the benefits of the alternative. 2) Maybe I missed some discussions. There is the case: responder may receives a ticket for an IKE SA that is still active and if the responder accepts it. In one of previous versions of this draft, there once was some description on this case. [YS] I believe you are referring to the text now in Sec. 4.3.4. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. [YS] If I understand the scenario correctly, it is similar to an attacker repeatedly sending notifications to an IKE client, making it believe that the IKE exchange has failed and needs to be reinitiated. This attack against plain-vanilla IKE would be much more CPU-intensive to the client and to the (real) gateway, compared to repeated session resumption. Even when you factor in the cost of generating a new ticket. Moreover, the regular IKEv2 anti-DOS cookie mechanism is supported by IKE_SESSION_RESUME as well. BRG Peny On Mon, Aug 31, 2009 at 10:09 PM, The IESGiesg-secret...@ietf.org wrote: The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Session Resumption ' draft-ietf-ipsecme-ikev2-resumption-07.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 ietf@ietf.org mailing lists by 2009-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption- 07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17 990rfc_flag=0 ___ IPsec mailing list ip...@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ IPsec mailing list ip...@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. smime.p7s Description: S/MIME
RE: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
-- S7.2, paragraph 2: Since some mobility entities, e.g., local mobility anchor and mobile access gateway, are allowed to receive and possibly send a Binding Revocation Indication or Binding Revocation Acknowledgement for different cases, therefore, if IPsec is used to secure signaling between the local mobility anchor and mobile access gateway, it prevents any of them from processing a Binding Revocation message that was not constructed by an authorized party. I have trouble parsing this sentence. (You did not respond to this one.) [Ahmad] We basically wanted to say that since the MAG and LMA are both allowed to send BRI and receive BRA, IPsec will enable the peer to detect if a man in the middle, for example, reflected a BRI message that it has initiated back to the peer and consequently silently drop that BRI message. In the broader sense, we wanted to say that IPsec enables any of the peers to detect if the received BRI is coming from an unauthorized party and consequently ignore without processing it. I hope we got it right:) I think if you replace the .. allowed to receive and possibly send a Binding Revocation Indication or Binding Revocation Acknowledgement for different cases with ...allowed to send BRI and receive BRA, it would be easier to read. [Ahmad] Sure, makes sense. Thanks again for all the comments. Hopefully will get a new revision before the end of the week. Regards, Ahmad ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Please see inline. Regards, Ahmad -Original Message- I still have concerns about the use of IPSec, though, as without IPSec of some other form of authentication, an attacker could conceivably impersonate the node that bindings were associated with. This is particularly bothersome in use cases that allow a node to revoke bindings without having to know the details of each individual binding, such as the G-bit, or an included NAI of the form @example.com. I'm not saying that this draft needs to make IPSec into a MUST. [Ahmad] If it comes to me, I am comfortably fine with that:) But it is appropriate for it to point out that if you _don't_ use it, bad things could happen. (See my comment on that point further down.) It may be that using MIPv6 without IPSec is just as bad without BRI as with it--in which case it's fair to say that any attacks enabled by not using IPSec with BRI are no worse than using the base technologies without BRI. (Such statements are easier to believe with some discussion to support them, though :-) ) [Ahmad] When IPsec is used, the only issue that we identified that needs special attention was the Global Revocation with Revocation Trigger value Per-Peer Policy when sent from the MAG [because it deletes all sessions between the two peers]. Although, some people still disagreed that there is no great risk in there and no special treatment should take place. At any rate, since this message coming from a peer in the visited network, we wanted the home network to have the upper hand and be able to give specific privileges to peers in the different visited networks, i.e., MAGs. What this means? the ability to establish an IPsec SA between the MAG and the LMA does not give the MAG the automatic privilege to use Global Revocation with Revocation Trigger value of per-Peer Policy. That why we required authorization. Again, I'm looking for discussion on what the impact of choosing _not_ to use IPSec, since it is only required at a SHOULD strength. I think the answer to the similar point below helps. [Ahmad] Ok. More inline: On Aug 27, 2009, at 1:32 PM, Ahmad Muhanna wrote: Hi, Ben, -Original Message- Summary: This draft is on the right track, but there are open issues. Additionally, I have a number of editorial comments. Major issues: -- I think the security considerations need quite a bit of work. In particular, there is very little guidance on authorization for sending BRI messages. This seem to me have utility for DoS attacks, particularly with the G bit set. There is mention of reusing existing security associations if IPSec is used--but no mention of what to do if IPSec is not used. [Ahmad] Binding Revocation is used between two peers to revoke/terminate a mobility session(s) that have been created using an IPv6 mobility protocol signaling (Client Mobile IPv6 or Proxy MIP6). RFC3775 and RFC5213, which are the main protocols targeted by this specification, specify that IPsec SHOULD be used. On the other hand, there is NO other standard track specification which specify other security mechanisms to secure the IPv6 mobility signaling. Therefore, Binding Revocation specification assumes the use of whatever security mechanism that currently available to secure the IPv6 mobility signaling. I think there are still a couple of issues here. First, Since the underlying RFCs only specify IPSec at SHOULD strength, this draft needs to discuss the consequences of not using it for BRI. Depending on those consequences, it might be enough to just warn implementors that, if you don't use IPSec, certain bad things can happen. [Ahmad] It is NOT expected that BRI/BRA will use a different security mechanism than what is being used for securing IPv6 mobility signaling. Therefore, in order to alert implementors of the danger if IPsec is NOT used, IMO, that needs to be discussed in related IPv6 mobility specifications, e.g., RFC3775 and RFC5213, which is already there. On the other hand, it is very difficult to anticipate the criteria of other security mechanisms that would possibly be used in the future to secure IPv6 mobility signaling and consequently BRI/BRA. Sure--but it's appropriate for the BRI spec to say If BRI is used without IPSec, these bad things can happen in addition to the bad things that might happen if you use the base technology without IPSec. Or alternatively, The bad things that can happen with BRI without IPSec are functionally identical to those for the base technology, so the IPSec related security considerations are identical to those in RFC/). [Ahmad] We can add something similar to this. Thx. Okay, thanks! OTOH, it might be
RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Please see inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 On Sep 1, 2009, at 3:35 PM, Ahmad Muhanna wrote: [...] So is it true that using bulk revocation without IPSec could make it possible for an attacker to masquerade as an authorized party, and delete large numbers of bindings with a single BRI? [Ahmad] Well, we need to be a little careful here:) I think what you meant to say here is without any security mechanism. In particular, without an authentication mechanism. So, If no valid SA is being used to protect the binding revocation signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad things could happen. Right, and those bad things seem at least slightly worse with BRI than without it, due to the bulk revocation mechanism--so additional mention seems appropriate. [Ahmad] Will try to address this in the new revision. Hopefully, this week. Or there underlying architectural features that prevent or make this hard? [Ahmad] I am not quite sure what you mean by the underlying architectural features in this context. But I can say the following: If no security mechanism (SA) is being used, neither BU/BA nor BRI/BRA are allowed to be used for establishing nor revoking mobility sessions. Hmm--maybe this is all some confusion on my part. Somewhere I got the impression the requirement to use IPSec for BU messages was SHOULD strength. But in rereading RFC3775, I see it at MUST strength. But I am then confused by the language in this draft that says If IPSec is used... So, to close on this--do you consider the _use_ of IPSec for BRI to be a SHOULD or MUST? If it's a MUST, then I withdraw my comments about what happens if you don't use IPSec?, and apologize for the confusion. [Ahmad] As you mentioned, RFC3775 mandates the use of IPsec to protect BU/BA between the MN and the HA. However, RFC5213, Proxy Mobile IPv6, mandates the implementation of IPsec on the MAG and LMA. So, as you see it is not straight forward:) On the other hand, I understand what you are trying to say. Let me work with the authors on this and will share the security related text before publishing. I am sure we can come up with a text that reasonably address your concern while staying within the wg consensus. think just discussing that in the SecCon would go a long way towards addressing my concerns.) [Ahmad] I am in the process of rewriting the security section and the whole draft to address all comments. Will revaluate before publishing whether we need anything specific here. Okay. Thanks! Ben. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
HI--I think we're almost closed on this Part II --remaining comments below: On Aug 29, 2009, at 2:14 AM, Ahmad Muhanna wrote: [...] Does the potential guess-ability of a sequence number have security implications? [Ahmad] Not at all. Packet must pass IPsec authentication first. But remembering that IPSec is only a should, does that answer change if IPSec is not used? I guess the question is around what damage would be done if it was guessed. [...] -- S7.2, paragraph 2: Since some mobility entities, e.g., local mobility anchor and mobile access gateway, are allowed to receive and possibly send a Binding Revocation Indication or Binding Revocation Acknowledgement for different cases, therefore, if IPsec is used to secure signaling between the local mobility anchor and mobile access gateway, it prevents any of them from processing a Binding Revocation message that was not constructed by an authorized party. I have trouble parsing this sentence. (You did not respond to this one.) [Ahmad] We basically wanted to say that since the MAG and LMA are both allowed to send BRI and receive BRA, IPsec will enable the peer to detect if a man in the middle, for example, reflected a BRI message that it has initiated back to the peer and consequently silently drop that BRI message. In the broader sense, we wanted to say that IPsec enables any of the peers to detect if the received BRI is coming from an unauthorized party and consequently ignore without processing it. I hope we got it right:) I think if you replace the .. allowed to receive and possibly send a Binding Revocation Indication or Binding Revocation Acknowledgement for different cases with ...allowed to send BRI and receive BRA, it would be easier to read. [...] -- 4th bullet: unless an Alternate Care-of Address mobility option is included In which case you do what? [Ahmad] Thanks! It is a long story:) What it means here is the following: The destination IP address of the packet is set to the care-of address. However, if the home agent include an Alternate care-of address option in the BRI, the destination IP address MUST NOT be set to the care-of address. When the home agent is able to include an Alternate Care-of Address in the BRI? ONLY when the mobile node sends a BU message with the Alternate Care-of address included in the BU. If the MN include the Alternate Care-of address inside the BU, the source IP address of the packet carrying the BU is different than the IP address inside the Alternate Care-of address. NOW: It depends on the home agent implementation: 1. The home agent can send the BRI message to the care-of address regardless, if this care-of address received as the source IP address of the packet carrying the BU or inside the BU in the Alternate Care-of address option. 2. If the home agent saves the source address of the packet carried the BU in addition to the MN care-of address in the MN BCE, then the home agent can send the packet that carries the BRI message to the source IP address of the packet that carried the BU. 3. Depends on implementation of the home agent, the home agent may send the BRI to the MN care-of address all the time. The key point here is: If the HA include the Alternate care-of address inside the BRI, then the destination IP address of the packet carrying the BRI is set to the source IP address of the packet that carried the BU. Are all of those choices interoperable? [Ahmad] Yes. Okay. But in any case, I think you need at least some guidance. Right now, you have a conditional MUST without an else clause for that condition. A simple ..., in which case, the destination address SHOULD (or MAY) be set to something. [Ahmad] Here is the new text: o The care-of address for the binding MUST be used as the destination address in the packet's IPv6 header, unless an Alternate Care-of Address mobility option is included in the Binding Revocation Indication. If an Alternate Care-of Address option is included in the Binding Revocation Indication message, the destination address in the packet's IPv6 header SHOULD be set to the source IP address of the packet that carried the latest successful Binding Update with the Alternate Care-of address included. Okay, that helps. [...] Also, the language here sounds more like you are talking about the initiator. The responder validates these are true, but does not set the values, correct [Ahmad] True. Will reword it. [...] -- Bullet 5: Why not MUST? [Ahmad] Good question. Since the sub-bullets include the proper normative, I believe we can remove SHOULD and rely on the sub bullet normative text. o If the Global (G) bit is NOT set, the local mobility anchor uses the included mobility options to identify the impacted mobile node binding as follows: Hmm, I don't see any normative statement in that sub-bullet. (The all- caps NOT is in
Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ahmad, Comments inline. I deleted items I think we can consider closed. On Aug 29, 2009, at 3:21 AM, Ahmad Muhanna wrote: [...] I still have concerns about the use of IPSec, though, as without IPSec of some other form of authentication, an attacker could conceivably impersonate the node that bindings were associated with. This is particularly bothersome in use cases that allow a node to revoke bindings without having to know the details of each individual binding, such as the G-bit, or an included NAI of the form @example.com. I'm not saying that this draft needs to make IPSec into a MUST. [Ahmad] If it comes to me, I am comfortably fine with that:) But it is appropriate for it to point out that if you _don't_ use it, bad things could happen. (See my comment on that point further down.) It may be that using MIPv6 without IPSec is just as bad without BRI as with it--in which case it's fair to say that any attacks enabled by not using IPSec with BRI are no worse than using the base technologies without BRI. (Such statements are easier to believe with some discussion to support them, though :-) ) [Ahmad] When IPsec is used, the only issue that we identified that needs special attention was the Global Revocation with Revocation Trigger value Per-Peer Policy when sent from the MAG [because it deletes all sessions between the two peers]. Although, some people still disagreed that there is no great risk in there and no special treatment should take place. At any rate, since this message coming from a peer in the visited network, we wanted the home network to have the upper hand and be able to give specific privileges to peers in the different visited networks, i.e., MAGs. What this means? the ability to establish an IPsec SA between the MAG and the LMA does not give the MAG the automatic privilege to use Global Revocation with Revocation Trigger value of per-Peer Policy. That why we required authorization. Again, I'm looking for discussion on what the impact of choosing _not_ to use IPSec, since it is only required at a SHOULD strength. I think the answer to the similar point below helps. More inline: On Aug 27, 2009, at 1:32 PM, Ahmad Muhanna wrote: Hi, Ben, -Original Message- Summary: This draft is on the right track, but there are open issues. Additionally, I have a number of editorial comments. Major issues: -- I think the security considerations need quite a bit of work. In particular, there is very little guidance on authorization for sending BRI messages. This seem to me have utility for DoS attacks, particularly with the G bit set. There is mention of reusing existing security associations if IPSec is used--but no mention of what to do if IPSec is not used. [Ahmad] Binding Revocation is used between two peers to revoke/terminate a mobility session(s) that have been created using an IPv6 mobility protocol signaling (Client Mobile IPv6 or Proxy MIP6). RFC3775 and RFC5213, which are the main protocols targeted by this specification, specify that IPsec SHOULD be used. On the other hand, there is NO other standard track specification which specify other security mechanisms to secure the IPv6 mobility signaling. Therefore, Binding Revocation specification assumes the use of whatever security mechanism that currently available to secure the IPv6 mobility signaling. I think there are still a couple of issues here. First, Since the underlying RFCs only specify IPSec at SHOULD strength, this draft needs to discuss the consequences of not using it for BRI. Depending on those consequences, it might be enough to just warn implementors that, if you don't use IPSec, certain bad things can happen. [Ahmad] It is NOT expected that BRI/BRA will use a different security mechanism than what is being used for securing IPv6 mobility signaling. Therefore, in order to alert implementors of the danger if IPsec is NOT used, IMO, that needs to be discussed in related IPv6 mobility specifications, e.g., RFC3775 and RFC5213, which is already there. On the other hand, it is very difficult to anticipate the criteria of other security mechanisms that would possibly be used in the future to secure IPv6 mobility signaling and consequently BRI/BRA. Sure--but it's appropriate for the BRI spec to say If BRI is used without IPSec, these bad things can happen in addition to the bad things that might happen if you use the base technology without IPSec. Or alternatively, The bad things that can happen with BRI without IPSec are functionally identical to those for the base technology, so the IPSec related security considerations are identical to those in RFC/). [Ahmad] We can add something similar to this. Thx. Okay, thanks! OTOH, it might be that BRI has greater security risks than for 3775/5213, and you might (for example) need to strengthen the IPSec requirement for BRI. I admit to not being an expert on 3375/5213, so it may be
Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
On Sep 1, 2009, at 3:35 PM, Ahmad Muhanna wrote: [...] So is it true that using bulk revocation without IPSec could make it possible for an attacker to masquerade as an authorized party, and delete large numbers of bindings with a single BRI? [Ahmad] Well, we need to be a little careful here:) I think what you meant to say here is without any security mechanism. In particular, without an authentication mechanism. So, If no valid SA is being used to protect the binding revocation signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad things could happen. Right, and those bad things seem at least slightly worse with BRI than without it, due to the bulk revocation mechanism--so additional mention seems appropriate. Or there underlying architectural features that prevent or make this hard? [Ahmad] I am not quite sure what you mean by the underlying architectural features in this context. But I can say the following: If no security mechanism (SA) is being used, neither BU/BA nor BRI/BRA are allowed to be used for establishing nor revoking mobility sessions. Hmm--maybe this is all some confusion on my part. Somewhere I got the impression the requirement to use IPSec for BU messages was SHOULD strength. But in rereading RFC3775, I see it at MUST strength. But I am then confused by the language in this draft that says If IPSec is used... So, to close on this--do you consider the _use_ of IPSec for BRI to be a SHOULD or MUST? If it's a MUST, then I withdraw my comments about what happens if you don't use IPSec?, and apologize for the confusion. think just discussing that in the SecCon would go a long way towards addressing my concerns.) [Ahmad] I am in the process of rewriting the security section and the whole draft to address all comments. Will revaluate before publishing whether we need anything specific here. Okay. Thanks! Ben. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
I think we've got closure on all Part I issues, pending the actual text :-) Thanks! Ben. On Sep 2, 2009, at 1:12 AM, Ahmad Muhanna wrote: Hi Ben, Please see inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 On Sep 1, 2009, at 3:35 PM, Ahmad Muhanna wrote: [...] So is it true that using bulk revocation without IPSec could make it possible for an attacker to masquerade as an authorized party, and delete large numbers of bindings with a single BRI? [Ahmad] Well, we need to be a little careful here:) I think what you meant to say here is without any security mechanism. In particular, without an authentication mechanism. So, If no valid SA is being used to protect the binding revocation signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad things could happen. Right, and those bad things seem at least slightly worse with BRI than without it, due to the bulk revocation mechanism--so additional mention seems appropriate. [Ahmad] Will try to address this in the new revision. Hopefully, this week. Or there underlying architectural features that prevent or make this hard? [Ahmad] I am not quite sure what you mean by the underlying architectural features in this context. But I can say the following: If no security mechanism (SA) is being used, neither BU/BA nor BRI/BRA are allowed to be used for establishing nor revoking mobility sessions. Hmm--maybe this is all some confusion on my part. Somewhere I got the impression the requirement to use IPSec for BU messages was SHOULD strength. But in rereading RFC3775, I see it at MUST strength. But I am then confused by the language in this draft that says If IPSec is used... So, to close on this--do you consider the _use_ of IPSec for BRI to be a SHOULD or MUST? If it's a MUST, then I withdraw my comments about what happens if you don't use IPSec?, and apologize for the confusion. [Ahmad] As you mentioned, RFC3775 mandates the use of IPsec to protect BU/BA between the MN and the HA. However, RFC5213, Proxy Mobile IPv6, mandates the implementation of IPsec on the MAG and LMA. So, as you see it is not straight forward:) On the other hand, I understand what you are trying to say. Let me work with the authors on this and will share the security related text before publishing. I am sure we can come up with a text that reasonably address your concern while staying within the wg consensus. think just discussing that in the SecCon would go a long way towards addressing my concerns.) [Ahmad] I am in the process of rewriting the security section and the whole draft to address all comments. Will revaluate before publishing whether we need anything specific here. Okay. Thanks! Ben. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell)
Individual submission I-Ds that don't fall in the purview of a chartered WG do not require WGLC, only IETF Last Call, with a double-length IETF LC. Thus RFC5647 (AES-GCM for Secure Shell) was published with only IETF LC -- there was no WG in which to run a WGLC. However, there had recently (April 2009) been a lengthy thread on the old SECSH WG mailing list (Cc'ed) about this very topic. A heads-up should have been sent to that list. I do not subscribe to the IETF list (ietf@ietf.org), for the very obvious reason that its signal-to-noise ratio is too poor, thus completely missed the IETF LC of draft-igoe- secsh-aes-gcm -- but I would not have missed a heads up on the ietf-...@netbsd.org list! Let's fix the IETF LC for individual submissions process. My recommendations: - Whenever there is a concluded WG [whose list remains in operation] that would have been a suitable WG for WGLC of an individual submission I-D, had that WG not been concluded, then send a heads up to that old WG's list. - Establish a separate list for IETF LC, or even one IETF LC list per-area. This will improve the signal-to-noise ratio, and will encourage wider review of individual submission I-Ds. Incidentally, only two weeks ago I was asked by a Security AD to initiate a pseudo-WGLC in WGs whose scope my I-D was outside. I gladly complied. The situation there was analogous to, though not exactly the same as, the situation with respect to draft-igoe-secsh-aes- gcm (now RFC5647). Why could a pseudo-WGLC in the concluded SECSH WG list not have been used? It's entirely possible that the notion of a pseudo-WGLC only just came up, that it was too late for draft-igoe-secsh-aes-gcm. But even so, a notion of pseudo-WGLC is too informal; we need a better solution than hope the current ADs think of asking for a pseudo-WGLC (no offense meant to the current ADs -- I'm worried about future cases). Comments? Please follow up the above comments on the ietf@ietf.org list, Cc' me, and drop the ietf-...@netbsd.org list from the Cc list. All that said, I'm reasonably happy with RFC5647, but there are several issues that I think should have been addressed prior to publication: - Nit: we don't call SSHv2 connections tunnels. - Clarification: The initialization of the 'invocation_counter' and 'fixed' portions of the GCM nonce, and their semantics need more description. Specifically: - 'fixed' _appears_ to be the four left-most octets from the c-to-s or s-to-c IVs (one for each direction), while 'invocation_counter' _appears_ to be initialized to the eight right-most octets of the corresponding IV. This clarification seems obvious enough. - The 'invocation_counter' wraps around to zero, but if normalized to zero it is expected never to wrap to zero. This clarification seems obvious enough as well. - 'fixed' appears to be fixed per-_key exchange_, not for the life of the connection. This one, in particular, is a complete and utter guess on my part. These are not stated or not stated clearly. I will send e-mail to the authors and the old SECSH WG list to propose errata. - Also, a rather esoteric comment with respect to unencrypted packet lengths occurs: one could always use a variable-length encoding of packet length, padded to 32 bits with randomly generated bits. Of course, most implementations' actual TCP/IP packets would correlate with SSHv2 packet boundaries strongly enough, most of the time, that packet length would be visible regardless. And to be sure: I really don't mind the unencrypted packet lengths -- that's how SSHv2 should have been from the get-go! Being robbed of the opportunity to flog such a horrible idea at the authors is not really a problem :) I wouldn't bother with that idea, but I'd have enjoyed pointing it out! :) Please follow up to the comments on RFC5647 on the old SECSH WG list. Nico -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IPsec] Last Call: draft-ietf-ipsecme-ikev2-resumption (IKEv2 Session Resumption) to Proposed Standard
Hi, floks: I have two comments on the draft of IKEv2 Session Resumption: 1) Sorry, I have to talk about my concern on the new IKE_SESSION_RESUME. In WG last call, actually I made this comment. However, no feedback was given, maybe because my comment was a little late for WG last call. So, I just copy it here again as a comment for IESG last call. Well, we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution is specified in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: - RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. - Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. - As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: - some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's an issue of implementation. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. 2) Maybe I missed some discussions. There is the case: responder may receives a ticket for an IKE SA that is still active and if the responder accepts it. In one of previous versions of this draft, there once was some description on this case. I know that how a client detects the need for resumption is out of the scope of this draft. But, there is the possibility that IPsec client may be continuously deceived and believe the fail of IPsec gateway. It may continuously present the ticket and update the ticket. In this sense, IMHO, this draft should take care of this case. BRG Peny On Mon, Aug 31, 2009 at 10:09 PM, The IESGiesg-secret...@ietf.org wrote: The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'IKEv2 Session Resumption ' draft-ietf-ipsecme-ikev2-resumption-07.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 ietf@ietf.org mailing lists by 2009-09-14. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=17990rfc_flag=0 ___ IPsec mailing list ip...@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
I'd like to keep this discussion focused on the question that Jari asked. While changes to the Independent Stream can be discussed, that seems like rfc4846bis, not this document ... Several people have said that the RFC Editor already has the authority we are discussing here. Sadly, it is not that simple. The words cited below from RFC 3932 cloud this issue. I think they conflict with the words in the RFCs cited by John. RFC 3932 says: The IESG may return five different responses, any of which may be accompanied by an IESG note to be put on the document if the RFC Editor wishes to publish. I think that ... to be put on the document if the RFC Editor wishes to publish is the heart of the matter. RFC 3932 leaves the RFC Editor with the final say on publication, but if the document is published, the note must be included. Sam and Pasi have already pointed out that the RFC Editor can appeal the action taken by the IESG if they think the note is off base. In practice, the RFC Editor has asked the IESG to reconsider the text of one note, and the IESG has done so. There have not been any appeals on this topic since the publication of RFC 3932. The rfc3932bis-08 text provides greater flexibility to the RFC Editor, making the IESG note a recommendation to the RFC Editor. The is the flexibility that several people have claimed the RFC Editor has had all along based on other documents. Please, let's try to answer this one question on this thread: When the IESG performs review of an Independent stream or IRTF stream document and provides an IESG Note, does the RFC Editor have the authority (without a request for reconsideration or an appeal) to publish the document without the IESG Note? Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Concerns about individual submissions process (c.f. RFC5647 AES-GCM for Secure Shell)
Nico, On 2009-09-03 07:54, Nicolas Williams wrote: ... I do not subscribe to the IETF list (ietf@ietf.org), for the very obvious reason that its signal-to-noise ratio is too poor, thus completely missed the IETF LC of draft-igoe- secsh-aes-gcm Last Calls are announced on the ietf-annou...@ietf.org list, which is a read-only list with relatively low volume. The reason for that is to avoid exactly the problem you describe. If you're not subscribed to ietf-announce, you won't see *any* Last Calls, or other important announcements. http://www.ietf.org/list/announcement.html Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
[Fwd: Re: I-D Action:draft-klensin-iasa-policy-00.txt]
Forwarded here at the request of one of the authors: Original Message Subject: Re: I-D Action:draft-klensin-iasa-policy-00.txt Date: Wed, 02 Sep 2009 17:10:32 +1200 From: Brian E Carpenter brian.e.carpen...@gmail.com Organization: University of Auckland To: John Klensin klen...@jck.com, Joel M. Halpern j...@joelhalpern.com References: 20090824183001.3410b3a6...@core3.amsl.com I think I agree with this document; these are editorial issues. There's a sequence in section 2.1 starting with the words I think that clearly needs rephrasing. Section 3: In both cases, it may be useful to think of the bouncing back process as as an appeal from the IASA to the Stream, but an appeal that is explicitly This material appears to be duplicated just above, in slightly different words. 5. Emergency Situations Emergencies can and do (unfortunately) occur. It is understood that in an emergency, steps will be taken, and remedies applied. The general rule is that if the Trust acts on an emergency basis, This surely applies to IASA as a whole, not just the Trust. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
On Sep 1, 2009, at 11:04 AM, Alissa Cooper wrote: This entire thread is perfectly illustrative of why the IETF needs a privacy policy. Without one, it is entirely unclear how the data collected about IETF participants is used, disclosed and protected, whether that data is part of an experiment or not. While the supplemental information about the RFID tagging experiment (http://www.ietf.org/meeting/76/ebluesheet.html ) is helpful, it is not complete (for example, how long the RFID- captured data is stored in electronic form is not disclosed), and nothing equivalent exists (to my knowledge) for other kinds of data about IETF participants, like registration data. In our protocol development work, many of us try very hard to design privacy and security features in from the outset, whether we're designing a highly experimental prototype or a core protocol. The same should be true for the design of data collection mechanisms and practices associated with IETF meetings. I fully agree with you about the need for a privacy policy. However, if we had one right now, it would likely not fully capture the full possibilities and potential dangers of an experiment like this. In my opinion, these experiments are as much or more organizational as they are technological. In fact, I would assume that the technology is likely to work. The real questions concern the organization, have to be brought to the surface, weighed and discussed by the community, and the answers improved based on experience. Or, to put it another way, I expect that the privacy policy (and maybe the document retention policy) will be informed and hopefully improved by the results of this experiment. Regards Marshall Alissa ___ 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
--On Wednesday, September 02, 2009 13:53 -0400 Sam Hartman hartmans-i...@mit.edu wrote: John, in principle, I would be delighted by this option if you made a few more changes to make the RFC process more accountable: 1) Open up the rfc-editorial board so that it was selected by some sort of nomcom/community process. That nomcom could of course draw from a broader community than the IETF as a whole 2) Provide an appeals path for IAB decisions related to the RFC-editor function I have a lot more faith in the IETF process than I do the RFC editor process. I believe that the RFC editor process is more open to a different type of abuse than the IESG process, but I believe we have a far more open process for addressing problems with the IESG than we do with IAB decisions about the RFC editor or with the RFC editor process itself. However, absent these changes, I don't believe there would be appropriate checks and balances present. Sam, Brian and Joel covered most of what I would have said had I gotten to your note earlier. I would add only three things to their remarks: (1) Checks and balances against what? I trust the answer is not publication of high-quality articles which contain content with which some AD happens to disagree because that is the only thing that has been at issue in the past. On other matters, the RFC Editor has _voluntarily_ deferred to the IESG, often going well beyond what the current procedures require. Remember that RFC Editor acceptance of an IESG Note is voluntary today, regardless of what the IESG might believe, _and_ that the written notice procedure I suggested has been followed, as a professional courtesy, for years, without any such requirement being written down anywhere. Put differently, what is the threat model against which you are trying to defend? (2) If I have to make a choice, I prefer to design systems to deal with real and identified threats rather than purely theoretical ones. As I pointed out, we've had repeated examples over the years of the IESG and/or individual ADs abusing the independent submission process and/or the RFC Editor and zero examples of the RFC Editor handling a request from the IESG unreasonably or arbitrarily. So why do you believe we need more protection against the possibility of RFC Editor abuse than we do against IESG abuse or, from a different perspective, believe that the wider community would be better served by tilting the balance even further toward the IESG? (3) As Dave Crocker is fond of pointing out, the Nomcom cannot be expected to make good appointments in areas that are outside the expertise of most of its members... there is just no foundation on which a Nomcom without that expertise can evaluate candidates. Given that, why do you believe that the Nomcom could select an effective editorial board, with or without a broader selection process? Neither democracy nor randomness seem to me to be guarantees of competence. And, again, what real problem do you think that would solve? john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Sam Hartman wrote: Russ, I think that it is absolutely critical ... Sam, However, the IESG is not the IETF. This is the single-most important statement in your note. Absolutely critical is strong language, but is not warranted by 20 years of experience or any other empirical basis. We need to be very careful not to confuse mathematical possibility with operational reality and we need to be careful to consider real costs, along with theoretical benefits. The RFC Editor is also part of the IETF, with plenty of its own accountability, and it has established a history of highly professional and responsible performance, including over the last 10 years, while under new management. The IESG is not, and must not be, the sole repository for responsible decision-making in the IETF, yet that really seems to be at the core of your view. There is no legitimate reason to allow the IESG to mandate language in an Independent RFC, and there is very good reason /not/ to allow it to. For example, it then wouldn't be Independent... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
From: Dave CROCKER d...@dcrocker.net The IESG is not, and must not be, the sole repository for responsible decision-making in the IETF Couldn't agree more. A division of powers, with checks and balances, are a critical part of any organizational system, IMO. Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Being a relatively short-term IETF participant, I lack the history that many on this list have, but since Jari asked for comments, I'll provide some. Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and others that it makes sense to have IESG notes be mandatory for the ISE to include in independent stream RFCs. Stated at more length: What is clearly going on here is that our branding is out of sync with the expectations of our customers. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. I think we all agree that documents that go through the IETF or the IAB can more or less legitimately claim that imprimatur. Independent submissions clearly cannot. Given that, it's not clear to me why the independent stream exists at all, other than for historical reasons. Given that the abolition of the independent stream doesn't seem to be an option at this point, the next best thing to do is to require that independent-stream RFCs alert the reader to two things: 1. That this is not a document that has received IETF or IAB review, and 2. If the Internet community has any serious concerns, what they are Clearly the first point is an issue for Headers and Boilerplates. The second point is represented in the current process by IESG notes; if the Internet community has concerns about a document, they can be included in the document as an IESG note. Given that the IESG is selected through a community process, I'm comfortable with this delegation, though requiring IETF consensus would clearly add some assurance. The other implication of the above paragraph is that the *absence* of an IESG note indicates to the reader that the community has no serious concerns, which means that enabling the ISE to reject IESG notes effectively enables the ISE to speak on behalf of the community. Given the choice, I would prefer the IESG to speak for me than the ISE. So I agree with Jari's option (b), that IESG notes should be something that is always applied to the published RFC. --Richard Jari Arkko wrote: I would like to get some further input from the community on this draft. But first some background. This draft was brought to a second last call in June because several IESG members felt uncomfortable with the IESG notes being used only in exceptional circumstances. I asked Russ to prepare the -07 version. This version allowed notes to be used at the IESG's discretion and suggested that the linkage (or lack thereof) to IETF work would typically be explained in the note. This version was taken to the second last call. While the number of comments we received was small, after the last call was over I determined that the consensus was against this change. As a result, I asked Russ to prepare the -08 version. This version goes back to the exceptional wording from -06, but incorporated a number of editorial corrections that had been made in interim. I also took the draft back to the IESG telechat last week. The IESG was not extremely pleased with the new version, but my understanding is that they were willing to accept the changes. However, a new issue was brought up: one of the changes that Russ and I felt was editorial highlighted the fact that the document makes the IESG notes a recommendation to the RFC Editor, not something that would automatically always be applied to the published RFC. Some IESG members were concerned about this, and preferred the latter. And now back to the input that I wanted to hear. I would like to get a sense from the list whether you prefer (a) that any exceptional IESG note is just a recommendation to the RFC Editor or (b) something that is always applied to the published RFC. Please reply before the next IESG meeting on September 10. Some e-mails on this topic have already been sent in the Last Call thread -- I have seen those and there is no need to resend. (For the record my own slight preference is b. But I have to say that I think the document has been ready to be shipped from version -06, and its unfortunate that we're not there yet, particularly since this document is holding up the implementation of the new headers and boilerplates system for independent submissions, IRTF submissions and IETF submissions. I will exhaust all possible means of getting this approved in the next meeting, as soon as I know what the community opinion is.) Jari Arkko ___ 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: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
In fact, I do not think the presence or absence of a note means what you describe. First, remember the Independent Submission do get reviewed. They do not get IETF review. But they do get technical review by senior technical participants in this community. This review can be thought of, as another note pointed out, as being comparable to the peer review required for scholarly journals. Secondly, given that one of the points of the stream is to provide a mechanism for informed critique of our work, it is unsurprising that the IESG has objected to such critiques. Third, it should be remembered that the IESG review being discussed is not a technical review. It is a review for the relationship between this work and the IETF work. If the IESG finds that there is a relevant relationship, and provides a reasonable note saying so, then the ISE is going to publish it. (There may be negotiation about the wording, but the editors responsibility to be factually accurate means that such accurate notes will be published.) If IESG members in reading the document find technical problems, then they should tell the ISE, just the way any other reviewer would. Next, given that the review is not technical, and given that the review is done by a small number of people, I would not want a reader to draw conclusions about technical competence based on the presence or absence of an IESG note. Such conclusions should be based on reading the document. And let's be careful about asserting that IESG review is an assurance of quality. There have been plenty of marginal documents that the IESG has approved over the years. Sometimes they approved them for very good reasons. Note that even 15 years ago the IESG was under interesting publication pressures some of the time. I am sure it still is. If you want to abolish the Independent Stream, then we can have a discussion (separately from this one) about who would get to do that, and whether that would mean that the IETF would have to find a different outlet, or the Independent Stream. The mix of history, practice, and branding would make for a very confusing situation. Personally, I think the Independent Stream is valuable. (That's why I help review them.) So I do not want that stream or its independence weakened. Also, remember that there are actually 4 streams. I presume that no one is trying to suggest that the IESG should get to put IESG warning notes on IAB documents or IRTF documents? Yet IRTF documents are actually sometimes less reviewed than Independent Stream documents. It is not uncommon for an IRTF Working group to produce multiple reports when the group can not come to agreement. (Note, I do not think that the degree of review correlates with the degree of quality. That is a further confusion about these notes.) Yours, Joel M. Halpern Richard Barnes wrote: Being a relatively short-term IETF participant, I lack the history that many on this list have, but since Jari asked for comments, I'll provide some. Stated briefly, I agree with Steve Kent, Adam Roach, Ben Campbell, and others that it makes sense to have IESG notes be mandatory for the ISE to include in independent stream RFCs. Stated at more length: What is clearly going on here is that our branding is out of sync with the expectations of our customers. Whatever their historical meaning, RFCs are now interpreted by the broad community as documents that have the been reviewed and approved, to a greater or lesser degree, by the Internet community. I think we all agree that documents that go through the IETF or the IAB can more or less legitimately claim that imprimatur. Independent submissions clearly cannot. Given that, it's not clear to me why the independent stream exists at all, other than for historical reasons. Given that the abolition of the independent stream doesn't seem to be an option at this point, the next best thing to do is to require that independent-stream RFCs alert the reader to two things: 1. That this is not a document that has received IETF or IAB review, and 2. If the Internet community has any serious concerns, what they are Clearly the first point is an issue for Headers and Boilerplates. The second point is represented in the current process by IESG notes; if the Internet community has concerns about a document, they can be included in the document as an IESG note. Given that the IESG is selected through a community process, I'm comfortable with this delegation, though requiring IETF consensus would clearly add some assurance. The other implication of the above paragraph is that the *absence* of an IESG note indicates to the reader that the community has no serious concerns, which means that enabling the ISE to reject IESG notes effectively enables the ISE to speak on behalf of the community. Given the choice, I would prefer the IESG to speak for me than the ISE. So I agree with
Protocol Action: 'IP Performance Metrics (IPPM) for spatial and multicast' to Proposed Standard
The IESG has approved the following document: - 'IP Performance Metrics (IPPM) for spatial and multicast ' draft-ietf-ippm-multimetrics-12.txt as a Proposed Standard This document is the product of the IP Performance Metrics Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ippm-multimetrics-12.txt Technical Summary The IETF has standardized IP Performance Metrics (IPPM) for measuring end-to-end performance between two points. This memo defines two new categories of metrics that extend the coverage to multiple measurement points. It defines spatial metrics for measuring the performance of segments of a source to destination path, and metrics for measuring the performance between a source and many destinations in multiparty communications (e.g., a multicast tree). Working Group Summary The working group input has improved this document through its revisions, and the document itself has been uncontroversial. Document Quality No known implementations claim to implement this metric. However, other implementers in the group have read the draft. Personnel The document shepherd is Matt Zekauskas (m...@internet2.edu). Lars Eggert (lars.egg...@nokia.com) reviewed it for the IESG. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: Internationalized Domain Names in Applications, Revised (idnabis)
The charter of the Internationalized Domain Names in Applications, Revised (idnabis) working group in the Applications Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Internationalized Domain Names in Applications, Revised (idnabis) --- Last Modified: 2009-08-10 Additional information is available at tools.ietf.org/wg/idnabis Chair(s): - Vinton Cerf v...@google.com Applications Area Director(s): - Lisa Dusseault lisa.dussea...@gmail.com - Alexey Melnikov alexey.melni...@isode.com Applications Area Advisor: - Lisa Dusseault lisa.dussea...@gmail.com Mailing Lists: General Discussion: idna-upd...@alvestrand.no To Subscribe: http://www.alvestrand.no/mailman/listinfo/idna-update Archive: http://www.alvestrand.no/pipermail/idna-update/ Description of Working Group: The original Internationalized Domain Name (IDN) WG specified rules for the use of characters other than Latin A(a)-Z(z), digits 0-9 and the hyphen (-) in domain names in RFC3490, RFC3491 and RFC3492 in 2002 (published in 2003 and often referenced collectively as IDNA2003). These documents depend on RFC 3454 and were tied to Unicode version 3.2. An update to the current version (5.x) is required to accommodate additional scripts. In addition, experience has shown that significant improvements could be made in the protocol as presently specified. This WG is chartered to decouple IDNA from specific versions of Unicode using algorithms that define validity based on Unicode properties. It is recognized that some explicit exceptions may be necessary in any case, but attempts will be made to minimize these exceptions. Additional goals: - Separate requirements for valid IDNs at registration time (insertion of names into DNS zone files), vs. at resolution time (looking up those names) - Review, and if necessary revise, the algorithms and rules for handling right to left character sequences in an IDN context to allow labels based on additional scripts and languages and to make presentation as predictable as reasonably possible. - Permit use of some scripts that were inadvertently excluded by the original protocols. - Ensure practical stability of validity algorithms for IDNs. The constraints of the original IDN WG still apply to IDNABIS, namely to avoid disturbing the current use and operation of the domain name system, and for the DNS to continue to allow any system to resolve any domain name in a consistent way. The client-based approach of the original IDN work will be maintained -- substantially new protocols or mechanisms are not in scope. In particular, IDNs continue to use the xn-- prefix and the same ASCII-compatible encoding, and the bidirectional algorithm follows the same basic design. The specifications are initially organized as four documents: overview and rationale, protocol, table algorithm, and improvements to the bidirectional algorithm. These documents are to be used as the basis for the discussion of the general direction of the work. This working group will be providing extended public review of the output of a design team that has been working on improvement of the IDNA specifications. This review-based approach is being used in part because of the way the work was undertaken by the team; in particular, the design team has been working with IETF visibility and has solicited and received significant amounts of technical review already from IETF participants and from others including experts in the Unicode specifications and the use of scripts in languages. If the public review provided by this Working Group confirms the basic method outlined in the input documents, it is expected that the working group will be able to respond with any needed changes and close in a short period of time. If technical issues arise that indicate a fundamentally different approach must be taken from the one outlined above, it is anticipated that this working group would close, and a new one with an appropriate charter would be considered. This work is intended to specify an improved means to produce and use stable and unambiguous IDN identifiers. There are a variety of generally unsolvable problems, notably the problem of characters that are confusingly similar in appearance (often known as the phishing problem) that are not specifically part of the scope of the WG although some of the preliminary results of the design team suggest that the improvements contemplated in the specifications might mitigate some of the ways in which the current IDNA specifications can be abused for phishing purposes. While it is referenced from the original IDNA2003 package, the original Stringprep specification, RFC 3454, is not formally part of the IDNA package and will not be altered by this work. The work will update or obsolete RFC 3490. It is not expected to continue to use Nameprep (RFC 3491). Nameprep is used by
