Re: draft-housley-iesg-rfc3932bis and the optional/mandatory nature of IESG notes
Hi, On 2009-8-31, at 18:34, Adam Roach wrote: In particular, when a user accesses a document at a url of the form http://www.ietf.org/rfc/rfc.txt, there is going to be a strong presumption on their part that the document was produced by the IETF. In the cases that this presumption is incorrect, it seems tantamount to deception to tuck the distinction between IETF and non-IETF documents away in an obscure header field. I agree with you. This is exactly why I had originally proposed to stick the words NOT AN INTERNET STANDARD into the top left corner on the first page (where it currently says Network Working Group) for all non-standards-track documents in all streams. That proposal got shot down with the (paraphrased) argument we should label RFCs with what they are rather with what they are not. I still disagree with this, because the #1 question what looking at any RFC should be is this an Internet standard or not? Lars smime.p7s Description: S/MIME cryptographic signature ___ 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 2009-8-31, at 19:24, Joel M. Halpern wrote: But the same could be said all our experimental and informational RFCs. Should we insist that all experimental and informational RFC, even from IETF WGs, carry big warnings THIS IS NOT AN IETF STANDARD. FWIW, this was exactly what I proposed a while ago. The current way we label RFCs requires folks to understand the intricacies of the different streams. Few in the broader industry do. Lars smime.p7s Description: S/MIME cryptographic signature ___ 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
Adam, So, to be clear, the question you have raised has to do with the difference between: The IESG may choose to add an IESG note to an Independent Submission... and: The IESG may choose to request the addition of an IESG note to an Independent Submission... Right? Yes. This has nothing to do with the text: In exceptional cases, when the relationship of the document to the IETF standards process might be unclear... ? Right. The exceptional vs. always-on question is another issue. Jari ___ 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
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). Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Non-smoking rooms at the Hiroshima venue?
Greetings, I just set about to reserve a room at the meeting hotel via http://www.ichotelsgroup.com/h/d/cp/1/en/cwshome/DPRD-7LT5AJ/HIJJA (which required that I join their PriorityClub...). Check-in on Saturday, check-out on Friday (nothing odd there). I was, though, VERY surprised that there are no non-smoking rooms available. All I got was: 1 SINGLE BED STANDARD SMOKING at ￥13,500. If I want non-smoking, I seem to have to pay 23,000 and have 2 beds. Is this other's experience as well? While I can survive a smoking room, I'd really rather not. I haven't tried calling, so perhaps that's the solution. Can anything be done to get us some non-smoking rooms since I suspect that's what almost everyone wants? 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
On Aug 31, 2009, at 3:29 PM, Jari Arkko wrote: 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. I am happy to see the document being reverted so that an IESG note is exceptional. Over the last years I've started to appreciate the fact that the RFC Series is not exclusively an IETF series. On the other hand I am sensitive to the argument that most consumers of RFCs do not see the fine distinction between standards track and non-standards track RFCs, let alone the difference between non-standards track from various streams. Headers and Boilerplates tried to address that and hopefully helps to clarify the fact that not every RFC is an IETF Standards Track document. However, the whole RFC streams framework has been build with complete independence of the various stream in mind. In my opinion that makes sense. The IAB should not be able to force notes on IETF stream documents, the IRTF should not be able to put them on IAB stream documents, and the IESG should not be able to force them on IRTF, IAB and Independent documents. In other words it is not clear to me why the combination IESG and the Independent stream should have a special status. And, as other mentioned, deciding about that special status is not a matter that rests solely with the IESG/IETF stream. I do think that in essence this is a fairly theoretical discussion. I believe that in general notes from the IESG will have merit and recommendations will in general be followed, specifically since they are likely to be exceptional. In the case that the judgement, by the IESG and ISE, of merit conflicts, there is a procedure in RFC 5620. I'm for (a). --Olaf (no hats) Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Non-smoking rooms at the Hiroshima venue?
Hi Dave, folks, Don't count me in. After freezing my fingers off in MSP, that's a plus point about Japan. At least this time I have a choice. So, apparently, do you. all the best, Lawrence On 1 Sep 2009, at 08:52, David Partain wrote: Greetings, I just set about to reserve a room at the meeting hotel via http://www.ichotelsgroup.com/h/d/cp/1/en/cwshome/DPRD-7LT5AJ/HIJJA (which required that I join their PriorityClub...). Check-in on Saturday, check-out on Friday (nothing odd there). I was, though, VERY surprised that there are no non-smoking rooms available. All I got was: 1 SINGLE BED STANDARD SMOKING at ￥13,500. If I want non-smoking, I seem to have to pay 23,000 and have 2 beds. Is this other's experience as well? While I can survive a smoking room, I'd really rather not. I haven't tried calling, so perhaps that's the solution. Can anything be done to get us some non-smoking rooms since I suspect that's what almost everyone wants? 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
Date:Mon, 31 Aug 2009 16:29:26 +0300 From:Jari Arkko jari.ar...@piuha.net Message-ID: 4a9bd036.1000...@piuha.net | 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. Definitely (a) - the reasons for this have already been made by many others and I won't repeat them. But, I'd also change the target of the recommendation - the IESG shouldn't be asking or instructing the editor (whichever form of editor, RFC or ISE or ...) in any way, rather they should be suggesting to the author of a document that it would likely be more acceptable if it included some extra particular text. The editor would then, of course, take the author's response to that request into account when deciding whether or not to publish the author's document. Lastly, as has been stated already, but this time I will restate it for emphasis, the IESG should not be making any kind of technical review of independent submissions - the reason the review was even permitted (remember previously independent submissions went directly to the RFC editor who simply published them, or declined) 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, the IESG is just supposed to determine whether there is (or perhaps should be) a WG to work on the same topic, and if so, invite the author to submit the document to that WG for further review (and even possibly elevation into the standards track). Beyond that, the IESG should be leaving independent submissions alone. kre ___ 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
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. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
Fred Baker wrote: Chill Out. Back at you. Go ahead and opt out. PLEASE opt out if you you can't deal with technology that might change - as all IETF technology does over time. Leave Alexa out of this. 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. There's also a good chance of missing important data about usage that might be ancillary, but desired by users, and will be lost with the new technology. We've already had a couple of postings providing such insight. But it's probably been ignored. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Let's be careful with those XML submissions to IANA
Looking at RFC5102 (IPFIXinfo), it, like many RFC, has normative definitions in the body of the document and a non-normative appendix, which, since it brings the definitions together, is easier and so more likely to be used. Indeed, the IANA considerations, s.7, tell IANA to register the non-normative appendix which is fine as long as the two are in step but what happens when they are not? In fact, they do differ slightly. The IANA considerations register URI: urn:ietf:params:xml:ns:ipfix-info-15 XML: See Appendix B for this document. whereas Appendix B says that the name is schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info which is what is in the IANA registry. IANA have used Appendix B and so have got the right answer by doing the 'wrong' thing. (Interestingly the last I-D of this document had, in Appendix B, schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info-10 xmlns:ipfix=urn:ietf:params:xml:ns:ipfix-info-10) What if an error is discovered in the body of the document (I have not looked at it in any detail) and an erratum is raised against it? Does this implicitly request IANA to update the registry? Does it matter whether the erratum is against the appendix or the body of the document? (I think this is called the distributed database problem:-) Tom Petch ___ 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
Date:Tue, 01 Sep 2009 16:37:31 +0300 From:Jari Arkko jari.ar...@piuha.net Message-ID: 4a9d239b.7070...@piuha.net | Right, and we are not. That is very good to hear. I haven't been watching much of recent IETF happenings (last few years) so I explicitly make no comment about anything that has happened recently. In the past however, back when I was more involved, there were occasions when that was certainly not the case - there were cases where the IESG decided that a proposal (an independent submission) would really be bad for the internet, and requested (and perhaps even published) notes with comments along the lines of how insecure, unscalable, and generally horrid some document was, and strongly advising the world to ignore it. That's all technical discussion, and none of that should ever be a part of an IESG note requested to be added to a doc. Given that, what's left for an IESG note pretty much amounts to this does not represent IETF consensus or Readers should also see RFC for an alternative solution - neither of which are very likely to be ignored by the editor - or in fact, by the doc author if requested of him or her - so there should be no need for mandatory addition of notes, just a request should be enough (ie: if one ever is refused, the chances are really pretty good that it should never have been requested.) One final note, none of this, of course, prevents anyone, including IESG members, writing their own independent submission, criticising some other proposal (in a different RFC) - such a thing could even be made an IETF consensus doc if desired - that's all reasonable,but of course takes more effort, and real considered and supported arguments, an IESG note to the same effect is just the lazy way out, and should never be used (and to repeat my opening comment, I am not claimimg that it has any time recently, I simply have no idea.) kre ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Important Information about IETF 76 Meeting Registration
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. Alissa ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Non-smoking rooms at the Hiroshima venue?
David, Let me take a stab at answering this. First of all, while it may not be obvious, you DO NOT need to be a Priority Club member in order to reserve a room. AMS is trying to get the link fixed so that this will be clearer. For now, you can just enter the desired arrival and departure dates. For some reason, if you already ARE a Priority Club member the page does not seem to load properly, anyway... that's being worked on hopefully :-) The ANA does indeed have a limited number of non-smoking rooms, but I know the hotel is well aware that most IETFrs will want non-smoking rooms and they will do their best to accommodate you (even if the reservation system may not indicate availability). Also, I stayed in an official *smoking* room at this hotel back in November and they had air cleaned it prior to my arrival. I had no issues, the room seemed as clean airwise as any non-smoking room I've stayed in anywhere in the world. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 1 Sep 2009, David Partain wrote: Greetings, I just set about to reserve a room at the meeting hotel via http://www.ichotelsgroup.com/h/d/cp/1/en/cwshome/DPRD-7LT5AJ/HIJJA (which required that I join their PriorityClub...). Check-in on Saturday, check-out on Friday (nothing odd there). I was, though, VERY surprised that there are no non-smoking rooms available. All I got was: 1 SINGLE BED STANDARD SMOKING at ￥13,500. If I want non-smoking, I seem to have to pay 23,000 and have 2 beds. Is this other's experience as well? While I can survive a smoking room, I'd really rather not. I haven't tried calling, so perhaps that's the solution. Can anything be done to get us some non-smoking rooms since I suspect that's what almost everyone wants? Cheers, David ___ 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?
As for me, I made a reservation at Mitsui Garden and just sent a note to the agency asking for a non-smoking room. They replied that they would forward my request to the hotel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Non-smoking rooms at the Hiroshima venue?
Hi Ole - 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. There are no non-smoking rooms even at the higher rate. Given that I believe you're correct that most of the IETF will be looking for a non-smoking room, I'm not convinced that the hotel will be able to air clean all the necessary rooms in time. It's possible, but would seem to be a lot of effort (and cost?) for the hotel that already has a signed agreement with the IETF - unless that agreement specifically requires that all non-smoking requests be accommodated? Since you're on the IAOC I believe, could you comment if that was part of the booking agreement? 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. Mike At 01:03 PM 9/1/2009, Ole Jacobsen wrote: David, Let me take a stab at answering this. First of all, while it may not be obvious, you DO NOT need to be a Priority Club member in order to reserve a room. AMS is trying to get the link fixed so that this will be clearer. For now, you can just enter the desired arrival and departure dates. For some reason, if you already ARE a Priority Club member the page does not seem to load properly, anyway... that's being worked on hopefully :-) The ANA does indeed have a limited number of non-smoking rooms, but I know the hotel is well aware that most IETFrs will want non-smoking rooms and they will do their best to accommodate you (even if the reservation system may not indicate availability). Also, I stayed in an official *smoking* room at this hotel back in November and they had air cleaned it prior to my arrival. I had no issues, the room seemed as clean airwise as any non-smoking room I've stayed in anywhere in the world. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 1 Sep 2009, David Partain wrote: Greetings, I just set about to reserve a room at the meeting hotel via http://www.ichotelsgroup.com/h/d/cp/1/en/cwshome/DPRD-7LT5AJ/HIJJA (which required that I join their PriorityClub...). Check-in on Saturday, check-out on Friday (nothing odd there). I was, though, VERY surprised that there are no non-smoking rooms available. All I got was: 1 SINGLE BED STANDARD SMOKING at ï¿¥13,500. If I want non-smoking, I seem to have to pay 23,000 and have 2 beds. Is this other's experience as well? While I can survive a smoking room, I'd really rather not. I haven't tried calling, so perhaps that's the solution. Can anything be done to get us some non-smoking rooms since I suspect that's what almost everyone wants? Cheers, David ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Non-smoking rooms at the Hiroshima venue?
Mike, I am going to let AMS answer that since they have the contract with the ANA. My understanding as of right now is that about 60% of the rooms are non-smoking. The ANA has been aware of our desire for non-smoking rooms for a long time so I am sure they are working on whatever solution they can find. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 1 Sep 2009, Michael StJohns wrote: Hi Ole - 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. There are no non-smoking rooms even at the higher rate. Given that I believe you're correct that most of the IETF will be looking for a non-smoking room, I'm not convinced that the hotel will be able to air clean all the necessary rooms in time. It's possible, but would seem to be a lot of effort (and cost?) for the hotel that already has a signed agreement with the IETF - unless that agreement specifically requires that all non-smoking requests be accommodated? Since you're on the IAOC I believe, could you comment if that was part of the booking agreement? 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. Mike ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Let's be careful with those XML submissions to IANA
Assuming that there actually is a contradiction here (and I don't know anything about IPFIX so I won't hazard a guess) the end result is a quality-control problem that should be brought to the attention of the RFC Editor. If I understand your comments below correctly, you're encouraging document authors and reviewers to have better attention to detail, which I agree is also a good takeaway. Finally, please remember this example the next time you're tempted to complain about how long it takes the RFC Editor and/or IANA to take action on a document. Reasonable concerns about processing timeliness aside, y'all are not so easy to work with as you would sometimes like to believe. :) Doug Tom.Petch wrote: Looking at RFC5102 (IPFIXinfo), it, like many RFC, has normative definitions in the body of the document and a non-normative appendix, which, since it brings the definitions together, is easier and so more likely to be used. Indeed, the IANA considerations, s.7, tell IANA to register the non-normative appendix which is fine as long as the two are in step but what happens when they are not? In fact, they do differ slightly. The IANA considerations register URI: urn:ietf:params:xml:ns:ipfix-info-15 XML: See Appendix B for this document. whereas Appendix B says that the name is schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info which is what is in the IANA registry. IANA have used Appendix B and so have got the right answer by doing the 'wrong' thing. (Interestingly the last I-D of this document had, in Appendix B, schema targetNamespace=urn:ietf:params:xml:ns:ipfix-info-10 xmlns:ipfix=urn:ietf:params:xml:ns:ipfix-info-10) What if an error is discovered in the body of the document (I have not looked at it in any detail) and an erratum is raised against it? Does this implicitly request IANA to update the registry? Does it matter whether the erratum is against the appendix or the body of the document? (I think this is called the distributed database problem:-) Tom Petch ___ 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?
60% of our room block is considered non smoking but, as our room block is on the smaller side, it is possible that all non smoking rooms are indeed sold out. We have contacted the hotel to see how we can best work through this issue, but at the moment it is only 3am in Hiroshima so it will be a number of hours before we hear back. We will update everyone as soon as we know more. Alexa On Sep 1, 2009, at 10:33 AM, Ole Jacobsen wrote: Mike, I am going to let AMS answer that since they have the contract with the ANA. My understanding as of right now is that about 60% of the rooms are non-smoking. The ANA has been aware of our desire for non-smoking rooms for a long time so I am sure they are working on whatever solution they can find. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 1 Sep 2009, Michael StJohns wrote: Hi Ole - 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. There are no non-smoking rooms even at the higher rate. Given that I believe you're correct that most of the IETF will be looking for a non-smoking room, I'm not convinced that the hotel will be able to air clean all the necessary rooms in time. It's possible, but would seem to be a lot of effort (and cost?) for the hotel that already has a signed agreement with the IETF - unless that agreement specifically requires that all non-smoking requests be accommodated? Since you're on the IAOC I believe, could you comment if that was part of the booking agreement? 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. Mike ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: BOFs for Hiroshima
Is there a standard interval for such deadlines before an IETF meeting? As you noted, this one seems particularly early this time. Jason On 8/24/09 12:16 PM, Marshall Eubanks t...@americafree.tv wrote: I just wanted to bring to people's attention this (fairly early) cut off date for Hiroshima : - 2009-09-14 (Monday): Cutoff date for Area Directors to approve BOFs at 17:00 PDT (24:00 UTC/GMT). This is not that far off. People who are thinking about preparing BOFs should get to it. Regards Marshall ___ 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: BOFs for Hiroshima
Yes, the standard BOF submission dates were recently changed, and they are a bit earlier now. As part of a renewed effort to avoid conflicts in the meeting agenda, it was decided that the BOF deadline should more closely coincide with the working group scheduling. By moving the BOF cutoff dates up earlier in the meeting preparation cycle, the area directors will have more time to review the draft agenda before it is published, which will hopefully result in few conflicts and, ultimately, a better meeting agenda. Alexa On Sep 1, 2009, at 12:18 PM, Livingood, Jason wrote: Is there a standard interval for such deadlines before an IETF meeting? As you noted, this one seems particularly early this time. Jason On 8/24/09 12:16 PM, Marshall Eubanks t...@americafree.tv wrote: I just wanted to bring to people's attention this (fairly early) cut off date for Hiroshima : - 2009-09-14 (Monday): Cutoff date for Area Directors to approve BOFs at 17:00 PDT (24:00 UTC/GMT). This is not that far off. People who are thinking about preparing BOFs should get to it. Regards Marshall ___ 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 --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: I-D Action:draft-klensin-iaoc-member-00.txt
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. As it stands the IETF Chair is in a unique position to understand all the requirements of the IETF community and IETF administrative activities. There isn't someone else who can step in: all other IESG members are tasked, as a primary responsibility, with looking after their particular areas. The IAB Chair similarly sits at the confluence of all the issues hitting the IAB, and is specifically responsible for tracking them so that they get addressed by the IAB. While the IAB Chair can, in theory, delegate actions on particular topics, it at least used to be the case that some tasks are too tricky or unappealing to get other involvement(too admin, not enough architectural content). And, even with successful delegation of individual tasks, the IAB Chair retains the perspective across all the activities -- technical, IANA, RFC Editor, etc. I'm not going to disagree that the jobs are heavily loaded, and that it's a problem for the IETF that the organization relies heavily on finding a solid candidate for each of these complex positions. However, I think taking them off the IAOC is *not* the place to start. It makes more sense to me to sort out the organizational challenges (of the IESG/IETF, and of the IAB) that cause overloading of these positions, and *then* see what makes sense in terms of identifying IAOC participation. Pulling these positions off the IAOC would succeed in weakening the IAOC, even as it increases the stress levels in the positions as the respective Chairs try to figure out what is going on with the administrative support for the balls they are trying to keep moving. My $0.02cdn Leslie. Brian E Carpenter wrote: Hi, Is this the correct list for discussing draft-klensin-iaoc-member? o workload and full-time positions Even without IAOC and Trustee roles, the IETF Chair and IAB Chair roles require considerable time and effort. This has been true for many years of the IETF Chair role. Indeed one of the main motivations for creating the IAOC and IAD roles was to tackle this. From personal experience, as the IETF Chair who bridged the changeover, there is no doubt in my mind that this changed the IETF Chair job from essentially impossible to reasonably possible. So it was a success in this respect. If anyone's interested in how I thought about the workload at that time, see: http://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks The question I have (as I did when writing that draft) is whether any further organisational change would have a *significant* effect on the IETF Chair workload. More on that below. My feeling is that the IAB Chair role has grown in recent times, and not in the sense of being able to spend more time on Internet Architecture. That seems like a Bad Thing. To some extent this is a short term effect due to the need to reorganise the RFC Editor service, which is a clear IAB non-architecture responsibility. However, it generates the same question about organisational change. In addition, it is useful to clarify the role of the IAB and IESG representatives by making them (and the chairs, if different) non- voting liaisons. That statement doesn't seem to be justified by anything above. Why is it useful, and what is unclear about their present (voting) roles? I'm missing a few steps in the argument. ... This reduces the requirement that IAB and/or IESG members be selected for the specific types of expertise needed on the IAOC and Trustees. NomCom has major difficulty in this anyway. We need IAOC members with good technical and community understanding *and* the IAOC/Trustee skills. This seems essentially unfixable to me. Also, it isn't discussed in the draft that by removing two voting members, the IAOC quorum becomes quite a bit smaller and the concentration of power perhaps too great. Wouldn't we want to add at least one regular member, which would make the NomCom task even harder? o If one or both of the liaisons specified immediately above are not the IAB Chair or IETF Chair, those individuals have permanent liaison status with the IAOC (and Trustees): they are not expected to attend meetings on a regular basis, but may do so and may not be excluded from any meeting, even executive sessions. Two points on this: 1. One possible effect of this is to add two people to every IAOC or Trust meeting. That doesn't seem like workload reduction. 2. In any case, it seems to me to be unrealistic to imagine that an IETF Chair would drop out of IAOC participation; in fact I would regard it as downright irresponsible to do so. Being non-voting would perhaps
Current ietf e-mail delays
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
Re: Fwd: Current ietf e-mail delays
Stefan Santesson ste...@aaa-sec.com 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 - The secretariat is responsible for mail transport. If you are experiencing problems with list mail, the most useful course of action would be to send the information, along with specifics and details, to ietf-act...@ietf.org. They are the ones who will be able to determine what the problem is. Further details and contact methods and information are available on the IETF website. Warm regards, Glen Barney IT Director AMS (IETF Secretariat) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-syslog-sign (Signed syslog Messages) to Proposed Standard
The IESG has received a request from the Security Issues in Network Event Logging WG (syslog) to consider the following document: - 'Signed syslog Messages ' draft-ietf-syslog-sign-27.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 i...@ietf.org mailing lists by 2009-09-15. 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-syslog-sign-27.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=6411rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'Layered Coding Transport (LCT) Building Block' to Proposed Standard
The IESG has approved the following document: - 'Layered Coding Transport (LCT) Building Block ' draft-ietf-rmt-bb-lct-revised-11.txt as a Proposed Standard This document is the product of the Reliable Multicast Transport Working Group. The IESG contact persons are Magnus Westerlund and Lars Eggert. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-revised-11.txt Technical Summary This document is an RMT Building Block that specifies protocol headers and procedures useful for building a reliable multicast transport protocol that can employ packet-level forward error correction (FEC) coding to enable massively- scalable, reliable, unidirectional network data transport without requiring receiver feedback. Layered Coding Transport is specifically designed to support protocols using IP multicast, but also provides support to protocols that use unicast. Layered Coding Transport is compatible with congestion control that provides multiple rate delivery to receivers. Working Group Summary There is consensus in the WG to publish this documents. Document Quality The document is of high quality and has been subject to extensive review in its Internet Draft and Experimental RFC forms. The revised draft represents a small number of changes from the original Experimental RFC 3451. Open source implementations of the LCT protocol are available and considerable experience in using this protocol has been accumulated. The protocol has been adopted by the Digital Video Broadcasting (DVB) industry consortium for content delivery. The content of this document was already reviewed and approved for publication as experimental RFC 3451. This document contains minor technical modifications. Personnel Brian Adamson is the Document Shepherd. Magnus Westerlund is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: SIP Common Log Format (sipclf)
A new IETF working group has been proposed in the Real-time Applications and Infrastructure Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Tuesday, September 8, 2009. SIP Common Log Format (sipclf) --- Current Status: Proposed Working Group Last Modified: 2009-08-27 Chair(s): TBD Real-time Applications and Infrastructure Area Director(s): Robert Sparks rjspa...@nostrum.com Cullen Jennings flu...@cisco.com Real-time Applications and Infrastructure Area Advisor: TBD Mailing Lists: TBD Description of Working Group: The SIP Common Log Format (SIPCLF) working group is chartered to define a standard logging format for systems processing SIP messages. Well-known web servers such as Apache and web proxies like Squid support event logging using a common log format. The logs produced using these de-facto standard formats are invaluable to system administrators for trouble-shooting a server and tool writers to craft tools that mine the log files to produce reports and trends and to search for a certain message or messages, a transaction or a related set of transactions. Furthermore, these log records can also be used to train anomaly detection systems and feed events into a security event management system. The Session Initiation Protocol does not have a common log format. Diverse elements provide distinct log formats making it complex to produce tools to analyze them. The SIPCLF working group will produce a format suitable for logging from any SIP element. The working group will take into account * the need to search, merge, and summarize the log records from one or more possibly diverse elements. * the need to correlate messages from multiple elements related to a given request (that may fork) or a given dialog. The format will take SIP's extensibility into consideration, providing a way to represent SIP message components that are defined in the future. The format will anticipate being used both for off-line analysis and on-line real-time processing applications. The working group will consider the need for efficient creation of records and the need for efficient processing of the records. The working group will identify the fields to appear in a log record and provide one or more formats for encoding those fields. The working group is not pre-constrained to producing either a bit-field oriented or text-oriented format, and may choose to provide both. If the group chooses to specify both, it must be possible to mechanically translate between the formats without loss of information. Specifying the mechanics of exchanging, transporting, and storing SIP Common Log Format records is explicitly out of scope. However, the working group will document as part of the definition of the log record format: * operational guidance considering log file management addressing size, rollover, aggregation and filtering. * guidance for correlating SIP CLF records with events reported via other log mechanisms such as syslog or SNMP traps. * security guidance for storage, access, and transporting SIP CLF log records, addressing information privacy The group will generate: - A problem statement enunciating the motivation, and use cases for a SIP Common Log Format. This analysis will identify the required minimal information that must appear in any record. - A specification of the SIP Common Log Format record Goals and Milestones Dec 09 - Problem statement, motivation, and use cases WGLC Jan 10 - Problem statement, motivation, and use cases to IESG (Informational) Mar 10 - SIP Common Log Format specification WGLC Apr 10 - SIP Common Log Format specification to IESG (PS) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
GEOPRIV Interim Meeting
On Tuesday, September 15, 2009, 16:00-17:00 EDT (20:00-21:00 GMT), GEOPRIV will be having a teleconference interim meeting. The draft agenda for the meeting is as follows: Geopriv architecture http://tools.ietf.org/id/draft-ietf-geopriv-arch-00.txt Location filters http://tools.ietf.org/id/draft-ietf-geopriv-loc-filters-05.txt DHCP LbyR URI option http://tools.ietf.org/id/draft-ietf-geopriv-dhcp-lbyr-uri-option-05.txt Dial-in information for this meeting will be posted to the GEOPRIV wiki page at: http://trac.tools.ietf.org/wg/geopriv/trac/wiki ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
