Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Fred Baker writes: I'm not sure I agree that Friday is a problem; the problem is that we have N working groups asking for M meetings and N*M needs to be = that fixed number. Friday is a solution, one that has certain downsides. Stanislaus doesn't like the solution and IMHO has not proposed a solution that tells us how to better manage the demands on the resource. The hotel has X meeting rooms, and X is known when the location is announced. If N*M/X=4 and the increased density doesn't lead to more problems than Friday does, then Friday is unnecessary for that particular meeting. Right now, the agenda is based on the chairs' perceptions of conflicts. It could be based on registrants' wishes, instead, which I think will permit a higher degree of parallelism without an increase in conflicts. That is, when you register, you click which WGs you really want to attend and which ones are also interesting, and the agenda is computed from that. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Arnt Gulbrandsen allegedly wrote on 11/11/2009 6:08 PM: Fred Baker writes: I'm not sure I agree that Friday is a problem; the problem is that we have N working groups asking for M meetings and N*M needs to be = that fixed number. Friday is a solution, one that has certain downsides. Stanislaus doesn't like the solution and IMHO has not proposed a solution that tells us how to better manage the demands on the resource. The hotel has X meeting rooms, and X is known when the location is announced. If N*M/X=4 and the increased density doesn't lead to more problems than Friday does, then Friday is unnecessary for that particular meeting. Even a full Friday isn't enough to remove the conflicts. In fact I'm triple-booked on Friday itself. There is no chance the IETF will fit in 4 days. That hasn't been possible for years. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Virtual Open Mike for NomCom :-)
Hi, Mary, I was really surprised this year when NomCom announced local interview slots wherever the NomCom members were, thought to myself that I should arrange for one of the interviews, and then got busy, left the country, etc. ... But I'd like to thank you guys for making this offer. You mentioned in your report tonight that you hadn't had a lot of people request slots locally - I hope you can talk about this process a little in your final report in March, because I hope future NomComs might also make this offer as well, if it's the right thing to do. Thanks, Spencer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Scott Brim writes: Even a full Friday isn't enough to remove the conflicts. In fact I'm triple-booked on Friday itself. There is no chance the IETF will fit in 4 days. That hasn't been possible for years. Why do so many people in WG meetings read mail, look bored and hardly say a word, then? Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
I read mail and listen and look at the slides, when I'm in a session that is secondary to my main interests. That doesn't mean I'm bored (maybe I always look bored), but I don't see that it affects the question whether we can fit all the parallel sessions into 4.5 days. Brian On 2009-11-11 22:23, Arnt Gulbrandsen wrote: Scott Brim writes: Even a full Friday isn't enough to remove the conflicts. In fact I'm triple-booked on Friday itself. There is no chance the IETF will fit in 4 days. That hasn't been possible for years. Why do so many people in WG meetings read mail, look bored and hardly say a word, then? Arnt ___ 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: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Arnt Gulbrandsen allegedly wrote on 11/11/2009 6:23 PM: Scott Brim writes: Even a full Friday isn't enough to remove the conflicts. In fact I'm triple-booked on Friday itself. There is no chance the IETF will fit in 4 days. That hasn't been possible for years. Why do so many people in WG meetings read mail, look bored and hardly say a word, then? Because Stanislav is at the mike :-) ... Seriously, are you suggesting that it might be possible to cluster WGs together so that people can stay for parts of the week? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Updated logistics and agenda for Smart Grid Bar BOF at IETF 76
There was an error in the reservation announcement. When I first set it up, I managed to hit the wrong date, and so I set up a correct one. The error was sent to the list earlier; it's still an error. oops Here is the correct data. Begin forwarded message: From: Frederick Baker messen...@webex.com Date: November 8, 2009 1:03:32 PM JST To: f...@cisco.com Subject: (Forward to attendees) Meeting invitation: Smart Grid IETF Bar BOF Reply-To: f...@cisco.com You can forward this email invitation to attendees Hello , Frederick Baker invites you to attend this online meeting. Topic: Smart Grid IETF Bar BOF Date: Wednesday, November 11, 2009 Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00) Meeting Number: 201 328 939 Meeting Password: smartgrid --- To join the online meeting (Now from iPhones too!) --- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=128776627UID=0PW=NZTViNTIwYzFhRT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: smartgrid 4. Click Join Now. To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/j.php?ED=128776627UID=0PW=NZTViNTIwYzFhORT=MiM0OQ%3D%3D ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes The affected toll free numbers are: (866) 432-9903 for the San Jose/ Milpitas area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 --- To join the teleconference only --- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350. Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 --- For assistance --- 1. Go to https://ciscosales.webex.com/ciscosales/mc 2. On the left navigation bar, click Support. You can contact me at: f...@cisco.com 1-408-526 4257 To add this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ciscosales.webex.com/ciscosales/j.php?ED=128776627UID=0ICS=MILD=1RD=2ST=1SHA2=OPRSuEQjxcIW1i8IRtMp/EUOrwEVTnOuxF2HObLGnx4=RT=MiM0OQ%3D%3D The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ciscosales.webex.com/ciscosales/systemdiagnosis.php Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
Scott Brim writes: Seriously, are you suggesting that it might be possible to cluster WGs together so that people can stay for parts of the week? I hadn't thought of that... No, I was suggesting that if registrants explicitly say which WGs are really interesting (conflicts in that set spoil my trip) and which are less interesting (I'll attend those since I'm there anyway), then it may be possible to use more meeting rooms for a shorter period, without spoiling people's trips. It really depends on how many people would include forty WGs in the really important for me set. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
On Nov 11, 2009, at 5:01 AM, Arnt Gulbrandsen wrote: Scott Brim writes: Seriously, are you suggesting that it might be possible to cluster WGs together so that people can stay for parts of the week? Of course it might be possible - in fact, I would assert that it is highly likely to be possible. Many organizations do this. With the RFID blue sheet data it would be pretty straightforward to do a cluster analysis and see if (say) RAI and Routing area attendees are disjoint enough that you could have RAI at the beginning of the week, RA at the end, and spread the load out. I would personally be surprised if a cluster analysis or principal component analysis of the RFID data didn't reveal some means of separating the meeting sessions like this. Whether this is a good idea is another matter. Regards Marshall I hadn't thought of that... No, I was suggesting that if registrants explicitly say which WGs are really interesting (conflicts in that set spoil my trip) and which are less interesting (I'll attend those since I'm there anyway), then it may be possible to use more meeting rooms for a shorter period, without spoiling people's trips. It really depends on how many people would include forty WGs in the really important for me set. Arnt ___ 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
If you found today's plenary debate on standards track tedious...
Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF Plenary Discussions
Russ, Olaf, et al, I was serious in my recommendation to experiment with limiting question (comment) time at the microphone at plenaries. I believe it'll not only help mere mortals pay more attention, but will also encourage those folks that have questions or comments to be more concise, thereby keeping the audience better engaged. I honestly mean no disrespect and appreciate the wealth of institutional knowledge that's on hand and frequently shared, I just believe that it'd be more effective use of such precious time (and encourage more discussions on this list :-). -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
Brian E Carpenter wrote: Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits-all-01.txt Typically, it's better to gain some agreement about tradeoffs among some choices, prior to starting lobbying for a particular choice. This has the distinct advantage of allowing the community to know why it rejected alternatives. And /that/ has the advantage of avoiding morning-after regret. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... --Richard On Nov 11, 2009, at 7:25 PM, Brian E Carpenter wrote: Who would like to adopt this idea: http://tools.ietf.org/id/draft-loughney-newtrk-one-size-fits- all-01.txt Brian ___ 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: IETF Plenary Discussions
+1 Stephan On 11/11/09 7:53 PM, Danny McPherson da...@tcb.net wrote: Russ, Olaf, et al, I was serious in my recommendation to experiment with limiting question (comment) time at the microphone at plenaries. I believe it'll not only help mere mortals pay more attention, but will also encourage those folks that have questions or comments to be more concise, thereby keeping the audience better engaged. I honestly mean no disrespect and appreciate the wealth of institutional knowledge that's on hand and frequently shared, I just believe that it'd be more effective use of such precious time (and encourage more discussions on this list :-). -danny ___ 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: If you found today's plenary debate on standards track tedious...
Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
On Wed, Nov 11, 2009 at 05:08:44AM -0500, Marshall Eubanks wrote: I would personally be surprised if a cluster analysis or principal component analysis of the RFID data didn't reveal some means of separating the meeting sessions like this. Whether this is a good idea is another matter. Indeed, I thought the primary argument for the Big Giant Meeting was supposed to be that cross-pollination of areas and WGs was beneficial. If we then try to schedule things so that people can conveniently come for just a few days (and, presumably, use the day passes that have just been invented), then that purported benefit goes away. In that case, I predict we'd quickly move to WG- or area-specific meetings with no or fewer Big Giant Meetings. (I am agnostic on whether that's a good idea, but it might be.) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
Not THIS again. Let's look at a few of the standards that are commonly used today: HTTP: DS SNTP: PS SIP: PS IPv6 Addressing Architecture: DS SMTP: DS Full standard MPLS-VPNs: PS BGPv4: DS MIME: DS XMPP: PS (although it seems the real work goes on elsewhere) OSPF: Full standard RIPv2: full standard BFD: not to be found VRRP: DS Radius: DS DNS base: full standard DNS components: varying SNMPv3: full (but long before anyone actually used it) And so you will forgive people who seem confused by our quaint notion that there are flavors of standards. We don't do a good job of describing maturity with our standards levels. Perhaps we do a good job of using the standards levels to make a recommendation. How much SNMPv1 and v2 is out there still? Apparently not many people are listening to that recommendation. Does standard matter at all any more? I think so. A good number of the base protocols that are run on the computer I type this from are actually IETF standards. Yeah (except for software and device management. We blew, and continue to blow that one). So let's get real. John's draft was the right thing to do for NEWTRK. But do we really have the stomach for it? Last time out we did not. Eliot ps: see you all in Orange County, where I'm sure this endless debate will continue. On 11/11/09 5:04 PM, Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ 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: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave == Dave CROCKER d...@dcrocker.net writes: I'm not sure I agree that Friday is a problem; the problem is that we have N working groups asking for M meetings and N*M needs to be = that fixed number. Friday is a solution, one that has certain downsides. Stanislaus doesn't like the solution and IMHO has not proposed a solution that tells us how to better manage the demands on the resource. Dave Establish authorization criteria for meeting slots that are Dave based on demonstrated progress and meeting milestones, along Dave with an agenda that is designed to achieve more progress. Dave Enforce the criteria rigorously. Dave We will then need far fewer meeting slots. +1 What he said. - -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Finger me for keys iQEVAwUBSvr0G4CLcPvd0N1lAQLacgf/YJuqXWMsOoBP0bLvmm/zOnaMl1umb1Mq VP3+arM/te9fgQqn+u4NUkOnfKusV+RCcb5AoBFgZ5QoIySZ/lQEmlgWw2XwkUeu uiOGvWlf5KojJ3IHZyX3ifJVLk2UmOsZKLRBlfFY+vzOpCnXdWrElJqJA2UAFteO MafOE+M7Y0Tvz5KWekten/hn7AsxdJ2rbFM/rcbFfYv+IEahg2dRBV0Rc+3b05eb 3OHosGsMJm+HnmtepJaP63B0MhlollRJdU70uX1t88A4nm5ThM/t9DmJdLxXCglQ UnedSJdZn3/3cZm4pILE7ZajNr990LEbPmjPQNmJ9ru9GVJ0YKjQdA== =bv+T -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technical plenary the last IETF session, like it was before
On Tue, 10 Nov 2009, Stanislav Shalunov wrote: But nobody will come to the technical plenary Friday afternoon! -- 1. We did come to the technical plenary when it was the last thing on Thursday, and it was in the evening. 2. If people won't come to the technical plenary, they won't come to WG meetings. If it's an unsuitable meeting time, we should not put WGs there. I tend to sympathize with this argument. I suppose WG meetings are, from some POV, more important than a plenary. So what if out of 1100 participants we get only 600 at the plenary? Maybe if the attendance drops low enough we could drop the whole plenary. Even better would be putting the administrative plenary there ;-) -- 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://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
+1 you shouldn' need to be an IETF insider to actually understand IETF standards. John Sent from my Nokia N900. - Original message - Not THIS again. Let's look at a few of the standards that are commonly used today: HTTP: DS SNTP: PS SIP: PS IPv6 Addressing Architecture: DS SMTP: DS Full standard MPLS-VPNs: PS BGPv4: DS MIME: DS XMPP: PS (although it seems the real work goes on elsewhere) OSPF: Full standard RIPv2: full standard BFD: not to be found VRRP: DS Radius: DS DNS base: full standard DNS components: varying SNMPv3: full (but long before anyone actually used it) And so you will forgive people who seem confused by our quaint notion that there are flavors of standards. We don't do a good job of describing maturity with our standards levels. Perhaps we do a good job of using the standards levels to make a recommendation. How much SNMPv1 and v2 is out there still? Apparently not many people are listening to that recommendation. Does standard matter at all any more? I think so. A good number of the base protocols that are run on the computer I type this from are actually IETF standards. Yeah (except for software and device management. We blew, and continue to blow that one). So let's get real. John's draft was the right thing to do for NEWTRK. But do we really have the stomach for it? Last time out we did not. Eliot ps: see you all in Orange County, where I'm sure this endless debate will continue. On 11/11/09 5:04 PM, Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ 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: If you found today's plenary debate on standards track tedious...
As I begged at the mike last night, let's make sure that this problem actually causes pain before spending one more second discussing it. Just for completeness :-| There is also the question of standards where we DO NOT WANT people to implement the full standard and say they are through - without PS updates, disaster happens. You don't need to look further than TCP. The full standard (STD007) is only RFC 793, with no slow start, no congestion avoidance ... that stuff is all in PSes. And we can't even add them to STD007, because they aren't full standards. Does this matter? A company that I worked at several years ago thought they were supposed to implement the full standards for TCP and waiting for the other in-process standards to become full standards - that wouldn't work, but we were doing passive network monitoring and not transmitting any packets, so it would have been Mostly Harmless. John told me he had the same experience at HIS company (before he explained that our standards levels are usually meaningless), and they DID transmit packets - they've probably made hundreds of millions of UAs (guess which technology this is), and they would probably have made a pretty serious dent in the Internet if they made another few hundred million UAs that provided HTTP (for example) and implemented TCP without congestion avoidance or slow start. On the other hand, we didn't add congestion avoidance or slow start to TCP until the net actually collapsed LAST time, so maybe that's what it would take for us to decide that fixing the standards track is worth doing. But we need to decide how much pain the standards track as defined today causes first, or we'll go through another round of endless discussions and still have STD007. IMO. Spencer Not THIS again. Let's look at a few of the standards that are commonly used today: HTTP: DS SNTP: PS SIP: PS IPv6 Addressing Architecture: DS SMTP: DS Full standard MPLS-VPNs: PS BGPv4: DS MIME: DS XMPP: PS (although it seems the real work goes on elsewhere) OSPF: Full standard RIPv2: full standard BFD: not to be found VRRP: DS Radius: DS DNS base: full standard DNS components: varying SNMPv3: full (but long before anyone actually used it) And so you will forgive people who seem confused by our quaint notion that there are flavors of standards. We don't do a good job of describing maturity with our standards levels. Perhaps we do a good job of using the standards levels to make a recommendation. How much SNMPv1 and v2 is out there still? Apparently not many people are listening to that recommendation. Does standard matter at all any more? I think so. A good number of the base protocols that are run on the computer I type this from are actually IETF standards. Yeah (except for software and device management. We blew, and continue to blow that one). So let's get real. John's draft was the right thing to do for NEWTRK. But do we really have the stomach for it? Last time out we did not. Eliot ps: see you all in Orange County, where I'm sure this endless debate will continue. On 11/11/09 5:04 PM, Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
I did not take the comment as disrespectful. A timer might be a very good experiment. Russ At 05:53 AM 11/11/2009, Danny McPherson wrote: Russ, Olaf, et al, I was serious in my recommendation to experiment with limiting question (comment) time at the microphone at plenaries. I believe it'll not only help mere mortals pay more attention, but will also encourage those folks that have questions or comments to be more concise, thereby keeping the audience better engaged. I honestly mean no disrespect and appreciate the wealth of institutional knowledge that's on hand and frequently shared, I just believe that it'd be more effective use of such precious time (and encourage more discussions on this list :-). -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
Individuals taking a long time to talk either on the mike or responding on the stage :-) is one problem. At times I wonder if a bigger issue is how long certain topics are discussed. I'm sorry but I just can't get excited about labeling of standards track RFCs, or even about how to get early review from the IESG on documents that advance. The issues are the same as they are for all other documents. If we want early review, get the document to the IESG and have us provide feedback in some documented manner. I'm curious why we end up discussing this stuff in the administrative plenaries. I do not believe we have run out of other things to discuss. For instance, we could have talked about the direction of the v6 transition work in the face of an ever growing set of proposals only slightly different from each other. Or how the IESG handled some BOFs, or the controversies that we have in a number of working groups. Or how the IETF should organize work around some emerging new topics. Did we NOT discuss these topics because we had nothing to say, or because we had been exhausted by the standards ladder discussion? Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART LC review of draft-dusseault-http-patch-15.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-dusseault-http-patch-15.txt
Reviewer: Brian Carpenter
Review Date: 2009-11-12
IETF LC End Date: 2009-11-24
IESG Telechat date:
Summary: Issue with transactional integrity
Comment:
I have not had time to follow all the Last Call comments on the IETF list.
Apologies for any overlap.
Major issues:
-
As far as I can tell, the proposal places the burden for ensuring
atomicity entirely on the server. However, PATCH is explicitly not
idempotent. If a client issues a PATCH, and the server executes the PATCH,
but the client then fails to receive an indication of success due to
an extraneous network glitch (and TCP reset?), then what prevents the client
issuing the same PATCH again? In other words, absent a two-phase commit,
there appears to be no transactional integrity.
If I have understood this correctly, PATCH is not only not safe in
the RFC2616 sense, it is not transactionally safe either, so the state
of the resource after {PATCH, lost response code, PATCH} is undefined.
I don't believe that the non-normative words starting Clients wishing to
apply a patch document to a known entity... are anything like enough to
fix this problem. I don't know enough to know whether some normative text
using ETag is sufficient (it's clear from the draft that If-Unmodified-Since
is insufficient). This doesn't seem easy to fix without adding a
ready to commit/commit exchange, which also needs transaction IDs
(perhaps based on strong ETags) and a new state machine at each end.
I'd be glad to learn that I'm missing something.___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
Adrian, I think both statements are true. I've seen operators putting almost any RFC in RFPs, (actually done it myself) STD, DS, PS, Informational, Experimental, Historic and April 1st. An RFC is an RFC is an RFC! On the other hand talking to folks active in other SDOs you very often hear the no standards argument. Renaming without changing definitions should part of the job. /Loa Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Managerl...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
Didn't Harald put up a timer sometimes during open mike? Tony Hansen Russ Housley wrote: I did not take the comment as disrespectful. A timer might be a very good experiment. Russ At 05:53 AM 11/11/2009, Danny McPherson wrote: Russ, Olaf, et al, I was serious in my recommendation to experiment with limiting question (comment) time at the microphone at plenaries. I believe it'll not only help mere mortals pay more attention, but will also encourage those folks that have questions or comments to be more concise, thereby keeping the audience better engaged. I honestly mean no disrespect and appreciate the wealth of institutional knowledge that's on hand and frequently shared, I just believe that it'd be more effective use of such precious time (and encourage more discussions on this list :-). -danny ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
i am remembering that this is correct. i have a faint memory that the timer might have been per topic (so you cut off the followups and moved to the next question), at least once or twice. i have a faint memory of a lot of things. harald? :-) spencer - Original Message - From: Tony Hansen t...@att.com To: IETF Discussion ietf@ietf.org Sent: Thursday, November 12, 2009 11:11 AM Subject: Re: IETF Plenary Discussions Didn't Harald put up a timer sometimes during open mike? Tony Hansen Russ Housley wrote: I did not take the comment as disrespectful. A timer might be a very good experiment. Russ At 05:53 AM 11/11/2009, Danny McPherson wrote: Russ, Olaf, et al, I was serious in my recommendation to experiment with limiting question (comment) time at the microphone at plenaries. I believe it'll not only help mere mortals pay more attention, but will also encourage those folks that have questions or comments to be more concise, thereby keeping the audience better engaged. I honestly mean no disrespect and appreciate the wealth of institutional knowledge that's on hand and frequently shared, I just believe that it'd be more effective use of such precious time (and encourage more discussions on this list :-). -danny ___ 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
NroffEdit updated with new boilerplate
Short informational notice. A new update of NroffEdit is available ( http://aaa-sec.com/nroffedit/index.html ), supporting the boilerplate from the new Trust Legal Provisions from September 2009. /Stefan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
Tony Hansen allegedly wrote on 11/12/2009 11:11 AM: Didn't Harald put up a timer sometimes during open mike? See attached ... Title: Discussion Timer TimeRemaining 0:00 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
publishing some standards immediately at Draft-Standard status?
One idea discussed over various beverages last night was based on an observation about the high bar that most Proposed Standards have had to pass over in order to become RFCs: many of them would not have gotten to publication without having already gone through interoperability testing. So the idea is that the shepherding files for such I-Ds could include interoperability reports indicating that they *are* already interoperable and have successful operational experience, and then be published directly at Draft Standard status. Tony Hansen t...@att.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Fix the Friday attendance bug: make the technicalplenary the last IETF session, like it was before
I wish to add a specific point to this. I also raised a proposal for over-weekend meetings a few years back. I feel that the attendees to US IETF, which have often predominated, but in the general sense the attendees to IETF who fly for more than 12h to get there, suffer a material disadvantage from the monday-friday timing. We loose two weekends, every IETF. the proposal to shift to mid-week start-end has the material advantage to these people that they now loose only one weekend, as does everyone else. Therefore, from a Benthamite 'maximal good to maximal people' sense, this is a better model. I recognize that very strongly held views, including faith-related issues, lie here. I do not wish to disrespect these beliefs. -George ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT Not Needed To Make Renumbering Easy
Forgive me if I do not see botching the IPSEC spec so that it fails through NAT as an argument against NAT. Why don't we repair the damage instead? If we are serious about the IPv6 transition then we should be insisting that IPSEC work transparently over NAT46 and NAT64. Its easy enough to solve the NAT issue in IPSEC. Just extend the key agreement so that the endpoints inform each other of the IP address that they believe to be in use and store that with the key data required to check the MAC. Then consider fixing up the IP address to be part of the verification function. Problem solved - unless some patent troll has claimed this rather obvious fix. The IETF can choose not to add it to the standard, and thus choose to ensure that IPSEC connectivity remains fragile. But that is a really lousy way to respect your customers. Authenticating the IP address is totally unnecessary from a security point of view, the data can only be checked at the security association endpoint. So if the packet has got there the address can't have been too far wrong. Further the binding of the key to the security association is going to be keyed of the IP source and destination addresses so it is rather hard to see how an attacker can gain from manipulating the IP addresses. Probably simpler to just declare some dummy algorithm identifiers for HMAC-SHA256 ignoring the IP addresses. And you can probably use the exact same hack to make the connection NAT46/64 agnostic, though to be honest I have not thought the issue through. OK back to polishing the moulds for my robot. On Mon, Nov 9, 2009 at 10:11 PM, Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com wrote: On 8 Nov 2009, at 16:22, Phillip Hallam-Baker wrote: There are two typical modes of deployment for IPSEC, the first is as a lousy remote access protocol where the lack of NAT support makes it far more effort than other solutions. SSL and SSH remote access just works, IPSEC VPN may or may not work depending on the phase of the moon. The third party clients are terrible, the built in support in the O/S is unusable because it does not have the tweaks necessary to get through the firewall. So we do not really have a standard for IPSEC remote access. There's at least one product making actual money in this space, Hamachi ( http://www.hamachi.cc/ ). Basically third-party-mediated IPSec-lite that goes over NAT. If you must use NAT, at least be aware of what can come back to your network due to NAT behaviour and internally initiated connections. I don't think NAT is providing the right kind of security here. But I must be careful not to start another flame war. But anyway, IPv6/Teredo does the same thing, and better; Microsoft is working on going that extra mile with IP over HTTPS, too, so soon we'll have peer-to-peer VPNs that really do Just work. In every case it is better than Hamachi's use of unassigned address space, and in no case better than fixing the trouble at the root, and shredding NAT. But, if NAT's your thing ... Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
The same is true of SMTP. RFC822 is the 'standard', We have a broken model. There are not enough hours in the day for the IESG to spend time deciding whether HTTP has reached a sufficient maturity level to be considered a full 'standard'. That may or may not be a problem. But the RFC 2822/822 issue is much worse, we are telling people to respect the wrong standards. Now my recollection of last go around is not that 'we' didn't have the stomach for it. On the contrary. What happened was that the debate went off into a closed room for the decision to be made and the peons were told that there would be neither change nor an explanation but they were to continue to congratulate themselves for being part of an organization with such a sterling tradition of transparency, openness and consensus based decision making. On Wed, Nov 11, 2009 at 4:57 PM, Spencer Dawkins spen...@wonderhamster.org wrote: As I begged at the mike last night, let's make sure that this problem actually causes pain before spending one more second discussing it. Just for completeness :-| There is also the question of standards where we DO NOT WANT people to implement the full standard and say they are through - without PS updates, disaster happens. You don't need to look further than TCP. The full standard (STD007) is only RFC 793, with no slow start, no congestion avoidance ... that stuff is all in PSes. And we can't even add them to STD007, because they aren't full standards. Does this matter? A company that I worked at several years ago thought they were supposed to implement the full standards for TCP and waiting for the other in-process standards to become full standards - that wouldn't work, but we were doing passive network monitoring and not transmitting any packets, so it would have been Mostly Harmless. John told me he had the same experience at HIS company (before he explained that our standards levels are usually meaningless), and they DID transmit packets - they've probably made hundreds of millions of UAs (guess which technology this is), and they would probably have made a pretty serious dent in the Internet if they made another few hundred million UAs that provided HTTP (for example) and implemented TCP without congestion avoidance or slow start. On the other hand, we didn't add congestion avoidance or slow start to TCP until the net actually collapsed LAST time, so maybe that's what it would take for us to decide that fixing the standards track is worth doing. But we need to decide how much pain the standards track as defined today causes first, or we'll go through another round of endless discussions and still have STD007. IMO. Spencer Not THIS again. Let's look at a few of the standards that are commonly used today: HTTP: DS SNTP: PS SIP: PS IPv6 Addressing Architecture: DS SMTP: DS Full standard MPLS-VPNs: PS BGPv4: DS MIME: DS XMPP: PS (although it seems the real work goes on elsewhere) OSPF: Full standard RIPv2: full standard BFD: not to be found VRRP: DS Radius: DS DNS base: full standard DNS components: varying SNMPv3: full (but long before anyone actually used it) And so you will forgive people who seem confused by our quaint notion that there are flavors of standards. We don't do a good job of describing maturity with our standards levels. Perhaps we do a good job of using the standards levels to make a recommendation. How much SNMPv1 and v2 is out there still? Apparently not many people are listening to that recommendation. Does standard matter at all any more? I think so. A good number of the base protocols that are run on the computer I type this from are actually IETF standards. Yeah (except for software and device management. We blew, and continue to blow that one). So let's get real. John's draft was the right thing to do for NEWTRK. But do we really have the stomach for it? Last time out we did not. Eliot ps: see you all in Orange County, where I'm sure this endless debate will continue. On 11/11/09 5:04 PM, Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression.
Re: If you found today's plenary debate on standards track tedious...
It is really hard to keep management backing for a standards process that does not deliver standards. I know that there are some people in the IETF who would very much like to see the commercial entities banished. And to some extent that has happened, there is a reason that IBM and Microsoft put more resources into OASIS and W3C and I do not think it is because they have more influence there. We are also seeing fewer academics. I don't think that you want participation in IETF activities to be limited to the few people fortunate enough to have managers who understand the nature of the organization and a few individuals of private means. On Wed, Nov 11, 2009 at 8:30 PM, Loa Andersson l...@pi.nu wrote: Adrian, I think both statements are true. I've seen operators putting almost any RFC in RFPs, (actually done it myself) STD, DS, PS, Informational, Experimental, Historic and April 1st. An RFC is an RFC is an RFC! On the other hand talking to folks active in other SDOs you very often hear the no standards argument. Renaming without changing definitions should part of the job. /Loa Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Loa Andersson email: loa.anders...@ericsson.com Sr Strategy and Standards Manager ...@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: If you found today's plenary debate on standards track tedious...
Yup, and most of those proposed standards and draft standards should have been declared full standards *long* ago. What we *don't* do well is revising the levels of standards that got published, became fully interoperable and deployed without needing a rev of the document. Why is their status still marked 'proposed' or 'draft'? RFC 2026 does NOT require a rev to the document to move forward if there are no errata. For those specs that everyone has implemented and deployed, but there are a number of errata that everyone agrees are required for the spec to be useful, here's an idea for a revision lite (the diet version of a revision): recycle the spec almost totally *as-is*, with a section added called Verified Errata. Copy in such errata, attach the interoperability and deployment reports, and publish. Tony Hansen t...@att.com Eliot Lear wrote: Not THIS again. Let's look at a few of the standards that are commonly used today: HTTP: DS SNTP: PS SIP: PS IPv6 Addressing Architecture: DS SMTP: DS Full standard MPLS-VPNs: PS BGPv4: DS MIME: DS XMPP: PS (although it seems the real work goes on elsewhere) OSPF: Full standard RIPv2: full standard BFD: not to be found VRRP: DS Radius: DS DNS base: full standard DNS components: varying SNMPv3: full (but long before anyone actually used it) And so you will forgive people who seem confused by our quaint notion that there are flavors of standards. We don't do a good job of describing maturity with our standards levels. Perhaps we do a good job of using the standards levels to make a recommendation. How much SNMPv1 and v2 is out there still? Apparently not many people are listening to that recommendation. Does standard matter at all any more? I think so. A good number of the base protocols that are run on the computer I type this from are actually IETF standards. Yeah (except for software and device management. We blew, and continue to blow that one). So let's get real. John's draft was the right thing to do for NEWTRK. But do we really have the stomach for it? Last time out we did not. Eliot ps: see you all in Orange County, where I'm sure this endless debate will continue. On 11/11/09 5:04 PM, Adrian Farrel wrote: Hi, From the perspective of the world outside the IETF, this is already the case. An RFC is an RFC is an RFC... I don't think this is a truth universally acknowledged. I have heard the IETF disparaged a number of times on account of hardly having any standards. For example, a full Standard is equated by some people with an ITU-T Recommendation with the implication that a DS and PS are significantly inferior to a Recommendation. Whatever we might think of the value of this statement and the motives of the people who make it, it is clear that the names of the different levels of RFC are perceived outside the IETF. Over dinner this evening we wondered whether something as simple as looking again at the names of the stages in the three phase RFC process might serve to address both the perceptions and the motivations for progression. Cheers, Adrian ___ 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: publishing some standards immediately at Draft-Standard status?
Raise the bar more? Not at all -- that's not what I said. I said that the bar has *already been raised* so high that many of our I-Ds have already become fully interoperable before they get an RFC number assigned. What I said, is that if you *have* interoperability and deployment when you get the RFC number assigned, go ahead and get published at DS or FS status. Unless there are errata, changing the status from PS to DS to FS should be an administrative task, not a wait-for-full-revision-taking-X-years chore. And yes, the above statements are *fully* in line with use the current process better. Tony Hansen t...@att.com Carsten Bormann wrote: On Nov 12, 2009, at 12:28, Tony Hansen wrote: published directly at Draft Standard status Raise the bar so they stay at I-D level for even longer? A sizable part of the Internet is run on I-Ds, not on PS. I think the right direction is to publish PS earlier. If done right, it's only six months from there to the DS, you know. (About half of that time the draft is stuck in the RFC finalization process anyway :-). (My suggestion would be to stop talking about changing the rules and instead just find ways to use the current process better.) Gruesse, Carsten PS.: And you could spend some time during I-D time already to upgrade your downrefs to DS :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: publishing some standards immediately at Draft-Standard status?
At 09:44 PM 11/11/2009, Carsten Bormann wrote: On Nov 12, 2009, at 12:28, Tony Hansen wrote: published directly at Draft Standard status Raise the bar so they stay at I-D level for even longer? A sizable part of the Internet is run on I-Ds, not on PS. I think the right direction is to publish PS earlier. If done right, it's only six months from there to the DS, you know. err... I thought this was minimum of 18 months? James (About half of that time the draft is stuck in the RFC finalization process anyway :-). (My suggestion would be to stop talking about changing the rules and instead just find ways to use the current process better.) +1 James Gruesse, Carsten PS.: And you could spend some time during I-D time already to upgrade your downrefs to DS :-) ___ 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: publishing some standards immediately at Draft-Standard status?
RFC 2026 section 6.2: 6 months from PS = DS 4 months and 1 meeting for DS = FS. As John notes though, the clock currently begins after RFC publication time. There's no allowance granted for time already spent in jail. Tony Hansen t...@att.com James M. Polk wrote: At 09:44 PM 11/11/2009, Carsten Bormann wrote: I think the right direction is to publish PS earlier. If done right, it's only six months from there to the DS, you know. err... I thought this was minimum of 18 months? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Updated logistics and agenda for Smart Grid Bar BOF at IETF 76
[As before, my apologies for the shotgun nature of this email.] Folks, I would like to provide an update to the logistics and agenda for tonight's Smart Grid Bar BOF. The Bar BOF will begin at 8:30 so that folks attending the plenary have a chance to grab dinner. Note that the meeting room will be Acacia West (prior announcements indicated Acacia 1). Here is the current agenda.. Smart Grid Bar BOF Agenda 8:30PM - ?, Acacia West November 11, 2009 I. Agenda Bashing (5 minutes) Tim Polk II. Smart Grid Overview (15 minutes) Jim St. Pierre/Tim Polk III. Japanese Interest in Smart Grid (15 minutes) Hiroshi Esaki IV. Introduction to the IP Priority Action Plan (15 minutes) Tim Polk V. Discussion of draft-baker-ietf-core (15 minutes) Fred Baker see http://www.ietf.org/id/draft-baker-ietf-core-04.txt VI. Is the IETF the right place to do this work? Russ Housley VII. How should the work be organized? (contingent on V.) Ralph Droms Slides will be available via webex for remote participants, but we will be using the IETF streaming audio feed for sound. The URLs for webex access have been appended to this message. The audio feed for this session will be streamed at the following URL: http://videolab.uoregon.edu/events/ietf/ietf762.m3u Remote participants will not be able to speak, but can send comments and questions in the webex chat room. Thanks, Tim Polk - webex access details - Frederick Baker invites you to attend this online meeting. Topic: Smart Grid Bar BOF in Hiroshima Date: Thursday, November 12, 2009 Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00) Meeting Number: 205 017 176 Meeting Password: smartgrid --- To join the online meeting (Now from iPhones too!) --- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=128776942UID=1209736217PW=NYTMxMDcxYzMwRT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: smartgrid 4. Click Join Now. To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/j.php?ED=128776942UID=1209736217PW=NYTMxMDcxYzMwORT=MiM0OQ%3D%3D ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: publishing some standards immediately at Draft-Standard status?
On Nov 12, 2009, at 12:28, Tony Hansen wrote: published directly at Draft Standard status Raise the bar so they stay at I-D level for even longer? A sizable part of the Internet is run on I-Ds, not on PS. I think the right direction is to publish PS earlier. If done right, it's only six months from there to the DS, you know. (About half of that time the draft is stuck in the RFC finalization process anyway :-). (My suggestion would be to stop talking about changing the rules and instead just find ways to use the current process better.) Gruesse, Carsten PS.: And you could spend some time during I-D time already to upgrade your downrefs to DS :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [76attendees] Smart Grid Bar BOF Slides
Tim had some troubles setting up the WebEx conference, so we are using audio streaming, along with a Jabber chatroom here: xmpp:smartg...@conference.jabber.org?join On 11/11/09 5:44 PM, Fred Baker wrote: FYI - the slide decks in use for the Smart Grid Bar BOF are available at: ftp://ftpeng.cisco.com/fred/IETF-SG/ We will be running webex tonight, and slides are of course visible there as well. On Nov 11, 2009, at 1:29 PM, Polk, William T. wrote: [As before, my apologies for the shotgun nature of this email.] Folks, I would like to provide an update to the logistics and agenda for tonight's Smart Grid Bar BOF. The Bar BOF will begin at 8:30 so that folks attending the plenary have a chance to grab dinner. Note that the meeting room will be Acacia West (prior announcements indicated Acacia 1). Here is the current agenda.. Smart Grid Bar BOF Agenda 8:30PM - ?, Acacia West November 11, 2009 I. Agenda Bashing (5 minutes) Tim Polk II. Smart Grid Overview (15 minutes) Jim St. Pierre/Tim Polk III. Japanese Interest in Smart Grid (15 minutes) Hiroshi Esaki IV. Introduction to the IP Priority Action Plan (15 minutes) Tim Polk V. Discussion of draft-baker-ietf-core (15 minutes) Fred Baker see http://www.ietf.org/id/draft-baker-ietf-core-04.txt VI. Is the IETF the right place to do this work? Russ Housley VII. How should the work be organized? (contingent on V.) Ralph Droms Slides will be available via webex for remote participants, but we will be using the IETF streaming audio feed for sound. The URLs for webex access have been appended to this message. The audio feed for this session will be streamed at the following URL: http://videolab.uoregon.edu/events/ietf/ietf762.m3u Remote participants will not be able to speak, but can send comments and questions in the webex chat room. Thanks, Tim Polk - webex access details - Frederick Baker invites you to attend this online meeting. Topic: Smart Grid Bar BOF in Hiroshima Date: Thursday, November 12, 2009 Time: 8:00 pm, Japan Time (Tokyo, GMT+09:00) Meeting Number: 205 017 176 Meeting Password: smartgrid --- To join the online meeting (Now from iPhones too!) --- 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=128776942UID=1209736217PW=NYTMxMDcxYzMwRT=MiM0OQ%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: smartgrid 4. Click Join Now. To view in other time zones or languages, please click the link: https://ciscosales.webex.com/ciscosales/j.php?ED=128776942UID=1209736217PW=NYTMxMDcxYzMwORT=MiM0OQ%3D%3D ___ 76attendees mailing list 76attend...@ietf.org https://www.ietf.org/mailman/listinfo/76attendees smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: publishing some standards immediately at Draft-Standard status?
Tony Hansen wrote: One idea discussed over various beverages last night was based on an observation about the high bar that most Proposed Standards have had to pass over in order to become RFCs: many of them would not have gotten to publication without having already gone through interoperability testing. So the idea is that the shepherding files for such I-Ds could include interoperability reports indicating that they *are* already interoperable and have successful operational experience, Note that a short version of this is already included in the shepherding document. and then be published directly at Draft Standard status. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Plenary Discussions
During previous technical sessions I mailed an announcement about the technical plenary and in those announcements I've asked something along the lines of: If you consider asking a question during the open-microphone session it would be helpful to send that question to the IABi...@iab.org in advance. In that way we may be able to think about the problem and answer your question effectively. Note that sending in a question is _not_ a requirement for asking one. I believe that submitting questions in advance will help to get concise questions asked (because some thought went into phrasing them) and get pointed answers (because some thought went into answering them). In fact the questions may be shared by the larger group and not just the individual opinions of the folk that are happen to be on stage. FWIW, in the sessions I had asked this questions nobody walked up during the microphone. I just forgot to add the paragraph in this weeks announcement. --Olaf Olaf M. KolkmanNLnet Labs Science Park 140, http://www.nlnetlabs.nl/ 1098 XG Amsterdam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-nsis-qos-nslp (NSLP for Quality-of-Service Signaling) to Experimental RFC
The IESG has received a request from the Next Steps in Signaling WG (nsis) to consider the following document: - 'NSLP for Quality-of-Service Signaling ' draft-ietf-nsis-qos-nslp-17.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-11-25. 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-nsis-qos-nslp-17.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=10853rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-nsis-qspec (QoS NSLP QSPEC Template) to Informational RFC
The IESG has received a request from the Next Steps in Signaling WG (nsis) to consider the following document: - 'QoS NSLP QSPEC Template ' draft-ietf-nsis-qspec-22.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-11-25. 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-nsis-qspec-22.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=12323rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
On the Technical Plenary
IETF 76 Technical Plenary, 1630-1930 Thursday 12th November 2009. Internationalization in Names and Other Identifiers This technical plenary can be seen as following on from the plenary at IETF68 on March 2007 in Prague on Internationalization and Internet Engineering and builds on an old realization that smooth and interoperable functioning#8232; of the Internet depends on text strings#8232; being interpreted in the same way #8232;by all systems connected to it. RFC 2277 (IETF Policy on Character Sets and Languages, January 1998) and RFC 5198 (Unicode Format for Network Interchange, March 2008) discuss the use of international text in Internet protocols. Internationalization of protocol elements is ongoing work within the IETF (e.g. IDNABIS WG, EAI WG, IRI BOF) and deployment of these technologies is ongoing. For example, there has been much publicity and excitement around the announcement that ICANN plans to start issuing international text country-code top level domains soon. The issues and complexities of handling international text affect many of our protocols, most Internet users, and many IETF Working Groups. However, the issues are complicated and there is not always a shared understanding even among experts in the field. This IETF Technical Plenary presentation will explore examples of the kinds of things that can go wrong with internationalized text, and examples of cases where even when things go right, the result may still not be what the average human might expect or want. The IAB is currently working on draft-iab-idn-encoding, with the goal of describing some of the important issues and problems, and giving guidance for future protocol design to reduce such problems. This plenary is a working session of the IAB where we want to share our experiences and learn from yours. For the IAB, Olaf Kolkman, Chair. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Document Action: 'New ASN.1 Modules for CMS and S/MIME' to Informational RFC
The IESG has approved the following document: - 'New ASN.1 Modules for CMS and S/MIME ' draft-ietf-smime-new-asn1-07.txt as an Informational RFC This document is the product of the S/MIME Mail Security Working Group. The IESG contact persons are Tim Polk and Pasi Eronen. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-new-asn1-07.txt Technical Summary The Cryptographic Message Syntax (CMS) format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. Working Group Summary This ID was discussed on the SMIME WG mailing list and at IETF 69, 70, and 71 (SMIME hasn't met since IETF 71). All SMIME WG Last Call issues have been resolved. Discussion during SMIME WG Last Call demonstrated working group consensus. This document has SMIME WG support. Note that the issue raised in PKIX on this document's sister document draft-ietf-pkix-new-asn1-05.txt (obsolete vs update) was not an issue in the SMIME WG. However, it is expected that whatever the result is that the SMIME WG ID will be on the same track. Document Quality This document obsoletes/updates a number of RFCs from the SMIME WG. The quality of the draft is comparable in quality to its predecessor. Personnel Sean Turner is the document Shepherd. Tim Polk is the responsible Security Area AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
