Gender diversity in engineering
There have been some good numbers floated on recent threads, but at least for me, they aren't enough to gain a complete (or nearly complete) picture of the issue. Having studied statistics, we need to know a starting point, and look for the reductions (or increases) from that point forward. Starting in high school is not sufficiently refined enough, as there are a lot that take advanced math (personally I'd start with trig - because that kicked my ass - but rarely is it its own class, so let's start with calculus 1) that don't go into engineering. Thus, high school is probably not a good place to measure from. Therefore, it needs to be college. We need to know % of class (based on year started) that is female in engineering (do we want to start with electrical and CS to be more applicable to our situation?) We'll call that percent 'X' then %X of drops from engineering (BS) (or just elec/CS?) over the college years before graduation? then %X that enter workforce after BS in Engineering (or just elec/CS?) into the engineering field? then %X that start graduate school (MS) in engineering (or just elec/CS)? %X that receive MS degree in engineering (or just elec/CS)? %X that enter workforce after MS in Engineering (or just elec/CS?) into the engineering field? then %X that start doctoral school (PhD.) in engineering (or just elec/CS)? %X that achieve PhD. in engineering (or just elec/CS)? then %X that enter workforce after PhD in Engineering (or just elec/CS?) into the engineering field? This will likely track those that are entering the engineering workforce, and with what level of education. From that point in the analysis - we can attempt to track at what point there are further drops out of the engineering workforce by women (i.e., after how many years). Or is it as simple as problems after childbirth to reenter the workforce (for whatever reason). As an example, if there is a significant difference from those that drop out after their BS from those that drop out MS, then maybe something should be done to encourage women to stay for the MS. comments or questions? James
Re: Future Handling of Blue Sheets
At 05:17 PM 4/24/2012, Martin Rex wrote: John C Klensin wrote: I strongly encourage the IASA to avoid ever holding an IETF meeting in Germany again without first obtaining appropriate legal advice that it is acceptable given our existing conditions to record the names and identities of anyone participating in any IETF activity, That does _not_ require a photo. whether they are explicitly sign something, are photographed, are identified by RFID, Keep in mind that if it isn't _voluntary_ consent, it will be legally void, even with a signature on it. IETF 87 is in Germany (15 months from now), so we'd better solve this issue soon, I should think. james have their names written down after they say something at a microphone or on Jabber, raise their hands (presumably in the expectation of being identified), or can be identified in some other way. What is wrong about simply archiving the information that participants are providing voluntarily, such as it has been the last 20 years? In Germany, an employer is not entitled to have and use a photo or picture of an employee without explicit, voluntary and anytime revocable consent of that employee (with very few and very narrow exceptions carefully scoped by the legislator). Writing something to a different effect into the employment contract will be legally void, because the consent to use the picture MUST be voluntary and anytime revocable. Of course, an acceptable alternative to no meetings in Germany or any other country with the rules you suggest apply would be explicit permission on registration forms as a condition of attendance. Or, presumably, a Chair could make an announcement that anyone who continues to sit in a particular room is giving permission for such identification. Please do not confuse any necessity to identify an originator of a contribution (which is where data protection laws would apply) and the personal privacy rights of individuals about photosportraits of themselves. -Martin
Re: Future Handling of Blue Sheets
At 06:31 PM 4/24/2012, Stephan Wenger wrote: Remember, this whole discussion is about a) taking pictures, and b) publishing them. incorrect, this discussion started with Russ proposing copying each WG meeting's attendees list - from the blue sheet - into the meeting minutes. It has gone on from there. James Avoid either, and we should be completely save. Do both, and it still takes at least one person to take offense to the point where he calls police or runs to a lawyer, proof, a judge finding that the privacy rights of the person have been violated, and so on. People take pictures in meetings all the time, in Germany and elsewhere. Folks exceed the speed limit (yes, even in Germany large stretches of the freeway system and all other roads have a speed limit :-). In either case, many say that the risk is in an acceptable relationship with the benefits. Stephan On 4.24.2012 16:19 , John C Klensin john-i...@jck.com wrote: --On Tuesday, 24 April, 2012 11:52 -1000 Robin Uyeshiro uyesh...@ifa.hawaii.edu wrote: snip The issue with John's purpose is that he is taking a picture of the audience(!), and if you take such a picture from the front in a small meeting room, there might a small number of folks end up _prominently_ in the foreground of that picture, at which point their consent will be required. Again, IANAL and I don't think you are either, so I don't want to argue prominently versus non-prominently. I can assure that, when pictures were used, the clear intent was the everyone with his or her hand up was individually identifiable and almost everyone else was too. john
RE: Conclusion of the last call on draft-housley-two-maturity-levels
At 04:29 PM 9/2/2011, Ross Callon wrote: In looking through this discussion, I see: - People saying that moving from 3 steps to 2 steps is a small step in the right direction, lets do it. Many people who have said this (including I) have been silent for a while quite possibly because they have gotten frustrated with the endless discussion. I think there are many that have voiced their frustrations that this draft isn't addressing the more important issue (or issues) in their minds. I don't see a consensus on what that 1 issue is, but many (including I) have said it's the problem of such a high hurdle to get a draft to PS. Because this draft isn't addressing that problem, I'm frustrated with this draft - because - I don't know that if this draft were to RFC that the high hurdle for PSs is the next thing tackled. OTOH, if the high hurdle for PSs were what we worked on initially, and solve it, then I'd probably be much more comfortable with this draft progressing (then having started to appreciate what this means as a second step where getting a draft to PS is the first step). just my opinion James - People saying that there are other more important problems that we should be focusing on. Therefore, rather than either making this simple change or discussing other possible improvements in the process, instead let's debate this simple step forever and never get anything done. - People saying that this step won't do anything. Two things that I don't seem to have picked up on: (i) Any consensus that a 3 step process is better than a 2 step process; (ii) Any hint of moving towards an agreement on other things that we might do to improve the process. I think that we should go to a two maturity level process, be done with this little step, and also enthusiastically encourage people to write drafts that propose *other* changes to the process. Then at least we can be debating something different 6 months from now than we were debating last year. Ross -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Friday, September 02, 2011 4:20 PM To: Jari Arkko Cc: ietf@ietf.org Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels --On Tuesday, August 30, 2011 23:17 +0300 Jari Arkko jari.ar...@piuha.net wrote: I have reviewed the discussion from the last call on this document. My conclusion as the sponsoring AD is that we have consensus to move forward. There was clearly a constituency who believed this is a good (albeit small) step forward. A number of other people did not care so much; did not believe there was either harm or benefit. I also saw a couple of opposing opinions, though some of them were more about a desire to do something else than specific objections about this proposal. I will be recommending that the IESG approve the draft. Jari, Like Scott, I wonder if there is some misunderstanding here. Part of the problem is the way that this draft was developed and the discussion has been handled, despite your heroic efforts. For example: (1) If someone says we should be looking in this different direction instead, the response has been irrelevant to consideration to this proposal, so it should go forward. The irrelevancy is debatable, but that may be another issue. (2) If someone says the proposal claims to solve problem X, but there is no evidence for that, the assertion about what problems are being solved is removed, but there is no substantive change to the draft. (3) If someone says this solves no problem, the response has been that things have been broken for years and therefore this proposal should be approved. (The difficulty with that logic should be clear.) Sometimes that has been accompanied by a claim that it is the only proposal on the table and should therefore be adopted (even though that statement isn't true and, true or not, would never even be considered if we were considering a protocol specification). One of the co-authors has recently argued for a very high standard of compelling necessity to make changes to important processes or related documents, but that criterion obviously does not apply to this document. (4) There have been a few arguments made that making this sort of change --without compelling justification and without evidence that it would accomplish anything-- would actually be harmful. There has been no substantive response to those arguments. In normal Last Calls, such comments are known as unresolved issues and the sponsoring AD does not move the document forward until they are addressed (or even dismissed) in some substantive way. (5) This is probably off-topic unless someone decides to appeal, but, to a certain extent, the processing of this document points out a far more significant problem with the handling of process change suggestions in the IETF. The IESG holds a discussion. An IESG member prepares a draft.
Re: voting system for future venues?
At 01:21 PM 8/29/2011, Melinda Shore wrote: On 08/29/2011 09:59 AM, Scott Brim wrote: WGs can and should apply discipline to make email the primary mode of interacting, with occasional virtual meetings and even more occasional physical meetings. Just because there is a physical meeting doesn't mean a WG should let issues pile up to be resolved there. Well, that's the theory but it's been my experience that more stuff is being resolved in meetings in recent years rather than less stuff (also, more voting and less consensus). I think that there's some relationship between this and increasing meeting costs, etc., and that both may be tied to the increasing professionalization (professional standardizers) of the IETF over the past decade or so. my (not so kind) view of professional standardizers) is that they slow things down and take too long to make progress - perhaps because they aren't that fast on the uptick/too detached from how products are actually built -- is that what you believe is happening in the IETF now (and for at least the last 5 or so years)? James BTW - I don't believe that is what's happening to the IETF, but perhaps I'm slow on the uptick. I think we're getting into way too complicated architectures involving way too many lateral WGs and/or Areas. We also jump too fast to the newest shiny thing, and don't complete our work in a given WG or Area. Take RTCWEB in the RAI Area, for instance. It's all the rage, cuz it's the newest, flashiest, shiniest thing, so everyone in RAI swarms to it - but it's not new. It's a rehash of something (or several somethings) just built in the RAI Area. It's just packaged a little differently, is backed by a HUGE company, and no one wants to get left out of the in crowd who was there from the start... Melinda ___ 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: Experiment for different schedule for Friday
At 04:24 PM 8/22/2011, IETF Chair wrote: The IESG is considering a different schedule for the Friday of IETF 82. The IESG is seeking your input on these potential changes. The IESG would like to try a schedule experiment on Friday, using this schedule: 9:00 AM - 11:00 AM - Session I 11:00 AM - 11:20 AM - Room Change and Cookie Break 11:20 AM - 12:20 PM - Session II 12:10 PM - 12:30 PM - Room Change Break 12:30 PM - 13:30 PM - Session III since there will be cookies, this is ok with me ;-) The IESG has already consulted with the IAOC because of the cost associated with the additional food and beverage break. The IAOC believes that the additional cost can be managed without raising the meeting fee. bonus James On behalf of the IESG, Russ ___ 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: location preferences
At 04:56 PM 6/20/2011, Dave CROCKER wrote: On 6/20/2011 2:47 PM, Andrew Sullivan wrote: Speaking only for myself, I will note that the worst IETF experience I ever had was in Dallas: the location was remote and poor, we were flooded out of the hotel, alternatives nearby were few, and you needed a car to go anywhere. It was, indeed, a horrible venue, along any number of parameters. Andrew rumor has it that IETF65 was supposed to be in New Orleans that November, but got hit by a little event called Katrina, so (again - only rumors) there had to be a mad scramble to find any hotel that could take 1400 in 2 months notice. Don't hold Dallas being hit by a freak storm against the city's ability to have a decent conference - especially given more time to plan which hotel to stay in. Fortunately, Dallas has a few other choices that are likely to work better, along every parameter we care about. yes it does James Also, the crime statistics for the city made me uneasy. The crime statistics for most American cities and most major European cities make me uneasy. In 1983 I moved to Toronto from Washington DC and was amused by the different perspectives about crime. I was told there were a couple of blocks in downtown Toronto that weren't very safe for women alone at night. By contract, perhaps 1/3-1/2 of DC was unsafe for almost anyone at night and maybe 1/4 for most folk during the day... I've been ripped off twice in Paris including a double-team pocket-picking. Purses and backpacks of IETF have been stolen -- including from the middle of meeting rooms(!) -- in Munich, Stockholm and I believe some other places. In any event, if crime statistics are to become a factor in choosing IETF venues, the IETF community needs to develop some consensus about this, including what the acceptable parameters are. As of now, I believe that's not generally part of the discussion in choosing a venue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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: I-D Action:draft-housley-two-maturity-levels-04.txt
At 04:05 PM 3/14/2011, Brian E Carpenter wrote: There are numerous improvements in this version and I hope we can get consensus soon. Just a couple of remarks on 5. Transition to a Standards Track with Two Maturity Levels 1) Probably there should be a statement that all existing Internet Standard documents are still classified as Internet Standard. That may seem blindingly obvious, but if we don't write it down, somebody will ask. 2) More substantively, Any protocol or service that is currently at the Draft Standard maturity level may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. This reclassification is accomplished by submitting a request to the IESG along with a description of the implementation and operational experience. I'm a bit concerned that this doesn't scale, and we will be left with a long tail of DS documents that end up in limbo. One way to avoid this is to encourage bulk reclassifications (rather like we did a bulk declassification in RFC 4450). Another way is to define a sunset date, e.g. Any documents that are still classified as Draft Standard two years after the publication of this RFC will be automatically downgraded to Proposed Standard. Brian playing devil's advocate here... Say someone submits a request for an existing DS to the IESG and it takes 6 months (or 3 months) to get through the process, but only 2 months remain before the 2 year window is up (since this RFC was published). Does that grandfather the DS into the process - meaning that document is no longer subject to this 'within 2 year notice' rule? I'm just saying that this appears to beg all DS editors to get their DS notifications into the IESG sooner rather than later, which is fine, but that also creates a heck of a workload on the IESG that they currently do not have, does it not? Something is going to be impacted. James 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: I-D Action:draft-housley-two-maturity-levels-04.txt
At 02:05 PM 3/15/2011, Brian Carpenter wrote: On Wed, Mar 16, 2011 at 1:11 AM, Phillip Hallam-Baker hal...@gmail.com wrote: On Tue, Mar 15, 2011 at 3:33 AM, James M. Polk jmp...@cisco.com wrote: Brian playing devil's advocate here... Say someone submits a request for an existing DS to the IESG and it takes 6 months (or 3 months) to get through the process, but only 2 months remain before the 2 year window is up (since this RFC was published). Does that grandfather the DS into the process - meaning that document is no longer subject to this 'within 2 year notice' rule? I'm just saying that this appears to beg all DS editors to get their DS notifications into the IESG sooner rather than later, which is fine, but that also creates a heck of a workload on the IESG that they currently do not have, does it not? Something is going to be impacted. Make it a 2 year deadline for receiving requests. Problem solved. Yes, good idea. thanks james Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 83 Venue
At 03:31 PM 1/19/2011, IETF Administrative Director wrote: The IAOC is pleased to announce Paris as the site for IETF 83 from 25 - 30 March 2012. The IETF last met in the city in 2005 at IETF 63. Paris was the number one choice for a European venue in a venue preference survey conducted after IETF 78. I don't know about this... after all, the last time we had an IETF there is when EKR blew a gasket at the lack of (real) cookies during the breaks. This cannot be overlooked as an isolated incident, or hand-waved away. I wouldn't want to be around him if this were to occur again. ;-) James 2012 IETF 83 Paris 25 - 30 MarchHost: your name here ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: BCP request: WiFi at High-Tech Meetings
At 09:55 AM 1/4/2011, Phillip Hallam-Baker wrote: It could be the 11a support. Or it might well be the vendor that supplies the 11a equipment. At home I have a box with 7 defunct WiFi routers that I discarded after they started to fail. Specifically the wireless side of the router would stop functioning or require rebooting every 24 hours or so to keep functioning. Then three years ago I mentioned the problem on this list and bought an AirPort Extreme on the advice of several people. It has now been running for three years without issue. I do notice that a significant proportion of laptops used at IETFs are produced by one specific vendor. Phillip - I bet you there are more Thinkpads than laptops from your unnamed vendor at any given IETF over the last 5-8 years. Don't take this as an attack on your laptop's vendor, I happening to be in transition to that very same vendor from a Thinkpad. James And lets face it, we are the type of audience that is quite willing to pay two to three times the minimum for a laptop. On Mon, Jan 3, 2011 at 3:49 PM, Worley, Dale R (Dale) mailto:dwor...@avaya.comdwor...@avaya.com wrote: From: mailto:ietf-boun...@ietf.orgietf-boun...@ietf.org [mailto:ietf-boun...@ietf.orgietf-boun...@ietf.org] On Behalf Of Chris Elliott [mailto:chell...@pobox.comchell...@pobox.com] I strongly agree here. Encourage .11a (5ghz) usage, disable .11n for the .11b/g 2.4ghz spectrum. We also have the luxury of a large number of repeat attendees, and many of you have learned the benefits of using .11a and will go out of your way to use it. We facilitate that through advertising .11a-only SSID's. ___ Whereas the NYT article seems to be describing large rooms full of journalists and other technology illiterates, many of whom are trying to send or receive streaming video, sometimes the video of the presenter they are sitting in front of! Dale ___ Ietf mailing list mailto:Ietf@ietf.orgIetf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Website: http://hallambaker.com/http://hallambaker.com/ ___ 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
TSVDIR Review for draft-ietf-mpls-ip-options-05
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC mailto:tsv-...@ietf.orgtsv-...@ietf.org if you reply to or forward this review. Summary: This is a well written, concise and needed modification to MPLS. That said, I don't understand why the 1st minor issue below is present. Recommend (fairly strongly) adding the Document Updates: RFC 3031, RFC 3032 as mentioned below on this first page of this RFC to be. Transport Issues: There are no issues minor issues: - S2 Motivation, last sentence is We believe that this document adds details that have not been fully addressed in [RFC3031] and [RFC3032] as well as complements [RFC3270], [RFC3443] and [RFC4950]. I find it surprising that this document does not formally update 3031 and 3032, given that it is mandatory to implement, optional to invoke. ISTM, as an outsider to MPLS, this would in fact be the case given the impact of/to IP stacks not adhering to this proposed standard. - Section 5.2 is about Router Alert Options, and states At the time of this writing I wonder if this subsection is valid, or needs another review against this IntArea ID http://tools.ietf.org/html/draft-ietf-intarea-router-alert-considerations-02 to still be valid in a month or two once the IntArea ID (currently in WGLC) is processed by the IESG and RFC-Editor? IMO - these two docs are progressing near enough to each other to each consider what the other says - with or without a normative or informative reference in either or both docs to the other. nits: - I'm surprised to see the Abstract on page 2. I thought we collectively fixed the case in which the Abstract can be on any page other than page 1. - at the page Footer, in the middle of the line, there isn't a short document name - which has been there on all previous well formed IDs and RFCs that I have seen (which of course is not all of them). It is recommended the authors pick a short form name for the subject of this doc for this location, such as LER Header Option Behaviors - S3, 4th para, second to last sentence is: First a downstream LSR may have not have sufficient IP routing information to forward the packet resulting in packet loss. recommend removing the first instance of have. The sentence reads better without it. - S3, 4th para, last two sentences list a First and a Second reason correctly, but are missing required commas after each word (i.e., First, ..., and Second, ... ) - S3, 5th para, 1st sentence is lacking commas here: ...FEC, yet are forwarded into an IP/MPLS network without being MPLS-encapsulated, present... - S5.1, last bullet has this: ...MPLS encapsulation at a ingress LER ... ^ s/a/an James ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Feedback on Day Passes
At 12:48 PM 11/30/2010, Bob Hinden wrote: James, Tobias, On Nov 29, 2010, at 10:46 AM, James M. Polk wrote: At 12:39 PM 11/29/2010, Tobias Gondrom wrote: Bob, agree with James request for more detail on the used day passes, if possible. We took surveys of day pass users after IETF76, IETF77, and IETF78. The results can be found at: IETF 76 - Hiroshima https://www.surveymonkey.com/sr.aspx?sm=q7wUzp3Y7LpMd_2fHQZ_2bG6_2f407S5nGSHbzxbsOltYaqV0_3d IETF 77 - Anaheim https://www.surveymonkey.com/sr.aspx?sm=p0f3XCVFGjqzGX13hCcDDayhGXXS5zm5dcL9Sk6avpI_3d IETF 78 - Maastricht https://www.surveymonkey.com/sr.aspx?sm=WQ_2bNSXS9_2bqPXQkbU1IrSnnAXsxefNAMdCl_2fkRwsBqD8_3d The survey for Beijing just opened and was sent to people to bought day passes. Personally, I believe the risen cost for day passes probably knocked out some of the demand (basic supply-demand curve from economics ;-) ). Probably day passes are more attractive to local participants who want to get a taste of the IETF or only visit one WG session. And in particular in China the cost of $350 is very high compared to local salary levels, so am not surprised about the decline. Well, I think $350 is high for any country for a day-pass. So IMO that should be lowered regardless... My personal view of day passes would be to allow first-time visitors (especially when from the local area) to get a taste of work with the IETF and reduce the initial hurdle. this is actually an interesting idea - to give legitimate first-timers a price break (and I'm talking about for the week, not just day-passes). That might increase overall the numbers of local attendees (i.e., from that country - where the travel costs aren't as great because the airfare isn't as much or there is no airfare at all). Has this been considered? The result of the surveys we took after the past three meetings showed people who had only attended one meeting: IETF76 33% (9 of 27) IETF77 39% (26 of 67) IETF78 75% (6 of 8) ** This is, of course, only the people who responded to the survey. From the registration data, Day Pass usage was 124, 135, and 71 for these meetings, and total first time attendees was 267, 192, 194. It's not clear to me how much correlation there is between day passes and first time attendees. We are taking a look at the registration data to see if people who bought a day pass attended a single IETF meeting or continue to attend subsequent meetings. I will also see if we can do a total correlation with first time attendees and day passes. I also note, that if we want to encourage first time attendees, we could have a discounted full week registration fee targeted at that. IMHO, that would be better than the day pass if that is the intent. Bob - I apologize for the miscommunication. Full week registration was what I meant when I stated this is actually an interesting idea... James Hope this is helpful. Bob ** Note, this number was derived by setting up a filter on the survey data. James In this regard I welcome the day passes and would even like to see them with lower prices. Not sure if others would share this point of view. But if we would have a common understanding on the purpose of day passes, we could even tailor the experiment a bit to be more targeted: e.g. only offer day passes to local newbies at a lower rate (in the $200 range or below) on conditions of only one day pass per person, only for first time IETF attendance (have never attended an IETF before) and maybe only if you live in hosting country or region (I figure we have the list of past participants so could actually easily verify such conditions). Just my 5 cents. Many greetings, Tobias On 11/22/2010 09:28 PM, James M. Polk wrote: Bob Is there any data to tell us whether these one-day passes were targeting a specific WG or day of converged scheduling in which a key number of WGs met within an area? It might be quite useful to know if day-passers were targeting a WG (and if so, which WG) or were just taking in whatever was on the day they wanted to (or could) attend. James At 02:59 PM 11/22/2010, Bob Hinden wrote: Hi, As part of the IAOC presentation in Beijing, I said that the IAOC will be making a decision on Day Passes in the middle of December. I would like your feedback on this. As reported in Beijing, the goal of the Day Pass experiment is to Goal is to access convenience to IETF attendees without significant impact on revenue Usage has been: 124 in Hiroshima ($200) 135 in Anaheim ($200) 71 in Maastricht ($350) 47 in Beijing ($350) While this looks like a trend toward lower usage (possibly driven by higher fees), it's hard to tell if this trend will continue or reverse. Possible reasons to continue offering Day Passes: - No significant negative impact on overall revenue. Hard to tell what percentage of people would buy
Re: Feedback on Day Passes
At 12:39 PM 11/29/2010, Tobias Gondrom wrote: Bob, agree with James request for more detail on the used day passes, if possible. Personally, I believe the risen cost for day passes probably knocked out some of the demand (basic supply-demand curve from economics ;-) ). Probably day passes are more attractive to local participants who want to get a taste of the IETF or only visit one WG session. And in particular in China the cost of $350 is very high compared to local salary levels, so am not surprised about the decline. Well, I think $350 is high for any country for a day-pass. So IMO that should be lowered regardless... My personal view of day passes would be to allow first-time visitors (especially when from the local area) to get a taste of work with the IETF and reduce the initial hurdle. this is actually an interesting idea - to give legitimate first-timers a price break (and I'm talking about for the week, not just day-passes). That might increase overall the numbers of local attendees (i.e., from that country - where the travel costs aren't as great because the airfare isn't as much or there is no airfare at all). Has this been considered? James In this regard I welcome the day passes and would even like to see them with lower prices. Not sure if others would share this point of view. But if we would have a common understanding on the purpose of day passes, we could even tailor the experiment a bit to be more targeted: e.g. only offer day passes to local newbies at a lower rate (in the $200 range or below) on conditions of only one day pass per person, only for first time IETF attendance (have never attended an IETF before) and maybe only if you live in hosting country or region (I figure we have the list of past participants so could actually easily verify such conditions). Just my 5 cents. Many greetings, Tobias On 11/22/2010 09:28 PM, James M. Polk wrote: Bob Is there any data to tell us whether these one-day passes were targeting a specific WG or day of converged scheduling in which a key number of WGs met within an area? It might be quite useful to know if day-passers were targeting a WG (and if so, which WG) or were just taking in whatever was on the day they wanted to (or could) attend. James At 02:59 PM 11/22/2010, Bob Hinden wrote: Hi, As part of the IAOC presentation in Beijing, I said that the IAOC will be making a decision on Day Passes in the middle of December. I would like your feedback on this. As reported in Beijing, the goal of the Day Pass experiment is to Goal is to access convenience to IETF attendees without significant impact on revenue Usage has been: 124 in Hiroshima ($200) 135 in Anaheim ($200) 71 in Maastricht ($350) 47 in Beijing ($350) While this looks like a trend toward lower usage (possibly driven by higher fees), it's hard to tell if this trend will continue or reverse. Possible reasons to continue offering Day Passes: - No significant negative impact on overall revenue. Hard to tell what percentage of people would buy full registration instead. - Useful for people buying the day passes. Possible reasons to discontinue offering Day Passes: - Caused unexpected effect on Nomcom qualification. - Encourages drop in for a single session and discourages full IETF experience, meetings in the hall, and cross area fertilization. - Not being used heavily. - Could impact revenue if usage increased. I appreciate you feedback. Feedback can be sent to me directly, the IAOC list (i...@ietf.org), or to the IETF list (ietf@ietf.org). Try to avoid all three :-) Thanks, Bob ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Feedback on Day Passes
Bob Is there any data to tell us whether these one-day passes were targeting a specific WG or day of converged scheduling in which a key number of WGs met within an area? It might be quite useful to know if day-passers were targeting a WG (and if so, which WG) or were just taking in whatever was on the day they wanted to (or could) attend. James At 02:59 PM 11/22/2010, Bob Hinden wrote: Hi, As part of the IAOC presentation in Beijing, I said that the IAOC will be making a decision on Day Passes in the middle of December. I would like your feedback on this. As reported in Beijing, the goal of the Day Pass experiment is to Goal is to access convenience to IETF attendees without significant impact on revenue Usage has been: 124 in Hiroshima ($200) 135 in Anaheim ($200) 71 in Maastricht ($350) 47 in Beijing ($350) While this looks like a trend toward lower usage (possibly driven by higher fees), it's hard to tell if this trend will continue or reverse. Possible reasons to continue offering Day Passes: - No significant negative impact on overall revenue. Hard to tell what percentage of people would buy full registration instead. - Useful for people buying the day passes. Possible reasons to discontinue offering Day Passes: - Caused unexpected effect on Nomcom qualification. - Encourages drop in for a single session and discourages full IETF experience, meetings in the hall, and cross area fertilization. - Not being used heavily. - Could impact revenue if usage increased. I appreciate you feedback. Feedback can be sent to me directly, the IAOC list (i...@ietf.org), or to the IETF list (ietf@ietf.org). Try to avoid all three :-) Thanks, Bob ___ 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: [IAOC] Badges and blue sheets
heck, make these miscreants where a special colored dot broadcasting they're out of a job so everyone will know they're meeting beggers and hopefully folks with jobs will feed them throughgout the week too... are any of you really this idealistic, or does it just feel good typing the words to pick on the downtrodden? (jeez) James At 06:26 AM 11/12/2010, JORDI PALET MARTINEZ wrote: Yes, you get all that in Spain. It is obvious, if you claim for public money, you agree to make it public. Transparency is over privacy. If you opt for your privacy, then you shouldn't get the public funding. Regards, Jordi From: Yoav Nir y...@checkpoint.com Reply-To: y...@checkpoint.com Date: Fri, 12 Nov 2010 11:08:39 +0200 To: jordi.pa...@consulintel.es jordi.pa...@consulintel.es Cc: i...@ietf.org i...@ietf.org, IETF discussion list ietf@ietf.org Subject: Re: [IAOC] Badges and blue sheets On Nov 12, 2010, at 7:36 AM, JORDI PALET MARTINEZ wrote: Hi Henk, I don't agree. If there is people essential to the meeting but can't pay, as we all pay for that, we have the right to know. I disagree with that. There is a privacy issue here. If x can't pay his way, and needs a comp ticket, it's enough that the IETF chair knows about this. It's not our right to know of their financial situation. This is an open organization right ? I will be VERY concerned if we don't have this information being made public immediately. It sounds really really strange to me. You pay for everything the Spanish government does, which, I assume, includes some kinds of welfare like unemployment benefits. You don't get a list of all people who get these benefits, do you? Is it documented in any RFC ? Moreover, if I'm in between jobs, or need a new job, or whatever, I think is good for me that others know, in case I can get some new offers. People look for jobs in various ways at their discretion. Being from Spain, there are only 6 more of your countrymen at the Beijing meeting. How many relevant job offers would you get? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [79all] IETF Badge
At 08:14 PM 11/11/2010, Scott O. Bradner wrote: This seems to be this year's cookie crises... speaking of cookies, I haven't found satisfactory ones yet (anywhere) ;-) BTW - otherwise, I've enjoyed the meeting and facilities here James ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
At 02:06 PM 10/28/2010, Eric Rosen wrote: James perhaps this needs to be stated (that the Type 4 is created by this James doc for your purpose)? I think the doc already makes this clear, maybe I'm not sure what you are asking. you may be right (that I'm not being clear). This is all about the wording in Section 3. You doc creates and IANA registers this Type 4 message (in the second paragraph), but you state in the doc that '...(this) may be used to assign a v6 customer to a P-tunnel in a PIMv4 SP.' To me, and this has been beaten into me over the 340+ IDs I've written, that anytime one uses lowercase may, it actually needs to be replaced with can. If I do that in my head, this usage of a Type 4 is wishy-washy, in other words, something else is obviously available to do the same thing, otherwise the can meaning would have been stronger - like a SHOULD be used to or MUST be used to or even will be used to, or the easiest is used to. And yes, I see that in the first paragraph you state that in some other doc a '...Type 1 may be used to to assign a v4 customer to a P-tunnel in a PIMv4 SP.' so the wording is consistent, but I still don't like the lowercase use of a 2119 word, especially may, because that means there are alternatives known, but here, they are not stated. James You can probably imagine how many SIP and RSVP protocol extensions James there are (70+ and about 20 respectively off the top of my head), and James yet every one of them have to state Session Initiation Protocol James (SIP) and ReSource ReserVation Protocol (version-1) (RSVPv1) the James first time they appear, no matter how big the community of interest James is. And this makes sense to you? no, but it is the way it has been and continues to be, at least in the areas I'm authoring in. So you can take this one with the grain of salt, because those of mine that have slipped through to the RFC-Editor have always been caught there, but now that I've pointed this out... Okay, I will expand the occurrence of S-PMSI in the abstract. On the issue of the maximum UDP packet size, I think that is an implementation issue and I don't think it is appropriate to raise it in this document. It would normally be ok, but your doc says effectively go ahead and stick as many Joins as you want and something/where else will deal with the consequences... and that doesn't make a good spec to me. I recommend that at least a warning of link MTU causing fragmentation be mentioned as a potential inefficient side effect. James ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
BTW Eric, my views here are just comments and shouldn't be taken as if these are showstoppers for your doc's progression. James At 02:38 PM 10/28/2010, James M. Polk wrote: At 02:06 PM 10/28/2010, Eric Rosen wrote: James perhaps this needs to be stated (that the Type 4 is created by this James doc for your purpose)? I think the doc already makes this clear, maybe I'm not sure what you are asking. you may be right (that I'm not being clear). This is all about the wording in Section 3. You doc creates and IANA registers this Type 4 message (in the second paragraph), but you state in the doc that '...(this) may be used to assign a v6 customer to a P-tunnel in a PIMv4 SP.' To me, and this has been beaten into me over the 340+ IDs I've written, that anytime one uses lowercase may, it actually needs to be replaced with can. If I do that in my head, this usage of a Type 4 is wishy-washy, in other words, something else is obviously available to do the same thing, otherwise the can meaning would have been stronger - like a SHOULD be used to or MUST be used to or even will be used to, or the easiest is used to. And yes, I see that in the first paragraph you state that in some other doc a '...Type 1 may be used to to assign a v4 customer to a P-tunnel in a PIMv4 SP.' so the wording is consistent, but I still don't like the lowercase use of a 2119 word, especially may, because that means there are alternatives known, but here, they are not stated. James You can probably imagine how many SIP and RSVP protocol extensions James there are (70+ and about 20 respectively off the top of my head), and James yet every one of them have to state Session Initiation Protocol James (SIP) and ReSource ReserVation Protocol (version-1) (RSVPv1) the James first time they appear, no matter how big the community of interest James is. And this makes sense to you? no, but it is the way it has been and continues to be, at least in the areas I'm authoring in. So you can take this one with the grain of salt, because those of mine that have slipped through to the RFC-Editor have always been caught there, but now that I've pointed this out... Okay, I will expand the occurrence of S-PMSI in the abstract. On the issue of the maximum UDP packet size, I think that is an implementation issue and I don't think it is appropriate to raise it in this document. It would normally be ok, but your doc says effectively go ahead and stick as many Joins as you want and something/where else will deal with the consequences... and that doesn't make a good spec to me. I recommend that at least a warning of link MTU causing fragmentation be mentioned as a potential inefficient side effect. James ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
Eric At 01:44 PM 10/27/2010, Eric Rosen wrote: Minor issues: - Section 3, 2nd para, second sentence is: A Type 4 S-PMSI Join may be used to assign a customer IPv6 (C-S,C-G) flow to a P-tunnel that is created by PIM/IPv4. I'm curious how else might a Type 4 S-PMSI be used? This sentence makes it seem unclear as to whether there are any uses a Type 4. While there is no other use of the Type 4 S-PMSI Join, there are other mechanisms that may be used for the same purpose. perhaps this needs to be stated (that the Type 4 is created by this doc for your purpose)? If the text read is used, someone might interpret that as meaning that there is no other mechanism for assigning a v6 flow to a v4 P-tunnel. So I think the wording should remain as is. I'm not sold, but won't make a big deal about it. - Section 3.2, 2nd para, 1st sentence is: A single UDP datagram MAY carry multiple S-PMSI Join Messages, as many as can fit entirely within it. What's the MTU of a UDP packet (or frame)? Might there be a problem if the MTU of UDP doesn't match the MTU of the link on the PE? This doesn't appear to be covered by the sentence above, but should be, IMO (i.e., state that the link MTU is the max that can fit new S-PMSI Join Messages, or the max bytes UDP allows should be stated here explicitly). I think it would be an inappropriate layering violation to state the maximum UDP size in this specification. fair - which was one of my goals with asking this, but a warning about the perils of having an unreliable packet type exceed the MTU of a link my be warranted, at least in the Security considerations section (if not elsewhere). If someone were to create a UDP packet that exceeded the link MTU, presumably it would get fragmented and reassembled. This might not be a wise implementation, but it would still work, and I don't see a reason to prohibit it. I can see this reason for recommended against doing it (in the text) YMMV - as someone not familiar with Multicast VPNs, having the acronym S-PMSI Join messages *not* exploded in the abstract is a bit confusing. I did think about this, but I thought that using the term Selective Provider Multicast Service Interface Join message in the abstract would not be any less confusing to someone who is not familiar with the MVPN work, and it would be more confusing to someone who is familiar with the MVPN work. You can probably imagine how many SIP and RSVP protocol extensions there are (70+ and about 20 respectively off the top of my head), and yet every one of them have to state Session Initiation Protocol (SIP) and ReSource ReserVation Protocol (version-1) (RSVPv1) the first time they appear, no matter how big the community of interest is. I had to look into the first and second paragraphs of the intro to determine for myself that it means Selective Provider Multicast Service Interface, That's a technical term defined in draft-ietf-l3vpn-2547bis-mcast. I'll bet you didn't look in that draft to see what this really means! to me, that doesn't mean you don't explode it... This is one of those cases where anyone who actually has to use the document will know what an S-PMSI Join message is, even if they don't know what the acronym expands to. I realize that the RFC Editor will probably expand it anyway ;-) - Intro, 3rd para, 1st sentence s/specifications/capability (or capabilities) I think s/specifications/specification would be better. MVPN implementers are likely to also be BGP and/or LDP implementers, and in those protocols the term capability is used to refer to something that requires explcit advertisement. ok, you know your area better You had a number of valid complaints about the writing of the first two paragraphs of the introduction. What do you think of the following proposed rewrite: The Multicast Virtual Private Networks (MVPN) specification [MVPN] defines the notion of a PMSI (Provider Multicast Service Interface), and specifies how a PMSI can be instantiated by various kinds of tunnels through a service provider's network (P-tunnels). It also specifies the procedures for using PIM (Protocol Independent Multicast, [RFC4601]) as the control protocol between Provider Edge (PE) routers. When PIM is used as the control protocol, PIM messages are sent through a P-tunnel from one PE in an MVPN to others in the same MVPN. These PIM messages carry customer multicast routing information. However, [MVPN] does not cover the case where the customer is using IPv6, but the service provider is using P-tunnels created by PIM over an IPv4 infrastructure. The MVPN specification also specifies S-PMSI (Selective PMSI) Join messages, which are optionally used to bind particular customer multicast flows to particular P-tunnels. However, the specification does not cover the case where the customer flows are IPv6 flows. yes, this makes it much
Gen-ART review of draft-ietf-l3vpn-mvpn-spmsi-joins-01
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: draft-ietf-l3vpn-mvpn-spmsi-joins-01.txt Reviewer: James Polk (jmp...@cisco.com) Review Date: 2010-10-27 IETF LC End Date: 2010-09-16 IESG Telechat date: (if known) Summary: This is a short doc that appears to do what sets out to do. I am not a PIM or MVPN expert, so take my comments and suggestions as you would any other comment within the L3VPN WG. there are a few nits, with some rising up a bit to be minor issues - but that's as far as it goes. Once these are cleared up, I believe this doc is ready to progress. Major issues: - there are no major issues with this doc. Minor issues: - Section 3, 2nd para, second sentence is: A Type 4 S-PMSI Join may be used to assign a customer IPv6 (C-S,C-G) flow to a P-tunnel that is created by PIM/IPv4. I'm curious how else might a Type 4 S-PMSI be used? This sentence makes it seem unclear as to whether there are any uses a Type 4. Recommend stating ...Join is used... or state in this or the next paragraph how else it can be used (unless I've missed something). - Section 3.2, 2nd para, 1st sentence is: A single UDP datagram MAY carry multiple S-PMSI Join Messages, as many as can fit entirely within it. What's the MTU of a UDP packet (or frame)? Might there be a problem if the MTU of UDP doesn't match the MTU of the link on the PE? This doesn't appear to be covered by the sentence above, but should be, IMO (i.e., state that the link MTU is the max that can fit new S-PMSI Join Messages, or the max bytes UDP allows should be stated here explicitly). Nits/editorial comments: - as someone not familiar with Multicast VPNs, having the acronym S-PMSI Join messages *not* exploded in the abstract is a bit confusing. I had to look into the first and second paragraphs of the intro to determine for myself that it means Selective Provider Multicast Service Interface, which isn't all in one explosion of this acronym. This might need to be changed for clarity. - The second paragraph's first sentence has an also that, to me, appears to be pointing back to the first paragraph. This is oddly disjointed. - in the second paragraph of the Intro section (2), the first sentence says ...allows PIM..., then the second sentence starts with ...requires PIM to be sent... and I don't get the connection. I think you mean to basically say PIM can be used to control PEs. If PIM is used, message are required to be sent through a P-tunnel from one PE in an MVPN to others in the same MVPN. - Intro, 2nd para, 4th sentence s/However, that specification.../However, RFC 4601... to be much clearer. - Intro, 2nd para, last sentence is redundant to what was stated 2 sentences earlier (including the However...), and should be removed. However, the specification does not cover the case where the customer flows are IPv6 flows. - Intro, 3rd para, 1st sentence s/specifications/capability (or capabilities) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
At 09:44 PM 10/25/2010, John Levine wrote: I am happy to agree to what the draft currently says. We've sliced and diced this many times over the years, and this seems very close to the least-unpopular view. That's the best we can hope for, imho. I'm not in love with the 3 maturity levels, especially when I was asked by an AD during Maastricht to provide proof of 2 independent implementations just to have an ID I was presenting be considered to become a WG item. That bar is just WAY too high. That said, I think the only part I'm concerned about with your proposal is allowing Internet Standards to reference Proposed Standards. Given that they can change so much - or more likely - they can have parts of them that just aren't ever implemented, but still have one or more of these un-implemented parts that is a critical to the Internet Standard. I guess if this clears the logjam of all the other issues, I'm willing to agree to this. James +1 R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
At 09:59 PM 9/30/2010, Brian E Carpenter wrote: Since you asked, I'd like to see this move forward as quickly as possible. Just one practical issue seems to be hanging. The draft says: This document makes no change to the current STD practice; however, this topic deserves further discussion by the whole community. Fair enough. But what happens to the existing STD numbers on the transition day? - Do existing full Standards keep their existing STD number as they are renamed Internet Standard? (I suggest: yes.) - Do existing Draft Standards acquire an STD number as they are renamed Internet Standard? (Pragmatically, I suggest no, unless they already obsolete or update an existing STD.) Brian I'm not sure I agree on your second point (specifically on your position of no). DSs have achieved a demonstrable hurdle that PS couldn't - by definition - by achieving independent interoperability. TO group DSs back with PSs is unfair and IMO, rather inappropriate. Said another way, when looking at the current PS, DS and FS within the standards track - what sufficiently differentiates these 3 into two groups? I would argue provable interoperability is that differentiation, which is why I wouldn't back-step DSs into the category that PSs will move into. I would progress them into where FSs are going, i.e., the Internet Standard category. of course, other opinions may think otherwise... James Regards Brian Carpenter On 2010-09-02 08:02, Russ Housley wrote: Dear IETF community: I just posted an update to draft-housley-two-maturity-levels. I tried to reflect what I heard during the plenary discussion in Maastricht. Please review and comment. Thanks, Russ ___ 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: Optimizing for what? Was Re: IETF Attendance by continent
At 05:45 PM 9/3/2010, Hascall Sharp wrote: On 8/30/10 3:57 PM, Olaf Kolkman wrote: ...snip... Am I missing something? ...snip... Yes. The IETF is having too many meetings where physical presence is required in order to participate effectively in the work. Creating the ability to mimic or replicate the effectiveness of a WG meeting is only part of the benefit of attendance at an IETF. Many of us that have been going there for years and years have the benefit of chance/rendezvous meetings in the hallway to discuss a topic - that we didn't know was being discussed, or - that we may now find ourselves in the middle of, or - that a small group might want to have outside of the main discussion area/session, or - etc Many of us have lots of ideas bantering around in our heads between meetings (or that have been dormant for a while) that this type of chance meeting could generate something of a meeting-of-the-minds about starting something new or something different that how it's done now. Many newcomers - whether this is their actual first meeting or just in their first few meetings - actively or passively seek out certain individuals for the possibility of having such a planned chance meeting in a hallway. None of this can effectively be done with IETF meetings moving to webex or worse, only on email. That said - I fully understand the financial burdens on people or corporations during non-robust years of economic (non) growth, such as we're in the middle of. JMO, which could be wrong James It seems to me that IETF is going in the wrong direction in terms of meetings. But maybe I'm getting old and cranky and everyone else has an ever expanding travel budget. chip ___ 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: All these discussions about meeting venues
At 06:31 PM 8/29/2010, Randall Gellens wrote: At 7:23 PM -0400 8/29/10, Marshall Eubanks wrote: It really comes down to which bias to apply in site selection: towards those who want to be a tourist, or those who want to do work. Based on my observation of and participation in the meeting selection process, the IAOC is (and has been throughout its existence) strongly weighted towards arranging meetings for those who want to do work. Touristic aspects hardly enter in. In various discussions prior to, during, and after Maastricht, my impression is that any complaint was dismissed with expressions of how delightful the city is. got that impression a few times too, which I didn't like ... james I apologize for allowing this impression to color my idea of the actual site selection process. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- An algorithm must be seen to be believed. -- Donald Knuth ___ 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: Meeting Venue Preference Survey
I'm going to pile on what Michael and Mary have already said, by saying the comparable list of cities (Minneapolis, Orlando, Vancouver, Barcelona, Prague) isn't even remotely close to including Maastricht. Each of the above cities are accessible internationally via air (as in: on intercontinental flights), and from many cities. Maastricht has a very small airport that I'm not sure you can get to it outside of NL and Germany (I'm sure I'm wrong, but I'm not wrong by much). You certainly can't get to Maastricht from North America or Asian directly. I agree with everything else Michael and Mary say as concerns, and mention that, like Michael, I'm not following as many WGs as I once did, however I am a WG chair, and have between 10-14 active IDs (in ~ 3 to 6 WGs) at any given time - but what Michael described was very near what I look for in a venue/IETF destination. James At 03:53 PM 8/27/2010, Mary Barnes wrote: I had the same reaction to the Maastricht comparison to any of those other cities in terms of equivalency. I added a comment in that regards to my responses. I agree 100% that the question is pretty useless if Maastricht is considered secondary. A survey of the number of hops (planes, trains and automobiles) that participants have to take to each of those secondary venues would highlight the distinct difference IMHO. I also added a comment about the fact that some of the differences in responses in terms of tourism opportunities likely depends upon how many sessions the individual needs to attend, how many WGs they chair and how many WGs they are presenting in. Asking folks that question would really help with the analysis. My guess is that it's those of us that need to be in sessions pretty much solid starting as early as 7:30 am and going to beyond 10pm on the majority of the days are the ones that are most concerned about efficiencies and the conveniences in getting the basics of food, a safe/clean place to sleep and Internet. Mary. On Fri, Aug 27, 2010 at 3:23 PM, Michael StJohns mstjo...@comcast.net wrote: Hi Ray - I started to take this survey then bounced out of it on the second page. This comes under the heading of bad survey design. I object to the way gateway/secondary cities are defined here and specifically equating Maastricht with Minneapolis seems somewhat stacking the deck. What I'm looking for in a meeting location is a venue with both formal and informal meeting spaces where I stand a good chance of having a good technical discussion with random people at pretty much any time of the day or night - that's my view of what has contributed to the IETF's success over the years. (Although the marathon session for the first draft of the Host Requirements document was probably stretching it) That generally means a central large hotel with attached conference space with access to non-hotel food and drink in close proximity. With respect to tourism, at different times in my career, I've had different interests in the IETF. Currently, I'm down to only a few WGs that I follow and as of the last meeting, none that I'm currently contributing to. Considering that I'm now consulting as my main activity and paying for this on my own dime, I expect that my ratio of tourism to attendance will be somewhat skewed towards tourism, but wouldn't expect the IETF to cater to that. My prime interest is still technical interaction and discussion. With respect to getting there - I'm finding the trend of getting off an international plane in a gateway city and then getting onto a train for 2-5 hours somewhat worrisome. I spent more time online for Maastricht trying to research how to get to Maastricht that I did reading IDs - and even then when I got to the Maastricht central train station, I had no luck buying a ticket for Maastricht Raandwyck. I live in a gateway city and would prefer to go to another gateway city - but I realize that's not always feasible and not always the best venue. I don't know how to categorize Maastricht vs Minneapolis except to say that air connectivity is better to Minneapolis and the meeting venue has more of what I'm looking for in an IETF setup - and I can't see any way to indicate that on your survey. To be honest, I don't think I'll find the output of this survey of much use in its current form. Mike At 03:12 PM 8/27/2010, Ray Pelletier wrote: All; Do you have IETF meeting venue preferences? If so, the IAOC wants to know! Please take this survey at: https://www.surveymonkey.com/s/8HPLZGJ Thanks! Ray IAD ___ 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: Nomcom Enhancements: Improving the IETF leadership selection process
At 06:15 AM 7/30/2010, Aaron Falk wrote: On 7/30/10 9:46 AM, Marshall Eubanks wrote: On Jul 30, 2010, at 3:11 AM, Mary Barnes wrote: Just to add my two cents to this discussion from a (past) noncom chair perpsective, having more experienced IETF participants on the Nomcom helps tremendously. It makes it far easier for the noncom chair and non-voting members (previous nomcom chair and liaisons) to stick to the roles as specified in RFC 3777 in terms of facilitatng and ensuring the integrity of the process and not influencing the decisions of the nomcom. In the end, each voting member gets one vote (using a methodology agreed by the voting members), so the positives of ensuring the nomcom has experienced members far outweigh any perceived negatives in my experience. I was discussing this with various people yesterday - maybe it would be useful to have a moving average NOMCOM, with a two year term, and 50% replacement each year. Once that was set up, I think that the need for experienced hands would diminish - one year on the NOMCOM seems to be quite a bit of experience. I don't think Mary is talking about members with previous nomcom experience but rather more IETF experience. I agree. In fact, why should we have nomcom members with little IETF experience picking our leadership? I agree completely on this point, even if it means having a 2-tiered system of half the current 3-of-5 meetings, and have (something like) 10-of-15 (or more) meetings. it's a thought (that goes to what Aaron is talking about) James --aaron ___ 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: Bar BoF on Location Coherence Wednesday at 11:30 AM
Richard This conflicts with the WG chairs lunch. Is there another time that's not inconflict with a meeting you're likely attending for this? James At 06:11 PM 3/17/2010, Richard Barnes wrote: Hey all, This message is announcing a bar BoF (lunch BoF) on Location Coherence -- interoperability between different location protocols and APIs -- for the lunch break on Wednesday of the IETF week. Location is still TBD (ironically). Full announcement here: http://www.ietf.org/mail-archive/web/geopriv/current/msg08377.html Mailing list here: http://groups.google.com/group/geo-loco Thanks, --Richard ___ 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: Last Call: draft-ietf-tsvwg-port-randomization (Part #1)
At 11:04 PM 3/2/2010, Fernando Gont wrote: (added CC to tsvwg) Hello, Alfred, Thanks so much for your feedback! Comments inline (1) Fundamental, general issue: Terminology A few voices have caused the authors to adopt a rather questionable terminology throughout the draft, during its last few revisions. - Randomization : My 5-vol. Dictionary of Mathematics defines (translated into English): Randomization; Randomized Algorithm: The introduction of randomness into mathematical algorithms. In practice, pseudo-random numbers are used. [] I therefore request that these inappropriate changes in terminology be backed out again. Port number obfuscation is a serious misnomer; port numbers still are transmitted in the clear under the methods presented in this draft; so port number randomization or, for short, port randomization is the proper term -- and it is widely adopted by the community since several years. I really don't know how to proceed here. That is, I'd honor your comment, but clearly that's not just up to me. What do the chairs and ADs think? Fernando and Alfred randomization in computing -- at least to me -- requires or necessitates a randomizer (pseudo or not), which this document doesn't attempt to specify or produce, so I'll have a hard time getting by this recommendation of yours. FWIW -- this was a specific point of discussion within the TSVWG, and not just a passing comment. We discussed this at length during a meeting, and in email with the ADs involved. My co-chair ought to chime in here if he feels strongly one way or the other. James with my TSVWG chair hat on (2) Abstract, last sentence The new elaborations on RTP seem to be inappropriate. RTP isn't a classical transport protocol. RFC 3550 says (Section 11, 2nd para): RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, ... [...] Therefore, I suggest to drop the clause on RTP entirely: FWIW, Dan Wing suggested this as one of the possible ways forward for the RTP issue. So unless anybody disagrees I will apply your prosed change. (3) Abstract and Section 1 (1st para) Recently, awareness has been raised ... The same words had been written in the first draft version in 2006. For not overstressing the word recent too much, I suggest to change that to: During the last few years, awareness has been raised ... ^ Fixed. (4) Section 2.1 There is ongoing confusion on the role of the IANA managed port number range. This is caused by the lack of distinguishing between the roles of ports -- server ports ((semi-)static port numbers used to 'listen') vs. client ports (ephemeral choice for activating a transport session with a 'listening' peer). In certain 'symmetric' protocols (peer-to- peer applications) without out-of-band agreement on port numbers, both communicating parties are to be regarded as taking the 'server' role, and for these the document is not applicable. To avoid the above confusion, I strongly suggest to clarify that the IANA registry *only* deals with *server port numbers*. First paragraph of 2.1: The Internet Assigned Numbers Authority (IANA) assigns the unique parameters and values used in protocols developed by the Internet | Engineering Task Force (IETF), including well-known ports [IANA]. [...] --- The Internet Assigned Numbers Authority (IANA) assigns the unique parameters and values used in protocols developed by the Internet | Engineering Task Force (IETF), including well-known server ports [IANA]. [...] ^^ With this clarification, it should become evident that the use of arbitrary port numbers as ephemeral port numbers on a particular node does not conflict with the IANA registry, unless the same port number is in use by a (listening) server application on the same node. Ok. Given that the port numbers issue has been debated recently, I'd like Lars to comment on this proposed change. The last paragraph of 2.1 is not backed by RFC 1122 (cf. sect. 4.2.2.1). Wrt the IANA Port number registry, Dynamic / Private Ports are simply those ports that are recommended for *server* programs that want to dynamically bind to a port they are listening on afterwards. Neither the TCP standard nor STD 3 contains verbiage to globally constrain port usage as ephemeral (client) ports. Therefore, IMO the last paragraph of 2.1 should be deleted or changed as follows: The dynamic port range defined by IANA consists of the 49152-65535 | range, and is meant for the selection of ephemeral ports. --- The dynamic port range defined by IANA consists of the 49152-65535 | range; it is meant for the dynamic selection of server ports and is | unrelated to ephemeral port selection, although this interpretation |
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: [IAOC] Request for community guidance on issue concerning a future meetingof the IETF
At 12:41 PM 9/24/2009, Dave CROCKER wrote: Ole Jacobsen wrote: Dave, By the time everthing is said about this I suspect the chilling effects will be minimized. There will probably still be people not wanting to go on principle, but I at least hope that the number will not be so great as to impact the success of the meeting. And here I was thinking it was already /increased/, not reduced. For example, I've enjoyed the meetings I've had in China -- and the anti-spam topic ran directly into potential sensitivities, of the sort discussed here, and with no problems. But this contract clause and ensuing discussion now have me fully expecting serious problems I wouldn't otherwise have thought much about... so -- here's another (compound) question to ask in this vein *IF* somehow the meeting gets shut down (for whatever reason), does that mean we IETF participants are to leave the country immediately, or can we remain in the country -- conceivably at the same hotel -- conceivably at the same hotel that shut the meeting down -- or do we have to then immediately find new accommodations? This would impact everyone of us attending, even if the incident that caused the meeting to shut down was a single individual not near where the rest of us were at that time. I know this is extreme, but Alissa's quoted paragraph (from Ole's) doesn't make that unlikely, it states that this is a probability (if the meeting were to be shut down). In other words, it seems that any offense can cause this action, even if most of us aren't involved. I don't like that uncertainty (that if I keep my nose clean, I can still be in a pickle because of some other (single?) offender). I personally don't know why the contract can't be rewritten to say something like If an individual is offending China, that individual is kicked out of the country (or goes to jail). If a group offends China, that group is kicked out of the country (or goes to jail). If the offense occurs during a plenary (the only time we are all together really), then the whole meeting is shut down, we are all going to jail or kicked out of the country. This would be more concrete for me, and something I could evaluate the risks of. James d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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: One level up on the IAOC decision in re: China.
At 03:38 PM 9/24/2009, Dave CROCKER wrote: HUANG, ZHIHUI (JERRY), ATTLABS wrote: Notwithstanding the letter (or the intent) of the quoted contract language, many people here have pointed out that all sides (IETF, Chinese government, the Hotel, and participants in China/Asia) want to have a successful IETF meeting in China - if we are having a meeting in China. IMO It's going to take a lot of agitation to get the locals riled up to upset/break up the meeting. Jerry, Alas, the letter is, in fact, standing and present. It says what it says, and it is unique in our history. It cannot be ignored. Also alas, nothwithstanding your excellent intentions, I suspect that you cannot speak for the government or the hotel, and we cannot know what behaviors will cause what damaging impact, nor can you reassure us about the limits that we must stay within. The issue is not one of strictly technical topics, but the ability of our community to navigate within those unknown limits. We /can/ know that as a community, the IETF is often socially inept and even offensive. Some of us are proud of that. Others of us are chagrined. But our behavior has been quite consistent over two decades and there is no sign if its changing. some will rightly argue nor should we have to I'm not sure I'm one of them, but I'm conscious of the impact of having done it once (looking as if IETF79 were in the past), we can/should do it again in the future... a pattern will emerge that many don't want to start d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ 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: China venue survey
At 11:23 AM 9/19/2009, Ole Jacobsen wrote: On Sat, 19 Sep 2009, Yaron Sheffer wrote: Hi Ole, The IETF is highly ideological. Probably more so than most other SDOs. We care deeply about the end to end principle, about net neutrality, and (at least in the community I'm a member of) about security. Many of our members care a lot about IPR and its effect on open source. So why when it comes to free speech, which is clearly related to our open way of making standards, we suddenly shy away from taking a moral stance and instead resort to budgetary calculations? And regarding the survey: most people, myself included, would bend a principle or two to go somewhere as interesting and exciting as China. But you would get a radically different answer if you asked: should the IETF hold a meeting in a country that mandates a non-free speech commitment, or should we prefer an alternative where no such commitments are required. Thanks, Yaron You might get a different answer, but it's ultimately up to the individuals who answer the survey. How would you expect our large and growing contingent from China to answer that question? Should we ask about the policies of the United States, France or Germany on a long range of topics (visa, wars, death penalty...)? Where do we draw the line? Actually -- the US is being openly questioned every time a meeting is held here due to Visa issues. At the plenaries - there are robust, heated and sometimes emotional debates about this. Could this same level of debate be had about free speech *during* the China IETF? If not, then I have a problem with what you're offering as an explanation. Also, from a free speech country looking out, the topic of free speech isn't political to most here. From a non-free speech country looking, I gotta believe it is a political topic. So all of this is from a certain perspective. One thing we know we are in the IETF is full of speech, so it would be taking something away from what we already enjoy (some to the point of not really wanting to control what we say because we're at the IETF where it has always been safe to talk like this). The idea that a meeting could get shut down, or a person could go to jail for doing what we have done for the previous 78 meetings in a row seems like a stretch to handwave away. Don't get me wrong, I have every respect for anyone who wants to avoid going to China for political/moral reasons, and if that collection of people is large enough to seriously impact our ability to run a successful meeting then I agree that another location would be better. [Insert philosophical comment about where most of our electronic products are produced these days, and maybe a shopping boycott would be in order too?]. I continue to believe, from personal experience, that we would have a great meeting and that none of the draconian stipulations in the contract would even come close to affecting us, but that doesn't matter if only a handful of people show up! The survey will tell us something about that, provided we get enough responses. Ole ___ 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: China venue survey
At 12:47 PM 9/22/2009, Ole Jacobsen wrote: Cullen, Well, nobody has officially announced that the proposed venue is Beijing, although a lot of people seem to have assumed so and yet more people copied the assumption. The announcent of the venue is expected soon, within say 30 days. But to the core of your question: The rotation would normally put us in Asia, err, what? the rotation is 3-2-1, and we're going to Asia this November. How does that mean we go back to Asia next November as normal? so you can think of Vancouver as a backup plan. We're not really asking you if you prefer Vancouver over X city in China (at least not in this survey). Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj On Tue, 22 Sep 2009, Cullen Jennings wrote: Given that the the current Location for IETF 79 is listed as Canada/China, the correct questions to ask is would people prefer IETF 79 be in Vancouver of Beijing. ___ 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: China venue survey
At 05:44 PM 9/22/2009, Dave Cridland wrote: On the other hand, I can accept as valid the suggestion that some people have made that the particular restrictions of speech that the PRC impose may restrict the scope of discussion that the IETF typically engages in. I suspect that it may not be so, and would hope that this can be determined, clearly, and in advance of any decision. Dave -- I'll note that most of this thread started over confusion about the provision within the agreement, and folks asking what's that mean? If more of us knew what the provision meant, we'd be more informed to make a more knowledgeable choice in the matter. Lacking that additional meaning leaves many of us flopping in the wind... However, I would note that I'm still concerned about the possible effects by and on remote participation. But you'll all have read my other comments, right? Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ 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: One Day Pass Proposal was Re: One Day Pass for newcomers
I think this doesn't address the concern about having a meeting agenda done before anyone needs to make travel adjustments. Quite simply having the agenda done the week before any meeting in the past 30 makes any flight or hotel booking adjustments laughable. This pressure to have a more robust agenda will be amplified greatly by those that count on sessions being on any one given day (say, on that provided on any version of a draft agenda) -- and will possibly explode some individuals when any session *they* wanted to go to gets moved off their day of choice. I don't see this mentioned in Ray's proposal -- though I don't have a good suggestion to solve this, as many things go into getting the agenda done early, even though its availability hasn't delivered it any earlier. James At 03:00 PM 8/24/2009, David Harrington wrote: Looks good to me. I have concerns about #6, since it is fairly common that we run light on food during the reception. And if there are limits on the reception, then I think it reaosnable to favor those who paid for the full week. But I can support the experiment. Will One Day Pass first-timers be invited to the First-Time Attendees reception as well? dbh -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ray Pelletier Sent: Monday, August 24, 2009 2:37 PM To: Doug Barton Cc: John C Klensin; 'IETF-Discussion' Subject: One Day Pass Proposal was Re: One Day Pass for newcomers All; Let me offer a suggestion for which we would like to receive quick and constructive feedback so that the opening of the IETF 76 registration will not be delayed. One Day Pass Program A person may purchase a One Day Pass to attend any one day of the IETF Meeting for $200. Benefits of the One Day Pass: 1. Attend all sessions during any one day of the Meeting, and partake of the food and beverage during the breaks that day 2. Day can be selected during online registration, but can be changed onsite without penalty 3. Payments may be made onsite without a late fee 4. Pass can be upgraded to a full Meeting Registration, however, late fee may apply if initial Pass payment not made before Early Bird deadline (Note: Intended to discourage gaming the system) 5. Attend Sunday Tutorials at no additional charge 6. Attend Sunday Welcome Reception at no additional charge 7. Attend Wednesday and Thursday Plenaries at no additional charge 8. Purchase a ticket 4 - 5 PM on Tuesday to attend the Host's Tuesday evening Social, if tickets are available Ray IAD On Aug 23, 2009, at 9:47 PM, Doug Barton wrote: John C Klensin wrote: --On Sunday, August 23, 2009 14:18 -0700 Doug Barton do...@dougbarton.us wrote: ... So, if someone doesn't get at least a day pass, I'd be happier if we charged a nominal (even if only $10 - $20) fee for registration for the tutorial than just open the doors. I disagree here. I think that opening the newcomer's session and (if the host is agreeable) the reception on Sunday to all comers would have way more benefits than costs. Of course we would have to capitalize on all those fresh bodies by having registration open and suitable promotional materials for both full and one-day registration prominently (yet tastefully) displayed. Doug, I think that the ability for active participants in the IETF to get into the reception and even eat is fairly important, probably more important than encouraging first-timers and visitors. I hope that you would agree with that, even though we would both prefer to have no restrictions in that regard. I definitely agree that if I pay for IETF I want my shot at the dried out chicken wings, yes. :) FWIW I'm not trying to minimize your concerns, which I think are valid. I simply think that reasonable minds can differ on the cost/benefit analysis. What caused my suggestion for a nominal fee and some sort of preregistration (which that fee would imply) was a vision of the IETF meeting in a location with nearby college campuses and the possibility of signs (possibly put up by third parties) advertising the reception and noting free food and, depending on the location and sponsor free beer. I leave the rest to your imagination. Well, you seem to have a darker view of human nature than I do, and that's saying something. There are ways to solve both problems I think, such as setting aside the first 30 minutes for paid participants and opening the doors wide after that. In any case I don't want to overengineer the social events. I personally think that we should use the golden rule. Whoever pays the gold for the event gets to make the rules. Regardless of where we come out on the socials I think it would be good to have some kind of consensus on opening the newcomer session and the plenaries, at minimum to those who pay for day passes (and IMO for all comers).
Re: IETF74 T-Shirt Art Donated to IETF Trust
This is a cool design, I agree. With that said, I think a discussion needs to occur on the devaluation of the importance of what the shirt means - were it to be distributed to any/many folks that did not attend an IETF. There have been several other cool designs from IETFs past, most notably is the one that the IETF refused to have a shirt for (i.e., IETF47 in Adelaide). I think that's still (for those who attended) the most popular IETF shirt. I'll give Juniper credit (dare I? ;-) that this is a very popular design. So, this is a choice between how can the IETF get money? vs. the purity that those that have an IETF shirt actually went to that particular IETF meeting. I realize this purity isn't really purity, given that I'm a rather large man, and sometimes they don't have my size, so I get a size that fits my wife or daughter. But the idea that there is one per paid attendee remains. I fear that advertising (Joe's Bar/Grill ISP) will become the next step to gain revenue goals if we go down this path, but I might be being too pessimistic... James BTW - I hate for this whole idea to devolve into this scenario -- the event sponsor will sell the design of the shirt to the IETF, who might believe they can earn more that it cost (sponsor fee plus COGS) in sales. At 02:49 AM 7/31/2009, Gregory M. Lebovitz wrote: I have been asked about this several times this week, so I'd like to clarify here for all. Juniper has donated the art for the highly popular IETF74 San Francisco T-shirt (brown, IPv6 World Tour, concert concept) to the IETF Trust. This was done because a) many people wanted to buy more of these shirts, b) the IETF expressed an interest in fulfilling those requests. We hope this art can be leveraged to spread the message about IPv6 transition broadly across the Internet community, in a fun and cool way . The ball is now in Ray (and team's) court. Hope it helps, and enjoy, the Juniper host team from IETF74 +++ IETF-related email from Gregory M. Lebovitz Juniper Networks g r e go r y d o t i e tf a t g m a i l do t c o m ___ 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: XML2RFC must die, was: Re: Two different threads - IETF Document Format
At 09:38 AM 7/5/2009, Colin Perkins wrote: On 5 Jul 2009, at 14:24, Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. I have no significant problems using xml2rfc, and find it easier to write Internet-Drafts using xml2rfc than I did using nroff, LaTeX, or Microsoft Word. I also appreciate the added consistency in Internet-Draft formatting that has resulted since xml2rfc has been widely adopted. This makes it a lot easier to print drafts, since they have consistent page sizes and form-feed characters. huh? the current boilerplate has the first page being 54 lines long, and subsequent pages being 57 lines long, but with the footer on the 56th line, and not the 57th. The footer on the first page isn't on the last line of the page either. This isn't very uniform... perhaps unless you use some special viewer to recreate this non-uniform display consistently. IDs and RFCs are displayed in text, and they should be viewable in any text program consistently. Or am I missing some magic program that is implicitly mandatory to use in all this process? -- Colin Perkins http://csperkins.org/ ___ 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: XML2RFC must die, was: Re: Two different threads - IETF Document Format
+1 At 11:01 AM 7/5/2009, Joel M. Halpern wrote: I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Otherwise, mandating would be inappropriate, as some folks do indeed find it difficult. Yours, Joel M. Halpern Iljitsch van Beijnum wrote: My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Native-SIP vs. Non-native SIP
Stella I think the answer to your question depends on your point of view. If a PSTN originated call connects with a gateway (i.e., a translator between two dissimilar communications or protocol techniques or methods) and converts that can set up into SIP - realizing that the SIP part needs to not violate any part of our RFCs, then yes, this is native SIP for the SIP leg of the call set up. Obviously this is not SIP end-to-end (e2e), which some personally define as native SIP. I am not one. I believe native SIP is anywhere there is standards compliant SIP messaging, even if the call set up is not SIP e2e. Does answer you question? James At 04:11 PM 5/8/2009, Stella Gnepp wrote: Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary=_=_NextPart_001_01C9D021.89A2F61B Dear IETF: I am following up on my April 23, 2009 email (please see below) to see if there has been any feedback on my question regarding the distinction between native and non-native SIP. Please let me know. Thank you for your assistance. Sincerely, Stella Gnepp -- From: Stella Gnepp Sent: Thursday, April 23, 2009 3:20 PM To: 'iesg-secret...@ietf.org' Subject: Native-SIP vs. Non-native SIP Dear IETF: I am looking for industry standards related to the definition of native-SIP and non-native SIP voice communication. Specifically, I am trying to determine whether a call is still considered native-SIP if a call originates as TDM, but is converted from TDM to data before leaving the customers premises. I am hoping that there is a standard definition that states the point of origination (whether it is at the point of where the call leaves the customer premises, or before thenat the equipment level) for determining whether a call is native-SIP. Any assistance is greatly appreciated. Thank you, Stella Gnepp Stella Gnepp TNCI Regulatory Affairs Manager 2 Charlesgate West Boston, MA 02215 Phone: 617.369.1163 Efax: 617.369.1187 Email: mailto:sgn...@tncii.comsgn...@tncii.com Web: http://www.tncii.com/www.tncii.com The information contained in or attached to this email is confidential and subject to the terms of any contractual agreement between you, your Company and TNCI. Please also note that the information contained in this email is provided for discussion only; it is not an offer, is not contractually binding on TNCI, and must be separately agreed-to in a written contract duly negotiated and executed by both parties in order to bind TNCI. ___ 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: Internet Society joins Liberty Alliance Management Board: Why?
Brian Taking a loose view of the OSI 7 layer stack for a moment - is there any group that's looking at more than 3 layers? Identity, as you know, can be at layer2 for link access sign on (the IEEE is addressing this area). There's identity associated to an IP address. There's identity associated with security principles within a VPN or TLS connection. Then there's all the identity related stuff happening at the applications layer. SIP has a few RFCs about this already, and more WG IDs in progress now. I'm not being a SIP bigot - but RAI is heavily influenced by what occurs in SIP, and they have RFC 4474 (SIP Identity) already. Where would a euphoric single sign-on (covering each of the above) be worked on in the IETF? Is that a WG or an Area? Hannes and I are but two working on IDs in this space - and have been for years, and because this topic is (either) so diluted or so spread out - it's hard to gain traction with many of its aspects - because of the lack of focus within any one WG or Area. With this, I don't necessarily believe that because we don't have a WG now, identity should be worked somewhere else. I believe identity should be view in both lower layer terms, as well as higher layer terms. This is certainly true within a lot of vendor's product focuses (it's at the link/network layer, or the application signaling layer). A distinct discussion is needed within the IETF on this topic IMO (which I guess is either a +1 to Hannees or a +1 to Dave's point(s)). James At 03:04 PM 3/1/2009, Brian E Carpenter wrote: Dave, On 2009-03-02 07:17, Dave CROCKER wrote: ... What is particularly interesting to me, about this line of comment, is not whether the relevant IETF-based technologies are superior or whether Can you point me to the IETF WG(s) that are considering identity management as a whole? I know there was the DIX BOF at IETF 65, but since then?? I think this is relevant to your very valid question below. I'd be mighty offended if ISOC signed up to an area of standards activity that overlapped with the IETF without a full and open discussion. But when it's an area that *is* relevant to the Internet, but that the IETF appears to have passed on, it's less clear what the discussion would achieve. More below... an ISOC alliance with an industry Alliance was the right thing to do. There can -- and probably should -- be focussed debate about such questions. But only within a larger context that I'd like to raise: Should there be more or different ISOC/IETF dialogue, when ISOC is pursuing a strategic topic that is relevant to the IETF? The IETF/ISOC relationship has changed dramatically, in recent years, primarily in terms of ISOC involvement in IETF management and funding. What I do not recall seeing is whether there should be changes in the involvement of the IETF in ISOC activities.[1] An easy example is exactly the sort of involvement being implied by the current thread: When ISOC is choosing to take a strategic action, should it seek public discussion within the IETF? Actually, it's written in the IAB charter that: The IAB acts as a source of advice and guidance to the Board of Trustees and Officers of the Internet Society concerning technical, architectural, procedural, and (where appropriate) policy matters pertaining to the Internet and its enabling technologies. If necessary the IAB may convene panels of knowledgeable people, hold hearings, and otherwise pursue the investigation of specific questions or topics presented to it by the Internet Society. So I'd say it's clear what should happen: ISOC should ask the IAB, and the IAB, in the spirit of openness, should raise discussion within the IETF. Personal opinion: I was never too happy, while I was in the IAB or IESG, that this channel was working as well as it should. But as you say: Public discussion is messy and IETF-wide consensus is virtually impossible to obtain for any interesting topic. So I'm not at all suggesting that ISOC depend upon gaining that from the IETF. Still, public discussion can surface useful information and opinion. Let me stress: I don't intend this as criticism. As things change, we gain insight. The exchange surfaced an issue that struck me as interesting and potentially useful, and worth pursuing among the ISOC and IETF communities. Agreed. Brian d/ [1] Side note: The list of ISOC Board of Trustees at: http://www.isoc.org/isoc/general/trustees/board.php does not indicate the constituency or selection mechanism that chose particular Trustees; it would be helpful to see that included in the list, to understand whether they are ex officio, elected by from a region, or the like. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list
Re: 73rd IETF - Registration
At 05:01 PM 8/21/2008, Tony Hansen wrote: IETF Secretariat wrote: Registration is now open for the 73rd IETF Meeting! Kudos on adding these two new questions to the registration form: T-Shirt Size +1 but what about cookie preference? ;-) James Dietary Restrictions? Tony Hansen [EMAIL PROTECTED] ___ 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: 73rd IETF - Registration
At 10:06 AM 8/22/2008, John C Klensin wrote: --On Friday, 22 August, 2008 02:14 -0500 James M. Polk [EMAIL PROTECTED] wrote: At 05:01 PM 8/21/2008, Tony Hansen wrote: IETF Secretariat wrote: Registration is now open for the 73rd IETF Meeting! Kudos on adding these two new questions to the registration form: T-Shirt Size +1 but what about cookie preference? No a single question. Need diameter (or parameters of other shapes), thickness profile, ingredients, nutrient values, and whether or not they are decorated with cute faces. The debate we have never had is whether people would be more or less productive after breaks if their cookies stared back at them. we do know that some get especially grumpy having not consumed any cookies at a break ekr comes to mind as an example case. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Progressing I-Ds Immediately Before Meetings
This could be WG chair approved too, i.e., WG chairs provide a list of IDs that are permitted to be submitted that are involved in the IESG process (but only ones that have gone through their first IESG meeting). Not that many per WG should be in this state during any one (normal blackout) period. Just a thought James At 05:20 PM 7/18/2008, Adrian Farrel wrote: S, How come I-Ds don't expire after publication has been requested? Could this be a field in the data base that could be accessed to allow continued submission of revisions regardless of cut-off dates? Well, if it is too hard or needs many hours of volunteer time, the answer is obvious. Adrian - Original Message - From: Russ Housley [EMAIL PROTECTED] To: Adrian Farrel [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Friday, July 18, 2008 7:19 PM Subject: Re: Progressing I-Ds Immediately Before Meetings Adrian: This has been discussed many times, and there is no easy way for the Secretariat to distinguish these document from others. With the on-line Internet-Draft Submission Tool (IDST), it might be possible to search the database for such documents and let them through. However, we're trying to get the existing functionality working first. Frankly, we'd need a volunteer to write the code for this to be done anytime soon. Russ At 11:43 AM 7/18/2008, Adrian Farrel wrote: Hi, The cut-off period before IETF meetings has (IMHO) some value to help people read an digest stable documents that will be discussed face-to-face. However, some I-Ds are beyond WG last call and are going through other review cycles. Why should updates to these be barred? For example, I have an I-D that has just completed IESG review. The updates are relatively simple and I would like to submit them and get the IESG to clear their Discusses. Apparently I cannot do this until July 27th. can anyone see a reason why this should be the case? 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: Proposed Experiment: More Meeting Time on Friday for IETF 73
At 04:33 PM 7/17/2008, IETF Chair wrote: The IESG is considering an experiment for IETF 73 in Minneapolis, 0900-1130 Morning Session I 1130-1300 Break 1300-1400 Afternoon Session I 1415-1515 Afternoon Session II I support this schedule ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
At 10:28 AM 2/1/2008, Jari Arkko wrote: Dean, We should know by now that isolated resorts ARE NOT ACCEPTABLE as meeting locations. Er... like Dallas or San Diego? Jari Dallas was supposed to be New Orleans until a little catastrophe called Katrina happened there and a secondary city needed to be found with little notice -- so don't bang on that city too hard. I agree with you on (the Harbor Marriott in) San Diego - which we've been to twice I've never been to Dublin and I don't know what exists on site. Maybe some locals could tell us? Also, as has happened in a number of IETFs so far (like in Dallas), Ray is scheduling a bus service for us. More generally, before we criticize meeting site selections, lets at least first figure out what the true conditions really are. I look forward to going to Dublin. Jari ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF Eurasia
At 10:34 AM 11/30/2007, Lars Eggert wrote: I'm not sure if there have been joint interims with multiple WGs attending, but that could make sense if there's a difficult piece of work that they need to agree on Geopriv and Ecrit had a joint meeting a couple of years ago that was mostly attended by folks that do SIP and SIPPING too. It was a productive meeting. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SAFE BoF in Vancouver
At 05:54 PM 11/20/2007, Ted Hardie wrote: At 11:38 PM + 11/20/07, Colin Perkins wrote: On 20 Nov 2007, at 19:07, Ted Hardie wrote: At 1:59 PM + 11/16/07, Colin Perkins wrote: The following BoF has been proposed for the Vancouver IETF. There is a mailing list [EMAIL PROTECTED] for discussion. This seems to be scheduled against both the Applications area open meeting and a RAI group focused on media servers. Both groups would have an interest in following this work and discussing where future IETF work in this area will happen. Is there still a possibility of adjusting this timing? I understand, of course, that not every conflict can be resolved, but it would be useful to know whether this is still something that might be addressed. We're aware of the conflicts, but this is the least bad scheduling we've been able to find. If you have suggestions for a better slot, we're open to ideas. Friday morning? There are no APPs or TSV groups meeting then, and the RAI group is GeoPRIV, which wouldn't have as high an overlap as most other RAI groups. But Ted, you're going to Geopriv? So how does this work? Again, I know we can resolve every conflict, and I appreciate your considering changes. regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:24 AM 10/30/2007, Simon Josefsson wrote: I admit now s/now/not all PSs have IPR attached, but this is almost certainly intended to kill any IPR from achieving DS. Is that what is intended here? I don't believe that was the intention, but that's a question for Brian. I disagree that all PSs are patented (if that is what you meant). see above - I misspelled a word that means something else. sorry I've implemented several such standards without worrying about patents. I believe the majority of PSs are actually published without known patents. A search in the IETF IPR tracker should answer that. /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:24 AM 10/30/2007, Simon Josefsson wrote: At 04:48 PM 10/29/2007, Simon Josefsson wrote: Eric Burger [EMAIL PROTECTED] writes: One interesting side effect of the existence of an open source implementation of a protocol is monoculture. We ran into a problem in ifax year ago when it turned out that all eight independent implementations all relied on the same library, thus rendering the independent implementations label difficult, to say the least. Why were there no independent implementations? Because in this case, the open source implementation was pretty good, and it was not worth investing in a proprietary implementation. The result here has a really bad side effect for the IETF: if there is a good open source, free implementation, there will be no second implementation, resulting in it being impossible for the standard to progress. But that is how it is supposed to work! If there is only one implementation, a standard is not mature enough to move to DS. You need to have at least two, preferably several more, completely independent implementations in order to quality-test a standard. but why does one or both have to be open source? Why can't both be commercial? DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. Another (existing) requirement is that any patent licenses needs to be obtained through separate processes. I believe that a good way to demonstrate that the patent license process works is to require that a free software implementation exists. I strongly believe it should be possible to participate on the Internet without paying a software patent tax to some organizations. I believe you are arguing that the ends justify the means. In other words, because all the licensing has to be worked out (to become a DS), you believe a free implementation is the answer. I say it is not. Two commercial organizations can work out licensing and comply with this requirement - but you don't want that to be acceptable. I hold that this is what I'm referring to as bad for the IETF because corporations will either start involving themselves less in the IETF (directly affecting the IETF's revenue - which is already too low, and probably adversely affecting corporate sponsorship of meetings - which is already hard to acquire), and/or have fewer corporate participants care about DS and FS RFCs, because there is no incentive for them to do the work. BTW - if you believe a free (cost-wise) implementation be mandatory for elevation to DS, why don't you suggest the text be changed to say that? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 2026, draft, full, etc.
At 05:18 AM 10/30/2007, Eliot Lear wrote: [I'm changing the subject and cutting off the references list as we seem to have changed topic.] Simon, DS designates a mature standard. If you read the requirements in RFC 2026 for a mature standard it is clear that few of the modern IETF protocols live up to that standard -- you need to demonstrate interoperability between two completely independent implementations of _all_ features in the protocol standard. I think we can all agree that the calendaring standard is mature. We are in the process of doing what I would consider to be a relatively minor update to it, and yet it is only PS. IMAPv4 is only PS and yet has MASSIVE deployment. LDAP is only PS and is MASSIVELY deployed. DHCP is the best (worse?) example of this, IMO. It's been DS (meaning at least 2 independent implementations) for how many years now (5, 6 or 8+ years)? It's (as you say) MASSIVELY deployed. Yet it isn't a Full STD. That one had always caused me to pause about how serious IETFers are really about 2026 processes... SIP is all over the place and it is only PS as well. And so it's pretty clear that nobody cares about DS or IS. Actually some do care *AND* the IETF gets dinged on this one by those that aren't IETFers as not mature. These are the same (psst: idoits) that confuse Internet Draft with Draft Standard, somehow thinking each status is the same (...somehow). What's more, why should they? What benefit does it bring to anyone to advance a standard to DS? AND it's a whole lot of work. So why are we even having an argument about what gets stuck into requirements for DS? Shouldn't we instead be eliminating it entirely? Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Oppose draft-carpenter-ipr-patent-frswds-00
http://www.ietf.org/internet-drafts/draft-carpenter-ipr-patent-frswds-00.txt offers this text as a modification to RFC 2026: A specification from which at least two independent and interoperable implementations from different code bases have been developed, of which at least one is available as free software, and for which sufficient successful operational experience has been obtained, may be elevated to the Draft Standard level. I oppose this text in any IETF document because it is counter to vendor implementations (*any* vendor implementations) to achieve Draft Standard status of a document, and that's bad for the IETF. For example, take two vendors: Vendor-A and Vendor-B. One of the vendor's has legitimate IPR claims on a PS RFC, the other either has a license on that IPR from the inventing vendor, or has implemented it under the IPR claim's royalty-free IPR statement (just as some IPR has in its claim into the IETF). Some PS RFCs are either very little used or very complicated, meaning they aren't very popular (to the Open Source community) or cost to much (time/money) to develop. So unless someone decides to do the work anyway (which doesn't make sense to require) - the suggested text above prevents both Vendor-A's and Vendor-B's implementations from being considered for elevation of this PS RFC to DS RFC *because* they (for some crazy reason) want to charge money for the products where this implementation can be utilized. BTW - isn't charging money for products how vendor's stay in business? The IETF preventing vendors from making money in order for the IETF to consider progressing a PS RFC to DS RFC is completely counterintuitive and will reduce vendor participation in the IETF. As much as some might applaud that result, it will mean either the demise of the IETF (without sponsors and vendor participants attending meetings to pay the bills), or that everything is just fine as a PS - which makes the suggested text above completely useless. James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Oppose draft-carpenter-ipr-patent-frswds-00
At 04:48 PM 10/29/2007, Simon Josefsson wrote: Eric Burger [EMAIL PROTECTED] writes: One interesting side effect of the existence of an open source implementation of a protocol is monoculture. We ran into a problem in ifax year ago when it turned out that all eight independent implementations all relied on the same library, thus rendering the independent implementations label difficult, to say the least. Why were there no independent implementations? Because in this case, the open source implementation was pretty good, and it was not worth investing in a proprietary implementation. The result here has a really bad side effect for the IETF: if there is a good open source, free implementation, there will be no second implementation, resulting in it being impossible for the standard to progress. But that is how it is supposed to work! If there is only one implementation, a standard is not mature enough to move to DS. You need to have at least two, preferably several more, completely independent implementations in order to quality-test a standard. but why does one or both have to be open source? Why can't both be commercial? So few PSs become DSs, I believe this will almost certainly make progression from PS to DS slower. Is that what we want? I admit now all PSs have IPR attached, but this is almost certainly intended to kill any IPR from achieving DS. Is that what is intended here? /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Travel Considerations
Unfortunately, using this logic -- I can buy a tank and get 2 gallons-to-the-mile mileage because the rest of the planet (or at least America) is still buying SUVs that get horrible mileage too, since there will be nearly an unmeasurable difference to global warming if I drive my tank or not... so why not drive it anyway. There is an individual responsibility to change what we each can change to help. As an organization, we can have a greater positive affect if we reduce demand for such spoke flights by only flying to hub sites of major airlines -- if we're going to continue to meet in person. If other organizations see ours as an example, and do the same, then the positive affect is greater on us doing the right thing... Doing the right thing in mass has to start somewhere -- why does it have to start somewhere else here? It's Friday... At 01:30 PM 10/12/2007, Dan Harkins wrote: You're assuming that if 1000 people decide not to fly to Prague some weekend that the number of planes burning jet fuel to fly there will be different. I don't think so. Maybe you can start a Boycott Prague The Spoke City campaign which, if wildly successful, will reduce demand to fly there by some discernable amount and thereby reduce the number of planes flying there and the amount of jet fuel they would've burned. Well, as long as the planes that aren't flying to Prague aren't used to fly to Heathrow or Frankfurt or some other hub city. Also doubtful. I do not intend on making ietf-discuss into a forum for discussing the pluses and minuses resulting from a degree centigrade temperature change but let me just say that the planet wins is a somewhat dubious statement. Dan. On Fri, October 12, 2007 7:32 am, Eric Burger wrote: Here is an interesting optimization problem: it turns out the most polluting part of a conference is people taking jets to fly to the conference. Minimize that and the planet wins. Favors hub cities over spokes, like San Diego or Prague, where you can't get there from here, no matter where here is. See http://www.sciencemag.org/cgi/reprint/318/5847/36.pdf Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
At 04:20 PM 4/19/2007, Dawson, Martin wrote: DHCP is not adequate because it doesn't meet multiple sets of requirements as documented multiple times ... bologna documented multiple times means in individual submissions of which, zero facts were presented to substantiate If DHCP were so inadequate, why is the DSL forum now going to specify it? Why does PacketCable define it? These were fairly recent moves... And, how many times has HELD been presented as if it were a product of an IETF WG? James ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68
At 04:31 PM 4/19/2007, Dawson, Martin wrote: And there it is. You're going to have to justify the accusation, John. Barbara S has already said she thinks she'll be constrained to deploying a system such as this - so it's certainly not a hidden agenda on her behalf. Other than that, it constitutes about 1% of the reasons for needing a location protocol that works above IP. The conspiracy theory is quite simply wrong. energy and misrepresentation doesn't make things right either Cheers, Martin -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Friday, 20 April 2007 7:13 AM To: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68 It is worth recalling that a subset of the AD's and GeoPriv Chairs have pursued surprise changes to the advertised agenda before. The agenda of the GeoPriv WG meeting at IETF 57 was distinctly different from the one advertised, with the inclusion of a presentation by Jon Peterson on draft-ietf-geopriv-dhcp-lci-option at the beginning. During Agenda Bash, I objected to the insertion of this presentation without the knowledge of the authors, and was told that the author not present had been told. Jon's presentation was a well-organized ambush with slides in which he raised a wide variety of concerns about the draft that he had not (for that matter never did) post to the WG mailing list. On the day after the draft minutes of the meeting were posted on September 23, 2003, I posted clarification on the mailing list of the whitewash of the objection to the inclusion of that ambush presentation. With modifications, that draft became RFC 3825, and represents the then-consensus position that hosts should obtain and control information about their geographic locations. The alternative that may have been the hidden agenda at IETF 68 instead advocates that control of a host's geographic location reside with the network operator, and delivered through location servers. The only requirement for these location servers appears to be the business interests of their operators, following the model of existing cellular telephone networks. Advocates for this server-centric model have pushed a protocol called HELD, which may have been represented as an IETF product (based on individual-submission drafts) to operator groups. Some of the same advocates have also undertaken attacks on RFC 3825 with arcane arguments about claimed differences between uncertainty and the resolution of a (latitude, longitude) location. After one of the chairs requested a draft to clarify the meaning of resolution in RFC 3825, and the comments from IETF 67 were incorporated into a WG-approved draft, the chairs have arbitrarily labeled this draft: draft-ietf-geopriv-binary-lci-00 as Awaiting revision by author team. There is reason to suspect that the maneuvers in Prague are part of an agenda to move control over a host's location from the host to the network operator in order to create a business of providing it. There is a pattern with implications on the outcome of the WG, not just procedural lapse. John On Apr 18, 2007, at 8:59 PM, Ted Hardie wrote: Howdy, I'd like to make some comments on the issues discussed below. Before diving into the details, I'd like to make two meta-comments. First, I believe that the chairs' messages noted that they had received private messages of concern, and that their e-mail was expressed as a response to those messages. As chairs, it is their responsibility to take the community's concerns seriously and to respond to them. My reading of their response is that they believe that the IETF 68 meeting of GEOPRIV was sufficiently unusual that it requires us to be very careful to follow our standard procedures in following up the meeting, so that the overall process is obviously fair and is as transparent as possible. This serves the interests of those who were at the GEOPRIV meeting at IETF 68, as well as those who participate but could not physically attend the meeting. Reading Cullen's response, it looks like he saw this as the chairs' impression and reaction as individuals; maybe that is part of it, but I believe is important to see this in terms of the view of the participant community (of which the Chairs certainly form part). I also believe that their suggested response is basically do business as usual, and make sure that's obvious, which I believe is non-controversial as a way forward. Secondly, I believe that this response has picked up some style elements of the original chairs' message and exaggerated them, falling into quasi-legal language that hurts us as a group of folks trying to get this done. As I read the original message, the core is that there were three unusual aspects of the GEOPRIV meeting at IETF 68: the schedule changed, which had some unfortunate consequences; the meeting agenda changed more than usual; and
Re: Improving Security with Encryption
At 09:58 AM 11/10/2006 -0500, King, Kimberly S. wrote: Fred Baker wrote: What I would suggest is that people encrypt confidential information on their laptops, and perhaps the entire laptop. I strongly agree and my entire laptop is encrypted. Perhaps people could consider suggesting to their management that data protection is critical and disk encryption is a simple effective step. Is *everything* on your laptop work related, or do you (speaking generally) sneek a few personal files on the laptop. If the latter, what are you plans on transferring that info to/from other personal devices, such as a hime computer, a PDA, or another device? If this policy you suggest is taken only a little bit too zealously, your company will mandate encrypting your work files, create and perhaps enforce a policy that only work related files are on your work owned laptop, and prevent things like synchronizing your calendar on your laptop and PDA, or other useful and harmless activities... I don't like this slippery slope (of my org making this choice) Sometimes managers aren't aware of the tools (or risks) available and maybe it is up to the technical community to inform them and help protect sensitive information (e.g., individuals data, company and client confidential data, etc.). Kimberly -Original Message- From: [EMAIL PROTECTED] To: Fred Baker; [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: 11/10/2006 12:34 AM Subject: RE: Risk of Laptop Seizure by Customs or Border Patrol Officers ... JORDI PALET MARTINEZ wrote: http://www.acte.org/resources/press_release.php?id=91 Ah, our brilliant government in its infinite wisdom Fred Baker wrote: What I would suggest is that people encrypt confidential information on their laptops, and perhaps the entire laptop. I would not recommend encrypting the entire laptop. As George Carlin would say (*), border service agents with a double-digit IQ and a triple-digit income might think that if dude encrypts the entire laptop, dude must really have top-secret stuff on it, while the only two confidential files dude has on his laptop are the payroll spreadsheet showing how much more dude makes compared to his office buddies and dude's mistresses phone numbers (one in each city, needs a database to keep track of). No need to trigger un-necessary scrutiny: Traveling Terrorist's 101: do not look, dress or act like one. Besides, there are several ways to carry confidential info while flying. Here's an example: They'll look at your laptop, but will not bother looking at the 4GB SD card you have in your digital camera, which happens to be a perfectly good plug-and-pray disk for any computer, PC or Mac. I have stored Excel and PowerPoint files both in and out of the directories used for pictures and it never bothered any camera I had in my hands. And even if they do look at it, there are ways to embed your confidential data within pictures. You need to use a lossless compression format such as TIFF. If done correctly, on a digital camera with a noisy CCD at high ISO settings, there is no way to find out that the least-significant bit of the picture contains actual data. A 5-megapixel 24-bit picture is 15MB, out of which 1.8MB are useable in theory and 300KB in practice. In short: configure the camera to TIFF, noise reduction to off, ISO 400 or higher. Heck, you don't even need a laptop. Just a digital camera. Michel. (*) Info: recorded _before_ 9-11-01 (*) Warning: absolutely politically incorrect and rude language. (*) If you have a problem with the F word, do NOT click the link below. (*) http://www.youtube.com/watch?v=BZwMz2bsbNY ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why are we still seeing new Internet-Draft announcements this week?
At 11:18 PM 11/8/2006 -0800, Ross Finlayson wrote: I'm curious: Why are we still seeing new Internet-Draft annnouncements (posted on the i-d-announce@ietf.org mailing list) this week? I thought that there were supposed to be no new Internet-Draft announcements from 1 week prior to each IETF meeting, until after the end of the meeting? this policy/behavior changed several meetings ago, in which IDs that missed the cut-off would be posted on or about the Monday of the coming IETF meeting. Ross. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (iepr ep)
At 04:29 PM 11/5/2006 -0800, Lars Eggert wrote: On Nov 5, 2006, at 16:06, King, Kimberly S. wrote: On Nov 5, 2006, at 13:27, Sam Hartman wrote: And I believe that the tsvwg is the right place to discuss where RSVP intersects with security. The point is that this work belongs here at the IETF, not which working group addresses a particular aspect. Note that I wrote: TSVWG is the WG currently chartered for RSVP maintenance, which I would see this falling under. I made no statement of where RSVP work should happen in the future, but having this work elsewhere would obviously require consensus at various levels. didn't the IESG, about 18 months ago (it may be longer) write a letter to either ITU-T or ETSI to stop attempting to extend RSVP, that it was supposed to be done in the IETF? I seem to remember that event occuring, though I admit I don't remember the details; Allison Mankin would know, as should Jon Peterson. Lars -- Lars Eggert NEC Network Laboratories ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
At 12:41 PM 11/2/2006 +0200, Pekka Savola wrote: On Wed, 1 Nov 2006, Sam Hartman wrote: I don't believe the new charter of ieprep working group belongs in the IETF. I understand why we chartered it here, and I believe that by doing as much work as we have done so far in the IETF, we have done something useful. We've described the broad problem and have helped to explain how it fits in the Internet context. That was an important thing for us to do. I think I'll agree with Sam. I do not agree with Sam Having looked at the output of the WG, it already seems to include a couple of useful framework documents and about 4 requirements documents. the framework RFCs are for within a single public domain. The other RFCs are requirements based. There is no architecture guidelines docs or peering guidelines or the like. This is because the charter of the past didn't allow such work. This new charter was supposed to allow such work AND investigate if protocol mods were needed to accomplish those arch and peering guideline efforts. This should already provide sufficient information how to continue the work. continue the work where? by who? by another SDO? Why? What isn't clear to me is what's the deployment level of these frameworks and various mechanisms. there are no various mechanisms defined, there are only framework and requirements. Little can be accomplished with just that IMO. We seem to have spent at least ~4 years on this. with both hands tied behind our backs, typing with with toes (so to speak). Overprovisioning and intra-domain TE seems to have been a popular approach, in which IEPREP doc was Overprovisioning and intra-domain TE discussed? but apart from that, where has this been deployed and how? Maybe we should let ITU, vendors, and/or deploying organizations to apply the existing techniques What techniques have been defined? I believe folks are assuming IEPREP has accomplished more than it was allowed to accomplish to date, and they ought to walk before they are allowed to run. A framework doesn't allow IEPREP to even walk. IEPREP was so constrained RFC 4542 had to be driven through another WG (TSVWG) because it wasn't allowed in IEPREP. Strike that, it would be allowed, but it would still be an individual ID because the charter wouldn't allow it to be a WG item even today. SPeaking of RFC4542, it was a INFO instead of a BCP because of the IESG, which didn't want an explanation of more than a dozen EXISTING mechanisms and techniques to be considered a BCP (isn't that by definition a BCP explaining how to put together a series of standards track RFCs?). and frameworks, let this rest for 5 years and then come back to look if there is something more to be said on the subject. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Softwires Interim Meeting
Mark I'm not an interested party here, and I don't mean to throw a monkey wrench into your plans, but I'm observing that this seems to be within the 30 days of moratorium of when we cannot have an interim, where (loosely) 'interims shall not be within 30 days of the next IETF meeting'. The Dallas IETF starts on March 19th, so I would think the cutoff would be Feb 19th for the last of an interim. What am I missing? At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote: The meeting will be Feb 23-24 in Hong Kong. Participants should plan to arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb 24. Accomodation information coming shortly (watch the [EMAIL PROTECTED] mailing list). Thank you, - Mark ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Softwires Interim Meeting
At 04:52 PM 1/24/2006 -0500, Marshall Eubanks wrote: March 19 - 30 days = Feb 17th. oops On Jan 24, 2006, at 4:19 PM, James M. Polk wrote: Mark I'm not an interested party here, and I don't mean to throw a monkey wrench into your plans, but I'm observing that this seems to be within the 30 days of moratorium of when we cannot have an interim, where (loosely) 'interims shall not be within 30 days of the next IETF meeting'. The Dallas IETF starts on March 19th, so I would think the cutoff would be Feb 19th for the last of an interim. What am I missing? At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote: The meeting will be Feb 23-24 in Hong Kong. Participants should plan to arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb 24. Accomodation information coming shortly (watch the [EMAIL PROTECTED] mailing list). Thank you, - Mark ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Softwires Interim Meeting
Jordi Please don't misunderstand me, I have no pension for making trouble here, I was just observing something that seemed a little out of place is all. I have no interest in forcing any changes to your plans. At 06:08 PM 1/24/2006 -0400, JORDI PALET MARTINEZ wrote: Hi James, This was already discussed in the WG, and I guess the AD has taken measures to avoid this being a real problem. Right now it will be a real problem canceling the meeting, as some people has already got non-refundable and very expensive flights after so many weeks of lack of adequate planning. I've insisted in Vancouver, when the plan for this meeting was drafted, to fix it at that time, unfortunately was repeatedly ignored, with the consequence of the meeting being first fixed at the end of January in San Jose with a non-clear consensus from the participants, and now in dates which are also unfortunate for some of us, but as said is too late now to start changing it again. In order to avoid this happening again, I'm working in some more clear suggestions for rules on how to adequately plan Interim meetings. I will circulate them ASAP. Regards, Jordi De: James M. Polk [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 24 Jan 2006 15:19:27 -0600 Para: Mark Townsley [EMAIL PROTECTED], ietf@ietf.org ietf@ietf.org Asunto: Re: Softwires Interim Meeting Mark I'm not an interested party here, and I don't mean to throw a monkey wrench into your plans, but I'm observing that this seems to be within the 30 days of moratorium of when we cannot have an interim, where (loosely) 'interims shall not be within 30 days of the next IETF meeting'. The Dallas IETF starts on March 19th, so I would think the cutoff would be Feb 19th for the last of an interim. What am I missing? At 03:38 PM 1/24/2006 -0500, Mark Townsley wrote: The meeting will be Feb 23-24 in Hong Kong. Participants should plan to arrive Feb 22 for an early start on Feb 23. We will finish by 2pm on Feb 24. Accomodation information coming shortly (watch the [EMAIL PROTECTED] mailing list). Thank you, - Mark ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Faux Pas -- web publication in proprietary formats at ietf.org
Mohsen Next time, don't mince your words. Be bold and say what you mean. Take a stand and voice an opinion, why don't you sheesh! At 07:16 PM 11/3/2005 -0800, [EMAIL PROTECTED] wrote: As of Wed Nov 2 22:47:14 PST 2005 the Restaurant Guide in http://www.ietf.org/meetings/IETF-64.html points to http://www.ietf.org/meetings/Restaurant_Guide_Map.ppt This information is provided in Microsoft PowerPoint, a vendor-specific proprietary format. This is the only format in which this information is available on the IETF website. It is wildly inappropriate for IETF to be using a proprietary format on its web page. For years we have been fighting this. Attached below is the form letter that I send back each time I receive a Microsoft Word document. The same concept applies to Microsoft's PowerPoint. This is particularly bad for an entity that claims to be a standards organization. Fix it quick. ---Subject: I Prefer Not to Receive Informaton in Proprietary Formats This is an automatic message: You sent the document in Microsoft Word format, a secret proprietary format, so it is hard for me to read. If you send me plain text, HTML, or PDF, then I will read it. Please recognize that this note is not about what you may have wished to communicate in that document. You have made the implicit assumption that I would be able to easily read the document in that format. That assumption is a mistake. Distributing documents in Word format is bad for you and for others. Receiving Word attachments is bad for you because they can carry viruses (see http://www.viruslist.com/eng/viruslist.html?id=7). Sending Word attachments is bad for you, because a Word document normally includes hidden information about the author, enabling those in the know to pry into the author's activities (maybe yours). Text that you think you deleted may still be embarrassingly present. See http://news.bbc.co.uk/2/hi/technology/3154479.stm for more info. But above all, sending people Word documents puts pressure on them to use Microsoft software and helps to deny them any other choice. In effect, you become a buttress of the Microsoft monopoly. This pressure is a major obstacle to the broader adoption of free software. Would you please reconsider the use of Word format for communication with other people? To convert the file to HTML using Word is simple. Open the document, click on File, then Save As, and in the Save As Type strip box at the bottom of the box, choose HTML Document or Web Page. Then choose Save. You can then attach the new HTML document instead of your Word document. Note that Word changes in inconsistent ways--if you see slightly different menu item names, please try them. To convert to plain text is almost the same--instead of HTML Document, choose Text Only or Text Document as the Save As Type. Your computer may also have a program to convert to pdf format. Select File = Print. Scroll through available printers and select the pdf converter. Click on the Print button and enter a name for the pdf file when requested. Regards, ...Mohsen http://www.neda.com PS: For further reasons why .doc should not be the format of choice when exchanging information electronically, I invite you to read http://www.gnu.org/philosophy/no-word-attachments.html It may be long, but it certainly exposes the compromises both you, as the sender, and I, as the receiver, are making by exchanging Microsoft Word documents. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF Meeting Venue Selection Criteria
At 05:35 PM 10/13/2005 -0700, Hallam-Baker, Phillip wrote: How about adding that the mean outdoor temperature at the time of the year the meeting is being held should be above 0 degrees Centigrade? and below 35 or 40? ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JORDI PALET MARTINEZ Sent: Thursday, October 13, 2005 6:30 PM To: ietf@ietf.org Subject: IETF Meeting Venue Selection Criteria Hi all, I've not seen the announcement yet, but it has been published: http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-v enue-selection -criteria-00.txt I hope we have a lot of comments and constructive inputs ! Remember, this document defines WHERE our next meeting will happen and under what conditions those venues are selected, so is important for all of us, right ? Regards, Jordi The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area
I agree with Melinda here regarding scaling is an issue *on* the ADs in those areas and that certain WGs in the Transport area are simply not transport related. I believe those WGs need to be moved out to another area of common focus. We have a critical mass of those WGs in the Apps and Transport area to do this rearrangement now (whether or not that's called major surgery) - we should take advantage of this mass to make *each* of the three areas more efficient and synergized. At 07:31 AM 9/21/2005 -0400, Melinda Shore wrote: On 9/21/05 1:25 AM, David Kessens [EMAIL PROTECTED] wrote: I would have a lot less trouble with the proposal of adding an area if we would be able to find another one that could be abolished, or reorganize ourselves in some way or form that would result in no net addition of Area Directors. I suspect that this ties to the general technical problem of it often being unclear what someone means by scaling. Something that scales well in one direction may scale very badly in another, and this is probably one of those cases. Rather than focusing exclusively on the problems introduced by growing the IESG we also need to discuss the problems introduced by not growing the IESG, which as someone pointed out include having a large number of working groups per AD. That's a scaling problem, too. I think it generally works well to have the two ADs in a given area have differing broad interests, but I think there's got to be a limit on how large the gap is between their areas of specialization (there does need to be some overlap) and the gap between network transport issues and multimedia application signaling issues really is enormous. There's a structural problem here. A lot of what's going on in the Transport Area today simply isn't transport. Of course RTP is a transport protocol, but SIP and RTSP and so on simply are not, and I think the work required to move those along is too demanding to consider them ancillary to transport (as emergency services would be to the new proposed area). If the same people are to remain responsible for the technical and administrative shepherding of both TCP and telephony signaling, then perhaps it should be the case that we get rid of the area concept entirely, have a fixed size IESG, and have the IESG members be responsible for working groups based on personal interest or obligation or the roll of a 13-sided die. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI)Area
At 04:35 PM 9/19/2005 -0400, Melinda Shore wrote: On 9/19/05 4:23 PM, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote: I think all areas in the IETF are more-or-less defined as core of the area + what is closely linked to the core + what fits less badly there than elsewhere - ECRIT would come under closely linked, since its subject area is use of the SIP-type services; GEOPRIV might be more characteristic of fits less badly here than elsewhere - it is used by many of the services like ECRIT, but is also used (or should be) by WGs in other areas. I think there may be a problem here in that real time may suggest to a number of people a level of rigor in timing that's really not applicable to much of the work the new area is intended to cover. I'm enthusiastic about the area; I am also enthusiastic about the area not so crazy about its name. I am also concerned about the name. This is basically (not absolutely!) about what is in and around SIP, and not everything in SIP is in real-time, with GEOPRIV being one of them. Yet, I believe GEOPRIV should be in this new area as there are many of the same faces in the ECRIT, GEOPRIV and SIP/SIPPING/SIMPLE WGs. This tells me there is a commonality between them such that they ought to be in the same area. Perhaps something like Rich Media Apps Area, shortened to the Media Area in discussions. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 63 On-line Survey
At 06:25 AM 8/18/2005 -0400, Jeffrey Altman wrote: In my working group I would say that a bigger factor related to the improved ability to hold a technical discussion were the four floating microphones. floating mics are a bad idea for many reasons - each getting worse with room and or audience size increasing. Who is in charge of who's next to speak? Who passes the mics to the folks in the middle of a row who didn't bother to get up? Turning of heads happens now to know places (mics in the aisles), but because seated persons are not standing, they cannot be easily seen, causing some confusion and general discomfort in the audience to find the person, then find their face to know who's saying what - which is important sometimes. Few people talk during sessions, and those that do, know to sit where they can readily get to a mic to make a point. I see nothing wrong with keeping this layout Participants are more than capable of turning their heads but when holding a technical discussion those extra mics make a significant difference. Jeffrey Altman ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: IETF 63 On-line Survey
At 11:56 AM 8/18/2005 -0400, Nelson, David wrote: James M. Polk writes... Few people talk during sessions, and those that do, know to sit where they can readily get to a mic to make a point. Yes, but sometimes there's a choice to be made between sitting where there is easy access to a mic and sitting where there are open power strip outlets. :-) that goes at another problem though - that should be addressed anyway ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: 63rd IETF Facilities Update
room 342 had dozens of power strips (all active), but the Havane room has about 10, and all are dead (no power) At 03:19 AM 8/1/2005 -0500, Adam Roach wrote: IETF Secretariat wrote: Power will be provided in the breakout meeting rooms, but will NOT be provided in the Plenary room on Wednesday and Thursday evening. Does this mean they will be running power to the rooms sometime today? Some appear to have none at all; others have on the order of a dozen outlets that are presumably to be shared by 100 to 200 people. /a ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-klensin-nomcom-term-00.txt
At 06:56 PM 7/27/2005 -0400, John C Klensin wrote: Phillip and Joel, --On Wednesday, 27 July, 2005 13:32 -0700 Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: I'd like to see some other options considered. How about a NONCOM review situation roughly such as this: if there is more than one candidate that can do the AD position for a particular area, if an active AD is one on the short list, and if that AD has alraedy severed 2 terms, the existing AD is not the one chosen for the new term. This will cause turnover only when there is an acceptable replacement as determined by the NONCOM, and not leave a situation in which there isn't any viable choice. As indicated in my longer note, my goal was to promote turnover and more circulation of ADs back into technical work, leadership, and mentoring at the WG level. I think the above suggestion does this without leaving the IESG with a less than desirable candidate. cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-klensin-nomcom-term-00.txt
John Why is this a no-op for the reasons you state? You're rationale is good, yet past experience shows the following to be true: that if a candidate is a sitting AD who wants the position again, why would they have ever be replaced? The opposite of this has happened within the last few years (do I need to give the example?). If it can happen without this type of language/guidance (from a document such as yours), then it should be more likely to happen with the language in a document such as yours. *Acceptable* turnover is the goal here, right? What I'm proposing is the opposite of the unwritten rule in boxing, where you have to beat the champ to take the title belt away because the benefit of doubt will always go towards the champ. We seem to have a similar situation here, if a sitting AD wants to stay in the position, unless that individual rally screw up (there is an example of this, too, recently), they keep the position. This should not continue, which is why I am please with your effort. At 11:19 PM 7/27/2005 -0400, John C Klensin wrote: James, Now I'm going to need to be a little cynical... --On Wednesday, 27 July, 2005 18:44 -0500 James M. Polk [EMAIL PROTECTED] wrote: How about a NONCOM review situation roughly such as this: if there is more than one candidate that can do the AD position for a particular area, if an active AD is one on the short list, and if that AD has alraedy severed 2 terms, the existing AD is not the one chosen for the new term. This will cause turnover only when there is an acceptable replacement as determined by the NONCOM, and not leave a situation in which there isn't any viable choice. This is actually a no-op. Please remember that there are not, and probably cannot be, any really objective and sufficient criteria for can do the AD job or for who is or is not a desirable candidate. Consequently, an incumbent will _always_ be more qualified than a potential replacement, if only because the incumbent already knows the job and the replacement will need to read in. In addition, an incumbent is always more or less a known quality, while the behavior someone new on the IESG is always uncertain. So that would leave us essentially where we are today. Worse, making a determination that there are additional qualified candidates blows away the notion of evaluating incumbent ADs separately from potential new candidates so that the latter are never running against an incumbent, which is a key element of the approach described in the draft. best, john cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-klensin-nomcom-term-00.txt
Spencer Let me add my agreement to this ID as a good idea with balance. At 05:18 PM 7/26/2005 -0500, Spencer Dawkins wrote: This draft (available at http://www.ietf.org/internet-drafts/draft-klensin-nomcom-term-00.txt) does a reasonable job of balancing between current-generation leadership continuity and next-generation leadership development. I would like to see this ID become one form of guidance for the next NOMCOM (as Spencer offers below), acknowledging this effort has not reached community consensus to date. If I read RFC 3777 correctly, we will be assembling the next NOMCOM very soon (at least two months before the Third IETF). So, I'm wondering... If there is community consensus that this draft proposes something reasonable, would we give the draft to the incoming NOMCOM as part of their instructions and perform a BCP 93 process experiment? Spencer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Locations
Clint I hope you get an answer to this! At 07:41 PM 7/14/2005 -0700, Clint Chaplin wrote: How far in advance are the locations of IETF meetings determined? Is there any way to find out what the possible candidates are? I'm having to budget travel for the next year, and knowing where IETF 65 will be held would help me a lot. -- Clint (JOATMON) Chaplin Wireless Security Technologist Wireless Standards Manager ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Uneccesary slowness.
At 08:22 PM 5/14/2005 -0400, Will McAfee wrote: I think the minimum time before a document can pass to another standards-track state is ridiculously long. If an rfc is huge, I can understand that. But to sweep that over all of them? A two-page proposed standard can take an absolutely ridiculous amount of time to pass through! each of the normative references need to be at that higher level too though... even for your 2 page PS-RFC I say we have variations based on how long the document is. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
Adding to this - and I'm not sure this is the kind of thing you were looking for, but it adds to the overall problem - is that IDs timeout after 6 months (which is fine), but that includes IDs that are in the RFC-Editor queue process too. For example, look at the RFC-Editor queue site: http://www.rfc-editor.org/queue.html and try and look at a document that has a original submission date more than 6 months ago (from today)? The search link will fail, and this is a problem. Some of these are quite valuable (especially to their WGs), yet the IETF process eliminates their viewing. Solution: perhaps an exception to the 6 month timeout should be made for every document upon entry into the RFC-Editor's queue such that every document remains until the document has been published as an RFC (or won't be). At 09:36 AM 5/10/2005 -0400, Margaret Wasserman wrote: I have one new root cause issue that I don't believe was included in the original Problem Statement: It takes too long to publish an RFC after final approval. It currently takes several months for an RFC to be published after it is approved by the IESG. This results in several problems: - RFCs come out much later than they should, contributing greatly to the perception that the iETF is slow. The time to move from approved I-D to RFC is often a significant percentage (perhaps averaging 20% of more?) of the time required to develop and publish a specification. - Stable references are not available until months after a specification is fully approved, resulting in ambiguity about the status of a document and encouraging the use of I-D names as references, thus blurring the distinction between WG I-Ds and approved specifications. - Too many changes are made to documents after WG and IESG approval (copy editing, changes to reflect updated thinking/terminology, etc.). These changes are often not reviewed or approved by the WG or the community. - Some RFCs are already out-of-date by the time they are published. The document then contains the RFC publication date, which may result in a mistaken impression about when the IETF held a specific view or encouraged a particular practice. I believe that the IETF should consider modifications to our document handling process to reduce or eliminate the delay in publishing approved specifications. Margaret At 2:36 PM +0200 5/10/05, Brian E Carpenter wrote: Having finally read the list traffic up to date, I have a question. Can anybody identify a *new* root cause problem at the same level of abstraction as those identified in RFC 3774? Or is it the case that (at that level of abstraction) we have only been re-discussing the RFC 3774 problem set? (Please try to be succinct... or change the subject header if you want to change the subject.) Thanks Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New root cause problems?
At 12:45 PM 5/10/2005 -0400, Thomas Narten wrote: Total time between IESG approval and publication, 5 1/2 months. And to get to Margaret's other points, I agree that these delays damage the IETF. It contributes to the perception that we are too slow, causes additional confusion about a document's true status, etc. Implementors and other SDOs need access to the final RFCs in a timely fashion. so do customers who feel an ID isn't sufficiently stable to specify as a customer requirement (for an RFP, for example) I have already had a customer get so frustrated with the IETF process they wrote an extension themselves into H.323 and got it ratified in 9 months (H.460.14) and our effort (that was first presented at the Adelaide meeting) just went to the IESG for review 5 years and 2 months later. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D/RFC source formats
At 03:20 PM 4/8/2005 -0400, Bruce Lilly wrote: On Fri April 8 2005 13:55, Francis Dupont wrote: BTW IMHO the best tool should be so painful that I-Ds would be very small (:-)? The size of the boilerplate alone precludes that, unfortunately. And it gets worse next month when the secretariat stops accepting he (or she, as the case may be) as an alternative to he or she in that boilerplate. I don't understand this point, can you expound on it for those of us that don't know about it? cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SIP INFO and RFC 2833 support?
At 05:45 PM 12/20/2004 -0800, Madabhushi Pramod wrote: Hi all, I have couple of questions: a couple answers... 1) What is the latest draft on SIP INFO? RFC2976, no revision is currently planned (and I have asked the SIP WG in the last two meetings) 2) Is it mandatory to signal DTMF via SIP INFO? no, RTP can be used, and there are others In INFO - this was a suggested and possible vehicle for DTMF, along with various other info like signal strength and other non-streaming information between endpoints, etc 3) Do SIP vendors support RFC 2833 for G711 along with G729 also? I mean is it common for vendors to support RFC 2833 for G711? Any help is appreciated. Thanks, Pramod Madabhushi = Pramod Madabhushi email: [EMAIL PROTECTED], [EMAIL PROTECTED] Phone:001-408-204-8077 __ Do you Yahoo!? All your favorites on one personal page Try My Yahoo! http://my.yahoo.com ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: List of Old Standards to be retired
I'm initially really surprised 1518/1519 is on this list. Wasn't there recent talk (like last week) of extending CIDR? And if this is true, shouldn't that work be completed before the existing docs are moved out to the pasture? At 12:46 PM 12/16/2004 +0100, Eliot Lear wrote: Hello, This is an update from the Old Standards experiment. Below are a list of proposed standards that are candidates to be obsoleted. The old standards mailing list has vetted out a good number, but still a good number remains. We are looking for experts who can say affirmatively whether a standard is implemented and in use. In particular, many of the docs class into four categories: - telnet options - MIBs (for X.25, 802.5, FDDI, and other) - SOCKS - Interaction with other protocol stacks (ISO, IPX, Appelalk, SNA, etc) If you see a document on the list below and you know it to be in use, would you please reply to this message indicating the RFC number, and whether you believe the doc should be advanced beyond proposed? Also, if you know of work to update anything on the list below, please include that. A note along these lines is generally sufficient to remove a document from the list below. RFC0698 Telnet extended ASCII option RFC0726 Remote Controlled Transmission and Echoing Telnet option RFC0727 Telnet logout option RFC0735 Revised Telnet byte macro option RFC0736 Telnet SUPDUP option RFC0749 Telnet SUPDUP-Output option RFC0779 Telnet send-location option RFC0885 Telnet end of record option RFC0927 TACACS user identification Telnet option RFC0933 Output marking Telnet option RFC0946 Telnet terminal location number option RFC1041 Telnet 3270 regime option RFC1043 Telnet Data Entry Terminal option: DODIIS implementation RFC1053 Telnet X.3 PAD option RFC1234 Tunneling IPX traffic through IP networks RFC1239 Reassignment of experimental MIBs to standard MIBs RFC1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 RFC1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 RFC1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers RFC1285 FDDI Management Information Base RFC1314 A File Format for the Exchange of Images in the Internet RFC1328 X.400 1988 to 1984 downgrading RFC1370 Applicability Statement for OSPF RFC1372 Telnet Remote Flow Control Option RFC1378 The PPP AppleTalk Control Protocol (ATCP) RFC1381 SNMP MIB Extension for X.25 LAPB RFC1382 SNMP MIB Extension for the X.25 Packet Layer RFC1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol RFC1414 Identification MIB RFC1415 FTP-FTAM Gateway Specification RFC1418 SNMP over OSI RFC1419 SNMP over AppleTalk RFC1420 SNMP over IPX RFC1421 Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures RFC1422 Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management RFC1423 Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers RFC1424 Privacy Enhancement for Internet Electronic Mail: Part IV: Key Certification and Related Services RFC1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 RFC1469 IP Multicast over Token-Ring Local Area Networks RFC1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol RFC1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol RFC1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol RFC1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol RFC1478 An Architecture for Inter-Domain Policy Routing RFC1479 Inter-Domain Policy Routing Protocol Specification: Version 1 RFC1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies RFC1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages RFC1502 X.400 Use of Extended Character Sets RFC1512 FDDI Management Information Base RFC1513 Token Ring Extensions to the Remote Network Monitoring MIB RFC1518 An Architecture for IP Address Allocation with CIDR RFC1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy RFC1525 Definitions of Managed Objects for Source Routing Bridges RFC1552 The PPP
draft-farrel-rtg-morality-requirements-00.txt
http://www.ietf.org/internet-drafts/draft-farrel-rtg-morality-requirements-00.txt I do not see why this ID should be limited to the Routing area... The Application of General Internet specifications should consider the Operations and Management of the Security surrounding Transport of morality considerations, even if in a Sub-IP moral zone. nuff said? cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-farrel-rtg-morality-requirements-00.txt
At 06:39 PM 11/16/2004 -0800, Fred Baker wrote: At 03:57 PM 11/16/04 -0800, Bob Hinden wrote: We should be proactive and create a morality area in the IETF. The morality ADs can review and vote Discuss if the Morality Considerations section in drafts being reviewed by the IESG is not adequate. Do the Morality ADs get to wear funny clothes? I think they *are* the fashion police... Inquiring minds want to know... ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Internet-Draft cutoffs and getting work done
John Good rant! I agree with each of your concerns, and ask too for discussion on what was brought up in your message. At 09:02 AM 10/18/2004 -0400, John C Klensin wrote: Hi. Summary: Four weeks? When we sometimes run only three months between meetings? Some years ago, the secretariat and IESG agreed on an I-D posting deadline about a week before IETF began, in the hope of getting all submitted drafts posted before WGs needed them for review and discussion. Prior to that rule, the last drafts to arrive either slipped through the cracks or were posted after we had started meeting, which did no one any good. As the load of incoming drafts increased, still with a completely manual process, the posting deadline was shifted back another week, to be two weeks before meetings began, and then a rule was imposed (for which I fear I'm at least partially responsible) requiring that initial-version drafts be posted yet a week earlier -- three weeks out. The theory behind the latter was the load continued to rise and that initial versions often took longer to process and confirm than second and subsequent versions, so it made sense to let the additional time burden fall on them. Such deadlines, considerably in advance of IETF meetings, are an impediment to objectives we claim for the standards process -- opportunities for people to get as much work as possible done outside the face to face meetings, and documents in hand that are timely enough that people who do not attend meetings in person can effectively express their comments. Over the last few IETF meetings, processing has become more automated, or the Secretariat has become more efficient in other ways. The typical time to get an I-D posted other than in the pre- and post-meeting rush has dropped to one working day and has sometimes even been less. And, during the rush, the queue has often cleared early enough that consideration of shortening the deadlines/ lead time would be in order. Instead, a new rule has apparently crept into the posting deadlines, with no community discussion or announcement other than in those deadline announcements. The rule, in this meeting's form, is that As always, all initial submissions (-00) with a filename beginning with draft-ietf must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, October 11 at 9:00 AM ET. First of all, this isn't as always. The rule requiring explicit WG Chair approval is fairly recent. But, more important, we now have a situation in which WG drafts -- presumably the most important documents for the face to face meetings-- now require formal naming, authorization, and approval a full four weeks before the first IETF meeting sessions. Remembering that we have sometimes had meetings as close as three months apart, but even with four months being the nominal separation, this is a _big_ chunk of time. On the three month schedule, and allowing a couple of weeks post-meetings for things to stabilize, people to get caught up, and new discussions to start, it could give a WG only six weeks to have a discussion that could generate a new document for discussion and agree on that document before cutoffs impose, at least, names that make those documents harder to find and track. As we continue to discuss problems and issues that get in the way of our getting effective work done, it seems to me that this is a new one that should be added to the list. Also, in the context of administrative reorganization, I would find it helpful, and others might too, to understand where this new requirement came from: (1) If from the Secretariat by unilateral action, it is perhaps a symptom of difficulties with the Secretariat that require some change in models. (2) If from the IESG, it perhaps should be examined as a procedural change made without an announcement to the community and opportunity for comment -- precisely the type of change that the July14 draft was intended to prevent in the future by providing a more efficient way to get such changes made _with_ community involvement and (at least default) authorization. Finally, if four weeks is really necessary, I suggest that we are in need of firm rules about minimum meeting spacing. john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: hop-by-hop and router alert options [Re: Question about use of RSVP in Production Networks]
Pekka While it is clear your distaste for RSVP, you haven't stated anything other than handwave why RSVP is so bad (in the first place). You mention there were mistakes and a BB will fix them, but you don't list a set of mistakes RSVP made for folks to digest. I don't know if you think they are so obvious you don't have to state them or you don't want to list them for whatever reason. Humor me (and a few others here) with a few listed mistakes you believe RSVP made in its design, with how you would redo them (either with a BB or just a better RSVP design). Without this, you are just ranting without substance to me - as I cannot glean anything real from your messages other than your distaste of RSVP in favor of a Bandwidth Broker... At 12:21 AM 8/13/2004 +0300, Pekka Savola wrote: Inline.. On Thu, 12 Aug 2004, David R Oran wrote: I question the usefulness of path-coupled signalling beyond a certain point in the network. Dean Anderson voiced them pretty well in the original thread about RSVP -- it just doesn't seem to make any sense beyond a very closed environment (like the first hop) -- and in that case, you should be able to use another kind of signalling as well. If we don't learn anything of the mistakes we did with RSVP, we're bound to repeat them. First, we have to agree on what the mistakes were :-) Of course. Then why this wasn't the first thing NSIS did after going for on-path signalling, or didn't I just manage to find it? I really really hope that there has been a problem statement... For example, has the design clearly restricted itself to the first or the last hop, or within the first couple of hops? No. Here's one counter-argument. Enterprise networks tend to have dumb-bell topologies, where the bottleneck links are in the interior rather than at the edges (exactly the opposite of serivce provider networks). They have meshes of 100meg+ all over each site, but the sites are interconnected with some service (like MPLS VPN, frame relay, etc.) which is expensive and often with very limited bandwidth (sometimes sub-T1). These links are not necessarily all that easy to identify in the topology, because for reliability enterprises configure mulitple routers and backup links. There is strong demand for flow-granularity admission control on such links, and an end-to-end model works better because site-to-site flows can swamp both the uplink at one end and the downlink at the other end. There are other useful examples which I can share if people are interested. Agreed, this seems like a possible use case; but again, this is within a site, and the congestion points can be well-defined. If it's not the first hop, then it's a predetermined point (or points) in the network. Hardly something you absolutely need on-path signalling for. For that purpose, I'm not 100% sure if you would need a path-coupled signalling. You'll certainly want path-coupled signalling for signalling with a much wider span (because it's the simplest way to do it from the host's perspective), but I'm arguing (as Dean was) that this isn't an interesting approach from the network operators' perspective. What about discovery of the furthest point. Do you not find that a persuasive use case? Further point where you can use path-coupled signalling, you mean? Not really, as there seems to be something seriously broken if you need set up priorization except in well-defined points in the network. And to achieve that, you could use a bandwidth broker: either it's able to set up the required bandwidth (it's in the same site, or at a site your site has a roaming agreement with), or it isn't and the approach is going to fail in any case, because the sites out in the Internet don't want outsiders to request bandwidth allocations. As for the alternatives: 1) for first-hop only, there's really little need for a router alert, any protocol would do, as you already know who your routers are :-) 2) for hops beyond the first-hop router, I'd consider setting up a single server which would be responsible for brokering the QoS capabilities, firewall holes, etc. You contact the server, and ask it to open a certain kind of hole, set up certain QoS between (source, destination), etc. There are a number of options how you could discover this kind of system: a) a DHCP option b) a DNS lookup (e.g., SRV record based on your DNS search path) c) asking the upstream router using protocol learned in 1). This assume edge tree topologies, which are common but hardly ubiquitous. I don't think I assumed edge tree topologies. Please elaborate. These kind of approaches essentially move the intelligence and processing to specific nodes who are better capable of handling such requests, having policy who can request what, removing the processing and cruft from the routers. And the hosts have have much easier time figuring out whether requesting these
Re: T-shirts, and some suggestions for future ietf meetings
At 01:00 AM 8/6/2004 -0400, Tony Hansen wrote: The first time in recent years that we almost didn't have a sponsor was in Adelaide (IETF 47, March 2000). So, what happened? In true IETF fashion, a bar BOF met, designed a T-shirt, and made arrangements with a T-shirt shop a couple of blocks from the convention center. Those people who wanted a T-shirt walked over there, picked a T-shirt color, put in an order, paid their money, and got a shirt a couple of days later. (It's definitely one of my most favorite IETF shirts.) As one of the designers of the T-Shirt (along with Randy Stewart and Peter Lei): thanks! I agree. It is the one that I see most often now at meetings. There is some pride with that effort, not only that is prevails with folks wearing it, but that we actually did it and gave folks choices of colors and such. I don't know exactly how many people wound up ordering their shirt this way, well over 1000 but I know the owner worked numerous overtime hours to meet the demand. he was sweating - but making money all the way, so he didn't mind at all. cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Civil-02 ID and PIDF-LO inconsistencies
At 10:13 PM 7/10/2004 -0400, Henning Schulzrinne wrote: James M. Polk wrote: In reviewing the pidf-lo-02 and the civil-02 IDs, I have discovered minor inconsistencies. Please note that the labels in the column 'NENA' refer to the NENA 02-010 data element labels. Neither FLR or PC are used there, as far as I can tell. FLR is not defined there at all and PC is called ZIP. h - inconsistencies should be avoided if known (therefore - see below) I've added a separate column to the civil-02 table, labeled PIDF, to make the correspondence explicit. this is good for the civil ID, but doesn't address what the pidf-lo ID is stating (which you shouldn't be solving) I believe the two charts should be consistent to each other, with the civil-02 ID being the one that's less complete, it should have the appropriate text added. They definitely should be. A separate, but related issue, is whether the language information contained in the civil-02 draft should also appear in PIDF-LO. I agree it is related. Perhaps the pidf-lo document should only reference the civil doc for the chart? In other words, have the civil ID be the creator of the chart, and not have it in both documents (fearing inconsistency), but have the pidf-lo document reference *to* the chart in the civil doc. I know this is not necessarily optimal, but this is the last week to catch this before IETF LC in the pidf-lo doc is completed, so there is time to address it now. cheers, James *** Truth is not to be argued... it is to be presented cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Comments on draft-ietf-pidf-lo
At 10:06 PM 7/10/2004 -0400, Henning Schulzrinne wrote: Based on suggestions by Brian Rosen, I'd like to propose three additional civic location elements for this document: - BLDG (building), e.g., Empire State Building I think LMK covers this (which is already defined), and is different than the occupant the building (which would be NAM I believe). - UNIT (unit), e.g, APT 42 or SUITE 123 - ROOM (room number), e.g., 1234 I know you gave only one example per, but room numbers have other characters in them frequently, like 63-1N (which is my office designation, so I didn't make it up) Otherwise, these last two seem reasonable Henning ___ Geopriv mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/geopriv cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Civil-02 ID and PIDF-LO inconsistencies
At 10:42 PM 7/10/2004 -0400, Henning Schulzrinne wrote: James M. Polk wrote: I know this is not necessarily optimal, but this is the last week to catch this before IETF LC in the pidf-lo doc is completed, so there is time to address it now. Given that both need to define different tags (XML element names in one case, numeric tags in the other), I think such reference would be difficult, but they both have a way too similar chart that doesn't match - implementors down the road might not see the subtle differences and we end up with another Mars Probe crashing into the planet because one set of engineers used km and the other used miles and both groups were happy until there were flames and smoke Not being consistent MUST lead to ignoring of fields in the IETF... this is not good unless (see below) even leaving timing issues aside. I think we can handle the synchronization of the documents this means the civil doc needs to change to exactly what the pidf-lo doc has (as the synchronization is up to the most mobile doc - and that's the civil doc near WGLC, but far from IETF LC) - the list of elements is small. agreed they are in the details side of addressing, but if someone sending a message was coded to the civil doc and includes BLDG, and the recipient's device was coded to the pidf-lo doc without such a reference, the BLDG value must be ignored by the recipient. Maybe this is the lone identifier on the Columbia Univ campus (The Law School). Leaving everything else consistent, a responder is going to go to a campus address and have the floor and room number, but not which building the caller was in. That might mean less lawyers that year... This I think presents a problem. Henning cheers, James *** Truth is not to be argued... it is to be presented ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
