RE: Re: [IAB] Last Call: Modern Global Standards Paradigm
+1 Well said Mike. For what its worth I completely and unconditionally support the signing of the document on behalf of the entire IETF community. This support is personal and does not represent any official position of the SIP Forum its full members or its board. But if we were asked . It is totally clear to me that the WCIT process represents a substantive threat to the multistake holder process in standards development that has made the IETF and the Internet work. What is horrifying to me as well is this idea of mandatory ITU based protocol certification testing. The ITU has ZERO business imposing this requirement on nation states. Our Industry deals with compliance and certification testing in its own way without government sanctioned intervention. Weve seen this class of threat before multiple times over the past decade. Hopefully this will pass but it will certainly come up again and again. Vigilance Vigilance. Though our focus has been pure engineering we cannot ignore the forces building up to demand a return to some form of intergovernmental control of global communications. We won! Now the forces of darkness say .. well if its going to deal with SIP/IMS telephony ( voice ) well it has to be regulated! Right ..!! Wrong .. Granted the European PTTs are not helping here with totally absurd ideas about abandoning the privately negotiated transit peering model with some form of data sender pays abomination because they cant figure out their business models. Now they first had a Whine and Cheese party in Brussels , but getting no satisfaction there they now go to the UN to support their untenable position. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michael StJohns Sent: Sunday, August 12, 2012 11:03 PM To: Glen Zorn; ietf@ietf.org Subject: Re: Re: [IAB] Last Call: Modern Global Standards Paradigm Glen and others - I wanted to go back and comment on the assertion that Glen made that the IETF and IAB chairs do not 'represent' [him] or any one other than themselves. I believe he is correct with respect to himself, and incorrect with respect to the IETF. I agree the IETF is not a representative democracy, the IESG and IAB (and not the IETF) are probably best described as electoral meritocracies. We randomly select electors from a qualified pool which self-selects mostly from the set of all participants which in turn selects the IESG and the IAB from that set of all participants. I'm pretty sure that Carsten was using elect to describe that process. While the IESG and IAB may not speak for the IETF participants, they de facto and de jure do speak for the IETF. It's a subtle difference, but an important one. [CF the various RFCs detailing the responsibilities and duties of the IESG, IAB and their respective chairs, the RFCs detailing the standards process, and the various liaison's that have been arranged over the years.] I've noted over the years that the constituency of IETF participants tends to have bouts with BSDS - back seat driver syndrome, and this is mostly not helpful. We (referring to the broad set of IETF participants going back 25+ years) have over time evolved and agreed upon various ways of moving forward for generally accepted values of forward. Those ways include having granted the IESG the power to set the standards agenda, the IAB to negotiate and approve liaison agreements with standards bodies, the IESG to ultimately approve the standards, and the IESG, IETF Chair and IAB chair to declare a perception of consensus. We (the participants) have reserved to ourselves the rights jointly and severally to comment on all of the above, to be heard on even items delegated to the IESG and IAB and at times to carp and cavil on every single point of order. Some of this is good for the process. But we go too far way too often. In this case, the IAB, IESG and their respective chairs are doing the jobs we've asked them to do. Russ, correctly I believe, asked for objections to the issuance of such statement, he didn't ask for consensus. I also believe it would have been well within the current job description of the IAB and IETF Chairs to just go ahead and sign the thing. I think it comes down to this: If you (an IETF participant) have an objection to the statement, make it here. If you have an objection to the process in general then - form your objections, write an ID, and socialize what you want changed. If consensus shows you correct, it will apply down the line. If you have a belief that the process has been violated, it's appropriate to make that point, but give details rather than vague intimations. If you have an objection related to the members of the IESG or IAB performance, make them
RE: So, where to repeat?
Minneapolis is infinitely more glamorous Frankfurt .. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tim Bray Sent: Friday, August 10, 2012 12:30 PM To: Geoff Mulligan Cc: Dave Crocker; ietf@ietf.org Subject: Re: So, where to repeat? Frankfurt as the Minneapolis of Europe: central, well-connected, cold, unglamorous. -T On Thu, Aug 9, 2012 at 11:37 AM, Geoff Mulligan ge...@proto6.com wrote: On 08/09/2012 09:17 AM, Yoav Nir wrote: On Aug 9, 2012, at 6:07 PM, Dave Crocker wrote: offlist. Not so much Geoff, Frankfurt is a city in Germany. I believe the IETF has never been there. Two more tidbits: - It's a huge aviation hub. There are direct flights from everywhere, similar to CDG, Heathrow, or Schiphol - Unlike Paris, London and Amsterdam, it's not a great tourist attraction, so conceivably it would be cheaper. I've found it relatively inexpensive, clean and very easy to get to. Other than those two tidbits about it, I've no idea what is to be accomplished by someone's randomly throwing out the names of cities for a discussion like this, especially when threads like these always have a great deal of trouble staying focused on the /principle/ rather than haggling the details. The principle would be to go to aviation hubs so as to minimize the collective pain. Most people from the US going to Prague, would have a connection in Frankfurt, so a meeting in Frankfurt would reduce the amount of flights. This is why I threw out a not so random city name - Frankfurt. Yoav On 8/8/2012 12:24 PM, Geoff Mulligan wrote: Frankfurt? On Aug 8, 2012, at 12:49 PM, Dave Crocker dcroc...@bbiw.net wrote: On 8/8/2012 11:46 AM, Geoff Mulligan wrote: So then why not consider, London, Paris (not the Concorde Lafayette), Frankfurt, Amsterdam? shockingly, amsterdam can't handle the ietf. wrong mix of resources. really. paris appears to have broad crime and work-ethic patterns that also are problematic, not just at the concorde. to be clear: i'm speaking for myself. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net Scanned by Check Point Total Security Gateway.
RE: So, where to repeat?
The tourist website www.minneapolis.org uses the slogan City by Nature. I think An infinitely more glamorous Frankfurt would be an improvement. [RS ] If you prefer a globally dysfunctional airport and a city run by bankers ..then yes its potentially more 'glamorous'. Granted they do have a world class Christmas Market in season. If you want the center of Europe .. Munchen. You could think about Berlin but then you have a totally non existent disfunctional airport. Wait a few years out and you can rethink Washington DC. A totally functional 5 runway international airport .. a full metro rail from the airport to the city and all of Washington's many nonexistent charms. . On Aug 10, 2012, at 10:01 PM, Richard Shockey wrote: Minneapolis is infinitely more glamorous Frankfurt .. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Tim Bray Sent: Friday, August 10, 2012 12:30 PM To: Geoff Mulligan Cc: Dave Crocker; ietf@ietf.org Subject: Re: So, where to repeat? Frankfurt as the Minneapolis of Europe: central, well-connected, cold, unglamorous. -T
RE: So, where to repeat? (was: Re: management granularity)
+1 Prague was excellent .. I actually liked Quebec City but connections were awful. So where in Asia? You have to have the 3. Is this discussion is really about are we the Internet Entertainment and Travel Facility?? Some of us have employers some of us do not. Is this about diversity or getting the work done. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Steve Crocker Sent: Tuesday, August 07, 2012 6:01 PM To: Tim Chown Cc: ietf@ietf.org Subject: Re: So, where to repeat? (was: Re: management granularity) I'll bet Dublin would be rated higher if the meetings had been downtown. Same for Vienna. Steve On Aug 7, 2012, at 5:55 PM, Tim Chown wrote: Hi, My top three repeat venues would be Prague, Minneapolis and Vancouver. Great meeting venues, with everything you need nearby. My least favoured venues have been Dublin, Vienna and Maastricht. Of course, you have to experiment to find good repeat venues... Tim
RE: So, where to repeat? (was:Re: management granularity)
[RS ] +1 and no employer ever argued that going to Minneapolis was a boondoggle. The Hilton in Minneapolis of all the IETF meetings Ive attended has the most optimal layout of meeting rooms etc. If we were to choose one place in the U.S. to meet, Minneapolis is the best choice IMHO. It's very reasonably priced, easy for many to get to and the hotel has adequate space for us (even back when we had many more attendees). Personally, the weather is not critical to me, since I spend the vast majority of my time in the hotel meeting rooms, so I'm very happy if we meet there in March and November. Mary On Mon, Aug 6, 2012 at 9:18 AM, Dearlove, Christopher (UK) chris.dearl...@baesystems.com wrote: I've never been to an IETF meeting where the plane fare has exceeded the hotel cost for a week. Caveats to that are that I have mostly gone for IETF recommended hotels, so may have missed particularly cheap hotels, and that I have only been to North American and Europe (but that statistic includes Vancouver and the even further away western US cities down to San Diego). And of course I fly economy, and it's much cheaper including a Saturday night in your trip, even at the cost of an extra night in a hotel (at least it is from here). An almost exception was Paris this year where I was staying fairly cheaply, but that was a cost-shared trip between me and my employer, and I didn't fly (I went by train - though that's not cheaper, just better). Paris has cheap(er) hotels and a metro I understand, so I felt less location constrained. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 tel:%2B44%201245%20242194 | Fax: +44 1245 242124 tel:%2B44%201245%20242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: Sprecher, Nurit (NSN - IL/Hod HaSharon) [mailto:nurit.sprec...@nsn.com] Sent: 06 August 2012 15:07 To: Dearlove, Christopher (UK); Daniele Ceccarelli; Andrew Sullivan; ietf@ietf.org Subject: RE: So, where to repeat? (was:Re: management granularity) --! WARNING ! -- This message originates from outside our organisation, either from an external partner or from the internet. Keep this in mind if you answer this message. Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages. When you are not close (time), flight cost may become higher in the priority (over hotem) Flying to Vancouver for me for example is the most expensive tripeven though the city is amazing and the host was wonderful! -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Dearlove, Christopher (UK) Sent: Monday, August 06, 2012 4:56 PM To: Daniele Ceccarelli; Andrew Sullivan; ietf@ietf.org Subject: RE: So, where to repeat? (was:Re: management granularity) Dublin's problem was that the venue was isolated from the city. This has also been the case with e.g. San Diego. (I'm assuming no personal car.) Contrast with Minneapolis (and several other places) where you were right in the city. Being in a city is better for lunch and dinner options, taking a break to go to a bookshop (or to buy something you forgot to bring) and so on. (I'm deliberately not including tourism here.) However at the moment my priorities to make being able to attend possible would be time (so the closer to me the better - I realise that's impossible globally), cost (hotel first, flight second, rest is noise) and the ability to plan ahead to only attend part of the week. This is the current economic reality. Dublin actually scores quite well on those for me. -- Christopher Dearlove Senior Principal Engineer, Communications Group Communications, Networks and Image Analysis Capability BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 tel:%2B44%201245%20242194 | Fax: +44 1245 242124 tel:%2B44%201245%20242124 chris.dearl...@baesystems.com | http://www.baesystems.com BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England Wales No: 1996687 -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Daniele Ceccarelli Sent: 06 August 2012 13:24 To: Andrew Sullivan; ietf@ietf.org Subject: RE: So, where to repeat? (was:Re: management granularity) --! WARNING ! -- This
RE: Feedback Requested on Draft Fees Policy
+1 Excellent idea in principle ..IMHO just a matter of working out details. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Bradner, Scott Sent: Friday, July 20, 2012 10:17 AM To: Scott Brim Cc: wgcha...@ietf.org; ietf@ietf.org; i...@ietf.org; i...@iab.org; IETF Announcement List Subject: Re: Feedback Requested on Draft Fees Policy great idea - just does not jive with the legal system which often need authenticated copies of documents Scott On Jul 20, 2012, at 10:14 AM, Scott Brim wrote: On Jul 20, 2012, at 9:07 AM, IETF Administrative Director wrote: The draft policy entitled Draft Fee Policy for Legal Requests can be found at: http://iaoc.ietf.org/policyandprocedures.html Fine idea.
RE: Feedback Requested on Draft Fees Policy
As a working assumption let's say at least 750 USD or Euros per hour to calculate cost recovery. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John C Klensin Sent: Friday, July 20, 2012 10:40 AM To: IETF Administrative Director Cc: ietf@ietf.org Subject: Re: Feedback Requested on Draft Fees Policy --On Friday, July 20, 2012 06:07 -0700 IETF Administrative Director i...@ietf.org wrote: The IAOC is seeking community feedback on a proposed policy by the IAOC to impose fees to produce information and authenticate documents in response to subpoenas and other legal requests. ... Before adopting a policy the IAOC would like feedback on this before making a decision. Comments appreciated to ietf@ietf.org by 6 August 2012. Seems entirely reasonable. Knowing how much effort some of these requests can produce, I do wonder if the fees are a bit too low but trust that the IAOC has determined that they will at least cover costs. john
The US Federal Communications Commission Technical Advisory Committee is discussing the end of POTS.
Aka the PSTN transition . http://www.fcc.gov/encyclopedia/technological-advisory-council http://transition.fcc.gov/bureaus/oet/tac/tacdocs/TAC-WG-Ques-5-9-12.pdf Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org
RE: 'Geek' image scares women away from tech industry ? The Register
[RS ] +1 This is not just something we should do, its something we have to do. I know the AD's try and keep a strong hand in talent spotting among the WG chairs on who might succeed them, but one thing I believe WG chairs need to do is appoint WG Secretaries. I always did. Limit the number of WG's a single individual can co-chair. The best way to mentor promising talent of is to give them a start on the career ladder I'm sure if there was a way for potential mentors to volunteer, there would be a good number of interested volunteers (myself included). Growing a next generation of leaders is something the entire IETF should do more of. Thomas
RE: Query to the community -- An additional IETF Meeting event?
+1 Its worth a try. I know IETF week is extremely busy for folks. There is the work that has to be done. There are dozens of private conversations folks want to have but IMHO we have to be realistic about making sure we are doing the right things to keep the meetings financially solvent in difficult times. In my personal role as SIP Forum chair we also looked at what NANOG did in developing our own SIPNOC conference for SIP Network Operators. We wanted peer reviewed presentations but we wanted a low key opportunity for vendors to participate especially those with limited budgets that would not conflict with full conference sponsorships. The Beer and Gear idea was perfect. The question would be what day .. Richard Shockey Chairman of the Board of Directors SIP Forum http//www.sipforum.org -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of IAOC Chair Sent: Friday, March 16, 2012 4:14 PM To: IETF Announcement List Subject: Query to the community -- An additional IETF Meeting event? The IESG and IAOC are considering an addition to the IETF meeting week, and we would like your views before we develop the idea further. At NANOG, there is a Beer and Gear reception one evening. There are exhibitor tables with product vendors (hardware and software) and service providers (registries, registrars, ISPs, ESPs, etc.) and anyone else interested in face time with NANOG participants. They show their equipment and services. There is bar in the center of the room serving beer, wine, and soft drinks. There are hors d'oeuvres scattered around the room. QUESTION: What do you think about doing a Beer and Gear style of event on an evening that does not conflict with other IETF activities? This would be an opportunity for free food and drink for attendees, for vendors and service providers to talk with IETF participants, and for additional revenue to the IETF. Obviously, attendance would be optional. Technical people are at the tables, not sales or marketing staff. Vendors know that the audience is very technical, so they send the people that can communicate with that audience. We would charge for exhibit tables, to raise additional funds for the IETF. A stronger base of opportunities for IETF sponsorship distributes our funding, making it less fragile; this could make it less likely that we would have last-minute scrambles for additional sponsors, including hosts. A successful Beer-and-Gear like event would not solve this but it would help. In the past, the IETF has avoided vendor exhibits and demonstrations. However it is clear that NANOG has found a balance that works and that NANOG participants and the vendors consider the event valuable. We believe this could translate well to the IETF. We are considering some test events, hopefully to be held at IETF 84 (Vancouver, July 2012) and IETF 85 (Atlanta, November 2012). The kinds of evaluation criteria we are considering could include: - Did participants enjoy the event? - Did vendors consider the event successful? - Did the IETF raise additional funds? - Did the event steal potential sponsors away from other aspects of the meeting? So, what do you think? Is this something that we should try? Please respond on the ietf@ietf.org mail list. On behalf of the IESG and the IAOC, Russ Housley Bob Hinden
FYI : Canada's CRTC mandates all IP Interconnection for voice.
In this decision, the Commission decides that it is in the public interest to establish a set of principles to facilitate IP voice network interconnections between network operators while allowing market forces to shape the details of the arrangements. Specifically, in areas where a carrier provides IP voice interconnection to an affiliate, a division of its operations, or an unrelated service provider, the carrier must negotiate a similar arrangement with any other carrier that requests such an arrangement. Within six months of a formal request, an arrangement is to be concluded. http://www.crtc.gc.ca/eng/com100/2012/r120119.htm Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: FYI : Canada's CRTC mandates all IP Interconnection for voice.
I didn't suggest that. It's clear in the Canadian Order that if you provide SIP interconnection to anyone you have to make it available to everyone. But as you correctly point out, I doubt such carriers either exist or will exist much longer. It does create a more level playing field. This Order clearly sidestepped the issue of a shot clock for full TDM retirement, though a review of the Order is suggested for 2014. I thought Paragraph 69-70 on establishing a Canadian carrier ENUM database personally amusing. The larger issue for our community is the existing NNI profiles have not been updated in years and there is still a huge gap analysis that needs to be undertaken that may require further IETF RAI work. I haven't seen that started yet. We haven't heard the last of this by any means. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Kevin P. Fleming Sent: Tuesday, January 24, 2012 4:54 PM To: ietf@ietf.org Subject: Re: FYI : Canada's CRTC mandates all IP Interconnection for voice. On 01/24/2012 02:28 PM, Richard Shockey wrote: /In this decision, the Commission decides that it is in the public interest to establish a set of principles to facilitate IP voice network interconnections between network operators while allowing market forces to shape the details of the arrangements. Specifically, in areas where a carrier provides IP voice interconnection to an affiliate, a division of its operations, or an unrelated service provider, the carrier must negotiate a similar arrangement with any other carrier that requests such an arrangement. Within six months of a formal request, an arrangement is to be concluded./ http://www.crtc.gc.ca/eng/com100/2012/r120119.htm I think that your subject is a bit misleading. This decision does not 'outlaw' non-IP interconnection, nor does it obligate a carrier that is not currently IP-interconnected (if such a carrier exists) to become so connected. It only levels the playing field and ensures that all IP-interconnected carriers make IP interconnection available to any other carrier that is interested in it, not just the 'chosen few'. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com www.asterisk.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: Interested in giving a talk at the FCC?
I'd like to whole heartedly endorse this suggestion and encourage a variety of IETF Subject matter experts to give talks relevant to the FCC. I personally help arrange two seminars at the FCC at the invitation of Doug Sicker, Henning's predecessor as CTO The first on was a tutorial on SIP and the second on MPLS. As a rule these kinds of talks should be vendor/policy neutral. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, January 22, 2012 11:10 AM To: ietf@ietf.org Subject: Interested in giving a talk at the FCC? If you're interested in giving a seminar to technical staff and/or economists at the US Federal Communications Commission (FCC), please let me know. The FCC won't be able to pay for travel, so we'd likely schedule any talks when you are in the DC area. Also, if you know of any colleagues the Commission staff should hear from, feel free to suggest them. I won't make any promises that I'll be able to accommodate all or even most offers, but this is an experiment to see if we can broaden the perspectives heard at the FCC. Most FCC staff are generalists, so topics should be accessible and of interest to this community. (In general, the FCC deals with many aspects of wired and wireless communications, and is interested in applications, as well as lower layers. Examples of topics of particular interest are spectrum-related issues, increasing broadband availability, security/privacy, IPv6, PSTN-transition issues, public safety and accessibility. Thus, if you're interested, please get in touch with me with a rough description of what you'd talk about. If there's local interest in your topic, I will get back to you to work out details. There is no deadline as such, so consider this a standing offer. Henning -- Henning Schulzrinne CTO, FCC 7C252, (202) 418-1544 ___ 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: FCC Names Henning Schulzrinne Chief Technology Officer
It's a great appointment and the IETF community should rightfully be thrilled and excited. I'm a cross posting a note I made to the RAI DISPATCH List. There are interesting things going on with core Layer 7 services and itsnot US centric. Its is the beginning of the transition of the entire real time communications service to IP networks. And yours truly was the opening act at the Workshop. Henning is absolutely right here. If there was ever a time for the RAI community to reach out the policy folks its now. BTW if you really want to understand what is going on here you can add this to your holiday reading list. http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1122/FCC-11-1 61A1.pdf War and Peace without the plot. If it seems overwhelming, it is but regulators have to deal with the law as it is, not as they would prefer it to be. Though some of these issues are US specific I would suspect that other national jurisdictions will start to take up these issues in the upcoming months and years. There are very relevant technical issues our community might have to deal with or certainly clarify. The above order specifically calls out non modification of the SIP headers by forwarding elements as it might relate to billing data such as Calling Party Number or SS7 Charge number. -Original Message- From: dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] On Behalf Of Henning Schulzrinne Sent: Monday, December 19, 2011 2:06 PM To: Paul Kyzivat Cc: dispa...@ietf.org Subject: Re: [dispatch] FYI FCC NAMES HENNING SCHULZRINNE CHIEF TECHNOLOGY OFFICER VoIP and related issues will play a major role in the FCC's work in the next year or two. For example, the FCC Technical Advisory Committee (TAC) will be looking at the PSTN transition; a video of a recent workshop can be found at http://www.fcc.gov/events/public-switched-telephone-network-transition-0 The Commission needs input from technically-oriented folks. Thus, don't hesitate to contact me if you or your organization wants to stop by at the Commission, or you have information you want to share. (FCC staff meets with both individuals and groups regularly, both within the rule making process and outside. No campaign donation or JD degree required.) For what it's worth, I've been tasked with outreach to standardization organizations as one of my responsibilities. Henning -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Fred Baker Sent: Monday, December 19, 2011 5:07 PM To: IETF Discussion Subject: FCC Names Henning Schulzrinne Chief Technology Officer http://www.fcc.gov/document/fcc-names-henning-schulzrinne-chief-technology-o fficer ___ 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: An Antitrust Policy for the IETF
+1 It would be helpful in the non normative statement to the community to cite what suits were are involved, what was the cause of action and what if any decisions were rendered in these cases. US antitrust law, for instance has specific exemptions for SDO's. http://en.wikisource.org/wiki/Public_Law_108-237/Title_I There are some requirements under this act that SDO's need to file a statement of purpose. I don't know if we ever did that. In general, however this sounds like a sound and valuable move. From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ted Hardie Sent: Monday, November 28, 2011 2:27 PM To: IETF Chair Cc: IETF; IESG Subject: Re: An Antitrust Policy for the IETF On Mon, Nov 28, 2011 at 11:10 AM, IETF Chair ch...@ietf.org wrote: Sorry, can you expand on the threat model here? Are we developing one in order to defend against some specific worry about our not having one? Because it has become best practice in other SDOs? Because the insurance agent wishes to see something in particular? I hesitate to develop something that we have not needed in the past unless it is clear what benefit it gives us. In particular, if we develop one without some particular characteristic, do we lose the benefits of being where we are now? Recent suits against other SDOs is the source of the concern. The idea is t make it clear which topics are off limits at IETF meetings and on IETF mail lists. In this way, if such discussions take place, the good name of the IETF can be kept clean. Russ Hmm, I would characterize our previous policy as a quite public statement that no one is excluded from IETF discussion and decision making, along with with reminders that what we are deciding is the technical standard, not the resulting marketplace. What we can say beyond that without diving into national specifics is obscure to me. I agree with Dave that the first work product of an attorney should be a non-normative explanation to the community of how having such a policy helps and what it must say in order to get that benefit. (I have to say that my personal experience is that prophylactic measures against law suits tend to change the terms of the suits but not their existence. In this case, suing someone because they did not enforce the policy or the policy did not cover some specific jurisdiction's requirements perfectly, seems like the next step. Your mileage may vary.) regards, Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: reading on small devices, was discouraged by .docx
15 or 20 years ago, I might have been able to use one of those small-screen devices. Nowadays - no way. If things are displayed large enough to be legible the amount of vertical scrolling makes reading anything longer than one (short) sentence painfully slow. But here's a solution: let's just wait a few more years, and the folks who are currently so enthusiastic about using these gizmos to read RFCs will have been compelled by their own aging eyes to move on to something else. [RS ] So should we suspend the discussion until then? :-) Personally I'm waiting for the iPad 3 with a retina display. :-) That should be available sometime in the springtime and we can take up the subject then as we traditionally do. Randy ___ 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: An Antitrust Policy for the IETF
Money for one discussions of product pricing and or costs for instance. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michael Richardson Sent: Monday, November 28, 2011 5:12 PM To: Russ Housley Cc: Sam Hartman; IETF Subject: Re: An Antitrust Policy for the IETF I'm still lost. What kind of things would the IETF have to prohibit discussion of, and specifically things that would involve anti-trust. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: reading on small devices, was discouraged by .docx
.epub I went over that months ago. EPUB 3.0 looks very functional. HTML 5 basis with LZW compression. http://idpf.org/epub/30 Is this conversation evidence of global warming? Some of my daffodils and narcissus are actually blooming here Northern Virginia. I usually thought that the rants over file formats were a natural IETF springtime discussion. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Levine Sent: Saturday, November 26, 2011 7:21 PM To: ietf@ietf.org Cc: ty...@mit.edu Subject: Re: reading on small devices, was discouraged by .docx ASCII is already unreadable on many popular devices and in a few years will be no better than old versions of word. If you can pan and scan a complex PDF file, you can pan and scan ASCII art. I've been doing some experiments trying to make RFCs and I-D's readable on my Kindle. It has native support for some reflowable formats (AZW and MOBI), and PDF. Amazon provides conversion software that turns several other formats into their flavor of MOBI, and a conversion service in which you e-mail documents to an address assigned to your Kindle, and they convert them to versions that appear on your device via a wireless network connection. You can also plug it into your PC as a USB disk and copy MOBI, AZW, and PDF files to it. [RS ] Calibre is your friend. The conversion service will accept text documents, but the results of sending an RFC or I-D through it are too painful to read other than in utter desperation, not just the ASCII art but the scrambled text. The device renders PDF page images quite well, but since the screen is so small, the text is too small to read. There's an option to select a rectangle and expand it, but the rectangle doesn't cover an entire line and you have to move it back and forth for every line which is slow and painful. You can turn the Kindle sideways, it rescales PDFs to the width of the screen, and you can use the up and down buttons. That is large enough to read, although still pretty small. I would have to say that PDF support is better than text, but still pretty poor. If you have PDFs with a native 4x6 page size, they look great, but you need to have your document in some other format that can be reformatted and printed to small page size PDFs. The conversion service and software handle a reasonable subset of HTML, so I tried running the XML source for I-Ds through saxon or the new xml2rfc, and then converting that to a Kindle native format. That works well, text nicely reflowed, ASCII art preserved as a block, and links to other sections and documents even work. I now use those as working versions of my I-D's. I haven't tried other e-readers, but the MOBI format is not unlike ePub format, so I expect the results would be similar. This tells me that it would be really nice to have a meta-format (probably xml2rfc, since it exists, and it's ASCII underneath so under even the worst scenarios the content is still accessible) that we can render into formats that work on whatever devices we use to read stuff. 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: The US Federal Communications Commission just sent the RAI/SIP community its Thanksgiving Turkey ...
pun intended Just in case you don't have anything interesting to read on the plane back from Tiawan. http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1118/FCC-11-1 61A1.pdf Selected passages of possible interest to the IETF RAI/SIP community are Pages 29-32 210-240 268-292 380-383 459-458 Does this mean that a carrier that recently jumped in the voice market (it could be either an ISP now providing VOIP to their customers along with a data bundle that -or- a VOIP-specialized carrier that leverages the IP bandwidth provided to the customer by another ISP) now has some leverage to go to the FCC to require (note the quotes) another carrier that historically has been in the traditional business of copper/TDM to connect primarily using IP/SIP? [RS ] Yep that's the idea! Negotiations are to be in good faith of course. No I have no idea what that means. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
UPDATE: The US Federal Communications Commission just sent the IETF RAI/SIP community an early Christmas present...
Santa came early this year http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1110/DA-11-18 82A1.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The US Federal Communications Commission just sent theIETFRAI/SIPcommunity an early Christmas present...
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Saturday, November 05, 2011 12:05 AM To: Worley, Dale R (Dale); Richard Shockey; John Leslie; IETF-Discussion list Subject: RE: The US Federal Communications Commission just sent theIETFRAI/SIPcommunity an early Christmas present... Worley, Dale R (Dale) wrote: it appears that their intention is to require IP-to-IP interconnection. The carrier with a majority of TDM clients will probably have to provide IP interconnection. Being an outsider, I wonder how big the stick is. [RS ] Its pretty big baseball or cricket bat. E.164 voice traffic is a fully regulated service with lots and lots of obligations associated with it and a very very large contingent of lawyers in DC to either enforce it the Act or find loopholes. But nevertheless I would say well played, as it indeed appears that the TDM heavy carriers will have little or no choice but to pay top dollar for an IP upgrade from the TDM vendors who provided them with their gear. [RS ] Well the other argument is the carriers have little or no choice at this point since the classic Class 5 SS7/TDM gear (DMS-5ESS) is well beyond its 25 year life cycle and is literally cracking up. The cost differential between a Class 5 and a IMS/CSCF running SIP is not even close .. plus the 5E, for instance use 400 amps to service, I believe only 100,000 customers. Plus the people operating these switches are retiring by the bushel full. Would you like gravy on your Christmas turkey? Michel. ___ 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: The US Federal Communications Commission just sent theIETF RAI/SIPcommunity an early Christmas present...
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Thursday, November 03, 2011 10:54 PM To: Richard Shockey; John Leslie; IETF-Discussion list Subject: RE: The US Federal Communications Commission just sent theIETF RAI/SIPcommunity an early Christmas present... Richard Shockey wrote: IMHO, they're talking obligation to interconnect between carriers as required by actual law. Please forgive a probably naive question; Does this mean that a carrier that recently jumped in the voice market (it could be either an ISP now providing VOIP to their customers along with a data bundle that -or- a VOIP-specialized carrier that leverages the IP bandwidth provided to the customer by another ISP) now has some leverage to go to the FCC to require (note the quotes) another carrier that historically has been in the traditional business of copper/TDM to connect primarily using IP/SIP? [RS ] Yep that's the idea! There is a good potential of conflict in the appreciation of the negotiate in good faith thing, as the carrier with a majority of SIP clients would not want to invest in the TDM hardware to connect, while the carrier with a majority of TDM clients would not want to invest in the SIP gateways. [RS ] Well that's why there are communications lawyers. Actually this has been going on for some time. Cable Operators in the US and the Netherlands as well as some CLEC's have been interconnecting among themselves via SIP/IP for years now as have US mobile operators. It's the copperhead land line operators that have resisted the move. Michel. ___ 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: The US Federal Communications Commission just sent the IETF RAI/SIPcommunity an early Christmas present...
I read it If you don't play nice .. we're going to make you. You are going to eat your Broccoli and like it and no whining .. From: George Willingmyre [mailto:g...@gtwassociates.com] Sent: Wednesday, November 02, 2011 11:01 PM To: Richard Shockey; 'IETF-Discussion list' Subject: Re: The US Federal Communications Commission just sent the IETF RAI/SIPcommunity an early Christmas present... Thanks for sharing this important development Richard. I do not know what is the meaning of the sentence, we expect all carriers to negotiate in good faith in response to requests for IP-to-IP interconnection for the exchange of voice traffic. Does anyone have insight? George T. Willingmyre, P.E. President, GTW Associates Spencerville, MD USA 20868 301.421.4138 www.gtwassociates.com - Original Message - From: Richard Shockey mailto:rich...@shockey.us To: 'IETF-Discussion list' mailto:ietf@ietf.org Sent: Wednesday, November 02, 2011 7:06 PM Subject: The US Federal Communications Commission just sent the IETF RAI/SIPcommunity an early Christmas present... Folks it was suggested that I resend this message from the RAI list to the Full Dispatch list but what the heck ... the IETF community needs to see this. What you see here is a very significant policy direction from the US Federal Communications Commission to the IETF/SIP/RAI community. Mandatory IP interconnection between carriers for E.164 named Voice. In addition there are clauses that mandate non modification of the calling parties E.164 number in the headers. This should come as no surprise to anyone. Our international carrier partners at i3Forum.org have been preaching this for some time. From the FCC executive summary of the Report and Order. 26. IP-to-IP Interconnection. We recognize the importance of interconnection to competition and the associated consumer benefits. We anticipate that the reforms we adopt will further promote the deployment and use of IP networks, and seek comment in the accompanying FNPRM regarding the policy framework for IP-to-IP interconnection. We also make clear that even while our FNPRM is pending, we expect all carriers to negotiate in good faith in response to requests for IP-to-IP interconnection for the exchange of voice traffic. http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1027/DOC-3106 92A1.pdf http://www.snrdenton.com/news__insights/alerts/2011-10-28_overhaul.aspx http://www.dwt.com/LearningCenter/Advisories?find=441777 I wish to make it clear that I'm personally willing to privately discuss with the technical community how we can transition our industry to the all SIP network. If you want to speculate on how you translate a E.164 number to a point of interconnection ..you can, but RFC 6116 is not a bad starting point though Global SPID identifiers would work. ( I gladly gave up my blue dot recently) We won! Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.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: The US Federal Communications Commission just sent the IETF RAI/SIPcommunity an early Christmas present...
Richard Shockey rich...@shockey.us wrote: From: George Willingmyre [mailto:g...@gtwassociates.com] I do not know what is the meaning of the sentence, we expect all carriers to negotiate in good faith in response to requests for IP-to-IP interconnection for the exchange of voice traffic. Does anyone have insight? I read it If you don't play nice .. we're going to make you. You are going to eat your Broccoli and like it and no whining .. Hopefully someone better informed than I will respond, but I have dealt in FCC-speak... :^( IMHO, they're talking obligation to interconnect between carriers as required by actual law. [RS ] In FCC terms this is Section 251 of the US Communications Act which the call must go through mandatory interconnection. interconnect in FCC-speak means exchange voice traffic at a feasible point. Carriers means a regulated voice provider. [RS ] Yea now we need to find out what is feasible IP interconnection. Welcome to DC! Thus, they mean to expect these regulated entities to negotiate a point of interconnection where they speak IP instead of e.g. SONET. [RS ] SIP-I IMHO but that has yet to be determined and will be the subject of lots of proceedings. And, yes, they will (eventually) force them to interconnect (using IP) whether or not the negotiations succeed. Speaking only for myself, I don't read it to impose anything except on regulated carriers, and they're opening up themselves to forcing a particular mechanism and point of connection when negotiation fails. [RS ] E.164 named traffic is the clear focus. The FCC Pulver order for OTT voice seems to be excluded. We'll see when the final Order is published but it's pretty clear that this is not just a US issue but will ultimately resonate in Canada and EC as well. This, of course, creates an opportunity to educate FCC folks on the actual technical issues of voice interchange at IP level... [RS ] I'm happy to point out how you all can file ex parte statements to the Commission. I'm sure they would be delighted to hear from the technical community. http://www.fcc.gov/topic/ex-parte When the final Order is released ..have a ball. Its easy its fun .. -- John Leslie j...@jlc.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
The US Federal Communications Commission just sent the IETF RAI/SIP community an early Christmas present...
Folks it was suggested that I resend this message from the RAI list to the Full Dispatch list but what the heck ... the IETF community needs to see this. What you see here is a very significant policy direction from the US Federal Communications Commission to the IETF/SIP/RAI community. Mandatory IP interconnection between carriers for E.164 named Voice. In addition there are clauses that mandate non modification of the calling parties E.164 number in the headers. This should come as no surprise to anyone. Our international carrier partners at i3Forum.org have been preaching this for some time. From the FCC executive summary of the Report and Order. 26. IP-to-IP Interconnection. We recognize the importance of interconnection to competition and the associated consumer benefits. We anticipate that the reforms we adopt will further promote the deployment and use of IP networks, and seek comment in the accompanying FNPRM regarding the policy framework for IP-to-IP interconnection. We also make clear that even while our FNPRM is pending, we expect all carriers to negotiate in good faith in response to requests for IP-to-IP interconnection for the exchange of voice traffic. http://transition.fcc.gov/Daily_Releases/Daily_Business/2011/db1027/DOC-3106 92A1.pdf http://www.snrdenton.com/news__insights/alerts/2011-10-28_overhaul.aspx http://www.dwt.com/LearningCenter/Advisories?find=441777 I wish to make it clear that I'm personally willing to privately discuss with the technical community how we can transition our industry to the all SIP network. If you want to speculate on how you translate a E.164 number to a point of interconnection ..you can, but RFC 6116 is not a bad starting point though Global SPID identifiers would work. ( I gladly gave up my blue dot recently) We won! Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: A modest proposal for Friday meeting schedule
+1 to that as well ..an excellent proposal. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Eric Burger Sent: Sunday, July 31, 2011 11:48 AM To: Hadriel Kaplan Cc: IETF-Discussion list Subject: Re: A modest proposal for Friday meeting schedule I don't think I have seen a proposal like this before. I really like it, as there are a bunch of post-IETF stuff, some of which starts in the afternoon and thus conflicts with the IETF. This fixes that problem, enables us to have the same amount of meeting time, and potentially lets people get home a day early. On Jul 31, 2011, at 11:40 AM, Hadriel Kaplan wrote: Howdy, First I'd like to thank the organizers for IETF-81 for another well-run meeting. The logistics and coordination for such an event must be daunting, and I know we (the attendees) tend to focus on the negatives rather than the positives... but we really are thankful for all the time and effort put into it. Thank you! I would also like to propose a small change for future meetings. On Friday, instead of having a 2.5 hour WG meeting, followed by a 1.5 hour lunch break, followed by 2 hours of WG meetings... perhaps we could just have 4.5 hours of WG meetings straight and also start a bit earlier? Something like this: 8:30-11:00 Session I 11:15-12:15 Session II 12:30-13:30 Session III End That way the people who need to get to an airport get more time, or fewer of them have to miss WG meetings, etc. And it would help reduce costs for attendees if they can avoid staying Friday night at the hotel. And lunch at 13:30 doesn't seem unreasonable (to me). I apologize if this has been brought up before. I tried to find it from an old email thread for the Experiment at IETF-73 which added the Friday afternoon sessions, but did not see this proposal being suggested. -hadriel ___ 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: Review of: draft-ietf-iab-draft-iab-dns-applications-02
I would like to add my support here to Dave Crocker's very thoughtful and IMHO accurate description of this revised draft. I share his views that the substantive criticisms have not been addressed. What exactly is the harm that this draft proposes to prevent? I can certainly understand the natural reluctance to continue to pile on to the DNS various data attributes but its should be clear that that this cat has been out of the bag for some time. Clearly we do not want the DNS to be used for search like functions where there may be a indeterminate response but the examples cited do not address those issues. I am baffled by the ongoing criticism RFC 6116 and the desire of some members of the community to extend 6116 to values that may not necessarily be defined as a URI. ENUM works and works quite well in both e164.arpa and in private instantiations. Frankly I think this draft needs to be completely withdrawn. If there are issues with new uses of the DNS, DNSEXT or DNSOPS are fully chartered to provide community review and do not need any fuzzy guidance on what is and is not acceptable. This entire draft could beeasily simplified byt a one sentence statement. If you need to do database look ups in the future we would prefer that you think of using protocols other than the DNS. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Dave CROCKER Sent: Thursday, July 21, 2011 6:41 AM To: IETF Discussion Subject: Review of: draft-ietf-iab-draft-iab-dns-applications-02 This is a summary of a followup review of the draft, after the one noted in Ticket #35 of the trac wiki for this draft: http://trac.tools.ietf.org/group/iab/trac/ticket/35 The complete version of this second review is at: http://trac.tools.ietf.org/group/iab/trac/ticket/35#comment:2 Summary: The latest version of the draft contains many substantial changes. However it continues to have basic problems with direction, scope, detail, writing, and with basic confusion about architecture. The draft maintains its claim of being a general considerations discussion when, in fact, it continues to focus on fear of inappropriate proposals. It continues to invoke examples of inappropriate proposals that lack constituency or even currency. In spite of language claiming to distinguish new /uses/ of the DNS from /changes/ to the DNS, the draft continues to confuse the two. The problem appears to be a difficulty distinguishing architectural layers. This is like saying that TCP changes IP or that HTTP changes TCP. Hence, for example, DDDS is a layer /above/ the DNS. The only two interesting questions about a client layer's use of a provider layer -- such as DDDS's use of DNS -- is whether the functional match is acceptable and whether it's performance demands cause problems. When focused on one layer, any further discussion of the other likely to confuse things significantly, as demonstrated in the draft. The paper continues to make broad criticisms that lack foundation and sometimes even lack citation. Some of the statements and logic sequences were entirely opaque to me. I could not decipher what they meant. In some cases the apparent meaning was factually incorrect or confused. From all of this, I suspect that the only way to make useful progress is to start over, and to begin with a much, much more clear and concrete statement of the goal for the draft and then a very diligent effort to organize the paper's sequence and carefully document its assertions. 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: PAWS BOF @IETF80 IMPORTANT .. Very Important.
I want to offer my personal support for this BOF and encourage all members of the IETF community to read the appropriate documents listed BEFORE attending the BOF. The BOF has only 1 hour of time on Monday. IMHO this is perhaps the most important BOF that will occur in Prague and its implications in expanding the availability of IP access is breathtaking and global in scope. It's a good thing tm. What is being discussed is an key protocol that could expand the use of both unlicensed and licensed spectrum far beyond anything we have previously known. We are all the beneficiaries of the extraordinary work that was done in the past to create national regulatory rules, such as the US FCC Part 15 Rules, that opened up the 2.4 MHz band to unlicensed devices. That effort created the preconditions for WIFI. The United States Federal Communications Commission, to its eternal credit, has developed a formal policy and rules that would allow unlicensed devices to use portions of the 700 MHz bands for various purposes. The 700 band is now used in some jurisdictions for broadcast digital television. Its propagation characteristics are outstanding. In order for this spectrum to be utilized the FCC has required that devices that wish to use the White Spaces in the digital television bands access a database first in order to download a profile of what permissible channels can be used. The PAWS BOF seeks to define the protocols for accessing these databases. This concept is under active consideration in many other national jurisdictions including Finland, United Kingdom and several countries in Asia. Many remote and rural areas on the planet are ill served for IP communications. This technology could expand IP access into areas that are economically impossible to reach via traditional landline or wireless communications technology. In addition the US FCC has speculated that if this White Space Database concept is successful it could be expanded into virtually the entire available RF Spectrum. The IETF is uniquely qualified to undertake this work. We have a long and successful record in developing protocols for Registry/Registrar/Registrant applications. Obviously there will be a need for close coordination with several IEEE 802 committees. I hope the BOF room is big enough. From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of gabor.ba...@nokia.com Sent: Wednesday, March 16, 2011 10:08 PM To: ietf@ietf.org Subject: PAWS BOF @IETF80 Folks, There will be a BOF on protocols to access white space databases at IETF80, on Monday March 28th at 15:10. If you are interested and plan to come, please read the following docs before the BOF: Problem statement: http://www.ietf.org/id/draft-patil-paws-problem-stmt-01.txt Use case scenarios: http://www.ietf.org/id/draft-probasco-paws-overview-usecases-00.txt The agenda of the BOF: 1. Overview and background of White space technology (15 Mins) 2. Database architecture (10 Mins) 3. Proposed charter and the work to be done in IETF (10 Mins) 4. Open discussion (20) 5. Conclusion (Show of hands/Hum) -Gabor ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
It is my understanding that there may some major revisions to the XML2RFC tools forthcoming
May I make a minor suggestion. I know its not spring and the daffodils are not in bloom but it might be nice if a possible output file for the XML2RFC tools were in .epub as well as .pdf Thank you for your attention. No need to flame. We will now return you to your regularly schedule program. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Win a free trip to Washington DC and the FCC.
The FCC challenges researchers and software developers to engage in research and create apps that help consumers foster, measure, and protect Internet openness. http://challenge.gov/FCC/114-fcc-open-internet-apps-challenge Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype-linkedin-facebook: rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Travel Tips for leaving or entering the US.
http://bostonherald.com/business/general/view.bg?articleid=1291536 National rollout of invasive pat-downs this week Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-iab-dns-applications - clarification re: Send-N
Because. Its not declining or disappearing .. just ask the mobile operators who have added several billion new mobile handsets over the past few years. Analog POTS is certainly dying but the E.164 namespace is doing even better than domain names. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Masataka Ohta Sent: Thursday, October 21, 2010 1:14 AM To: David Conrad Cc: ietf@ietf.org Subject: Re: draft-iab-dns-applications - clarification re: Send-N David Conrad wrote: In the intervening decades, it is probably worthwhile dealing with the reality that PSTN (and hence E.164) exists. But, why do we have to be bothered by proposals for more efficient processing of the declining and disappearing E.164? Masataka Ohta ___ 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-iab-dns-applications - clarification re: Send-N
And finally, regarding: It is unclear why this data is better maintained by the DNS than in an unrelated application protocol. If a device is performing an ENUM dip hoping to find a contactable SIP URI, it is simply most efficient for the ENUM response to directly include the Send-N metadata when needed rather than have separate queries using a different network protocol. Also, the hierarchical and distributed nature of the DNS protocol makes it an _ideal_ structural fit for this meta data. I believe the onus should be on your draft to explicitly identify valid technical reasons why the DNS protocol should _not_ be used, rather than make vague hand-waving assertions which appear to have little or no justification. RS Precisely, What is unclear is why the IETF and the IAB is suddenly trying to block a perfectly legitimate extension of RFC 3761 that is in various forms of global deployment, proven to work, scale and more importantly provides a valuable and essential function in the transition from analog POTS to SIP based communication. Just saying no is not a solution to the real issues of number translation in carrier networks. Ok a lot of people hate phone numbers including, it seems, 50% of RAI directorate but they are not going away anytime soon. So just say it .. is this the message? Don't even try to charter E2MD? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-iab-dns-applications - clarification re: Send-N
Well Bill with due respect, the data that most of us would like to use for this class of application is very static and its sources are very authoritative. That which is somewhat volatile is easy to sync such as Local Number Portability data or line status. There is a staggering amount of data in the field that Infrastructure oriented ENUM works and works well in the field. Speed and scale were the keys and the desire NOT to have another protocol stack in mission critical network elements such as the CSCF or SBC at the edge of the SIP/IMS networks. But the larger issue is this. When the ENUM WG was rechartered it was explicit that this class of application was in scope. Now for some inexplicable reason its out of scope. I want to know why. 3. The working group will continue examine and document various aspects of ENUM administrative and /or operational procedures irrespective of whether e164.arpa domain is used. 4. The working group will also examine the use of RFC 3761 technology for storing and delivering other information about services addressed by E.164 numbers, for example PSTN call routing and signaling data. As a practical matter the horse has left the barn, mated, now has several foals. This document is a terrible attempt at an ex post facto architectural decision that is significantly damaging to those of us who want to make things in SIP work better. As a practical matter I want to know are all of these proposals for PSTN metadata, trunk group, SPID, source URI etc are now out of scope for IETF standardization. Even as private deployments? If so than the IESG and the IAB should say so explicitly now and not waste our time in Prague on a BOF that will never be chartered. I personally find section 5.1 unusually amusing as if now the IAB wants to say split-DNS should be considered harmful. Leakage in to the public DNS .. geez really. Like what where are the examples of the harm? So who put ringtones in the DNS :-) -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of bill manning Sent: Wednesday, October 20, 2010 3:43 PM To: Richard Shockey Cc: 'Ray Bellis'; draft-iab-dns-applicati...@tools.ietf.org; ietf@ietf.org Subject: Re: draft-iab-dns-applications - clarification re: Send-N while I agree that the hierarchical and distributed nature of the DNS is a scintillating, shimmering attractant, it is wise to be aware of the baseline assumption in your arguement, e.g. that a client will -ALWAYS- ask an authoritative source... The DNS is so designed that caching is a huge component of the scalability of the DNS... and its greatest hinderance for such ideas as are laid out in the ENUM dip lookup.You can't be assured that the data is timely. This is a strong reason to consider that the DNS is _NOT_ the droid you are looking for, in spite of its other attractive qualities. just my 0.02 lira. --bill On 20October2010Wednesday, at 12:25, Richard Shockey wrote: And finally, regarding: It is unclear why this data is better maintained by the DNS than in an unrelated application protocol. If a device is performing an ENUM dip hoping to find a contactable SIP URI, it is simply most efficient for the ENUM response to directly include the Send-N metadata when needed rather than have separate queries using a different network protocol. Also, the hierarchical and distributed nature of the DNS protocol makes it an _ideal_ structural fit for this meta data. I believe the onus should be on your draft to explicitly identify valid technical reasons why the DNS protocol should _not_ be used, rather than make vague hand-waving assertions which appear to have little or no justification. RS Precisely, What is unclear is why the IETF and the IAB is suddenly trying to block a perfectly legitimate extension of RFC 3761 that is in various forms of global deployment, proven to work, scale and more importantly provides a valuable and essential function in the transition from analog POTS to SIP based communication. Just saying no is not a solution to the real issues of number translation in carrier networks. Ok a lot of people hate phone numbers including, it seems, 50% of RAI directorate but they are not going away anytime soon. So just say it .. is this the message? Don't even try to charter E2MD? ___ 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: draft-iab-dns-applications - clarification re: Send-N
So what is your point ..you don't use phone numbers so the rest of the planet shouldn't? From: Phillip Hallam-Baker [mailto:hal...@gmail.com] Sent: Wednesday, October 20, 2010 4:42 PM To: Paul Hoffman Cc: bill manning; Richard Shockey; Ray Bellis; draft-iab-dns-applicati...@tools.ietf.org; ietf@ietf.org Subject: Re: draft-iab-dns-applications - clarification re: Send-N I don't much see the issue here. Looking at my ATT records, I have made about 1000 iphone calls in the past year. Of those less than 50 are to numbers not in my contacts and I probably dialed half of those using Safari. Telephone numbers are not going away, but telephone dialing is already a necessary legacy thing more than a current requirement. At this point I don't think that there are any telephone numbers I dial from memory. I think that the underlying problem here is that the crappy POTS handsets on sale today do not interface to Internet telephony systems well. This whole problem would go away if Cisco and the other makers of VOIP bridges worked out that the real market requirement here is for a box that plugs into an ethernet port and connects to DECT6.0 telephones rather than a box that plugs into an ethernet port and has telephone wires sticking out the back. That way the VOIP system knows how long the telephone number from the phone book entry. Your basic problem here is that you are losing this information by converting all your data to the obsolete POTS wire format and back. Anyone who wants to do that should further realize that what they need to do is to allow for multiple boxes on the same VOIP connection in a secure fashion. DECT6.0 does not have the range to cover some houses and for some reason the pinheads that designed it seem to think that 6 phones is enough for one house. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-iab-dns-applications - clarification re: Send-N
This document is a terrible attempt at an ex post facto architectural decision that is significantly damaging to those of us who want to make things in SIP work better. As a practical matter I want to know are all of these proposals for PSTN metadata, trunk group, SPID, source URI etc are now out of scope for IETF standardization. Even as private deployments? If so than the IESG and the IAB should say so explicitly now and not waste our time in Prague on a BOF that will never be chartered. well... if its done faster/better outside the IETF by an industry group... Well if that is the preference of the IAB and the IESG then so be it. What we need now is clarity on the architectural status for this class of application drafts etc and this document is not providing it. After almost 4 years of ongoing discussion on how to deal with this data in a IP context now we have this Well guys maybe this isn't such a good idea. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The Evils of Informational RFC's
And add to that one that Mr Burger should vaguely recall :-) http://www.rfc-editor.org/rfc/rfc3482.txt Number Portability in the Global Switched Telephone Network (GSTN): An Overview -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Fred Baker Sent: Wednesday, September 08, 2010 9:49 PM To: Eric Burger Cc: IETF Discussion Subject: Re: The Evils of Informational RFC's Please, no. The RFC Series is not a collection of standards. It is community memory, and in it we have white papers that have been seminal such as RFC 970, problem statements, requirements documents, and analyses of a wide variety, all of which are informational. Let me give you two specific examples: http://www.ietf.org/rfc/rfc2804.txt 2804 IETF Policy on Wiretapping. IAB, IESG. May 2000. (Format: TXT=18934 bytes) (Status: INFORMATIONAL) http://www.ietf.org/rfc/rfc3924.txt 3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker, B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes) (Status: INFORMATIONAL) The former gives a view on the topic of lawful interception, and requests that anyone that develops an interception technology publish it so that it can be reviewed openly within the community. The latter does exactly that. The collected experience in the RFC series is at least as valuable as the protocol descriptions in it. On Sep 9, 2010, at 12:03 AM, Eric Burger wrote: Can we please, please, please kill Informational RFC's? Pre-WWW, having publicly available documentation of hard-to-get proprietary protocols was certainly useful. However, in today's environment of thousands of Internet-connected publication venues, why would we possibly ask ourselves to shoot ourselves in the foot by continuing the practice of Informational RFC publication? On Sep 3, 2010, at 7:48 PM, Richard Bennett wrote: With respect, Brian, I don't think this is simply the failure of journalists to discern the distinction between Informational RFCs and Standards Track RFCs. Nobody has made the claim that the IETF produced a standard for accounting and billing for QoS or anything else. Informational RFCs are a perfectly fine record of what certain people in the IETF community may be envisioning at a given time, as long as people understand that envisioning is not the same as requiring, which is basic English literacy. ___ 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: My comments to the press about RFC 2474
sigh Enough.. can we go back to travel tips now? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Richard Bennett Sent: Saturday, September 04, 2010 6:02 PM To: Livingood, Jason Cc: ietf@ietf.org Subject: Re: My comments to the press about RFC 2474 It seems to me that Russ should have said something like this: IETF develops technical standards. Our DiffServ standard enables applications to communicate their requirements for specialized treatment to edge networks and for networks to aggregate packets requiring similar treatment at network-to-network boundaries. We've generally expected that specialized treatment will be coupled by network operators with charging plans, but we're not in the business of standardizing business models. ATT's interpretation of the early DiffServ RFCs is fundamentally correct - closer to correct than the Free Press interpretation - but those documents are what we call Informational RFCs and not Standards. Informational RFCs reflect the views of the authors and not any broader consensus within IETF. IETF neither supports nor opposes differential charging for differential treatment of traffic flows. We deal with technical issues, not business models. The statement that he did make: This characterization of the IETF standard and the use of the term 'paid prioritization' by ATT is misleading is itself misleading and implies, to those familiar with the context of ATT remarks as a response to claims made by Free Press, that Russ the IETF support the Free Press side of the debate between these two parties. Check the headline: IETF: ATT's Net neutrality claim is 'misleading'. Does that make IETFers comfortable? If IETF wants to walk the fine line between the sides in the regulatory debate, which will have technical implications before it's over, it needs to communicate a lot more clearly with the press than it has. RB On 9/4/2010 10:00 AM, Livingood, Jason wrote: He's not saying that. He's effectively saying what I'm saying: payment models are outside the scope of the standards, which don't require any particular payment model in order to perform their job. +1 to that. It seems the press struggles to understand that the IETF does technical standards and not business models. - Jason ___ 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: My comments to the press about RFC 2474
LTE for a start.. From: ietf-boun...@ietf.org [ietf-boun...@ietf.org] On Behalf Of Ofer Inbar [...@a.org] P.S. My neighborhood is about as far from being a tech backwater as it is possible to be in the world. Yet I still have only one viable option for high speed Internet. It's a business law problem, not a technology problem. ___ It's a traditional monopoly problem. Market-based mechanisms don't work if there isn't vigorous competition. The traditional solution is common carrier regulation of natural monopolies. At the least, we need to define data carriage as a common carrier business, where the carrier must provide service on a non-discriminatory basis at published rates. (Whatever happened to the dream of multiple WiMax providers?) Dale ___ 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: My comments to the press about RFC 2474
Well first .. I do want to congratulate Russ for actually injecting a bit of sanity into the ongoing NN debate and I think we all know he was speaking as a individual. I'm personally +1 on his comments. The problem we collectively have is that there is very little or no technical clue in the NN discussion, a problem some of us that inhabit the orbit of the 495 DC beltway see quite often. Brian is equally correct in noting that being quoted out of context is par for the course in DC circles, however it is vitally important that those of us who can, point out to our National Regulatory Authorities the reality of how the Internet actually operates and what we are doing to address ongoing issues of network management and congestion control. This is extremely important in the ongoing discussions among NRA's on how to transition classic PSTN and Emergency services from Analog POTS to a IP world, something the IETF is technically involved with on multiple levels. http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-09-2517A1.pdf Silence is not a option. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Russ Housley Sent: Thursday, September 02, 2010 1:48 PM To: IETF Subject: My comments to the press about RFC 2474 I want the whole community to be aware of the comments that I made to the press yesterday. Clearly, these comments do not represent IETF consensus in any way. They are my opinion, and the reporter was told to express them as my opinion. One thing that I said was not captured quite right. The article says: With services that require certain speeds to operate smoothly, such as Internet telephony, calls are given precedence over TV, Housley said. I actually said that DiffServ can be used to make sure that traffic associated with applications that require timely delivery, like voice and video, to give preference over traffic associated with applications without those demands, like email. The whole article is copied below, and it is online here: http://www.nationaljournal.com/njonline/tc_20100902_7144.php Russ = How Neutral Is The Internet?: Existing Limits Are In The Spotlight As ATT And A Consumer Advocacy Group Squabble Over Net Traffic by Eliza Krigman Thursday, Sept. 2, 2010 Whether the Internet is truly a democratic forum was called into question this week in a dispute about Internet traffic management between ATT and the consumer advocacy group Free Press. The feud boiled down to what it means to have paid prioritization, a phenomenon viewed as anathema by advocates of Internet openness, and to what extent preferential treatment of content already takes place. The issue is at the very heart of a broader debate about what regulatory steps are necessary, if any, to ensure the Internet remains an engine of economic growth and a platform of equal value to people across the socioeconomic spectrum. ATT, in a letter filed with the Federal Communications Commission on Monday, argued that paid prioritization of Internet traffic, contrary to claims made by Free Press, is already a common practice of Web management and consistent with protocols set by the Internet Engineering Task Force. Largely unknown to people outside the technology field, IETF is a professional organization composed of engineers that develop standards for the Internet; for over two decades, it has played an integral role in the management of the Internet. The current chair of the IETF, Russ Housley, disagrees with ATT's assessment. ATT's characterization is misleading, Housley said. IETF prioritization technology is geared toward letting network users indicate how they want network providers to handle their traffic, and there is no implication in the IETF about payment based on any prioritization. Dedicated lines of service, according to ATT, are examples of current paid prioritization schemes, a concept Free Press flatly disagrees with. ATT constructed bogus interpretations of 'paid prioritization' that reflect no arguments or statements made by the FCC or any proponents of net neutrality, said S. Derek Turner, research director of Free Press. The group calls paid prioritization an anti-consumer practice where third-party content owners can pay an Internet service provider to cut to the front of the line in Web traffic. It's a practice that would lead to a pay-to-play scenario where only big business could afford the premium channels needed to compete, net neutrality advocates say, thereby squeezing the little guys out of the market. But ATT dismisses those assertions, saying Free Press' acceptance of dedicated lines of service as a management practice is hypocritical given its stance against paid prioritization. We understand why Free Press is upset with our letter, said Michael Balmoris, spokesman for ATT. We outed them by shedding light on their inconsistencies. After all, for years Free Press has used empty rhetoric and faux-technical mumbo jumbo
RE: [dispatch] VIPR - proposed charter version 3
Paul of course I've read them, though the PVP document is uniquely dense and gave me a headache. Security by ID Obscurity. My assertion still stands. In the absence of any linkage in the PVP to the E164 numbering authorities and or databases any assertion about verification and validation of a E.164 is in essence self validation. The charter does NOT state that. My point is the proposed charter is badly written and implies a trust model that does not exist. I guess your no-SS7 hat doesn't fit anymore? RS Well I have to swap it from time to time with my NO PRI hat. I'm still trying to kill it off SS7 if someone will let me put metadata in ENUM databases. :-) That trust model which does not exist is exactly the trust model that we all use, daily, whenever we dial the pizza joint across the street, the paint contractor with the spiffy one-page advertisement in the yellow pages, pay FedEx or the postal service to deliver a package, or pay a shipper to send a crate full of Champagne from France to some other country, or call the Sears Roebuck catalog number give them our credit card and expect them to use a shipper (FedEx/postal service/UPS/DHL) to send us the product. RS There is a reasonable trust model in the PSTN that relies on several factors ..first the regulatory structure that says you will route e164 transactions by law if you are a licenced carrier and access to the root numbering structures and databases which in North America are the LERG and the NPAC GTT etc. You can determine who is the responsible carrier of record for nearly any E.164 number out there. You just have real trouble determining who was issued that number. I agree that trust model is imperfect. But that trust model is what delivers almost all of the commerce and business in the world. To assert that this trust model does not exist is a false assertion. RS You cannot authoritatively determine a binding between a phone number and a consumer (domain) without access to the databases. You make a phone call if it answers and you hopefully get a caller ID that hasn't been spoofed then maybe you are OK and maybe you hope the TTL is set to some interval that doesn't cause number hijacking. But gee what happens when the number is disconnected from the PSTN? Hu Similar disconnections (and resales) of telephone numbers happen, today, on the PSTN. I dial a restaurant (now out of business) which has taken over the same physical location (oh my gosh, Identity Thieves!) and paid to acquire the previous restaurant's phone number. Other, non-restaurant businesses do similar things. SBC bought the assets of ATT including its brand name, doing something similar with the att.com domain itself and, I'm sure, with its 800 services. But the routing data aka the DPC's were updated to reflect those transactions. So, it's not as if querying SS7 would provide some magic sauce to prevent the problem. The problem is different, to be sure, just as IP addresses, domain names, physical (street) addresses, email addresses, telephone numbers, are not all quite exactly the same. But each is considered an identity to a varying degree. The use of the term validation and or verification here implies authentication and my assertion is that any authentication of the responsible domain for a E.164 number outside of the PSTN service provider or national numbering authority is not possible under the current regulatory circumstances. Consequently the charter implies an ability to develop a solution which we all know is impossible. I disagree. Solution rewrite the charter to note that fact that this is, in fact, best efforts only, full disclosure or caveat emptor to be precise. Once I know someone owned an E.164 and I can, afterwards, do crypto to ensure I know I'm talking to the same entity -- that is *far* more reliable than what occurs, today, on the PSTN. The PSTN where phone numbers are bought and sold willy-nilly. RS for the 352nd time you don't own E.164 numbers. They are not property by treaty. RS Well this could go on forever. My point is still that the charter as written implies a service level and trust binding that unrealistic and what is proposed is essentially a best efforts service. Ok there is nothing wrong with that. TCP? The underlying DHT technology here has been demonstrated to work in the past but to imply that ViPR is some way cool new new thing I'm going to rely on just because it made a successful PSTN call with a ill determined TTL binding .. please. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [dispatch] VIPR - Speaking of Video Calls ..
Speaking of ad-hoc video calls. Side bar issue.. Has anyone figured out who to talk to at Apple about FaceTime? Granted Apple has had a few issues to deal with recently but the silence on how they plan to publish their profile is deafening. I call Steve's office if I have to ..but From: Peter Musgrave [mailto:peter.musgr...@magorcorp.com] Sent: Tuesday, July 06, 2010 8:21 AM To: Richard Shockey Cc: Lawrence Conroy; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi, From my perspective what this is really about is the ability for me to have interoperable ad-hoc video calls between businesses which can be established via SIP with a good enough level of authentication and security. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [dispatch] VIPR - proposed charter version 3
I don't make that assumption at all. ENUM cannot be used to establish any authoritative mapping of E.164 to domain. I fought that war for 10 years and lost thank you. In addition I reject the assertion in the proposed charter that private federations don't scale. In fact they do and are widely deployed among service providers who in fact self assert their authority over TN's based on their own knowledge of what TN's they are authoritative for and have access to the underlying national telephone numbering databases and signaling mechanism. The charter does not make any mention of Local Number Portability at all. This discussion of running code is irrelevant here and has zero merit in this discussion. In fact a more simplistic approach to the problem statement was developed by Asterisk years ago called DUNDI and though I haven't spoken to Mark Spencer and company in several years about this subject, I don't believe it deployed in any significant way. It's a form of DHT among trusted peers with self validation of the underlying TN's. It works. Fine. That is a private protocol deployed among private Asterisk deployments. There is a ID lying around somewhere. My assertion still holds. Without meaningful cooperation of national numbering authorities it is impossible to establish a chain of trust that can reliably determine the domain of authority for a E.164 number especially in conditions where the number is either disconnected or potentially ported. The validation scheme proposed is essentially it can successfully make a PSTN call. Wow I'm impressed! Then what? My assertion is that the charter has to reflect that there is no reliable chain of trust or validation model for E.164 numbers and consequently assertion of E.164 numbers by domains relies on self validation. The central thesis of this proposed charter is false, that you can authoratively validate a mapping between E.164 and a domain. You want to call this SELF-verification involving PSTN reachability fine. Then you would have a honest statement of what you propose to develop. This is about truth in protocol development tm. From: Peter Musgrave [mailto:peter.musgr...@magorcorp.com] Sent: Monday, July 05, 2010 9:15 AM To: Richard Shockey Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi, I think the charter issue here is an assumption that number ownership is established using ENUM. I agree with you comments about chains of trust, certs etc. and that this is likely impossible but they are not the mechanism being proposed in the charter. It states: Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. An approach which is given as a sample solution is in the vipr-overview doc. The fact that there is running code shows the solution has some merit. Can you please clarify what part of this approach you view as impossible? Thanks, Peter Musgrave On Sun, Jul 4, 2010 at 4:48 PM, Richard Shockey rich...@shockey.us wrote: Well folks can certainly do what they want to do. And the IETF has a lamentable record of some protocols that don't accomplish much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify or authenticate the responsible party for a E.164 number. It is incapable of doing so since there is no possible administrative chain of trust other than self assertion . Hence the possibility of identity or number/session hijacking is very large. You have to have the cooperation of the national numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn't change that problem either. This has been a well known problem in SIP for some time and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however in private trees BTW. Consequently I think this issue has to be fully defined in the charter and I will gleefully anticipate what the security considerations text will look like. The fact that there is CISCO running code is utterly irrelevant. There is lots of bad code out there. I understand the problem of how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to fail. I do understand that many folks don't like their voice
RE: [dispatch] VIPR - proposed charter version 3
Paul of course I've read them, though the PVP document is uniquely dense and gave me a headache. Security by ID Obscurity. My assertion still stands. In the absence of any linkage in the PVP to the E164 numbering authorities and or databases any assertion about verification and validation of a E.164 is in essence self validation. The charter does NOT state that. My point is the proposed charter is badly written and implies a trust model that does not exist. You make a phone call if it answers and you hopefully get a caller ID that hasn't been spoofed then maybe you are OK and maybe you hope the TTL is set to some interval that doesn't cause number hijacking. But gee what happens when the number is disconnected from the PSTN? Hu The use of the term validation and or verification here implies authentication and my assertion is that any authentication of the responsible domain for a E.164 number outside of the PSTN service provider or national numbering authority is not possible under the current regulatory circumstances. Consequently the charter implies an ability to develop a solution which we all know is impossible. Solution rewrite the charter to note that fact that this is, in fact, best efforts only, full disclosure or caveat emptor to be precise. I'm not saying it might not work. As I used to tell Mark Spencer about DUNDI it's a fine intra-domain PBX session routing protocol. Might work in some highly integrated industries like airlines, auto etc but the empirical evidence indicates a uphill battle. -Original Message- From: Paul Kyzivat [mailto:pkyzi...@cisco.com] Sent: Monday, July 05, 2010 1:43 PM To: Richard Shockey Cc: 'Peter Musgrave'; 'DISPATCH'; 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 Richard, Have you actually read and understood the drafts that Jonathan submitted on ViPR? I don't see how you could make the assertions you are making if you had. Thanks, Paul Richard Shockey wrote: Well folks can certainly do what they want to do. And the IETF has a lamentable record of some protocols that don't accomplish much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify or authenticate the responsible party for a E.164 number. It is incapable of doing so since there is no possible administrative chain of trust other than self assertion . Hence the possibility of identity or number/session hijacking is very large. You have to have the cooperation of the national numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn't change that problem either. This has been a well known problem in SIP for some time and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however in private trees BTW. Consequently I think this issue has to be fully defined in the charter and I will gleefully anticipate what the security considerations text will look like. The fact that there is CISCO running code is utterly irrelevant. There is lots of bad code out there. I understand the problem of how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to fail. I do understand that many folks don't like their voice service providers or PSTN that perpetuates the use of E.164 numbers but this proposal is not going to solve that. IMHO in the absence of any rational trust or security model you can certainly publish something as Informational but getting something past the IESG is another thing entirely. *From:* Peter Musgrave [mailto:peter.musgr...@magorcorp.com] *Sent:* Saturday, July 03, 2010 5:49 PM *To:* Richard Shockey *Cc:* Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list *Subject:* Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, Clearly we don't want to be trying to solve the impossible - that could take a really long time. The mechanism in the ViPR drafts seemed to be able to accomplish the finding the party responsible for a number - and IIRC this is based on *running code* in the Cisco IME. ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it. Peter Musgrave On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey rich...@shockey.us mailto:rich...@shockey.us wrote: A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed. IMHO this charter is a non starter and should not be approved on the basis of this statement alone. finding domains that claim to be responsible for a given phone number This IMHO
RE: [dispatch] VIPR - proposed charter version 3
Thank you Brother Conroy... this is a full IETF discussion since it does involve the creation of a new working group that does not seem to understand what is actually involved in E.164 validation. I do understand what this is really about..how do we screw global voice service providers since the IETF has not been able to convince normal folk to use SIP URI's. A reasonable objective, but I haven't seen many SIP URI on the back of plumbing or tree conservation trucks driving down my Reston VA neighborhoods recently. HTTP URI's are another thing. The real ultimate question is, can we, the SIP community, possibly learn to live with E.164 in SIP in some rational manner? Phone numbers are not going to go away as much as my dear friend Henry Sinnreich would prefer. -Original Message- From: Lawrence Conroy [mailto:lcon...@insensate.co.uk] Sent: Monday, July 05, 2010 7:46 PM To: Richard Shockey Cc: Paul Kyzivat; DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, folks, [removing ietf-general as cross-posting this whole thread doesn't help, IMHO] I have remained silent so far, but just to clarify... Richard is absolutely correct. The comments on ENUM seemed to miss WHY public ENUM has been hard to roll out. Each country (or region) has its own idea of Eligibility criteria for ENUM domain registration in its jurisdiction. One thing they pretty much every one of the authorities agrees on is that *AT LEAST* there has to be a demonstrable proof that the domain owner is provided (or provides) service via the associated E.164 number. To say that this is a challenge to arrange cheaply or simply (or at all) is an understatement. Trust me; I know to my cost, as does Richard. Even that does not demonstrate that a value published in an ENUM domain MUST be, by some guarantee, always tied to that domain and its associated E.164 number. If I own a domain, I can provision what I like in that domain. The validation hook is tied some way to the numbering authority for E.164 numbers in a particular jurisdiction, and there IS no validation authority that ties a SIP URI to an E.164 number. In private ENUM clouds, carriers know their own and trust partner carriers (at least partially). That's a set of contractual agreements, nothing more. The real question you have to ask is: can you gain access to the basic information on which the private ENUM domains provisioning is based? If you are part of that federation, then yes (at least you can query the private ENUM tree). If you are outside that federation, then no protocol magic is going to change that fact. Sorry for the long post, but it isn't a protocol issue; that well be LDAP (or something that scales). It's an operational and contractual agreement between CSPs, and last I heard that was not an IETF topic. all the best, Lawrence On 5 Jul 2010, at 19:48, Richard Shockey wrote: my assertion is that any authentication of the responsible domain for a E.164 number outside of the PSTN service provider or national numbering authority is not possible under the current regulatory circumstances. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [dispatch] VIPR - proposed charter version 3
Well folks can certainly do what they want to do. And the IETF has a lamentable record of some protocols that don't accomplish much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify or authenticate the responsible party for a E.164 number. It is incapable of doing so since there is no possible administrative chain of trust other than self assertion . Hence the possibility of identity or number/session hijacking is very large. You have to have the cooperation of the national numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn't change that problem either. This has been a well known problem in SIP for some time and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however in private trees BTW. Consequently I think this issue has to be fully defined in the charter and I will gleefully anticipate what the security considerations text will look like. The fact that there is CISCO running code is utterly irrelevant. There is lots of bad code out there. I understand the problem of how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to fail. I do understand that many folks don't like their voice service providers or PSTN that perpetuates the use of E.164 numbers but this proposal is not going to solve that. IMHO in the absence of any rational trust or security model you can certainly publish something as Informational but getting something past the IESG is another thing entirely. From: Peter Musgrave [mailto:peter.musgr...@magorcorp.com] Sent: Saturday, July 03, 2010 5:49 PM To: Richard Shockey Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, Clearly we don't want to be trying to solve the impossible - that could take a really long time. The mechanism in the ViPR drafts seemed to be able to accomplish the finding the party responsible for a number - and IIRC this is based on *running code* in the Cisco IME. ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it. Peter Musgrave On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey rich...@shockey.us wrote: A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed. IMHO this charter is a non starter and should not be approved on the basis of this statement alone. finding domains that claim to be responsible for a given phone number This IMHO is flat out impossible. Validating or authenticating an entity that is responsible for a phone number is as bad as who is the carrier of record , is a massive rathole. Cullen and Johathan should know better. Certs? LNP ? We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF. -Original Message- From: dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, June 30, 2010 11:33 AM To: Mary Barnes Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 It looks to me that one can imagine 'centralized' solutions which are also based on reusing SIP related functionality developed in RAI. I would rather not close such an option and allow the WG a window of opportunity in which alternate solutions that could meet the same goals can be presented. Dan -Original Message- From: Mary Barnes [mailto:mary.ietf.bar...@gmail.com] Sent: Wednesday, June 30, 2010 6:24 PM To: Romascanu, Dan (Dan) Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Dan, The term peer to peer is intended to exclude mechanisms that would use a central repository for the information: This was discussed in an earlier thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html In one sense it is a solution, however, in another sense it is reusing SIP related functionality defined in RAI and thus is in a similar vein as specifying the use of SIP in a charter. Thanks, Mary. On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) droma...@avaya.com wrote: The VIPR WG will address this problem by developing a peer to peer based approach to finding domains that claim to be responsible for a given phone number and validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. Hi, Clarification question. What exactly means 'peer to peer based approach' and what kind of approaches are excluded by having this in the charter. Does 'approach' mean
RE: [dispatch] VIPR - proposed charter version 3
A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed. IMHO this charter is a non starter and should not be approved on the basis of this statement alone. finding domains that claim to be responsible for a given phone number This IMHO is flat out impossible. Validating or authenticating an entity that is responsible for a phone number is as bad as who is the carrier of record , is a massive rathole. Cullen and Johathan should know better. Certs? LNP ? We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF. -Original Message- From: dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, June 30, 2010 11:33 AM To: Mary Barnes Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 It looks to me that one can imagine 'centralized' solutions which are also based on reusing SIP related functionality developed in RAI. I would rather not close such an option and allow the WG a window of opportunity in which alternate solutions that could meet the same goals can be presented. Dan -Original Message- From: Mary Barnes [mailto:mary.ietf.bar...@gmail.com] Sent: Wednesday, June 30, 2010 6:24 PM To: Romascanu, Dan (Dan) Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Dan, The term peer to peer is intended to exclude mechanisms that would use a central repository for the information: This was discussed in an earlier thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html In one sense it is a solution, however, in another sense it is reusing SIP related functionality defined in RAI and thus is in a similar vein as specifying the use of SIP in a charter. Thanks, Mary. On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) droma...@avaya.com wrote: The VIPR WG will address this problem by developing a peer to peer based approach to finding domains that claim to be responsible for a given phone number and validation protocols to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. Hi, Clarification question. What exactly means 'peer to peer based approach' and what kind of approaches are excluded by having this in the charter. Does 'approach' mean solution? If so why does a specific type of solution need to be agreed in the charter, while all we have at hand at this point are individual contribution I-Ds that describe the 'problem statement and some possible starting points for solutions'? Thanks and Regards, Dan -Original Message- From: dispatch-boun...@ietf.org [mailto:dispatch-boun...@ietf.org] On Behalf Of Mary Barnes Sent: Monday, June 28, 2010 8:38 PM To: DISPATCH Subject: [dispatch] VIPR - proposed charter version 3 ___ dispatch mailing list dispa...@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
By any chance does anyone know who is the SIP guy/gal at Apple?
Aka FaceTime? Some of us in the RAI directorate would like to extend a welcoming hand. J Plus see what the SDP looks like etc , interop options, naming, where is the rendezvous server, etal. Small stuff. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Ok .. I want my IETF app for my iPad ..
Dan P.S. Richard, yes, EPUB is great for the eBook readers... next I suppose you're going to want RFCs and I-D's in EPUB? :-) (And no, I am NOT really trying to stir up the recently concluded chapter in the ongoing IETF document format wars...) RS Well yes actually. My original thread was actually invite the epub folks to hand over change control to the IETF like Jabber did with XMPP and then we could use a document standard that was IETF anointed and reviewed. Done. But then we wouldn't have the annual ritual of arguing about ID RFC formats and it just wouldn't be the IETF if we didn't do that. We have to stand for some traditions around here however irrelevant they are. Though as Cullen pointed out having things that could allow tablet readers to annotate and highlight text files like that would be a great boon and not printing these things out all the time is a bonus. On Apr 8, 2010, at 11:16 AM, Tony Hansen wrote: For RFCs and I-Ds, I use tools.ietf.org/html/rfc and tools.ietf.org/html/draft-. An unsung feature of that tool is that it both displays AND *prints properly*, using CSS to control pagination. (It's a workaround for what you're complaining about, but it works.) Tony Hansen t...@att.com On 4/8/2010 10:47 AM, Richard Shockey wrote: That was what I had in mind when I started this thread or maybe configuration options for push of new WG drafts. No browser including Safari displays ASCII text well and that has been my ultimate objection. It drives me nuts that I have to print out all new drafts to actually read them ( sorry HP ). If the app could convert the ASCII to something that allow for different fonts and auto repagination display that would be totally wonderful. That function alone has been one of the huge drivers for tablet devices as Amazon's own market analysis has determined. Its very very age skewed to the over 40 crowd. That is why I'm totally sold on the .epub format. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
Lets not forget what this specification was attempting to solve, which has been the well known boot strap problem with SIP-CUA's we have collectively ignored since the creation of SIP, especially those that might use (dare I say it) phone numbers. The model here is to make such things as SIP CUA's as easy to use as traditional POTS phones. Plug them in, they work.. at least now after punching in a small data string into the keypad of a device, instead of having to manually Config the device using some on board HTTP app. As the success of some Apple devices testify ( and Skype for that matter) ..making complex electronics configuration nearly stupid proof increases the overall market. :-) This could also expand the market for SIP devices and the for competitive SIP services by permitting them to be sold at mass market outlets without being necessarily tied to one SSP, if, yes, they were compliant with the specification and yes Hadriel you had a branded logo program that insured compliance. The SIP Forum is not there yet on that kind of testing, compliance and logo program. Any discussion of how to improve the specification is useful but the goal is the expansion of SIP related services in the market. Gee sort of what we are trying to do with the PBX to SSP issues. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Scott Lawrence Sent: Thursday, April 08, 2010 9:37 AM To: Hadriel Kaplan Cc: Cullen Jennings; IETF Discussion Mailing List Subject: RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC On Thu, 2010-04-08 at 04:12 -0400, Hadriel Kaplan wrote: Howdy, I said I would shut up, but I missed one question from Cullen, which was: This conversation constantly confuses the issue of must implement vs must deploy. Which one are you objecting to here. Answer: I am objecting to there not *being* a distinction between must implement vs. must deploy in this draft. The draft requires the implementation and DEPLOYMENT of a SIP Subscription service. It is not optional to use. It is not optional to deploy. Well, one could argue that a provider could cause the returned SIP url for the change notice subscription to be one for which there is no routing (return 'Link: sip:devnull.example.org'). By the rules, the UA would periodically make a DNS request to try to find it, but would be allowed to use the configuration data. Silly, but allowed. No one is going to be forced to use any of this specification. If you don't want the features it provides (automatic initial configuration with prompt updates), then don't use it. At the risk of repeating myself, I want to make sure that one reason for using SUBSCRIBE/NOTIFY for the change notices is clear: there is no other existing standard way to address a specific User Agent. User Agents do not register a contact that identifies the device (or program); they register addresses that identify users (SIP AORs), and those same addresses might well also map to other UAs. If I want to change the configuration of exactly one device, I need a way to send a message just to that one device. Putting a subscription URL in the Link header returned by the HTTPS configuration data response allows the Configuration Service to associate every item of configuration data with the devices that have it, so that when that data it is possible to send a message to exactly the set of devices that need to know. Through some careful analysis of the implementation requirements stipulated in the draft, one may be able to find an exemption path to avoid deployment by means of configuration - but the language of the requirements to do so is so weak that it's meaningless. If you have a suggestion for better wording that preserves the intent, I'm happy to hear it. You cannot stipulate that a UA MAY do foo in a SIP-Forum profile or IETF RFC, and then expect administrators to rely on that foo for anything useful whatsoever, because not all UAs are required to do foo. Some will, some won't. All of them will be compliant. This basically defeats the whole point of having an implementation profile, imho. In general I agree with that paragraph, and have tried hard not to put that particular kind of problem into this spec. I don't think that any of the examples you cite below produce the kind of problem you describe. I'll attempt below to explain why each are needed... For example, the following requirements are stipulated: The User Agent MAY obtain configuration information by any means in addition to those specified here, and MAY use such information in preference to any of the steps specified below, but MUST be capable of using these procedures alone in order to be compliant with this specification. The MAY 'escape' clauses above are there primarily to allow a configuration to 'stick'. The user of a UA may
RE: Ok .. I want my IETF app for my iPad ..
That was what I had in mind when I started this thread or maybe configuration options for push of new WG drafts. No browser including Safari displays ASCII text well and that has been my ultimate objection. It drives me nuts that I have to print out all new drafts to actually read them ( sorry HP ). If the app could convert the ASCII to something that allow for different fonts and auto repagination display that would be totally wonderful. That function alone has been one of the huge drivers for tablet devices as Amazon's own market analysis has determined. Its very very age skewed to the over 40 crowd. That is why I'm totally sold on the .epub format. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Rob Evans Sent: Tuesday, April 06, 2010 12:40 PM To: Ole Jacobsen Cc: ietf@ietf.org Subject: Re: Ok .. I want my IETF app for my iPad .. Display RFCs? Doesn't this new toy of yours already have a browser? I was idly thinking of this a few days ago. An app for the iPad that will sync across RFCs and I-Ds for offline viewing would be quite useful. Rob ___ 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: Ok .. I want my IETF app for my iPad ..
Well if you are over 55 with bifocals, like me, you might have a issue. Which is why tablet readers really are a boon. On 04/08/2010 07:47 AM, Richard Shockey wrote: That was what I had in mind when I started this thread or maybe configuration options for push of new WG drafts. No browser including Safari displays ASCII text well and that has been my ultimate objection. I've got to really question what you mean by well. It's been perhaps a decade since I printed an rfc and virtually every one of them that I've read since has been in a browser. fwiw I use the same fixes width font when viewing them there as I do when composing this email or editing a draft but that's not exactly hard to achieve. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-lawrence-sipforum-user-agent-config (Session Initiation Protocol (SIP) User Agent Configuration) to Informational RFC
True.. but I don't think anyone realized when we began the SIP Connect 1.1 process and MARTINI that what is a simple business issue I just want to plug in foo and it works. would turn into a total philosophical debate of the SIP registration process. This is why members of our Board insisted that the proposed informational documents be reviewed by the usual RAI suspects here in the IETF. In retrospect I think that was a reasonable idea. I think the proposed PAN registry, however, is essential to make this all work but that IMHO is utterly outside the scope of the IETF. -Original Message- From: Richard Shockey [mailto:rich...@shockey.us] Sent: Thursday, April 08, 2010 10:34 AM Lets not forget what this specification was attempting to solve, which has been the well known boot strap problem with SIP-CUA's we have collectively ignored since the creation of SIP, especially those that might use (dare I say it) phone numbers. I am not forgetting that at all. That's one of the reasons I find it so perplexing that a draft which is supposed to make things easy and simple for boot strapping, has decided to mandate a nice-to-have feature which adds complexity and is not required for boot-strapping. Any discussion of how to improve the specification is useful but the goal is the expansion of SIP related services in the market. Gee sort of what we are trying to do with the PBX to SSP issues. Right, and as we learned with PBX to SSP issues in SIP-Connect 1.0, not being extremely specific and getting it right the first time will hurt you later. ;) -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Ok .. I want my IETF app for my iPad ..
And I want it now! Yes I'll pay thank you. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard(at)shockey.us skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Ok .. I want my IETF app for my iPad ..
About 10 to 15 USD would work fine for me BTW. At least we should do it before the ITU and TIES does it .right? J From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Richard Shockey Sent: Saturday, April 03, 2010 5:21 PM To: ietf@ietf.org Subject: Ok .. I want my IETF app for my iPad .. And I want it now! Yes I'll pay thank you. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Why the normative form of IETF Standards is ASCII
My my it must be springtime! Time for our annual food fight ritual of ASCII in RFC's. Actually I was thinking that the IETF should approach the International Digital Publishing Forum with the thought that they consider making the .epub format an IETF standard. .epub is getting considerable traction and I've personally found it to useful to convert some RFC's into .epub for storage on my Amazon kindle and soon to have iPad. You have to use desktop Stanza to convert again to the Kindle native format but this permits the document to be read and more important the fonts to be adjusted on the display for those of us with increasing issues with 10 point type. http://www.openebook.org/ I do get the arguments in favour of ASCII, though I think there are some pretty serious countervailing arguments (like, for instance, that we can't spell many contributors' names, to take an easy one). But the RFC format _is not_ plain ASCII. Just ask anyone whose draft has failed the increasingly stringent and lengthy list of IDNits tests due to bad pagination in their I-D. Best, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ 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: WG Review: Internet Wideband Audio Codec (codec)
I can see the motivation to pay big bucks for video codecs. Using Mpeg4 can reduce your bandwidth costs and save real money. I can see why there was a big incentive to save money on audio codecs in the 1990s. At this point an audio codec is going to have to save a huge amount ot bandwidth to be worth the hassle, let alone the cost of using encumbered technology. Its not about the bandwidth. Its about the quality of the voice in occasionally lossy networks landline or mobile. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: WG Review: Internet Wideband Audio Codec (codec)
+1 Emphatically If people want to do the work, why not let them try. If they cannot succeed then shut it down. That does bring up the more sensitive subject that the IETF as a whole needs to consider which is when can it be determined that a WG is not succeeding. That is a much much longer thread. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Sam Hartman Sent: Monday, January 04, 2010 5:41 PM To: Patrik Fältström Cc: co...@ietf.org; Phillip Hallam-Baker; i...@ietf.org; k...@munnari.oz.au; ietf@ietf.org Subject: Re: WG Review: Internet Wideband Audio Codec (codec) I've been thinking about the codec issue for a while. I think it is really desirable for the IETF to charter this group. I don't think the charter should prohibit the working group from selecting some existing codec nor should it prohibit doing new work in this space. ___ 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
The IETF and the SmartGrid
NIST has issued its formal request for comments on the NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0. As I noted in a previous message this extremely important to the evolution, reliability and security of not just the Electricity Grid but to the Internet itself. It's a short fuse. Comments must be received on or before November 9, 2009 instructions on how to comment are located below. http://edocket.access.gpo.gov/2009/E9-24429.htm and the SmartGrid Cyber security requirements. http://edocket.access.gpo.gov/2009/E9-24430.htm Relevant documents are located here as noted before. http://www.nist.gov/smartgrid/ Richard Shockey PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype/AIM: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
The IETF and the SmartGrid
dimensions of design space for LoWPAN applications. A list of use cases and market domains that may benefit and motivate the work currently done in the 6LoWPAN WG is provided with the characterisitcis of each dimention. A complete list of practical use cases is not the goal of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-usecases-04.txt Richard Shockey PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype/AIM: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The IETF and the SmartGrid
It will certainly get their attention ... :-) -Original Message- From: Michael Dillon [mailto:wavetos...@googlemail.com] Sent: Monday, October 05, 2009 5:54 PM To: Richard Shockey Cc: ietf@ietf.org Subject: Re: The IETF and the SmartGrid Myself and others are deeply concerned by how this effort is developing. There is no current consensus on what the communications architecture of the SmartGrid is or how IP actually fits into it. The Utility Industry does not understand the current IPv4 number exhaust problem and the consequences of that if they want to put a IP address on every Utility Meter in North America. What is equally troubling is that many of the underlying protocols that utilities wish to deploy are not engineered for IPv6. We have an example of that in a recent ID. I've asked the ARIN Public Policy mailing list how people would feel about banning the Electric Utility industry (and sub contractors) from receiving any IPv4 addresses for use on the Smart Grid. This would include direct ARIN allocations and assignment from ISPs. I think that you are right to raise this issue in discussion since we badly need to shine a light on the details of transitioning the Internet to IPv6. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: The IETF and the SmartGrid
Thank you for your response. Is there any documentation URL's etc ( hopefully in English ) that you could share? -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Hiroshi Esaki Sent: Monday, October 05, 2009 8:39 PM To: Michael Dillon; Richard Shockey; ietf@ietf.org Subject: Re: The IETF and the SmartGrid Hi Fred and Michael, This is Hiroshi Esaki of WIDE project, Japan. We have long time worked on the introduction of IP technology into the faculity networks, especially focusing on the usage of IPv6. We run the Green University of Tokyo Project. We have some professional operation using IPv6 on bulding automation and lightening control system. The most of exisiting and current system in this particular field is based on non-IP system, however they are going to realize the benefit of IP technology and open technology in this field. Thanks, Hiroshi Esaki, WIDE Project ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
New validation of RFC 2543
Time to move to Draft Standard. http://idle.slashdot.org/story/09/09/08/1414248/SAs-Largest-Telecomms-Provid er-vs-a-Pigeon Richard Shockey PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype/AIM: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
How should ICANN spend its money ..
Give it to the IETF obviously ... http://blog.icann.org/2009/04/have-an-opinion-on-where-icann-should-spend-it s-money/ Richard Shockey PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us skype: rshockey101 LinkedIn : www.linkedin.com/in/rshockey101 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Comment on draft-iab-ipv6-nat-00 FYI
No business case for IPv6, survey finds But Internet Society members report rising customer demand, deployment plans http://www.networkworld.com/news/2009/032009-ipv6-business-case.html?nladnam e=032009dailynewspmalcode=nldailynewspm187866 Business incentives are completely lacking today for upgrading to IPv6, the next generation Internet protocol, according to a survey of network operators conducted by the Internet Society (ISOC). In a new report, ISOC says that ISPs, enterprises and network equipment vendors report that there are ``no concrete business drivers for IPv6.'' Developers and Identity Services : Tackling Identity Data with Identity Hub: Download now However, survey respondents said customer demand for IPv6 is on the rise and that they are planning or deploying IPv6 because they feel it is the next major development in the evolution of the Internet. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Brian E Carpenter Sent: Thursday, March 19, 2009 4:48 PM To: Pete Resnick Cc: Christian Vogt; Lixia Zhang; Keith Moore; IETF Discussion Mailing List Subject: Re: Comment on draft-iab-ipv6-nat-00 I recently had this exchange with Dan Wing on the BEHAVE list: ... it seems to me that we might consider defining a generic 'referral object', containing more information than just an address, that could be passed among application entities. It could contain TLVs that would provide the semantics of the referred address as well as the raw address bits. Does this seem worth exploring? Yes, this could form the basis for very useful guidance to application designers. ICE does something like this already, but abstracting its functions up several levels, as you propose, would be useful. Something like: here is my IPv4 address, it goes through a translator so avoid using it if you can utilize my IPv6 address and so on. Brian On 2009-03-20 07:04, Pete Resnick wrote: On 3/19/09 at 8:17 AM -0400, Keith Moore wrote: Lixia Zhang wrote: I believe that people in general agree that applications should not use IP address for referrals. I don't know which people you're referring to there, but that's absolutely not the case for application developers. In the current internet, use of IP addresses for referrals is essential. That IP addresses are currently essential for referral is not mutually exclusive with the idea that applications should not use IP addresses for referrals. IP addresses fail for referrals in a vast number of cases including 1918 addresses, firewalled networks, certain asymmetric routing cases, etc. Given the current state of the network, you can neither recommend nor completely forbid the use of IP addresses for referrals in applications. (And nowhere in what Lixia said was the statement that applications MUST NOT use IP addresses for referrals.) And in fact every application that uses DNS does exactly that. I think that's a rather narrow view of where DNS falls in the architecture. It's all well and good to imagine a world where there would be a clear ID-LOC separation. But we've never created such a world, and we don't currently have an ID-LOC mapping layer that is good enough to use by all applications. Yup. In part, that's what LISP is about. But I actually think it's incorrect to talk about having an ID-LOC mapping layer good enough to use by all applications. If we're talking about the ideal world, applications should almost never need to use the mapping layer; they should be able to simply use the ID (without touching the LOC) and let the routing system deal with finding a LOC for the ID. That an application would have to actually deal with the mapping is an artifact of the current state of affairs where neither the LOC (IP address) or ID (DNS) is good enough to allow the application to do what it needs to do. DNS falls short in many ways. And as long as there is not a universal mapping layer that is aware of things like NATs and mobility, and for that matter as long as there are devices that impose arbitrary limitations on traffic flow (e.g. connections have to be initiated from inside), there will be a need for applications to deal explicitly with IP addresses. Sure it's ugly but it's the best that applications can do. I'm guessing we're in violent agreement, but NATs and mobility and traffic flow limiters actually make it impossible (viewing it from the other end) to use IP addresses: Giving a reference to myself using my own IP address when I am behind a NAT is useless; using a name, if one is available, is the only way to go. (And I still agree with your above paragraph.) pr ___ Ietf mailing
RE: [IAOC] ISSN for RFC Series under Consideration
+1 no brainer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Resnick Sent: Wednesday, May 21, 2008 3:06 PM To: Ray Pelletier Cc: Working Group Chairs; IAB; IETF Discussion; IAOC; The IESG; RFC Editor Subject: Re: [IAOC] ISSN for RFC Series under Consideration On 5/21/08 at 2:36 PM -0400, Ray Pelletier wrote: The Trust did consult with lawyers, old-crusty-IETFers, RFC Editor, and found no disadvantages to indentifying the RFC Series with an ISSN. [...] We've done our due diligence, but we respect the community and the process, and seek its guidance. Gotta love that! ;-) Sounds like a fine idea to me. pr -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651- 1102 ___ 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: Blue Sheet Change Proposal
Exactly .. I don't see the problem. I've not seen any evidence of abuse. IMHO if the procedure is not broken why are we trying to fix it? Why is the IETF so continuingly dragged about in these, frankly trivial, process issues? I won't repeat what others have said about the presence or absence of the problem, but I'm not convinced either. john ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
FW: RFC 5241 on Naming Rights in IETF Protocols
Can this be extended to WG naming rights as well. :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 12:58 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RFC 5241 on Naming Rights in IETF Protocols A new Request for Comments is now available in online RFC libraries. RFC 5241 Title: Naming Rights in IETF Protocols Author: A. Falk, S. Bradner Status: Informational Date: 1 April 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 12 Characters: 25304 Updates/Obsoletes/SeeAlso: None URL:http://www.rfc-editor.org/rfc/rfc5241.txt This document proposes a new revenue source for the IETF to support standardization activities: protocol field naming rights, i.e., the association of commercial brands with protocol fields. This memo describes a process for assignment of rights and explores some of the issues associated with the process. Individuals or organizations that wish to purchase naming rights for one or more protocol fields are expected to follow this process. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/ietf-announce ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: My view of the IAOC Meeting Selection Guidelines
And this coming from the Standards body that has developed SIP ... unbelievable. I don't think I'm going to listen to any more arguments about IPv6 experiments during Plenary's any more. One thing the IAOC is looking at at this instant is our phone bill. The IETF's phone budget for 2008 is IESG: $58,800 IAB:$22,500 Nomcom: $30,000 IASA/IAOC: $17,235 - $128,535 ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: My view of the IAOC Meeting Selection Guidelines
Thanks Bob ..as someone who had questions, I find this a perfectly reasonable and rational explanation. In the case of Dublin, the IAOC did understand that the sites distance to Dublin wasn't ideal, but it was the only site we could find in the area that meet the other requirements. In this case, we will try to ameliorate this issue by providing busses to downtown Dublin. In my view we are having a meeting in Dublin because we have a host to wants to host the meeting there. I don't think we would have done it there if there was not a host. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IETF 72 -- Dublin!
Is there an unwritten requirement that IETFs are placed to afford us sightseeing? You mean this isn't the Individual Enlightenment and Travel Foundation mailing list ... oh so sorry. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IETF 72 -- Dublin!
It's Ray's job to make the call. It's the IAOC's job to see that he does his job well. I think Ray has at least earned the benefit of the doubt. I don't think so ..given the perfectly rational questions that are being asked about this particular sub-optimal site, the community has a perfect right to ask pointed questions about why it was selected and what if any were the alternatives. The deal is done, I agree with that, but there are aspects of this particular selection that are different from any other I've seen in the IETF in the 10 years or so I've been attending. Sites that are substantially distant from city centers or major transportation hubs IMHO don't work for the IETF community irrespective of whether they are in North America, Asia or ECMA. Perhaps this is best viewed retrospectively since contracts are signed? Eliot ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IETF 72 -- Dublin!
My comment said or as in one or the other, if you had re read the comment properly before going snarky. I don't dispute Dublin airport is a useful transportation hub. I want to know why this particular venue was selected and what was the criterion used to make the evaluation. That is a simple question given the legitimate questions many of us are asking. IMHO it was a bad selection and I think many of us want to make sure it does NOT happen again. That said I love Ireland .. delighted to go there ..but. -Original Message- From: David Kessens [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 06, 2008 5:21 PM To: Richard Shockey Cc: 'IAB'; 'IETF Discussion'; 'IAOC' Subject: Re: IETF 72 -- Dublin! Richard, On Wed, Feb 06, 2008 at 04:48:15PM -0500, Richard Shockey wrote: Sites that are substantially distant from city centers or major transportation hubs IMHO don't work for the IETF community irrespective of whether they are in North America, Asia or ECMA. While I don't particularly like this location, I don't see how you can imply that it is hard to get to Dublin airport and from there to the meeting site. Aer Lingus has reasonably priced (for summer time) direct flights from most large US cities. Most european cities are served by Aer Lingus and by Ryan Air which is quite possible the cheapest airline on earth. David Kessens --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
With all of this layer 10 discussion of V4 V6 outages...which bores me to no end.
It's useful to have a holiday season reminder of why we are doing any of this at all. http://www.nytimes.com/2007/12/19/education/19physics.html?emex=1198213200; en=f1969a5703b764c9ei=5087%0A If there was ever a reason to reflect on why we argue about dancing packets on the head of a pin this is it. It is a ongoing privilege to make things like this happen. This article BTW is the Number One emailed article currently on the NY Times web site. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Charging I-Ds
A excellent start... You forgot $500 for messages on the use of ASCII in RFC's. -Original Message- From: Eric Rosen [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 10:50 AM To: Eric Gray (LO/EUS) Cc: ietf@ietf.org Subject: Re: Charging I-Ds Eric Gray The discussion is essentially inane I think this is an excellent observation. It suggests to me though that perhaps the best way to get more funding for the IETF is to impose a surcharge on inane messages to the ietf mailing list. The surcharge can be based on the degree of inanity of the message. I suggest the following schedule of charges: - $10 for a generic message whining about US customs/immigration processes ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Charging I-Ds
In keeping with Eric Rosen's excellent thread .. The simple solution is to charge 500 .. UK POUNDS!! for Internet Access during the IETF meetings. This is clearly in keeping with standard hotel/airport practices around the world. This would clearly solve the budget problem as well as discourage people attending WG meetings from spending most of their time on YouTube instead of following the discussion. ### On Jul 31, 2007, at 5:16 PM, Peter Sherbin wrote: The current business model does not bring in enough cash. How do we bring in more in a way that furthers ietf goals? E.g. other standards setting bodies have paid memberships and/or sellable standards. IETF unique way could be to charge a fee for an address allocation to RIRs. On their side RIRs would charge for assignments as they do now and return a fair share back to IANA/IETF. A IP address use fee might help solve two problems ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Interesting turn of events
I love it just bomb the fux spammers into submission. Off we go into the wild cyber yonder .Climbing high into IP .. Or maybe Over hill over dale we hit the cyber trailFor its HI HI HEE in the Cyber Artillery ... and those Caissons go rolling along. From: Fred Baker [mailto:[EMAIL PROTECTED] Sent: Friday, November 03, 2006 4:05 PM To: ietf@ietf.org Discussion Subject: Interesting turn of events http://www.cnn.com/2006/TECH/internet/11/03/airforce.cyberspace.reut/index.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: NOMCOM term limits... Re: Now there seems to be lackofcommunicaiton here...
Well said.. Incompetence and stupidity have never been an impediment to a genuine democratic process. You only need look at the US Congress, UK Parliament, German Bundestag, and Japanese Diet etal for evidence of that. -Original Message- From: Theodore Tso [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 05, 2006 5:31 PM To: todd glassey Cc: [EMAIL PROTECTED]; Keith Moore; ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: NOMCOM term limits... Re: Now there seems to be lackofcommunicaiton here... On Tue, Sep 05, 2006 at 12:30:40PM -0700, todd glassey wrote: Yes Keith even the incompetent get to speak here. And that includes you too. Yes, the incompetent do get to speak here. That has been amply demonstrated on this and other threads, without naming anyone in specific. And, the incompetent, if they attend a sufficient number of IETF meetings, are also capable of putting their names into the hat and have a random chance of being selected to serve on the Nomcom, like everyone else. There is the hope that by the time have served on the requisite number of IETF meetings and worked on various IETF projects, that they will have learned enough about the community which they are proposing to serve that they won't, perhaps, be as incompetent as when they first started. No, it is not a mob rule by the uneducated. Some would say this is a good thing. The uneducated mob can and does rule by exerting pressure on the vendors, of course. So they do have a role to play in this whole process, even if they don't get to vote on the IETF management structure. - 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: NomCom 2006/07: Selection Process Reset
And to that hopefully final note, lets not forget that taking on the responsibility of NOMCOM chair is a generally thankless task that Andrew has volunteered to do. The process has to go forward and Harald is completely correct. I was selected in the previous spin and if selected again Andrew will, of course, have my compete support. -Original Message- From: Harald Alvestrand [mailto:[EMAIL PROTECTED] Sent: Friday, September 01, 2006 3:04 AM To: ietf@ietf.org Subject: Re: NomCom 2006/07: Selection Process Reset Just to say me too... I think that Andrew as Nomcom chair needs to have the authority to make the decision in this case and make it stick, no matter how many people think that he could have done better. I've got no problem with the community having opinions about his decisions, and even somehow encoding that into the advice left for later chairs - but I think it's 100% right that it is HIS decision. Harald ___ 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: Now there seems to be lack of communicaiton here...
-Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 3:29 AM To: [EMAIL PROTECTED] Cc: 'IETF-Discussion' Subject: Re: Now there seems to be lack of communicaiton here... Richard Shockey wrote: This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. This message is on its way to the ietf-announce list; that takes time with several thousand subscribers. That is the appropriate list, not this one. Brian what in the world are you thinking? Given that the issue involved here is the integrity of the NOMCOM process, it deserves no more notification than a posting on the announce list? Second ...a complete explanation of why this go screwed up should have been posted to the community. The message seems to give a complete explanation. Oversights happen. We are a volunteer community, and any of us can overlook something, any time. 'Seems' is a very mild word here. I do not believe there is any malice involved here only a severe lack of communication and consultation on an issue that essentially disqualifies the entire elector slate. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. Actually the custodian of the process is, as I read RFC 3777, the ISOC President. There is a formal dispute procedure defined in RFC 3777, but Andrew took remedial action before anyone invoked that. Since remedial action has been taken, I don't see an issue at this time. Well I do. The suggestion that the selection process be respun is IMHO very very serious and the incorrect solution here. Why respin the entire list when it would have been just as easy to select the next elector on the list? IMHO options here should have been made clear before the decision was ultimately made. I don't dispute the NOMCOM's right to make the decision only that on a matter of such gravity input come from the community at large. This entire event has been very badly handled Brian. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
Granted 3777 does not require the consultation of the community on disputes involving the NOMCOM but given the highly unusual nature of the problem at hand and the tendency of the IETF toward anal retentive behavior in matters of process it seems reasonable to suggest that a wider set of views should have been solicited. I'm in complete agreement with Ned Freed here. Full disclosure: My personal opinion, which I *did* give to Lynn and Andrew when I became aware of this glitch, is that a reset is the only way to be certain that the selection process is unbiased. Well, I have to say I think you provided some extremely bad advice, and I sincerely hope that there isn't anyone on the first list that has an even slightly acrimonious public relationship with Andrew. We could be in very deep doo if there is. And with Dave Crocker, Again, the underlying problem with the effort to fix the problem was that that effort was made too fragile by involving too few people, for handling such an exceptional situation. However I'm willing to suggest that the damage has been done and we should respect Andrew Lange's decision. I may disagree with the process by which Andrew made his decision but in the final analysis a decision had to be made and he did it. If the error had been discovered before the random data became available, the first choice would have been the obvious one. However, it was not, and the situation is complicated by the fact that the list of volunteers did not become available in time for anyone to challenge eligibility prior to the random data becoming available. Even before the error in the list was discovered, I considered complaining about the timing issue and suggesting the remedy of running the process with new random data that would not become available before people had a chance to object (in other words, the same remedy that Andrew ended up applying). If you or anyone else feels that there is a problem, the correct course of action as described by RFC 3777 is to bring the issue to the nomcom chair and then, if the situation is not resolved to your satisfaction, take it to the ISOC President as a formal dispute. Nowhere does RFC 3777 suggest that a suitable remedy is to complain on a public mailing list that you were not personally consulted. -- Jeff ___ 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: Now there seems to be lack of communicaiton here...
I agree as well. Again, having started this charming little discussion thread, any other course of action at this late stage would cause more problems than it would solve. R. Shockey -Original Message- From: Joel M. Halpern [mailto:[EMAIL PROTECTED] Sent: Thursday, August 31, 2006 9:40 PM To: IETF-Discussion Subject: Re: Now there seems to be lack of communicaiton here... I agree that this seems to be the best course available. Yours, Joel M. Halpern At 09:08 PM 8/31/2006, Theodore Tso wrote: On Thu, Aug 31, 2006 at 05:55:25PM -0400, Jeffrey Hutzelman wrote: Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and always rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility beresolved before the random data becomes available. I think Jeff proposal makes a lot of sense and is probably the best way to move forward given the current circumstances. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Now there seems to be lack of communicaiton here...
As someone who was actually selected in the previous round and started this little thread, I support this position. I've reviewed the specification for this process, including the random selection algorithm, several times over the past few years. I've always believed the selection process was reasonably well-designed to meet its goals, and I certainly didn't predict the present situation. However, now that it's been raised, it seems reasonable to fix it _for the future_. Therefore, I propose the following: (1) Andrew's decision stands. Under RFC 3777, the only recourse available to anyone who disagrees with that decision would be to ask Andrew to reconsider or to file a dispute with the ISOC President. The former has already been done, and so far no reversal has been announced. Given that it is now after the close of trading on August 31, I would submit that a reversal of this decision by either Andrew or Lynn would do more harm than good. (2) Text is added to the next version of the selection process to addresss this issue. I would suggest a strengthening of the existing language about leaving questionable candidates in the list and rejecting them in a later pass. In fact, it might be wiser to require the use of the original list of volunteers as given to the secretariat and _always_ rejecting ineligible candidates in a later pass. This would remove any need to insure that errors or disputes about eligibility be resolved before the random data becomes available. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Resend: RE: What is going on with the NOMCOM
-Original Message- From: Richard Shockey [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 30, 2006 6:55 PM To: 'IETF-Discussion' Subject: What is going on with the NOMCOM Maybe my mail filters are failing but I understand there is a problem with the selection process. Can some one explain this ASAP. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Now there seems to be lack of communicaiton here...
This seems to be on the IETF NOMCOM web page but I do not see it in the ietf@ietf.org archives. I suggest that given the unique importance of this NOMCOM cycle that a fuller explanation is in order. First .. the instant there was a problem the IETF community should have been notified in full on this list. Second ...a complete explanation of why this go screwed up should have been posted to the community. Third .. the IETF community AS A WHOLE should have been consulted as to possible remedies to this problem etc. Consultations to the IESG and IAB are not sufficient on matters of such gravity. * From: Andrew Lange [EMAIL PROTECTED] To: IETF Announcement Date: August 30, 2006 Subject: NomCom 2006/07: Selection Process Reset A few members of the community have expressed concern over two issues with the selection process for this year's NomCom. First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there was some dispute on the eligibility of a number of NomCom volunteers. They were not on the secretariat's list, but they had attended the requisite number of IETF's. I chose to provide the secretariat some time to look into their eligibility because I was concerned about (in no particular order): 1) Disenfranchisement. I wanted to be sure that every voice that was willing to be heard, was heard. I didn't want an administrative snafu to prevent someone who wanted to from serving. 2) Representation. In order to ensure that the NomCom is representative of the community we need the largest possible body of eligible individuals. I believe that these are fundamental to the entire process of the IETF and NomCom. This resulted in the list being sent to the secretariat later than I would have liked, and the message then got hung up in the secretariat's queue. The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was published late, the appearance is not ideal. Second: A sitting member of the IAB's name appeared on the candidate list. According to 3777, section 15, sitting IAB, IESG and ISOC members are not eligible to serve on the Nomcom. This was an oversight on my part. Ordering in the list does matter for the selection process. Although this person was not selected to serve, and the harm done is minimal, it is important that the IETF follow our own processes as closely as possible. For these reasons, and after consultation with members of the IAB, IESG and ISOC, I have decided that to remove any doubt from the proceedings we must re-run the selection algorithm with new seed information. This is unfair to the people who volunteered for NomCom and are the backbone of the process. These people rightfully believed that they were or were not selected, and everyone selected was preparing to serve. To the volunteers: Thank you for volunteering, for your patience and understanding. I apologize for any inconvenience this reset may cause. In order to close this issue quickly, the same stocks and procedure will be used as last time, but the trading date will be drawn from the September 1, 2006 Wall Street Journal which reports the the sales figures from the previous trading day - August 31, 2006. The list we will use is the same as before, but with the IAB member's name removed. The list will be sent in a separate mail. Thank you. Andrew Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
What is going on with the NOMCOM
Maybe my mail filters are failing but I understand there is a problem with the selection process. Can some one explain this ASAP. Richard Shockey Director, Member of the Technical Staff NeuStar 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:5651(at)neustarlab.biz PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683 mailto:richard(at)shockey.us mailto:richard.shockey(at)neustar.biz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Meetings in other regions
On Monday, July 17, 2006 10:11:07 AM -0400 Jeffrey Altman [EMAIL PROTECTED] wrote: For me Paris and Montreal were the two worst meetings I have experienced in ten years because of the separation of the IETF hotel from the meeting locations and the in ability to provide network access in the hotel public spaces. My productivity dropped significantly because of those failures. While I agree with most of what Jeff said, I have to comment on this. The network access in the Delta was a problem. But the Montreal Venue was excellent. Well worth the minor walk. The city was marvelous. I'd easily vote to go back again. This potential pattern of one meeting in Canada one in the US and the other in Euro/Asia-Pac is working out very well. However, the conference centers in both Paris and Montreal had excellent meeting facilities. The network last week was fabulous, and as Jeff pointed out in a message to the WG chairs list, Paris was where we first discovered the utility of having a few extra wireless mics for supporting round-table discussion. The best IETF meetings from my perspective are those held in Minneapolis. The hotel understands what we need. The lounge and bar areas are smoke free and plentiful. There is accessible food via the habitrails. Things just work. I strongly agree. We've been away from Minneapolis for too long. Gag .. Yes the Hilton in MN is nearly the perfect physical venue but frankly enough is enough. There are many other US cities with comparable facilities. It makes a lot of sense to move the meetings around the vast majority of us do like the opportunity to experience a different city from time to time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Meetings in other regions
-Original Message- From: Melinda Shore [mailto:[EMAIL PROTECTED] Sent: Monday, July 17, 2006 11:31 AM To: Dave Cridland Cc: IETF-Discussion Subject: Re: Meetings in other regions On 7/17/06 11:26 AM, Dave Cridland [EMAIL PROTECTED] wrote: I think Melinda's intention was to suggest that the meetings ought to be growing in significance. Is that better? The wording is better, but it's still the case that I'd rather that we made a better effort to conduct the bulk of the IETF's business on mailing lists rather than in meetings. What I'm saying is that it's hard to get the toothpaste back in the tube, and that if the growing role of meetings is inevitable let's acknowledge that and try to make it work well. I like Spencer's suggestion. In the past I've prepared final meeting minutes by editing together the minute-taker's notes and the jabber log and I thought it worked very well. I've found that to be a very useful technique a well. The other thing that continually amazes me is that more WG's have not adopted the practice of appointing a WG Secretary to assist the chairs in various administrative functions like document tracking, NIT reviews and more importantly being the defacto permanent scribe. I'm constantly amazed at WG meetings where 5 or 10 minutes being wasted trying to console some poor soul into acting as a scribe. I cant imagine co-chairing the ENUM WG anymore without a WG Secretary. I wholeheartedly recommend enough the practice. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
Hallam-Baker, Phillip wrote: Perhaps it is just me but I find the two assertions implicit/explicit in your messages to be incompatible: 1) That identity is a topic that the IETF has failed to do useful work on in the past That is a unfair statement. 1. There is lots of useful work being done on Identity Management its just not being done at the IETF. We are not the only standards body on the planet. 2. There is lots of interest in Identity all over the IETF specifically in the RAI area where there are several important drafts being worked on the relationship of SIP to SAML. I think this work extremely important. Are you familiar with the existent SIP SAML work? The question continues to be what areas _could_ or _should_ the IETF make a useful contribution on and how does that relate if any to the existing body of work on SAML and Liberty's Federated Identity Management work. I have some suspicion that W3C is also looking at this area. You were correct earlier post that the current work in Liberty has been oriented towards the enterprise single sign on problem but that does not mean it cannot be generalized to the cross domain problem that is the focus of the current Liberty Federation work. As everyone knows modern Identity management theory came out of the violent reaction to Microsoft's Passport proposal. I remain very cautious about reinventing the wheel here. 2) That the organizers of the BOF have need of more extensive input from those who have failed to do productive work on the topic before proceding. While learning lessons from past failures is an important part of the design process this does not appear to be the type of input into the procedings that you appear to have in mind. You incorrectly assume there are failures in this space. In fact there are several successes. I for one agree that the IETF has not looked correctly at Identity management in general but I also strongly believe the IETF has ignored the significant body of existing work in the space. It is reasonable to tell the builders of the new bridge to ask the architects of the old one why it fell down. I also do not want to build a new bridge if in fact the existing tunnels can handle the demand. It is completely unreasonable to tell the builders of the new bridge to ask the architects of the old one how to build the new bridge and wait on their reply. This BOF is not the only initiative underway in this space. The internet is under attack, phishing is a form of identity theft. So working out how to fit theft proof credentials into the Internet infrastructure is an important problem. Yes but what I and many others would like to see first better grasp of the problem statement, a survey of what is existent in Identity Management, a determination of what currently exists can be reasonably adapted to the problem ..then and only then attempt to design something new. There are lots of folks at IETF that are very familiar with Identity related problems and protocols. I am a bit disturbed that a solution is being proposed before the problem and the alternatives are throughly investigated. Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
In hindsight I probably should have recommended that the existence of the mailing list be announced much earlier. Earlier input from people like yourself, Steve Bellovin, and others who have shared opinions would be better. Since that didn't happen, though, my goal for the BOF is to try to capture a list of actions and issues for the proponents to consider as they developing their proposals. Such as, Is existing work on Identity Management such as SAML, Liberty etal relevant to the problem statement as defined? How should a proposed solution integrate with the needs of the RAI area where this topic is under active discussion? That for a start ..please add to this if necessary. I fully expect that a second BOF will be required before a working group can be considered. On this I'm in complete agreement. -Scott- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF 65 BOF Announcement: Digital Identity Exchange (DIX)
John Merrells wrote: Name of the BOF I dont see a preliminary discussion list on this BOF. That's IMHO is customary. I'm wondering what is the relationship of this proposed work to SAML or the work of Liberty Alliance. http://www.projectliberty.org/ I was frankly astounded that there is nothing in the Charter Draft or associated documents that mentions the huge body of work already existent on Federated Identity Management. Could someone summarize the problem statement this proposed WG attempts to solve, more specifically what is lacking in existing Federated Identity Management efforts that the IETF may have some relative expertise in solving? Digital Identity Exchange (DIX) Area: Applications Chairs: Lisa Dusseault [EMAIL PROTECTED] John Merrells [EMAIL PROTECTED] Sponsoring Area Directors: Scott Hollenbeck [EMAIL PROTECTED] Ted Hardie [EMAIL PROTECTED] BOF Description Objectives 1. To consider the creation of a new IETF working group within the Applications Area titled Digital Identity Exchange. The proposed charter for such a working group is referenced below. 2. To discuss and hone the scope of a DIX working group. 3. To discuss the architectural requirements that derive from the laws of identity identified by ‘The Identity Gang’ at ‘The Berkman Center for Internet Society, Harvard Law School’. Referenced below. 4. To discuss existing architectural implementations within the context of these requirements. An individual submission Internet Draft that describes one such implementation is referenced below, named ‘draft-merrells-dix-00.txt’ 5. To determine if there is enough interest and commitment to form a Working Group and if so to then discuss what the specific goals and milestones of that working group would be. BOF Agenda Introduction and Agenda Discussion (5 min) Scope Discussion (10 min) Identity Laws and Architectural Requirements (10 min) Existing Architecture Presentations (30 min) Call for Participation (5 min) Deliverables Discussion (15 min ) Open Discussion (any remaining time) Documents Charter Draft: http://dixs.org/index.php/DIX_Charter DIX Protocol ID: http://www.ietf.org/internet-drafts/draft-merrells-dix-00.txt DIX Protocol ID: http://dixs.org/index.php/DIX_Protocol_ID Identity Laws: http://www.identityblog.com/stories/2004/12/09/thelaws.html ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Richard Shockey supports IETF renditioning the Jefsey Morfin problem to the CIA
Now can we get back to our regularly scheduled rants on the pro's an con's of ASCII in RFC's? -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: FW: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
JORDI PALET MARTINEZ wrote: Hi, Here is the original announcement and the IETF URL. Comments please ! I'm assuming this is going to be Informational only and as such not formally binding on the IAOC on the Secretariat. In fact that should be made explicit that nothing in this document should be considered formally binding on the IAOC or the Secretariat and that it only represents useful suggestions. This IMHO should have come directly out of the IAOC as the subject matter is directly within their oversight and charter. What is the relationship of this document to the IAOC? Frankly there is'nt much about this document I like. It's a classic example of the current IETF fashion for process over substance. Title : IETF Meeting Venue Selection Criteria Author(s) : J. Palet Filename : draft-palet-ietf-meeting-venue-selection-criteria-04.txt Pages : 18 Date : 2006-1-18 This document provides the IAD with technical and logistic criteria for selecting venues for IETF meetings. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-ietf-meeting-venue-selection -criteria-04.txt -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
J I'm assuming this is going to be Informational only and as such not formally binding on the IAOC on the Secretariat. My personal view is that this should be an Informational document, as a guideline of the selection criteria, as I already tried to describe in the document. There should be no difference between this and any other IETF document, in that sense. But there are differences Informational is just that Informational and as such not binding on the parties as would be the Charter of the IAB IAOC, NOMCOM etc. My opinion is that the binding is not related to the document type, but to how we want to manage the meetings the next years. Clearly, the old document that we have in the IETF site is insufficient and the decision is so *subjective* (not accusing to anyone, just a fact), that the situation is not fair neither acceptable. My position is this A. if it an'nt broke dont fix it and I do not see what is currently broken. B is is irrelevant whether the selection is subjective or not. All selections of this type are ultimately subjective. This class of IETF policy is the IMHO business of those to whom the NOMCOM has appointed to oversee such activity in this case the IAOC. If the IAOC wishes to develop a criterion for site selections and then seek community support for such criterion then fine , that is the IETF way as I have come to understand it. We appoint leadership for a reason ..to lead and make decisions. I dont like binding leadership with rules unless they serve a specific defined purpose necessary to the critical functioning of the organization. This is one of those decisions best left to those to whom we duly appoint to make such decisions. In shorter words I believe in the concept of Management. The business of IETF Management is to Manage so we can get on with our business which is Internet Standards. I've complained during years, and I guess that was the reason Brian Carpenter pointed to me suggesting that I should write the document (not stating that Madrid should be the right venue), and I decided to take the risk. Well Madrid indeed anywhere in Spain is the right venue for _anything_ :-) IMHO!!! I personally would not have any objection to having all future IETF meetings in Spain. Well maybe alternate the fall meetings in Portugal .. Oporto Lisbon come to mind. Now I can see some objections to Ibiza. That might be a stretch...but at least once??? IMHO Brian Carpenter was seriously wrong in suggesting that an individual member of the community attempt to create such a policy document especially since we have just gone through a brutal process to set up a brand new management oversight committee to ultimately preform such functions, the IAOC. Please dont get my wrong. You have obviously put much work into this and we should all be grateful for such contributions to the community. I just dont think it was necessary right now and even if there was a general consensus that it was necessary this is the proper task of the IAOC. Brian should have known better. In fact that should be made explicit that nothing in this document should be considered formally binding on the IAOC or the Secretariat and that it only represents useful suggestions. I think that's precisely against the original target of the document. As said is only a guideline, but it must be followed in an objective way. NO on that I do disagree. That is why if this document is to become a RFC and I believe that it should not, it must be Informational. My understanding is that the IAOC is not engaged in the day-to-day work, and that's the reason to have the IASA, the secretariat and the IAD. But they need community driven guidelines to be able to follow as much as possible an objective criteria. The current set up is very new. I think it is a very very bad idea to impose policy criterion on these bodies until the dust settles. It has been a long hard struggle to get where we are at right now. Again if the IAOC wishes to consider such criterion then your draft is better edited there then presented to the community. Now, all that said, I don't recall having heard comments from your side on the document during all the process in any of the previous versions. It will be very helpful that you provide them now, but please, try to be constructive by commenting what exactly you dislike and even propose specific text. I'm sure everyone will be happy to consider all the inputs. I have commented on the document. I dont think it should exist and certainly not as a BCP or Standards Track RFC. 1. Venue Selection Criterion is best left to the IAOC to determine policy. 2. Even if there was a need for community input the current IETF administrative structure is very new and some what fragile and we should not for the time being impose unwanted solutions on them they did not solicit support for. -- Richard Shockey, Director - Member of Technical
Re: I-D ACTION:draft-palet-ietf-meeting-venue-selection-criteria-04.txt
John C Klensin wrote: Jordi, Unlike several others and their comments, there are significant parts of this I find useful, at least in terms of identifying issues that should be examined. There are several other parts of it with which I disagree. And, ultimately, the presentation of a list of suggestions without prioritization lowers its utility considerably. On the other hand, I doubt that consensus even on the list of suggested principles is possible. Consensus about how they should be prioritized would be more difficult yet, and consensus among those with significant experience planning and running IETF meetings would certainly be no less difficult. Thank you John. As usual you have summarized many of my own feelings better than I have done. The difficulty, it seems to me, is the combination between that problem with claiming consensus and what can and should be done with the document operationally. It is just my opinion, but I consider anything whose purpose is to tell the IAD, IAOC, or IESG (or the IETF or IASA more generally) how to behave procedurally or decide on things to be completely inappropriate for publication as an independent submission RFC. My point exactly, again many thanks for your clarity. One possibility is to just leave it as an I-D, updating it periodically as needed, but keeping it out there as a perspective that the IAD might consider. as Informational only. -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Possible new Real-Time Applications and Infrastucture (RAI) Area
Melinda Shore wrote: On 9/23/05 5:38 PM, "Dave Crocker" [EMAIL PROTECTED] wrote: For the proposed area, that does not seem to explain the inclusion of ENUM, instant messaging or presence. (This area is going to take over xmpp, too?) ENUM is ancillary to telephony and not really to much else. ENUM's only reason is map E.164 numbers to URI's which in 99.9 % of the cases means VoIP. ENUM's very existance is totally linked to the rest of the SIP applicaiton suite and as such needs to remain with the rest of those groups. But anyway, you'll note that I argued that "real-time" is an unsuitable name because of what it actually means, not that your definition of real-time was vernacular and we need to focus on what's actually real-time. I tend to prefer naming it something around multimedia applications but as long as whatever it is is reasonably descriptive and won't lead to people thinking that it's a proper place to work on things like storage device controllers, I'm good. I thought the original proposal was pretty good and needed little or no editing including hair splitting on what the name of the directorate should be. Real Time Applications is a pretty good descritpion of the general problem set or maybe "Death to the PSTN Directorate?" . can we just get on with it ? Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF has difficulty solving complex problems or alternatively Why IMS is a big fat ugly incomprehensiable protocol
Pekka Nikander wrote: In a whimsical mood, I put up a web page that tries to clarify the comments that I made about complexity during the Paris IETF Thursday plenary. So, for your bed time enjoyment: http://www.tml.tkk.fi/~pnr/FAT/ Pekka this is a outstanding piece of work and I would suggest an alternative thesis that fits your model. Why IMS is similar to grotesque body fat --- the case for cranial liposuction among IMS engineers Compulsive IMS ...how to reckgonise the problem and how to treat it Bulimia networka ( aka IMS ) is defined as a period of uncontrolled definition of network elements. The network designer places up to10,000 boxes in an archichectural design . Bulimia networka is commonly associated with excessive attendance at industry conferences and standards bodies ( Stockholm Syndrome ) followed by purging behaviors, i.e., service provider bankruptcy, layoffs, etc. I'm sure we can expand on the model endlessly... --Pekka Nikander ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The IETF has difficulty solving complex problems or alternatively Why IMS is a big fat ugly incomprehensiable protocol
Spencer Dawkins wrote: This was quite funny - both of you! Of course, the first thing to do when you want to lose complexity is Stop adding to the problem (as in Put down the fork and push away from the table...). Oh..darn ..you mean I cant have a Session Border Controller for dessert ? Grumble Grumble .. burp See you in Vancouver, Spencer From: Richard Shockey [EMAIL PROTECTED] To: Pekka Nikander [EMAIL PROTECTED] Cc: ietf@ietf.org Sent: Friday, September 09, 2005 1:35 PM Subject: Re: The IETF has difficulty solving complex problems or alternatively Why IMS is a big fat ugly incomprehensiable protocol Pekka Nikander wrote: In a whimsical mood, I put up a web page that tries to clarify the comments that I made about complexity during the Paris IETF Thursday plenary. So, for your bed time enjoyment: http://www.tml.tkk.fi/~pnr/FAT/ Pekka this is a outstanding piece of work and I would suggest an alternative thesis that fits your model. Why IMS is similar to grotesque body fat --- the case for cranial liposuction among IMS engineers Compulsive IMS ...how to reckgonise the problem and how to treat it Bulimia networka ( aka IMS ) is defined as a period of uncontrolled definition of network elements. The network designer places up to10,000 boxes in an archichectural design . Bulimia networka is commonly associated with excessive attendance at industry conferences and standards bodies ( Stockholm Syndrome ) followed by purging behaviors, i.e., service provider bankruptcy, layoffs, etc. I'm sure we can expand on the model endlessly... --Pekka Nikander ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Richard Shockey, Director - Member of Technical Staff NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:57141(at)fwd.pulver.com ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683 Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Enum] Re: Last Call: 'Voice Messaging Directory Service' to Proposed Standard
At 10:53 AM 2/3/2005, Stastny Richard wrote: Related to the current discussion at the enum list I am not sure if http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-08.txt http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-08.txt is ready for last call. It defines enumservices and has not been discussed yet in the enum WG at all. Copies of this ID announcement have been cross posted to the ENUM WG from time to time. And as ENUM WG co-chair I've made numerous presentations to the VPIM WG. The process defined in RFC 3761 never the intended that the ENUM WG review all enumservices registrations from other Working Groups. Von: [EMAIL PROTECTED] im Auftrag von The IESG Gesendet: Do 03.02.2005 16:07 An: IETF-Announce Cc: [EMAIL PROTECTED] Betreff: Last Call: 'Voice Messaging Directory Service' to Proposed Standard The IESG has received a request from the Voice Profile for Internet Mail WG to consider the following documents: - 'Voice Messaging Directory Service ' draft-ietf-vpim-vpimdir-09.txt as a Proposed Standard - 'Voice Message Routing Service ' draft-ietf-vpim-routing-08.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-02-17. The files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-vpim-vpimdir-09.txt http://www.ietf.org/internet-drafts/draft-ietf-vpim-routing-08.txt __ Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:[EMAIL PROTECTED] ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Why people by NATs
At 11:33 AM 11/22/2004, Fred Baker wrote: At 09:44 AM 11/22/04 -0500, Eric S. Raymond wrote: Who needs market research? All you have to do is look at the cost-feature profile of the most popular NATs and notice who they were designed for. Those vendors have already done the market research and bet real money on the results. Has anyone mentioned that ISP's charge a absurd premium for multiple static V4 IP numbers in residential markets saying ..oh thats a business service. NAT's exist because IP numbers are made artificially expensive by ISP's. Yes, but be careful with that. What has happened at Linksys and others is that they have come up with a simple configuration that allows them to sell a pre-configured device to a client, advertise a few features that clients like, and sell them like hotcakes with little or no support costs. What the customer is buying is not, in most cases, uses private addressing to separate your IP address space from that of your ISP so that if you move you will not have to reconfigure things. That may be what Linksys etc is selling, but what the customer is buying is plug it in and it will work. Any configuration that gives the customer simplicity of implementation by a non-expert in the technology will meet their needs. To sum up, NAT gives me two features: 1. Multiple machines on the single-address allocation the ISP gives me. 2. Decoupling of mt local network addresses from the ISP assignment. I hear a lot of muttering about NATs being evil. I really don't have an opinion on the subject -- I understand some of the theoretical problems, but they've never bitten me. So, asking as a network administrator, how would the implied problems be solved in an IPv6 world? In an IPv6 world, I would expect your ISP to sell you a /64 at one price or a /48 at another. The /48 is for if you will subnet behind your firewall, which is to say if you are a business. What your Linksys gives you is a fairly common residential configuration - a single LAN encompassing your home. Yes Fred I would _expect_ my ISP to sell me a /64 but at what price? It continues to amaze me that no one discussing the IP V6 adoption issues will focus attention on the obvious question ..what is it going to cost me? Would some nice US DSL provider out there sell me 6M ADSL transport and a V6 /64 for about $49.95 please? I'll even sign a long term contract !! If the RIR's could enforce downstream pricing policy on the IS's for V6 numbering resources we might have a chance. BTW there is an analogy brewing in VoIP. There are proposals out there in some countries to tax phone numbers in order to support universal service efforts. A noble goal to be sure ..but the economic effect will be create a disincentive for the use of phone numbers and potentially move consumers towards the use of URI's for phone dialing. Now that may or may not be a bad idea either but it should highlight that if you price a product ( numbering ) too high people will look for ways to route around it. NAT's have been the inevitable answer to the poor pricing policy of IP numbering. Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org sip:[EMAIL PROTECTED] ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
