Additional Jabber Rooms to be added at 7:00 p.m. Easter Time (1 minute downtime)
New Jabber Rooms for BOFs: offpath rtpsec dmsp wai Moving forward we will request all jabber room changes two weeks before each event. Thanks!! NSS ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: When did the ID drafts index disappear
Brian, Its not just the disappearing link to the abstracts, it's the entire organization of the site and the attitude that anyone that has any business working with the IETF already knows where everything is. I don't like playing twenty questions to find pieces of information that should be presented clearly. You reply with yet another piece of insider information. The Web site is the front door to the organization. For the past ten years it has been treated as an afterthought. Phill -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 4:25 PM To: Hallam-Baker, Phillip Cc: Andrew G. Malis; ietf Mailing List Subject: Re: When did the ID drafts index disappear So, Phill, how about a polite note to [EMAIL PROTECTED] or [EMAIL PROTECTED] suggesting that they add a link to 1id-abstracts.txt and to the ftp directory to the page at http://www.ietf.org/ID.html? Incidentally, if you type 'abstracts' into the search box at www.ietf.org, the first hit is the 1id-abstracts page. Brian Hallam-Baker, Phillip wrote: I start at the IETF home page, go to the ID drafts page Look for the abstracts and all I can find is the database interface. If its not in the index it does not exist. From: Andrew G. Malis [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 12:39 PM To: Hallam-Baker, Phillip Cc: ietf Mailing List Subject: Re: When did the ID drafts index disappear Phillip, Did you mean http://www.ietf.org/internet-drafts/1id-abstracts.txt ? It's still there, as always. 1id-index.txt is also there. Cheers, Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Two tickets for social available
For cost ($35 US), for cash, Canadian is good... Spencer, who is not entirely sure where to post things like this now... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
My notes from this morning at breakfast
Tuesday - Area Breakouts John Klensin - downref document Has been deferred to next telechat. Some of Ted's concerns addressed in e-mail. Bill has noticed that documents that are expedited aren't just numbered early, they are published early - doesn't exactly match the document text. Sam - how many documents are we talking about, that this would apply to? Documents submitted to IESG with normative references to either documents that are also in IESG queue, or have been approved at the same or lower level, but not published yet. Sam - just RFC Editor publication delays? John - document prepared after discussions in the community about norm ref rule holding things up. John doesn't think there are many documents covered, just wrote proposal because of the noise. Have reviewed last call comments, in interesting place. John doesn't care if proposal is approved or not, or whether documents waiting to be published are included or not. If IESG rejects document on grounds that were not raised during last call, community can say IESG is doing what IAB was doing in 1972 (was this 1992? but that's the quote). Sam - want to make sure understanding is correct, what delays are included. Ross - two documents held up for more than a year for references that shouldn't have held the documents up. BGP spec updated, but not the protocol, shouldn't have held up the proposal, but it did, and held up multiple proposals. John - could have said BGP spec is changing, but not in any meaningful way, go publish. Sam - would experiment have helped with this situation? not sure. Ted - my confusion - reference to RFC Editor queue document whether or not it had a reference hold? There are cases where documents that are done are being held for references that are not done. Would have helped with SDPnew, gotten more documents out more quickly. John - meant to be able to do what you're asking about, but not required to do so. 5-minute discussion on whether reference hold is appropriate. Ted - we don't ask RFC Editor to remove reference holds today. Sam - can't remove reference hold - that's on a document that wouldn't qualify for this experiment. John - this is a deliberately small change being proposed. Ted - second issue is that experiment has wide latitude, so IESG needs to actually run the experiment. Brian - first experiemental text has to be carefully crafted - cut-and-paste after that? Ted - stable RFC numbers is no problem - run experiments in stages, starting with stable RFC numbers? Brian - no one challenged IESG discretion at last call time. Sam - three stages - downref to RFCs, downref to approved transitive closure, downref to transative non-closure. May want guidelines on situations that might make us leery of applying guideline, John has proposed examples where experiment would work. Brian - are DISCUSSants NO-OBJ on next telechat? Do concerns prevent running the experiment? Ted - don't try to run all three parts of the experiment at once. Suggest that we approve document and say clock starts ticking when we publish something. Don't start experiment before we're finished baking it. Sam - late last call comment from Kurt, believes this might not cover case where you advance an RFC with no text changes, but with resulting downrefs. Approval message, rather than text in the document? Mark - sitting on a document with that issue now. John - if I understand, a much more radical change - making a cautious downref in the text, making a community decision that downref is OK, and a third case where we shouldn't be making a downref at all - that was the thinking. Brian - some AD has to step up to the mark on writing up the experiment Sam - no, someone has to step up, AD not required. Brian - that's true. Clock starts when we have experiement written up. Date for next retreat (But not everyone is here) Sam noticed that he can pay for one retreat, but he hasn't yet (since previous one was in Boston). Reasonable timescale for next retreat? Not six months later, puts us in November. Brian - last retreat was useful - need another one? Jon - efficiency retreat experience, set around an agenda, said we would cancel retreat if we didn't have an agenda ... Sam - agenda content was pretty much nailed down OK, even though the final agenda wasn't published until a couple of days before the retreat. Lars - no more than three retreats per year. Ross - would like to do more at retreats, and meet with community at IETFs. Dan - start with agenda? we are beyond team building. Lisa - joint IAB/IESG retreats useful? Sam - agenda during e-mail, availability needs face-to-face Brian - need provisional date (months in advance). (not recording minute-by-minute here) Looking at Sept 25th and October 2nd weeks? Looking at October 9th? Brian will send proposal to the list. Ted - need to plan for remote participation. Lars is possible host, in Europe. Cullen can
Re: My notes from this morning at breakfast
This was NOT intended for general distribution - my apologies... Spencer - Original Message - From: Spencer Dawkins [EMAIL PROTECTED] To: ietf@ietf.org Cc: John C Klensin [EMAIL PROTECTED] Sent: Tuesday, July 11, 2006 8:43 AM Subject: My notes from this morning at breakfast Tuesday - Area Breakouts John Klensin - downref document Has been deferred to next telechat. Some of Ted's concerns addressed in e-mail. Bill has noticed that documents that are expedited aren't just numbered early, they are published early - doesn't exactly match the document text. Sam - how many documents are we talking about, that this would apply to? Documents submitted to IESG with normative references to either documents that are also in IESG queue, or have been approved at the same or lower level, but not published yet. Sam - just RFC Editor publication delays? John - document prepared after discussions in the community about norm ref rule holding things up. John doesn't think there are many documents covered, just wrote proposal because of the noise. Have reviewed last call comments, in interesting place. John doesn't care if proposal is approved or not, or whether documents waiting to be published are included or not. If IESG rejects document on grounds that were not raised during last call, community can say IESG is doing what IAB was doing in 1972 (was this 1992? but that's the quote). Sam - want to make sure understanding is correct, what delays are included. Ross - two documents held up for more than a year for references that shouldn't have held the documents up. BGP spec updated, but not the protocol, shouldn't have held up the proposal, but it did, and held up multiple proposals. John - could have said BGP spec is changing, but not in any meaningful way, go publish. Sam - would experiment have helped with this situation? not sure. Ted - my confusion - reference to RFC Editor queue document whether or not it had a reference hold? There are cases where documents that are done are being held for references that are not done. Would have helped with SDPnew, gotten more documents out more quickly. John - meant to be able to do what you're asking about, but not required to do so. 5-minute discussion on whether reference hold is appropriate. Ted - we don't ask RFC Editor to remove reference holds today. Sam - can't remove reference hold - that's on a document that wouldn't qualify for this experiment. John - this is a deliberately small change being proposed. Ted - second issue is that experiment has wide latitude, so IESG needs to actually run the experiment. Brian - first experiemental text has to be carefully crafted - cut-and-paste after that? Ted - stable RFC numbers is no problem - run experiments in stages, starting with stable RFC numbers? Brian - no one challenged IESG discretion at last call time. Sam - three stages - downref to RFCs, downref to approved transitive closure, downref to transative non-closure. May want guidelines on situations that might make us leery of applying guideline, John has proposed examples where experiment would work. Brian - are DISCUSSants NO-OBJ on next telechat? Do concerns prevent running the experiment? Ted - don't try to run all three parts of the experiment at once. Suggest that we approve document and say clock starts ticking when we publish something. Don't start experiment before we're finished baking it. Sam - late last call comment from Kurt, believes this might not cover case where you advance an RFC with no text changes, but with resulting downrefs. Approval message, rather than text in the document? Mark - sitting on a document with that issue now. John - if I understand, a much more radical change - making a cautious downref in the text, making a community decision that downref is OK, and a third case where we shouldn't be making a downref at all - that was the thinking. Brian - some AD has to step up to the mark on writing up the experiment Sam - no, someone has to step up, AD not required. Brian - that's true. Clock starts when we have experiement written up. Date for next retreat (But not everyone is here) Sam noticed that he can pay for one retreat, but he hasn't yet (since previous one was in Boston). Reasonable timescale for next retreat? Not six months later, puts us in November. Brian - last retreat was useful - need another one? Jon - efficiency retreat experience, set around an agenda, said we would cancel retreat if we didn't have an agenda ... Sam - agenda content was pretty much nailed down OK, even though the final agenda wasn't published until a couple of days before the retreat. Lars - no more than three retreats per year. Ross - would like to do more at retreats, and meet with community at IETFs. Dan - start with agenda? we are beyond team building. Lisa - joint IAB/IESG retreats useful? Sam - agenda during e-mail, availability needs
Re: Two tickets for social available
Tickets are claimed - will contact people after SIPPING for handoff... Thanks, Spencer - Original Message - From: Spencer Dawkins [EMAIL PROTECTED] To: ietf@ietf.org Sent: Tuesday, July 11, 2006 7:22 AM Subject: Two tickets for social available For cost ($35 US), for cash, Canadian is good... Spencer, who is not entirely sure where to post things like this now... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The IETF 66 Attendees Alias
Ray, I sent a similar email in reply to the endless thread on Internet access at the Delta. Please only allow emails to the participants list from IETF personel for important meeting-related information. Y(J)S ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: The IETF 66 Attendees Alias
Ray, May I make a suggestion for the next time around? How about if the registration page asks if you want to be subscribed to this list? As I understood it, this experiment was performed at the request of people on the ietf discussion mailing list. That list is _not_ the appropriate place to talk about cookie shortages, mail and netowrk problems and issues with the hotel, _either_. Since the registration page already has a number of questions it ask about things we might or might not want to do. Why not add one more - and assume the default answer is no? I like the idea of having a separate list because it allows me to decide quickly what I can safely ignore most of the time. -- Eric -- -Original Message- -- From: Ray Pelletier [mailto:[EMAIL PROTECTED] -- Sent: Monday, July 10, 2006 10:53 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: Re: The IETF 66 Attendees Alias -- -- Alan, et al. -- Message received. -- I agree. -- Changes being made. -- Experiment provided valuable information. -- Sorry for the pain. -- Ray -- IAD -- -- -- Alan Hawrylyshen wrote: -- -- Folks; -- -- I understand the utility and need for the administrative -- staff to have -- a mailing alias for all registered delegates for the 66th -- IETF event. -- However, in all the meetings I have attended - which is -- more than a -- few, but less than most of you - I have never been -- deluged with such a -- volume of non-critical announcements in my main inbox. -- -- I hope that people will understand my strong desire and sympathize -- with my point of view when I request that all general -- IETF messages be -- posted uniquely to the IETF general list and that this address be -- reserved only for the critical or emergency announcements by the -- administrative staff. One step better would be for this -- address to be -- moderated so we no longer receive various complaints about water -- closets and wifi unless we seek them out on the IETF -- discussion lists. -- :-) -- -- Perhaps if there is a strong desire to have a 'hallway or -- watercooler -- style' list for discussions pertaining uniquely to IETF -- 66 attendees, -- we could create a NEW mailing list that is OPT-IN called -- 66attendees-chat (or similar) at ietf.org. I'd even -- volunteer to set -- one up (at a different domain of course) for the duration -- of IETF 66. -- -- My sincere apologies if I have misunderstood the purpose of the -- 66attendees address but my BlackBerry is going crazy with -- things that -- I would not normally choose to have in my commercial, -- corporate email -- box. -- -- Respectfully, -- -- Alan Hawrylyshen -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Clafication: 16ng - NOT IP over IEEE 802.11 Networks
Due to misprinted agenda. Clarifying that 16ng is IP over IEEE 802.16 Networks NOT IP over IEEE 802.11 Networks. TUESDAY 13:00-15:00INT16ngIP over IEEE 802.16 Networks WG Regards, Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF 66 audio broadcast and recording notes.
Since officially beginning monday morning, participation and feedback on the audio streaming has been pretty good. So far there have been 1148 streams requested on the remote server and 297 on the ietf-local one. Just a few notes. If you want use the streaming for impromptu meetings, the 8 breakout rooms are being streamed live even during breaks, lunchtime and when they are empty. They are not being recorded outside of scheduled meetings. Even small groups benefit from microphone utilization if there are remote participants or in order to support the scribes. The unedited mp3 files from monday are becoming available at: ftp://limestone.uoregon.edu/pub/videolab/media/ietf66/ The schedule which is useful for matching recordings to meetingsor tuning in is available at: http://videolab.uoregon.edu/events/ietf/ regards joelja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF 66 Attendees Alias
Gray, Eric wrote: Ray, May I make a suggestion for the next time around? How about if the registration page asks if you want to be subscribed to this list? Will do. As I understood it, this experiment was performed at the request of people on the ietf discussion mailing list. Nope. It was my attempt to provide *useful*, *important* info to attendees only, and a list to send a meeting survey sometime after the meeting. I did not implement it well. That list is _not_ the appropriate place to talk about cookie shortages, mail and netowrk problems and issues with the hotel, _either_. Since the registration page already has a number of questions it ask about things we might or might not want to do. Why not add one more - and assume the default answer is no? I like the idea of having a separate list because it allows me to decide quickly what I can safely ignore most of the time. -- Eric -- -Original Message- -- From: Ray Pelletier [mailto:[EMAIL PROTECTED] -- Sent: Monday, July 10, 2006 10:53 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: Re: The IETF 66 Attendees Alias -- -- Alan, et al. -- Message received. -- I agree. -- Changes being made. -- Experiment provided valuable information. -- Sorry for the pain. -- Ray -- IAD -- -- -- Alan Hawrylyshen wrote: -- -- Folks; -- -- I understand the utility and need for the administrative -- staff to have -- a mailing alias for all registered delegates for the 66th -- IETF event. -- However, in all the meetings I have attended - which is -- more than a -- few, but less than most of you - I have never been -- deluged with such a -- volume of non-critical announcements in my main inbox. -- -- I hope that people will understand my strong desire and sympathize -- with my point of view when I request that all general -- IETF messages be -- posted uniquely to the IETF general list and that this address be -- reserved only for the critical or emergency announcements by the -- administrative staff. One step better would be for this -- address to be -- moderated so we no longer receive various complaints about water -- closets and wifi unless we seek them out on the IETF -- discussion lists. -- :-) -- -- Perhaps if there is a strong desire to have a 'hallway or -- watercooler -- style' list for discussions pertaining uniquely to IETF -- 66 attendees, -- we could create a NEW mailing list that is OPT-IN called -- 66attendees-chat (or similar) at ietf.org. I'd even -- volunteer to set -- one up (at a different domain of course) for the duration -- of IETF 66. -- -- My sincere apologies if I have misunderstood the purpose of the -- 66attendees address but my BlackBerry is going crazy with -- things that -- I would not normally choose to have in my commercial, -- corporate email -- box. -- -- Respectfully, -- -- Alan Hawrylyshen -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: My notes from this morning at breakfast
On 11 jul 2006, at 09.07, Spencer Dawkins wrote: This was NOT intended for general distribution - my apologies... perhaps, but the timely transparency was refreshing. thanks for the error. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF 66 Attendees Alias
Please, take the opportunity that you are going to modify the registration page to remind about the invoices. In many economies/accounting systems, if you don't have an invoice, you can't account (legally speaking) the cost of the IETF attendance. I've been asking for this for more than 3 years already ... Hopefully now is going to happen ! I've been already in the case where auditors reject it and needed to pay from my own pocket instead of the company expenses. I think there is no excuse at all for IETF not doing so. Actually, and this is not fault, there is not excuse at all for not having done this just right after the first request 3 years ago or even sooner (if somebody else requested first). Regards, Jordi De: Ray Pelletier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 11 Jul 2006 11:14:23 -0400 Para: Gray, Eric [EMAIL PROTECTED] CC: [EMAIL PROTECTED], ietf@ietf.org Asunto: Re: The IETF 66 Attendees Alias Gray, Eric wrote: Ray, May I make a suggestion for the next time around? How about if the registration page asks if you want to be subscribed to this list? Will do. As I understood it, this experiment was performed at the request of people on the ietf discussion mailing list. Nope. It was my attempt to provide *useful*, *important* info to attendees only, and a list to send a meeting survey sometime after the meeting. I did not implement it well. That list is _not_ the appropriate place to talk about cookie shortages, mail and netowrk problems and issues with the hotel, _either_. Since the registration page already has a number of questions it ask about things we might or might not want to do. Why not add one more - and assume the default answer is no? I like the idea of having a separate list because it allows me to decide quickly what I can safely ignore most of the time. -- Eric -- -Original Message- -- From: Ray Pelletier [mailto:[EMAIL PROTECTED] -- Sent: Monday, July 10, 2006 10:53 PM -- To: [EMAIL PROTECTED] -- Cc: ietf@ietf.org -- Subject: Re: The IETF 66 Attendees Alias -- -- Alan, et al. -- Message received. -- I agree. -- Changes being made. -- Experiment provided valuable information. -- Sorry for the pain. -- Ray -- IAD -- -- -- Alan Hawrylyshen wrote: -- -- Folks; -- -- I understand the utility and need for the administrative -- staff to have -- a mailing alias for all registered delegates for the 66th -- IETF event. -- However, in all the meetings I have attended - which is -- more than a -- few, but less than most of you - I have never been -- deluged with such a -- volume of non-critical announcements in my main inbox. -- -- I hope that people will understand my strong desire and sympathize -- with my point of view when I request that all general -- IETF messages be -- posted uniquely to the IETF general list and that this address be -- reserved only for the critical or emergency announcements by the -- administrative staff. One step better would be for this -- address to be -- moderated so we no longer receive various complaints about water -- closets and wifi unless we seek them out on the IETF -- discussion lists. -- :-) -- -- Perhaps if there is a strong desire to have a 'hallway or -- watercooler -- style' list for discussions pertaining uniquely to IETF -- 66 attendees, -- we could create a NEW mailing list that is OPT-IN called -- 66attendees-chat (or similar) at ietf.org. I'd even -- volunteer to set -- one up (at a different domain of course) for the duration -- of IETF 66. -- -- My sincere apologies if I have misunderstood the purpose of the -- 66attendees address but my BlackBerry is going crazy with -- things that -- I would not normally choose to have in my commercial, -- corporate email -- box. -- -- Respectfully, -- -- Alan Hawrylyshen -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: My notes from this morning at breakfast
Avri Doria wrote: This was NOT intended for general distribution - my apologies... perhaps, but the timely transparency was refreshing. thanks for the error. +1 d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IPv6 troubles
Today again someone took it upon themselves to send out router advertisements even though they're not a legitimate IPv6 router, with broken IPv6 connectivity as a result. On the Mac, where IPv6 is enabled by default, so apparent but non- working IPv6 connectivity is extremely annoying, you can see this with: ndp -an NeighborLinklayer Address Netif ExpireSt Flgs Prbs ::1 (incomplete) lo0 permanent R [...] fe80::204:23ff:fe50:c11d%en00:4:23:50:c1:1d en0 23h48m39s S R fe80::206:d6ff:fe0f:b806%en00:6:d6:f:b8:6en0 23h59m42s S R fe80::20a:95ff:fecd:987a%en00:a:95:cd:98:7a en0 permanent R fe80::212:f0ff:fe5f:c4ec%en00:12:f0:5f:c4:ec en0 23h52m15s S R An R flg indicates a router, with fe80::206:d6ff:fe0f:b806 being the real one. You can filter out the unwanted router advertisements with: sudo ip6fw add 10 permit ipv6-icmp from fe80::206:d6ff:fe0f:b806 to any icmptypes 134 in sudo ip6fw add 20 drop ipv6-icmp from any to any icmptypes 134 in And if you already have broken connectivity, filtering all ICMP messages towards the router in question will kickstart dead neighbor detection: sudo ip6fw add 30 drop ipv6-icmp from fe80::204:23ff:fe50:c11d to any Shortly after this you can enjoy the fabulous IPv6 connectivity that the IETF66 meeting has to offer: traceroute6 to www.ietf.org (2001:503:c779:b::d1ad:35b4) from 2001:510:102:100:20a:95ff:fecd:987a, 30 hops max, 12 byte packets 1 2001:510:102:100:206:d6ff:fe0f:b806 7.125 ms 0.668 ms 0.561 ms 2 2001:510:100:100::84ca:1c8 0.765 ms !N 0.944 ms !N 3.284 ms !N traceroute6 to www.isc.org (2001:4f8:0:2::d) from 2001:510:102:100:20a:95ff:fecd:987a, 30 hops max, 12 byte packets 1 2001:510:102:100:206:d6ff:fe0f:b806 2.201 ms 7.626 ms 1.444 ms 2 2001:410:101:13::1 1.846 ms 1.736 ms 3.85 ms 3 2001:410:101:5::1 24.331 ms 24.983 ms 102.792 ms 4 2001:410:101:30::2 239.214 ms 96.351 ms 96.318 ms 5 2001:320:1b00:1::1 210.57 ms 210.528 ms 210.714 ms 6 2001:320:1a05::10 211.26 ms 220.1 ms 210.472 ms 7 2001:320:1a05::20 211.47 ms 254.317 ms 211.431 ms 8 2001:320:1a09::1 214.655 ms 214.478 ms 214.43 ms 9 2001:320:1a07::2 216.013 ms 216.143 ms 215.784 ms 10 2001:2b8:5:10::2 214.027 ms 228.96 ms 214.316 ms 11 2001:220:1000:42e::2 214.341 ms 220.359 ms 214.777 ms 12 2001:220:1000:400::1 217.728 ms 217.345 ms 217.12 ms 13 2001:220:400:200::1 219.455 ms 266.643 ms 219.859 ms 14 2001:220:1800:200::1 220.861 ms 223.042 ms 391.591 ms 15 3ffe:8140:101:1a::162 228.454 ms 228.31 ms 227.647 ms 16 2001:200:901:1036::2 266.8 ms 228.512 ms 239.632 ms 17 2001:200:901:7::18 228.109 ms 228.281 ms 228.358 ms 18 as2914.nspixp6.net.wide.ad.jp 289.724 ms 288.772 ms 288.343 ms 19 ge-7-0-0.a20.tokyjp01.jp.ra.gin.ntt.net 288.219 ms 288.992 ms 292.174 ms 20 xe-0-0-0.r20.tokyjp01.jp.bb.gin.ntt.net 287.444 ms 289.068 ms 287.622 ms 21 p64-2-3-0.r21.mlpsca01.us.bb.gin.ntt.net 308.109 ms 305.339 ms 304.836 ms 22 xe-0-2-0.r21.plalca01.us.bb.gin.ntt.net 425.596 ms p64-0-0-0.r21.plalca01.us.bb.gin.ntt.net 319.325 ms 304.013 ms 23 p16-1-0-0.r00.plalca01.us.bb.gin.ntt.net 304.464 ms 338.699 ms 305.647 ms 24 p1-0.isc.plalca01.us.bb.gin.ntt.net 318.962 ms 306.91 ms 303.59 ms 25 www.isc.org 306.776 ms 305.18 ms 304.959 ms IPv4: traceroute to www.isc.org (204.152.184.88), 64 hops max, 40 byte packets 1 h0003-net84db (132.219.0.3) 1.761 ms 0.492 ms 0.352 ms 2 ericsson1-internet.dmtrl-uq.risq.net (132.202.60.65) 0.473 ms 0.515 ms 0.416 ms 3 amtrl-rq.risq.net (192.77.63.49) 0.418 ms 0.475 ms 0.438 ms 4 192.77.63.37 (192.77.63.37) 0.417 ms 0.542 ms 0.411 ms 5 vlan254.msfc2.mtt-montreal.teleglobe.net (66.198.80.1) 0.607 ms 0.647 ms 1.661 ms 6 if-10-0.core1.mtt-montreal.teleglobe.net (207.45.221.129) 1.189 ms 0.594 ms 0.587 ms 7 if-1-3.mcore4.nqt-newyork.teleglobe.net (66.198.81.14) 82.572 ms 82.549 ms 82.575 ms 8 if-4-0.mcore4.pdi-paloalto.teleglobe.net (216.6.86.13) 105.497 ms 83.140 ms 82.882 ms 9 if-7-0.core3.pdi-paloalto.teleglobe.net (216.6.86.2) 82.927 ms 82.929 ms 82.809 ms 10 ix-4-6.core3.pdi-paloalto.teleglobe.net (207.45.196.66) 83.162 ms 82.964 ms 83.226 ms 11 external.isc.org (204.152.184.88) 92.539 ms 82.764 ms 82.776 ms ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Bad IPv6 connectivity to commercial networks
On Tue, 11 Jul 2006, Iljitsch van Beijnum wrote: traceroute6 to www.isc.org (2001:4f8:0:2::d) from 2001:510:102:100:20a:95ff:fecd:987a, 30 hops max, 12 byte packets 1 2001:510:102:100:206:d6ff:fe0f:b806 2.201 ms 7.626 ms 1.444 ms 2 2001:410:101:13::1 1.846 ms 1.736 ms 3.85 ms 3 2001:410:101:5::1 24.331 ms 24.983 ms 102.792 ms 4 2001:410:101:30::2 239.214 ms 96.351 ms 96.318 ms 5 2001:320:1b00:1::1 210.57 ms 210.528 ms 210.714 ms 6 2001:320:1a05::10 211.26 ms 220.1 ms 210.472 ms 7 2001:320:1a05::20 211.47 ms 254.317 ms 211.431 ms 8 2001:320:1a09::1 214.655 ms 214.478 ms 214.43 ms 9 2001:320:1a07::2 216.013 ms 216.143 ms 215.784 ms FWIW, I complained about this issue (lack of commercial peering/transit, e.g., NTT or GBLX or their customers) to RISQ and Canarie (v6 upstreams) on Saturday, but have seen no response or improvement. Routing to Europe or the US through various networks in Japan leaves room to improvement.. (Connectivity to academic networks is excellent, though..) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by JFC Morfin dated 2006-02-17
Hi, I do not wish to enter the substance of this appeal for i am qualified neither by position nor training to adjudicate on the justice of an appeal. But I do want to question one paragraph that has been published on behalf of the leadership of this organization. This questioning is not in relation to the appeal itself, but rather to the acceptability of the statement in itself. On 10 jul 2006, at 14.05, IESG Secretary wrote: Secondly, the IESG believes that the Universal Declaration of Human Rights does not apply to the IETF's internal rules. IETF participants are assumed to be aware of IETF process rules before choosing to participate, and their participation is voluntary. Without making any personal judgement about the correctness of such a hypothetical claim, I could understand an IESG decision that the Universal Declaration of Human Rights (UDHR) did not apply in this particular case. I do not, however, understand a categorical statement to the effect that the IETF, with its rules, is not subject to the UDHR because it is a voluntary association. While the IETF itself is not a signatory to the UDHR, most, if not all, of the nations in which the IESG members live are signatories and the host country of the ISOC corporation, the IETF umbrella, is also a signatory. I believe that in all things we do, we are always subject to the UDHR. And I worry about an organization, especially one I believe in, making a categorical claim that human rights, as defined by the UDHR, do not apply within this organization. We may be here to do technical work, but we should, in my opinion, never leave the responsibilities of humanity at the door. To claim that something so fundamental as human rights do not apply within the confines of the IETF is too all encompassing a statement, and one I don't feel can be allowed to stand without at least a little protest. To quote Eleanor Roosevelt The destiny of human rights is in the hands of all our citizens in all our communities . I think this applies to the IETF community as much as it does to any other community. I hope that the IAB, whatever it may decide on the merits of the appeal in question, will see fit to repudiate the claim that the UDHR does apply to the IETF or its rules. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by JFC Morfin dated 2006-02-17 - 2006-05-17.
On 11-Jul-2006, at 05:32, Dean Anderson wrote: BTW, the IESG response implied that the allegations of scientific fraud were (somehow) not substantiated. I haven't seen these specific complaints voiced with this clarity before (maybe I overlooked some mail). Perhaps this is a good opportunity to dispense some additional perspective. [...] What the full community may not know, [but ISC, RIPE, Joe Abley, David Kessens, Brian Carpenter, and the IESG do know], is that the report claiming that stateful anycast was stable was fabricated, and that no stateful testing was performed by the DNSMON program. Contrary to assurances given by Karrenberg, there is no data which supports the notion that stateful DNS Anycast is safe, nor any data that disputes data and assertions that show DNS Anycast is unsafe. I don't believe the fact that DNSMON sends all its probe queries using UDP transport is news to anybody. It's certainly not a secret, as you have aptly illustrated by looking at the source code, which is freely available. I was in the meeting in Seattle where Daniel presented his analysis of DNSMON and RIS data in an attempt to draw conclusions about the stability of various nameservers which had been distributed using anycast. The approach Daniel took (which was analogous to earlier work presented by Verisign and also the work done by Peter Booth at the University of Oregon) was to look at measurements which had already been made by the NCC's DNSMON project, and try to identify whether individual DNSMON probes saw oscillations in node selection over time and if so, with what frequency. It is possible to identify oscillations in node selection from individual probes without using TCP transport. (In fact, it seems to me that it's easier to acquire unambiguous results using UDP transport, since if there *are* node oscillations which would damage TCP, measurements using TCP would simply indicate failure without revealing the nature of the oscillation.) However, from what I could tell from Daniel's presentation, the fact that UDP transport was used by DNSMON was a simple result of the fact that UDP measurement data is what was already stored, and hence that was the data that was available for analysis. I can find no example of Daniel (or anybody else) claiming that DNSMON in general, or the data which formed the basis of Daniel's NANOG presentation in particular, resulted from DNS queries made using TCP transport. The only person suggesting otherwise is you. Surely this whole issue is a red herring. Now put this in context along with repeated assertions from Joe Abley and others associated with ISC and RIPE that stateful anycast is safe and even non-controversial. More history is found at http://www.av8.net/IETF-watch/DNSRootAnycast/History.html I fully support continued measurement of services which have been distributed using anycast. I make no claims that anycast is definitively safe for protocols and services which don't involve trivial, stateless transactions. The document draft-ietf-grow-anycast-04 goes to great lengths to describe considerations in protocol/transaction and network characteristics which should be well understood before anycast is chosen as a service distribution mechanism. Kurtis and my slides in the open ops area meeting this afternoon will repeat the message that unicast is not a universally applicable strategy. However, I also don't presume to say that (for example) protocols based on TCP are always unsafe for deployment using anycast in all possible networks. For example, there are people using anycast to distribute services using very long-held sessions (e.g. internet radio, HTTP) with great success, and to ignore their experience and success would be idiotic and arbitrary. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: When did the ID drafts index disappear
Phill, The addresses to which one should report problems are not insider information; they are displayed at the Secretariat page right off the home page. As for reorganizing the web site, yes, it would be nice to have the resources to do that. Brian Hallam-Baker, Phillip wrote: Brian, Its not just the disappearing link to the abstracts, it's the entire organization of the site and the attitude that anyone that has any business working with the IETF already knows where everything is. I don't like playing twenty questions to find pieces of information that should be presented clearly. You reply with yet another piece of insider information. The Web site is the front door to the organization. For the past ten years it has been treated as an afterthought. Phill -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 4:25 PM To: Hallam-Baker, Phillip Cc: Andrew G. Malis; ietf Mailing List Subject: Re: When did the ID drafts index disappear So, Phill, how about a polite note to [EMAIL PROTECTED] or [EMAIL PROTECTED] suggesting that they add a link to 1id-abstracts.txt and to the ftp directory to the page at http://www.ietf.org/ID.html? Incidentally, if you type 'abstracts' into the search box at www.ietf.org, the first hit is the 1id-abstracts page. Brian Hallam-Baker, Phillip wrote: I start at the IETF home page, go to the ID drafts page Look for the abstracts and all I can find is the database interface. If its not in the index it does not exist. From: Andrew G. Malis [mailto:[EMAIL PROTECTED] Sent: Monday, July 10, 2006 12:39 PM To: Hallam-Baker, Phillip Cc: ietf Mailing List Subject: Re: When did the ID drafts index disappear Phillip, Did you mean http://www.ietf.org/internet-drafts/1id-abstracts.txt ? It's still there, as always. 1id-index.txt is also there. Cheers, Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by JFC Morfin dated 2006-02-17
Hi Avri, all, I totally agree on this. In fact, I've sent similar comments about this statement to Brian yesterday when read the appeal response email. All the organizations are oblige by higher lever laws, which can never be ignored or even challenged with this kind of statement, and we should be in the IETF case even more serious and careful because the international participation. I'm not a lawyer and may be wrong, but I even think this is common sense (w/o entering on the discussion about what is common sense, by the way). Regards, Jordi De: Avri Doria [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 11 Jul 2006 14:17:33 -0400 Para: ietf@ietf.org Asunto: Re: Response to the Appeal by JFC Morfin dated 2006-02-17 Hi, I do not wish to enter the substance of this appeal for i am qualified neither by position nor training to adjudicate on the justice of an appeal. But I do want to question one paragraph that has been published on behalf of the leadership of this organization. This questioning is not in relation to the appeal itself, but rather to the acceptability of the statement in itself. On 10 jul 2006, at 14.05, IESG Secretary wrote: Secondly, the IESG believes that the Universal Declaration of Human Rights does not apply to the IETF's internal rules. IETF participants are assumed to be aware of IETF process rules before choosing to participate, and their participation is voluntary. Without making any personal judgement about the correctness of such a hypothetical claim, I could understand an IESG decision that the Universal Declaration of Human Rights (UDHR) did not apply in this particular case. I do not, however, understand a categorical statement to the effect that the IETF, with its rules, is not subject to the UDHR because it is a voluntary association. While the IETF itself is not a signatory to the UDHR, most, if not all, of the nations in which the IESG members live are signatories and the host country of the ISOC corporation, the IETF umbrella, is also a signatory. I believe that in all things we do, we are always subject to the UDHR. And I worry about an organization, especially one I believe in, making a categorical claim that human rights, as defined by the UDHR, do not apply within this organization. We may be here to do technical work, but we should, in my opinion, never leave the responsibilities of humanity at the door. To claim that something so fundamental as human rights do not apply within the confines of the IETF is too all encompassing a statement, and one I don't feel can be allowed to stand without at least a little protest. To quote Eleanor Roosevelt The destiny of human rights is in the hands of all our citizens in all our communities . I think this applies to the IETF community as much as it does to any other community. I hope that the IAB, whatever it may decide on the merits of the appeal in question, will see fit to repudiate the claim that the UDHR does apply to the IETF or its rules. a. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IAOC Office hour
All - The IASA presentations will be part of Wednesday nights plenary and we plan to hold an open office hour Thursday afternoon. If you have follow up questions or comments please drop by. IAOC Office - Room 521c Thursday July 13th 1550-1650 office hour (overlaps the 1610-1700 Break) Lucy E. Lynch Academic User Services Computing CenterUniversity of Oregon llynch @darkwing.uoregon.edu (541) 346-1774 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by JFC Morfin dated 2006-02-17
I don't think the IESg intended to imply that the IETF does not care about human rights. The IETF does have its own process rules intended to insure fairness, and section 6.5.3 of RFC 2026 provides relief in cases where those rules are inadequate. However the IESG at least believes that while the spirit of the UDHR applies to the IETF, the letter of the law does not. In other words, I personally believe it would have been more reasonable for Jefsey to complain that the process was not fair using the UDHR as a example of fairness rather than to directly refer to the UDHR. It is my personal opinion that Jefsey was trying to be legalistic, and the IESG was legalistic in its response. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to the Appeal by JFC Morfin dated 2006-02-17
At 21:41 11/07/2006, Sam Hartman wrote: It is my personal opinion that Jefsey was trying to be legalistic, and the IESG was legalistic in its response. Dear Sam, I only want one single thing: interoperability between the internet of the users and the RFC 3935 IETF Internet as long as it survives. Between a Multilingual, Multicultural, Multilateral, Multinational, Multitechnology etc. Internet and the outdated Internationalized Internet which delays it for reasons the IAB clarified a long ago in RFC 3869. RFC 3935 says The mission of the IETF is to produce ... documents that influence the way people design, use, and manage the Internet ... [] The Internet isn't value-neutral, and neither is the IETF. We want the Internet to be useful for communities that share our commitment to openness and fairness. We embrace technical concepts such as decentralized control, edge-user empowerment and sharing of resources, because those concepts resonate with the core values of the IETF community. These concepts have little to do with the technology that's possible, and much to do with the technology that we choose to create. I wanted the IESG to clearly state what are the core values of the IETF community and their legitimacy to influence the world. Because they have little to do with the technology that's possible, and much to do with the technology that the IETF leaders (cf. RFC 3935) and the IESG choose to create. I wanted the IESG to document what it considers as openness and fairness. To show our core difference. Because the technology that is possible and I choose to create has much to do with human rights and I believe it is technically far more efficient for that very reason. The reason why we oppose is described in http://nicso.org/equilang.htm the WG-LTRU opposed. Legalistic, elastic, autocratic... I know of no other way to consider the HR for technicians than what they must live by to make sure the technology they produce will work better for the human beings. A nd will eventually lead to better economic development. Also, I know of no other way to respond an appeal than to speak the Truth. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF 66 Attendees Alias
On 11-Jul-2006, at 11:14, Ray Pelletier wrote: Nope. It was my attempt to provide *useful*, *important* info to attendees only, and a list to send a meeting survey sometime after the meeting. I did not implement it well. More feedback for you on the implementation: the mail that was sent on to the 66 attendees alias contained no useful header which could be used by (e.g.) sieve or procmail to reduce some of the pain involved in receiving the mail. For example, there was no List-Id: header, and no Sender: header. There was a Received: header which included the string 66attendees, but that seems like pretty weak regex-food. Whatever is done in future, it would be good if all lists/aliases/ whatever included something like a List-Id: header as a matter of routine. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF 66 Attendees Alias
Joe Abley wrote: On 11-Jul-2006, at 11:14, Ray Pelletier wrote: Nope. It was my attempt to provide *useful*, *important* info to attendees only, and a list to send a meeting survey sometime after the meeting. I did not implement it well. More feedback for you on the implementation: the mail that was sent on to the 66 attendees alias contained no useful header which could be used by (e.g.) sieve or procmail to reduce some of the pain involved in receiving the mail. For example, there was no List-Id: header, and no Sender: header. There was a Received: header which included the string 66attendees, but that seems like pretty weak regex-food. Whatever is done in future, it would be good if all lists/aliases/ whatever included something like a List-Id: header as a matter of routine. Concur. Ray Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'OCSP Extensions to IKEv2' to Proposed Standard (draft-myers-ikev2-ocsp)
The IESG has received a request from an individual submitter to consider the following document: - 'OCSP Extensions to IKEv2' draft-myers-ikev2-ocsp-02.txt as a Proposed Standard While IKEv2 supports public key based authentication (PKI), the corresponding use of in-band CRLs is problematic due to unbounded CRL size. The size of an OCSP response is however well-bounded and small. This document defines two extensions to IKEv2 which enable the use of OCSP for in-band signaling of certificate revocation status. Two new content encodings are defined for use in the CERTREQ and CERT payloads: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash CERTREQ payload triggers transmission of an OCSP Response CERT payload. When certificates are used with IKEv2, the communicating peers need a mechanism to determine the revocation status of the peer's certificate. OCSP is one such mechanism. This document applies when OCSP is desired and security policy prevents one of the IKEv2 peers from accessing the relevant OCSP responder directly. Firewalls are often deployed in a manner that prevents such access by IKEv2 peers outside of an enterprise network. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-myers-ikev2-ocsp-02.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Adding WAE Jabber Room at 12:00noon ET (1 minute downtime)
Adding WAE jabber room at 12:00noon ET (1 minute downtime) ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'IMAP4 extension to SEARCH command for controlling what kind of information is returned' to Proposed Standard (draft-melnikov-imap-search-ret)
The IESG has received a request from an individual submitter to consider the following document: - 'IMAP4 extension to SEARCH command for controlling what kind of information is returned ' draft-melnikov-imap-search-ret-03.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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-08. Please note that the document gives an extension of X-DRAFT-I02-ESEARCH; this is a placeholder for a value to be assigned by IANA. The file can be obtained via http://www.ietf.org/internet-drafts/draft-melnikov-imap-search-ret-03.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'EAP Password Authenticated Exchange' to Informational RFC (draft-clancy-eap-pax)
The IESG has received a request from an individual submitter to consider the following document: - 'EAP Password Authenticated Exchange ' draft-clancy-eap-pax-08.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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-08-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-clancy-eap-pax-08.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
