Re: Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt
other WG in the same situation? To quote you from above ...most people out there do not even know the differences between the different types of RFCs... In other words, I'm postulating that if a small subset of a WG could get their favorite draft that has (and will) not reach WG consensus published as an RFC, then where exactly is this subset going to benefit from a competing proposal, even if backwards compatible (it's gotta be more complicated to implement, right?), published in phase II or any WG? Said even another way - couldn't this small subset make enough of a stink about the WG draft, once they have gotten their ID published as an RFC, to ensure it will never be published? Is that really where we want to go as a community? I'm suggesting that this AD-sponsored draft *not* get published until after the WG solution is published (originally proposed by Dan Romascanu in his Gen-ART review of this draft). Do this, and I believe this problem of getting around any WG intent goes away. James Cheers, Gonzalo On 04/09/2013 10:41 PM, James Polk wrote: All I've been out on leave since just after Berlin (which I had to cancel at the last minute, so I wasn't able to attend in realtime, or present the INSIPID reqs and solutions drafts - which I normally do at each IETF). Somewhere along the way, it was decided that draft-kaplan-insipid-session-id should be informational and not historic. I backed this draft becoming historic, and wouldn't have backed this draft becoming an informational RFC, for some very specific reasons that Dan's Gen-Art review successfully tease out. I'm glad to see that Robert and Gonzalo Salgueiro (INSIPID WG chair) each generally agree to (Robert's agreement is below, Gonzalo's note of agreement is the next message on this thread on the INSIPID list). Basically, as the author of more than 50% of the requirements doc text and approximately 70% of the solution doc text (from a 2 draft WG) I'm intimately familiar with the topic. We, as a WG, have 2 existing legacy drafts that were never intended to reach RFC because they could never get any WG to reach consensus on either; I'm referring to draft-kaplan-insipid-session-id-00 and draft-kaplan-insipid-session-id-03 (neither is compatible the other). But, that didn't stop 3GPP from referencing one of the (the -03 version of the kaplan draft) - and only a few months ago it was decided in INSIPID that we would rather have kaplan-03 as a separate historic RFC than an appendix within the existing solution doc currently progressing in INSIPID. But alas, now with this magical change, the kaplan-03 _IS_ going to become an I-RFC, and it's going to be AD-sponsored, so the authors really don't have to abide by the INSIPID WG - and I have a problem with that on many levels. #1 - this bait-and-switch will produce a non-historic RFC, where there was NOT any specific call for consensus to do that reassignment on the INSIPID list. I deem that a process violation. #2 - with IETF LC about or actually over, one could interpret any failure of the INSIPID WG to produce a standards-track RFC with this kaplan-03 document as an informational RFC as INSIPID's meeting some measure of success within the WG, and that is not acceptable. Attempting to get WG consensus to point #1 would have addressed or at least fleshed this out. #3 - I firmly want what Dan refers to with his Major issue #1 below, in that, as a condition of the INSIPID WG successfully documenting a standards-track solution, this kaplan-03 draft can then be published - perhaps even consecutive RFCs - as an I-RFC that way the INSIPID solution RFC(to-be) does all the IANA registration because it has the lower RFC number. #4 - I am firmly opposed to the kaplan-03 draft IANA registering any part of the new Session-ID header. I would like to point out that if Dan's #1 major issue is worked out, his major issue #2 will also likely be worked out as a result of making the changes necessary for major issue #1. The kaplan-03 draft should be written with INSIPID's express plan to produce their own solution, with the intention of the kaplan-03 document being approved *after* the INSIPID solution is RFC'd. James Date: Thu, 22 Aug 2013 12:08:26 -0500 From: Robert Sparks rjspa...@nostrum.com To: Romascanu, Dan (Dan) droma...@avaya.com CC: gen-...@ietf.org gen-...@ietf.org, draft-kaplan-insipid-session-id@tools.ietf.org draft-kaplan-insipid-session-id@tools.ietf.org, insi...@ietf.org insi...@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt Adding the working group. Dan - thanks for this review. I've been working towards trying to express a concern, and this really helped clarify what was bothering me. This document, AFAIK, _is not_ actually trying to register the Session-ID header with IANA, even though there is a section that looks
Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt
All I've been out on leave since just after Berlin (which I had to cancel at the last minute, so I wasn't able to attend in realtime, or present the INSIPID reqs and solutions drafts - which I normally do at each IETF). Somewhere along the way, it was decided that draft-kaplan-insipid-session-id should be informational and not historic. I backed this draft becoming historic, and wouldn't have backed this draft becoming an informational RFC, for some very specific reasons that Dan's Gen-Art review successfully tease out. I'm glad to see that Robert and Gonzalo Salgueiro (INSIPID WG chair) each generally agree to (Robert's agreement is below, Gonzalo's note of agreement is the next message on this thread on the INSIPID list). Basically, as the author of more than 50% of the requirements doc text and approximately 70% of the solution doc text (from a 2 draft WG) I'm intimately familiar with the topic. We, as a WG, have 2 existing legacy drafts that were never intended to reach RFC because they could never get any WG to reach consensus on either; I'm referring to draft-kaplan-insipid-session-id-00 and draft-kaplan-insipid-session-id-03 (neither is compatible the other). But, that didn't stop 3GPP from referencing one of the (the -03 version of the kaplan draft) - and only a few months ago it was decided in INSIPID that we would rather have kaplan-03 as a separate historic RFC than an appendix within the existing solution doc currently progressing in INSIPID. But alas, now with this magical change, the kaplan-03 _IS_ going to become an I-RFC, and it's going to be AD-sponsored, so the authors really don't have to abide by the INSIPID WG - and I have a problem with that on many levels. #1 - this bait-and-switch will produce a non-historic RFC, where there was NOT any specific call for consensus to do that reassignment on the INSIPID list. I deem that a process violation. #2 - with IETF LC about or actually over, one could interpret any failure of the INSIPID WG to produce a standards-track RFC with this kaplan-03 document as an informational RFC as INSIPID's meeting some measure of success within the WG, and that is not acceptable. Attempting to get WG consensus to point #1 would have addressed or at least fleshed this out. #3 - I firmly want what Dan refers to with his Major issue #1 below, in that, as a condition of the INSIPID WG successfully documenting a standards-track solution, this kaplan-03 draft can then be published - perhaps even consecutive RFCs - as an I-RFC that way the INSIPID solution RFC(to-be) does all the IANA registration because it has the lower RFC number. #4 - I am firmly opposed to the kaplan-03 draft IANA registering any part of the new Session-ID header. I would like to point out that if Dan's #1 major issue is worked out, his major issue #2 will also likely be worked out as a result of making the changes necessary for major issue #1. The kaplan-03 draft should be written with INSIPID's express plan to produce their own solution, with the intention of the kaplan-03 document being approved *after* the INSIPID solution is RFC'd. James Date: Thu, 22 Aug 2013 12:08:26 -0500 From: Robert Sparks rjspa...@nostrum.com To: Romascanu, Dan (Dan) droma...@avaya.com CC: gen-...@ietf.org gen-...@ietf.org, draft-kaplan-insipid-session-id@tools.ietf.org draft-kaplan-insipid-session-id@tools.ietf.org, insi...@ietf.org insi...@ietf.org Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt Adding the working group. Dan - thanks for this review. I've been working towards trying to express a concern, and this really helped clarify what was bothering me. This document, AFAIK, _is not_ actually trying to register the Session-ID header with IANA, even though there is a section that looks like it does. Rather, that registration is in http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/ That is a very good example of how just adding the explanatory paragraph at the beginning of the document isn't enough to turn this into something that documents an earlier path considered and implementation that exists current deployments - the text needs to be touched in several places to make it clear that's what the document is doing. In the IANA considerations case, one possible adjustment is to change the text to here's what known implementations have used for syntax. See [draft-ietf-insipid-session-id] for the intended registered syntax, and not issue instructions to IANA. It's more work for Hadriel, but I think it's necessary. RjS On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document:
Re: procedural question with remote participation
At 12:38 PM 8/5/2013, John C Klensin wrote: Hi. I seem to have missed a lot of traffic since getting a few responses yesterday. I think the reasons why slides should be available well in advance of the meeting have been covered well by others. And, as others have suggested, I'm willing to see updates to those slides if things change in the hours leading up to the meeting, but strongly prefer that those updates come as new alides with update-type numbers or other identification rather than new decks. In other words, if a deck is posted in advance with four slides numbered 1, 2, 3, and 4, and additional information is needed for 3, I'd prefer to see the updated deck consist of slides 1, 2, 3, 3a, 3b, 4 or 1, 2, 3a, 3b, 3c, 4, rather than 1, 2, 3, 4, 5, 6. How exactly do you do this in pptx? Numbering slides is a linear operation AFAICT, and it's binary (it's either on or off). Please educate me if I'm wrong; lord knows I don't know don't know how to do everything flag/setting in powerpoint... And, in my 8 years as TSVWG chair, I've rarely had completely new individual slides sprinkled throughout an existing deck. Rather, I've received updated slides - each with part of their content altered. Does this fall into your desire for a 3a, or is that just 3 (because 3a means an entirely new slide from scratch)? BTW - I'm very much *not* in favor of stipulating to my WG that slides must be turned in 7 days in advance of a TSVWG meeting. I personally think no more than a 48 hour advanced window should ever be considered. James I also prefer consolidated decks but, if WG chairs find that too difficult, I'm happy to do my own consolidating if everyting is available enough in advance for me to do sol Almost independent of the above, the idea that one should just watch the slides on Meetecho implies that Meetecho is available in every session (it isn't) and that everything works. In addition, they either need the slides in advance or need to be able to broadcast real-time video at a resolution that makes the slides readable. The latter was not the case last week in some of the sessions in which Meetecho was transmitting the slides sometimes due in part to interesting speaker-training issues. The reasons to discourage anonymity aren't just patent nonsense (although that should be sufficient and I rather like the pun). Despite all we say and believe about individual participation, the IETF has a legitimate need to understand the difference between comments on a specification from an audience with diverse perspectives and organized campaigns or a loud minority with a shared perspective. That requires understanding whether speakers are largely independent of each other (versus what have sometimes been referred to as sock puppets for one individual) or whether they are part of an organization mounting a systematic campaign to get a particular position adopted (or not adopted). The latter can also raise some rather nasty antitrust / anti-competitiveness issues. Clear identification of speakers, whether in the room or remote, can be a big help in those regards, even though it can't prevent all problems. And the IETF having a policy that requires clear identification at least establishes that we, organizationally and procedurally, are opposed to nefarious, deceptive, and posslbly illegal behavior. A rule about having slides well in advance helps in another way: slides that are bad news for some reasons but posted several days in advance of the meeting provide opportunities for comments and adjustments (from WG Chairs and others). Ones that are posted five minutes before (or 10 minutes after) a session lose that potential advantage. Again, I don't think we should get rigid about it: if slides are posted in advance and then supplemented or revised after feedback is received, everyone benefits. I want to stress that, while I think registration of remote people who intend to participate is desirable for many reasons, I think trying to condition microphone use (either remote on in-room) with proof of registration and mapping of names would be looking for a lot of trouble with probably no significant benefits. best, john
Re: WebRTC and emergency communications (Was: Re: IETF Meeting in South America)
At 11:58 AM 5/28/2013, Ted Hardie wrote: On Sat, May 25, 2013 at 12:10 AM, Jari Arkko mailto:jari.ar...@piuha.netjari.ar...@piuha.net wrote: James: did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. I knew that WebRTC is happening fast, including implementations coming out before standards. I don't think everyone have yet realised the full impact this technology will have. I didn't know about the details of the emergency communications situation. But it is always difficult to balance getting something out early vs. complete. I know how much pressure there is on the working groups to keep up with things actually happening in the browsers and organisations setting up to use this technology. Do you think the retrofit will be problematic, and do you have a specific suggestion about what should be included today? Jari I'm replying here, rather than down thread, because I believe it's important to tackle two different statements here: one James' and one Jari's. The first is James' that RTCWEB is ignoring Emergency Services. Perhaps by actively ignoring James means that the working group considered emergency services and made a decision he did not agree with, which is that the baseline capabilities already allows a PSAP or other emergency service to provide a WebRTC application that would work to connect you to its emergency responders, and that this was enough. As context, it's very important to recognize that the WebRTC efforts in the IETF and W3C *are not building a telephone into a browser*. We could have done that in a few weeks. The groups *are* creating building blocks that allow a javascript application within a browser or mobile context to add peer-to-peer audio, video, or data channels to whatever *its* application happens to be. That application can be a game (we often use a poker game as an example here), a puzzle (there's an example where you compete with a peer in unscrambling a tiled video feed), or a pure data exchange (where neither audio or video are passed). In that context, the group considered two questions: can you use the WebRTC building blocks to create an application to talk to emergency responders? should every application be required to have the ability to talk to emergency responders? It gave the answer to the first one as yes, and I am convinced that any emergency responder that wished to create such an application could do so with the existing building blocks. A set of emergency responders could even create and distribute one that was highly generalized and took advantage of LoST's facilities to be useful in many locations. To the second question, the working group answered no. There are applications of WebRTC which are not general-purpose communications, including some applications where there will be no audio or video at all. Requiring that a puzzle should provide you 911 service because it happens to provide have live video is not really sensible. Fundamentally, making every application also be a generalized telephony application with ECRIT support makes no more sense here than it would for desktop applications; you could equally require a text processor connected to the network to support texting emergency responders--after all, it has the UI facilities and the user's attention, right? The second statement is Jari's, which seems to imply that the implementations coming out before standards is a problem in the WebRTC case. The implementers in this case are also very active contributors to both the IETF and W3C efforts, and they are feeding implementation experience into the process. That's a good thing, since it is coming along with a willingness to change implementations to match group consensus. That won't last forever, obviously, but we have that now and should continue to take advantage of it while we do. That's my personal take, in any case, as someone who has been actively involved in both efforts. Ted - this view (I believe) doesn't reconcile with the view stated by Henning's yesterday. (truth be told, it's hard
Re: IETF Meeting in South America
At 05:25 PM 5/23/2013, Jari Arkko wrote: For what it is worth, I wanted to provide my perspective on this. I of course believe that it is important that the IETF reaches out to an even more international participation than it already has. This is first of all because we really need the views from different types of organisations and different parts of the world. For instance, I recently had an opportunity to talk to a number of people about peering in different regions. It really opened my eyes about how the Internet experience can differ from what I've been used to so far. We also need to understand how regionally changing requirements for, e.g., emergency communications I hate to call you out on this point Jari, but... did you know that you have a audio/video realtime interactive communications WG churning out proposals and solutions that is *actively* ignoring emergency communications in its entirety? No? Look at RTCweb, which will become a dominant form of interactive communications between humans in the near future. You have an equally active WG in the same area that is addressing emergency communications (ECRIT) that is further along/mature in its documents (i.e., they've already produced the bulk of their RFCs, specifically RFC 6443 and 6881). Given that young people already think contacting a local emergency call center (PSAP) can or should be achievable through SMS, IM, twitter and Facebook... just how long does anyone think it will be before calling 911/112/999 will be requested or mandated through WEBrtc/RTCweb? Waiting will only make it more painful to retrofit it into the future RFCs produced by RTCweb. humbly James or whitespace management affect our work. Finally, our international coverage is not just important for our work but also for how we are perceived. For all of these reasons, reaching out to different parts of the world is important, and one aspect of that is rotating through meeting locations around the world. I would also like to highlight one part of the message from Bob: The IAOC would also like to get feedback on how we can ensure the meeting is as successful as possible and on ways to grow participation in the region. This is really important, and I hope that we get good feedback on what kinds of things would be useful to do in order to achieve this. That is, we're not just asking a binary question if the meeting is or is not ok. Just meeting in some place does not bring too many new participants, at least not in a lasting manner. But combined with some other actions, this may be possible. Are there specific companies or research teams that we could reach out to, and who might want to be involved in the IETF? Are there local events where where it would be useful to have someone from the IETF give a talk? Are there specific IETF or IRTF efforts where we could get more people from South America involved? Should the ISOC fellows program target something different than it has so far, or be scaled up? Other ideas? Jari P.S. By coincidence, I happened to visit Buenos Aires last year, and found it to be a fun city. I felt safe and despite not speaking the local language I was able to talk to the friendly locals, order food, access the network, acquire a SIM card (albeit with some bureaucratic and technical difficulties, but I think I can still dig up the MNC numbers that were needed to configure the phone correctly :-), use the airports, rent a car, and find a Finnish sauna. I think the city offers all the essential ingredients for life :-)
Re: IETF Diversity Question on Berlin Registration?
At 10:28 AM 4/18/2013, Pete Resnick wrote: I noticed this post from a few days ago, but I think instructive to talk about. And this is not picking on James; I think it's likely that there are many folk who have similar perceptions, and I think it's useful to think about. On 4/12/13 3:37 PM, James Polk wrote: Eyeballing the IETF (and I've missed 2 meetings since IETF45, been a WG chair for 8 years, and written or revised over 300 submitted IDs) there is consistently about a 70-to-1 ratio of men to women. Your eyeballing had you put the ratio at about 70:1. I wouldn't be surprised if this was a common view. However, when the whole diversity conversation started, a few people quickly scanned through attendance lists just to do a guesstimate of the actual ratios over the past 10 years. They were seeing rates somewhere between 10:1 and 18:1 (with so much variability due to guessing on the basis of names), and it's seemed pretty consistent over the last 10 years. Over the past 5 years, the ratio of Nomcom members (randomly selected from the community) is about 10:1, which is consistent with those numbers. I believe I did myself a disservice in assigning such a high ratio without saying it feels like 70:1, which it does. But I'd truly be surprised if it's only 10:1 - and you can't make effective and accurate estimates based on guessing the gender of the names of an international organization like the IETF is. Now, and this is purely from a defending myself pov, the feel of a 70:1 crowd that's right in front of you from a 18:1 crowd isn't that much, especially if you're part of that larger number. There is a matter of the number of the group you happen to be part of is so overwhelming you tend to guess on the high side. That's a factor of between 4 and 7 difference between an eyeball guess and a rough calculation. I think that's likely an unintentional sampling bias of your (and many other folks) eyeballs. And I think it's because we have a tendency to subconsciously discount the numbers of people who do not appear in leadership, or even simply don't behave the way the rest of us do. I have to disagree with you here. In my mind, this feels like a 70:1 ratio has nothing to do with the ratios of leadership to the community within the IETF, it's from the gathering places and hallways where there are just wave after wave (after wave) of men. It's also from sheer lack of numbers of women within the WGs I've attended over the years (SIP related, MMUSIC, GEOPRIV, ECRIT, the whole TSV area, etc). This isn't to say that we should spend all of our time on this question by collecting statistics; that's just navel gazing. But we do want to understand the nature of the problem and not let our guesses and subconscious biases get in the way. whether it's 70:1 or 18:1 - that's significantly more of one group that the other. Thanks Pete for making this point, and causing me to clarify what I originally wrote. James pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Technologies, Inc. - +1 (858)651-4478
Re: IETF Diversity Question on Berlin Registration?
what you are suggesting is quotas and forced participation from a volunteer organization... are you serious? At 11:51 PM 4/16/2013, Abdussalam Baryun wrote: My own feeling is that if we were to find that the numbers supported the notion that there's bias present in the system we probably couldn't do anything about it without tearing the organization apart, so, Is there a way to increase #countries #small companies #women etc? Be it about the participants or the leadership. Could we set a goal that we'll increase some aspect every year, 2014 to be better than 2013? IMO we can do many thing about it, if we discuss these issues into an I-D. - There is a way to increase #women when they decide together as a group what is missing, and what should be done, - There is a way to increase #small companies when they are accepted/involved in IETF WGs documents. If individuals are encouraged then SMEs will be as well, - There is a way to increase #countries/states when each have their accepted access to the IETF WG system. I may suggest that each WG system to not only have two chairs, but also 5 administrated participants (for each continent, they may give chance to SMEs access and new I-Ds) that should look into the implementation/running-code of the IETF WG standards in real life. They can look into countries/states challenges/involvement in such work of the WG, to be documented if available. Countries will only increase-in/use IETF if their SMEs are using IETF systems. Now it seems that there are influences/directions from the industry/countries to IETF WGs' work but not seen/clear to others. For women, I think there must be at least 10% of women in the IETF leadership, as we should not ignore that many research/SMEs in industry are directed by women. They should publish an I-D related if they are interested. Is IETF still directed by men or both? AB
Re: IETF Diversity Question on Berlin Registration?
At 02:11 PM 4/12/2013, Melinda Shore wrote: And I don't know if you intended to or not, but what you communicated is The best candidates are nearly always western white guys, since that's who's being selected. That's a problematic suggestion. I respect you, Melinda. I think you are smarter and more technically and philosophically qualified than me. Having said that, what Lou asked was an honest question, yet you seemed to take it in the worst possible way. I'd say each of us is likely bringing our own baggage to how we each look at this 'problem', if there is a problem at all (which doesn't appear to be universally agreed upon). since that's who's being selected is a biased observation in and of itself. That's saying that because of the outcome, there has to be bias to skew the results this way - because it's the only logical explanation that could answer these results. My BS-meter is pegging into the red on that one. The nomcom isn't randomly picking hats in a crowd. They are picking talent of those that have volunteered to serve. At any given time there could be 1 or 2 or 5 women how volunteered to server at particular AD slot, but there might be 1 white guy that is more qualified. From the audience at any plenary - that could appear the fix is in to ace out the women, but clearly (in this hypothetical example) it's not the case at all. Eyeballing the IETF (and I've missed 2 meetings since IETF45, been a WG chair for 8 years, and written or revised over 300 submitted IDs) there is consistently about a 70-to-1 ratio of men to women. I'd observe that this is likely the case of hurt feelings rather than unqualified males achieving the AD position in lieu of more qualified females - especially in the face of these rough ratio approximations. I believe we need to reduce that ratio, and am for anything that increases the number of (qualified) women in this engineering organization. I am against artificially forcing the nomcom to implement a quota system to overcome low participation numbers of any diversity aspect. Admittedly, I'm only teasing out the male/female diversity facet, and not any other the other - equally deserving diversity criteria. James
Re: RFC 6921 on Design Considerations for Faster-Than-Light (FTL) Communication
At 03:59 PM 4/5/2013, Dave Cridland wrote: Actually, getting rich without implementing anything seems to happen quite often enough these days - it's called acquisition. or be a Kardashian On Fri, Apr 5, 2013 at 6:12 PM, Wes Beebee (wbeebee) mailto:wbee...@cisco.comwbee...@cisco.com wrote: Or use the FTL to predict the company stock price so that you get rich without implementing anything. - Wes On 4/5/13 5:12 AM, Adrian Farrel mailto:adr...@olddog.co.ukadr...@olddog.co.uk wrote: So instead of asking the community do you have an intention to implement and deploy? we should ask have you already been going to have implemented and deployed yet? thinking about this and assuming that the FTL Communication are deployed in a not too far distant future, wouldn't we have started to receive packets that was sent in the future already now? Indeed, and this tells us that publication of this was important, since we'll need to be in a position to handle the issues that will occur much sooner than deployment, and for that matter development of the technology.
Re: Internet Draft Final Submission Cut-Off Today
At 01:01 PM 2/26/2013, Dale R. Worley wrote: From: James Polk jmp...@cisco.com It used to be 5 PM Pacific, now it's 24:00 UTC. It's always been 2400 UTC, but with all the daylight savings time adjustments from country to country changing from year to year, I have talked to the Secretariat before (and recently), and verified this is indeed 8pm ET, at least for those in the US. Well, 2400 UTC is 8pm Eastern Daylight (i.e., summer) Time (GMT-4), but 7pm Eastern Standard Time (GMT-5). So I'd ask *when* did the Secretariat tell you that? well, I can't remember if it was for Paris or Vancouver now that you ask... Personally, I'd trust date -u much sooner than any random person. Even better: $ date --date='00:00 Feb 26, 2013 UTC' Mon Feb 25 19:00:00 EST 2013 $ Dale
Re: Internet Draft Final Submission Cut-Off Today
The ID upload tool says the deadline has passed, yet a decade or more the deadline has been 8pm ET/5pm PT. That's 15 minutes from now. What gives? James At 11:05 AM 2/25/2013, IETF Secretariat wrote: This is a reminder that the Internet Draft Final Submission (version -01 and up) cut-off is today, Monday, February 25, 2013. All Final Version (-01 and up) submissions are due by UTC 24:00. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 86 can be found at: https://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-dra...@ietf.org.
Re: Internet Draft Final Submission Cut-Off Today
At 06:50 PM 2/25/2013, Peter Saint-Andre wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2/25/13 5:47 PM, James Polk wrote: The ID upload tool says the deadline has passed, yet a decade or more the deadline has been 8pm ET/5pm PT. That's 15 minutes from now. I had the same problem last week for the -00 cutoff. It used to be 5 PM Pacific, now it's 24:00 UTC. It's always been 2400 UTC, but with all the daylight savings time adjustments from country to country changing from year to year, I have talked to the Secretariat before (and recently), and verified this is indeed 8pm ET, at least for those in the US. James Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLAbrAAoJEOoGpJErxa2pJCQQAK05V61dUleo5z+nsodQPNCn Lt98t7543ic48vaYHpwCYv4zT7sbCJ9KJ7bm0gqBHwnsRnUvb2qeLfQTrBGpKHLG ZFLiIVDoTqJjEKzcGoEv6ZupZADjiZZZxAN0c+0o2NWJJFs5Jt1x/88k4fmAPGpo qUGOAUdaQ+ayD4qPYysSiexAJ4kj4x2oSjqWK9SQXJ2LX816mI6YIY75BxF/HniE Hz95w05hVS6h1LNpr5O0DlY44pUHrBEi4jxXF7GVPhA/XvBS1ONRlbWVBz/tsURG SJ1HXkKOWpKegld6HjllqjvkSXIEKcs/xc5L68+pkOmdySQ7SQxl0WBqIXDv0Yul t82W5gUxgkX0XpDE5+SQ3npuseCY77q9HzN3XkzZA1HWTcSMPIUEY7PhgWmuSms6 /aH46hBLVJhOAWDSNieG+lfnJahlvrmTUcZ5l/JJo/AeTbK+cxY8a0NDVit+pi2P wS8XKBuyM5Z1BxqxtozmDAU1HP3qhTt+m/tBNPNkN185MSylDlnWZQVbZ+ZjH5Jq LrO9ELqyPC6Evq0j4V4pltOs0T7yVMw7XFWKZv/cVjkC7fu6ZZ3inMovnjmHfQe/ H+ItSqZuHLMOBuFjioPskdujLWadIt1vpULjsw5tdaton82sruaqIC0NdSh7Sr7C hKLwIVutjXHVvW7b5kzC =60kr -END PGP SIGNATURE-
RE: draft-gellens-negotiating-human-language-01
Hey Randy SDP, defined in the MMUSIC WG (why isn't this being discussed on that list? because it'll have to go to that list before this draft progresses anyway), isn't a negotiation protocol, it's an offer/answer exchange (per RFC3264) - and even if you didn't want SIP, there's not a back-and-forth that typical negotiations have. You're already familiar with RFC 4566 (SDP). SIP has a session layer language tag, from RFC 3261 20.3 Accept-Language The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server SHOULD assume all languages are acceptable to the client. The Accept-Language header field follows the syntax defined in [H14.4]. The rules for ordering the languages based on the q parameter apply to SIP as well. Example: Accept-Language: da, en-gb;q=0.8, en;q=0.7 RFC 4566 has an attribute (a=lang) that you quote, but I'm confused why you first propose using it, then dismiss its use. Now, your draft does say For various reasons, including the ability to establish multiple streams each using a different media (e.g., voice, text, video), it makes sense to use a per-stream negotiation mechanism, using SDP. but there I have not found justification (or even examples) for these various reasons... maybe I missed them, but media level attributes are there for those offers that have more than one m= line, where the same attribute has a different value per m= line. In your one example, you list 'en' 'it' for the languages you want to receive in the offer, and just 'it' in the answer. Why does this have to be a media level attribute when you're really after _the_one_language_for_all_m-lines_? James At 09:44 PM 2/23/2013, Doug Ewell wrote: That means essentially the same thing. Check to make sure your other reviewers feel that wording is OK. -- Doug Ewell | Thornton, CO, USA http://ewellic.org | @DougEwell -- From: mailto:ra...@qti.qualcomm.comRandall Gellens Sent: â2/â23/â2013 20:34 To: mailto:d...@ewellic.orgDoug Ewell; mailto:ra...@qti.qualcomm.comRandall Gellens; mailto:ietf@ietf.orgietf@ietf.org; mailto:rg+i...@qualcomm.comrg+i...@qualcomm.com Cc: mailto:ietf-langua...@iana.orgietf-langua...@iana.org Subject: RE: draft-gellens-negotiating-human-language-01 Hi Doug, At 8:20 AM -0700 2/23/13, Doug Ewell wrote: You might want to reference BCP 47 instead of RFC 5646, but this is up to you. When I reference RFC 5646, the actual reference includes it as both RFC and BCP. I would actually suggest leaving off the reference to the Registry and just say the tag must conform to 5646 (or BCP 47). That will imply the use of the Registry. How about: The 'humintlang' attribute value MUST be a language tag per RFC 5646? -- From: mailto:ra...@qti.qualcomm.comRandall Gellens Sent: 2/23/2013 1:18 To: mailto:d...@ewellic.orgDoug Ewell; mailto:ietf@ietf.orgietf@ietf.org; mailto:rg+i...@qualcomm.comrg+i...@qualcomm.com Cc: mailto:ietf-langua...@iana.orgietf-langua...@iana.org Subject: Re: draft-gellens-negotiating-human-language-01 Hi Doug, Thanks very much. So, if I understand, your suggestions would be: (1) Change the text for the possible new 'humintlang' attribute from: The humintlang attribute value must be a single RFC 3066 [RFC3066] language tag in US-ASCII [RFC3066]. It is not dependent on the charset attribute. To: The humintlang attribute value must be a single RFC 5646 [RFC5646] language tag from the IANA registry [IANA-lang- tags]. It is not dependent on the charset attribute. (2) Add RFC 5646 to the Normative References Since the IANA registry referenced now was actually created by RFC 5646 not RFC 3066, this is both better technically (for the reasons you mention) and more correct. Let me know if I've understood, and if so, I may be able to get an update in before the cut-off. At 9:09 AM -0700 2/22/13, Doug Ewell wrote: Draft-gellens-negotiating-human-language-01, Negotiating Human Language Using SDP, says this about the source of values for the SDP 'lang' attribute: The lang attribute value must be a single [RFC3066] language tag in US-ASCII [RFC3066]. Although this wording is quoted from RFC 4566, the subsequent section proposing a new 'humintlang' attribute uses the same wording. Any new format or protocol that employs language tags should apply BCP 47 (RFC 5646), not RFC 3066, which was obsoleted in 2006. BCP 47 allows the use of more than 7300 additional language subtags derived from ISO 639-3, as well as script subtags based on ISO 15924 and variant subtags, none of which are permitted in a generative manner by RFC 3066. The draft says, The attribute value should be a language tag from the IANA registry [IANA-lang-tags],
Re: Recall petition for Mr. Marshall Eubanks
At 01:43 PM 11/1/2012, Fred Baker (fred) wrote: On Nov 1, 2012, at 9:32 AM, Olaf Kolkman wrote: I also offer my signature under the recall procedure, in case pragmatism doesn't prevail (see my other note). My offer of signature should in no way be interpreted as reflecting an opinion about Marshall's character. exactly how I feel, and I am Nomcom eligible (37 out of 39). James Ditto, and Ditto.
Re: Proposed IETF Meeting Calendar 2018 - 2022
IETF 106 seems a bit late in November. Are we boxed in by other SDO meetings, or is this by our own choice? James At 02:15 PM 9/6/2012, IETF Administrative Director wrote: All; Below are suggested Meeting dates for 2018 - 2022, IETF's 101 - 115. The IAOC is soliciting the community's feedback before adopting. Comments appreciated to ietf@ietf.org by 20 September 2012. Ray 2018 IETF 10118-23 March 2018 IETF 10222-27 July 2018 IETF 1034 - 9 November 2018 2019 IETF 10424 - 29 March 2019 IETF 10521 - 26 July 2019 IETF 10617 - 22 November 2019 2020 IETF 10722 - 27 March 2020 IETF 10826 - 31 July 2020 IETF 10915 - 20 November 2020 2021 IETF 11021 - 26 March 2021 IETF 11125 - 30 July 2021 IETF 1127 - 12 November 2021 2022 IETF 11320 - 25 March 2022 IETF 11424 - 29 July 2022 IETF 1156 - 11 November 2022
Re: Meeting lounges at IETF meetings
Having missed only 2 meetings in 13 years, I can say that no venue was perfect, but some were very good. It becomes a case of which venues have the fewest bad things. I believe this venue was exceptional at many things, very good at nearly all others, with the bad things being food/snacks served in the crowded hallway and that sucky elevator algorithm (which was by far the worst think here). The crowded hallway we can't change. We can change where the snacks are served, and I have read that will happen for our next meeting in Vancouver here in 15 months. To me the exceptional aspects far outweighed the bad things - so I'm chalking this venue up as one of the best in 13 years of attending IETFs, and a *serious* contrast to the Paris venue (which I believe was one of the worst - each time we were there, though the city was nice). However, YMMV James At 05:10 PM 8/3/2012, Ole Jacobsen wrote: The narrowness of the corridoors, placement of food/drink and all that was discussed in our wrap-up meeting this morning, and indeed the issues you have raised were indentified as areas for improvement. Since we are coming back to THIS hotel, there are certainly things that can be done better, and will be done better, next time. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Fri, 3 Aug 2012, Mary Barnes wrote: The issue that I experienced (and why I'm fussing) is that if you were attending many sessions in the Regency rooms (and moving rooms between sessions), it was extremely difficult to weave your way through the corridor as many people were having their discussion directly in the middle of the corridor. There just was not room in that corridor for side conversations. The situation was made worse as that corridor was where they served the refreshments. And trying to ask people politely to move generally had no impact in my experience as people were too engaged in their conversations. Mary. On Fri, Aug 3, 2012 at 4:14 PM, Thomas Nadeau tnad...@lucidvision.comwrote: I agree with randy. I've never had an issue finding a place to huddle/meet when necessary at an ietf meeting venue. between the hallways, bar, etc I'm not sure what the fuss is all about. Tom On Aug 3, 2012, at 3:27 PM, Randy Bush ra...@psg.com wrote: i have no need to micro-manage the secretariat. seems to happen a lot around here... symptom of too much free time on hands randy
Re: New Version Notification for: draft-baryun-rfc2119-update-00.txt
At 12:05 PM 8/1/2012, Abdussalam Baryun wrote: I agree with what Paul and Melinda have said. This document is pointless, as there is no actual problem that it's solving and no misunderstanding that it's clarifying. It is solving the problem of specifications that don't specify conditions in a easy manner that implementers/users need. normative language is for implementers, not education for users - at least as its primary goal. Implementations can be configured to comply and not comply with one or more RFCs, based on the needs of the customer and the desire of the implementer (i.e., vendor) to want the sale of their equipment to that customer. This fact is commonly misunderstood. Melinda has wise words Please note that IF THEN is reducing the number of words in the draft as well (more efficient). Please tell me what specification can specify a conditional situation in less words than IF, THEN. Many RFC don't follow the easy way properly, Further, it's actively *harmful*. I implemented some RFC that don't specify if, then, and it was harmful for me. I don't know what kind of harmful that the update will make, please explain by an example. Do you mean harmful to the reviewers or to the draft authors. Please note that we should make the internet a better place for ALL not only for authors. It's arguable that 2119 already reserves too many words by giving them specific, normative meanings (SHALL *and* MUST; SHOULD *and* RECOMMENDED). Adding IF, THEN, and ELSE would not only be unnecessary, but downright *bad*. It is necessary, and the words in RFC2119 are not many if we compare with our RFCs pages. I thank you for your comments, AB
RE: Proposed IETF 95 Date Change
At 07:28 AM 7/23/2012, DRAGE, Keith (Keith) wrote: Let's forget the religious discussion that seems to have broken out as a result of this. While Easter may be a major Christian festival, I don't believe the issue is such (I can think of no reasons why Christians would have a doctrinal reason other than those that apply to any other Sunday and those obligations could mostly be met at the venue rather than at home). Rather it is Easter the secular public holiday that happens to occur in many countries. This is the set of days when schools take an extended break, parents take said children off on short holidays; cheap air tickets cease to be available; when you get on the plane, it is full of screaming children; kinda like we're all going to experience at next year's IETF86 timed exactly in the middle of US spring break going to/from Orlando (home to 4(?) amusement parks including Disneyworld)? Air travel will be crazy (families book tickets many months - like 6 - in advance), and depending on which hotel we're in, it could be worse than staying at the airport each day. -j local transport all works to a reduced timetable; for those IETFers who end up wishing to travel by train, they find themselves moving to busses to cater for the engineering works which a 4 day weekend seems to encourage. So my advice would be, change the dates if it looks like you are going to hold the meeting in a country that takes such holidays, or where a significant number of people would need to transit through such a country. If so you need to take into account at least both the Friday and Monday in some countries. Keith P.S. Trying to avoid every religious and public holiday is an impossible task. Do what other organizations have done and concentrate on the impact of such holidays on holding the meeting in any location. -Original Message- From: wgchairs-boun...@ietf.org [mailto:wgchairs-boun...@ietf.org] On Behalf Of IETF Administrative Director Sent: 20 July 2012 17:06 To: IETF Announcement List Cc: i...@ietf.org; i...@iab.org; ietf@ietf.org; wgcha...@ietf.org Subject: Proposed IETF 95 Date Change The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Ray Pelletier IETF Administrative Director
Re: Proposed IETF 95 Date Change
At 12:58 PM 7/20/2012, Richard L. Barnes wrote: For convenience, the complete list: http://www.interfaithcalendar.org/2016.htm outstanding - now we can't meet that whole year... ;-) On Jul 20, 2012, at 1:44 PM, Andrew G. Malis wrote: As long as you don't go any later than the week of April 10 - the week of April 17 runs into the start of Passover. Thanks, Andy On Fri, Jul 20, 2012 at 1:29 PM, Fred Baker (fred) f...@cisco.com wrote: On Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote: On 7/20/12 09:06 , IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. 20 march is palm sunday on the western calender. If one's a conflict presumably the other is too... I personally avoid being away from home on Easter, and would prefer that the IETF meeting avoid it. Yes, Palm Sunday is a question, but not quite on the same scale as Easter. I will note, however, that Good Friday (the Friday before Easter) is a national holiday in a number of countries. People schedule vacations around that weekend. My suggestion: take the week of April 3 or later.
Re: Proposed IETF 95 Date Change
At 12:29 PM 7/20/2012, Fred Baker (fred) wrote: On Jul 20, 2012, at 9:36 AM, Joel jaeggli wrote: On 7/20/12 09:06 , IETF Administrative Director wrote: The IAOC is seeking community feedback on a proposed date change for IETF 95 scheduled for March 2016. Currently IETF 95 is scheduled for 27 March to 1 April 2016. 27 March is Easter. The IAOC is proposing IETF 95 be rescheduled for 20 - 25 March 2016 and would like feedback on those dates before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. 20 march is palm sunday on the western calender. If one's a conflict presumably the other is too... I personally avoid being away from home on Easter, and would prefer that the IETF meeting avoid it. Yes, Palm Sunday is a question, but not quite on the same scale as Easter. I will note, however, that Good Friday (the Friday before Easter) is a national holiday in a number of countries. People schedule vacations around that weekend. My suggestion: take the week of April 3 or later. I agree Easter is a date to avoid, but am not offering which way to move the meeting. April 3rd of later seems interesting, but does start to impact the interval between this meeting and the summer one. James
Re: New Non-WG Mailing List: IETF-822
At 01:46 AM 6/15/2012, Yoav Nir wrote: On Jun 15, 2012, at 12:44 AM, Peter Saint-Andre wrote: On 6/14/12 3:37 PM, IETF Secretariat wrote: List address: ietf-...@ietf.org Is no one thinking ahead to the 822nd meeting of the IETF in the year 2258?!? Well, I've started working on draft-nir-ipv6-were-finally-deploying-it but I'm not sure what format would be an appropriate submission format in the 23rd century. Doesn't it coincide with the 1st season of Babylon 5? a B5 reference... this doesn't happen often enough IMO BTW - 2258 was the second season of B5. Yoav
