Re: Terminal room at IETF74
On Mar 2, 2009, at 1:52 PM, Joel Jaeggli wrote: Dearlove, Christopher (UK) wrote: But now, if I come to IETF74, I won't have a laptop with me. Corporate policy, based on recent US legal decisions, is that I may not take a laptop (or PDA etc.) into the USA. This is not subject to modification. Obviously even a machine in the terminal room would be a very poor second, but it seems even that is out. I don't know about you but I wouldn't trust a public terminal no matter how well maintained for the applications which I carry a laptop. Depending on your bent, either a personal laptop (with no corporate data on it) or a mobile phone with the appropriate email conduit but no pre-existing configuration might be a more desirable (and secure) way to go. The worry is not that the border goons will expose confidential information on one's device, but that they'll CLAIM they did (even if they have to insert it themselves), and there's no way to disprove this when the device is writable. Hence the need to carry no writable devices across the border, not even a USB memory stick or a camera. Or a modern cellphone, for that matter. Of course, that doesn't keep them from claiming that you had a writable device in your possession, then planting one there. Given sufficient paranoia in one's threat model, there's just no way to justify waking up in the morning. -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Terminal room at IETF74
Alexa Morris Actually, the Terminal Room will have two laptops set up for attendee use; these are traditionally used primarily for printing (boarding passes, etc) but are available for other uses as well. That's useful to know. I did enquire of the Secretariat (reference rt.amsl.com #13335) as to whether there would be any such machines, and got a negative answer before raising it here. This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU
Hi guys, I sent the message to this list (as well as LTRU) in the belief I was following the instructions given to me... (My mail actually preceded Martin's request to the AD.) I admit to confusion about the suggestion I can register the change after 4645bis is accepted. 4645bis changes a code that exists already. I shouldn't have to reregister it to restore it. If anything, have 4645bis go forward without the change, and the change can be discussed separately. I'll pursue the discussion on the ltru list as requested and respond to Randy's other comments there. tex -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Presuhn Sent: Monday, March 02, 2009 5:36 PM To: ietf@ietf.org Subject: Re: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU Hi - From: Phillips, Addison addi...@amazon.com To: ietf@ietf.org Sent: Monday, March 02, 2009 9:49 AM Subject: RE: draft-ietf-ltru-4645bis-10.txt issue with preferred value for YU Hi Tex, I don't think this is probably appropriate, at least for this list to consider. Tex's posting came after the document shepherd (co-chair Martin Duerst) had sent the information to our AD requesting that the IESG consider publishing it. So although the IESG has not yet (AFAIK) acted on the request, much less issued an IETF last call, I can understand why ietf@ietf.org might be included. I have already responded to it on both lists, even though I think the issue is probably of little interest to most on the ietf@ietf.org list. Unless instructed to do otherwise by our AD, I would suggest that all follow-on discussion be directed to l...@ietf.org 1. You haven't posted to LTRU's mailing list, only ietf-languages@, yet. Tex's message was posted to *both* lists. 2. Even if draft-4645bis is approved, the process for language tags (in either RFC 4646 or its proposed successor) allow you to register the information you want, if you think it was inappropriately omitted. ... Correct. 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: Internet Society joins Liberty Alliance Management Board: Why?
I think that a rather more fundamental problem is the fact that the IETF constitution prevents any organization or party speaking on behalf of the IETF as a whole. I agree that it would be rather better if the IAB could take on this particular role than ISOC. But even the IAB can only represent a subset of IETF views on this topic. The tendency of NOMCON is to pick an IAB that 'will work together', which tends to mean that conflicting technical views have already been excluded before the IAB discussion begins. At least the IAB could serve as a conduit for Liberty views into the IETF. I don't see ISOC playing that role. From a wider industry view, it is important to recognize here that the Liberty Alliance of 2009 is not the same organization that it was at the start, nor do the same conditions exist in the industry as then. Liberty began at a time when the industry and mainstream press saw 'identity' as a gold rush. Many thought that the first company to establish a claim would gain control of cyberspace and so on. Liberty and AOL Magic Carpet were begun as an attempt to stop Microsoft Passport. At this point we know that the original premise behind that particular industry battle was false. Deployment of an industry wide identity system is a much harder prospect than anyone thought then. There is really no risk that a proprietary system will grow like kudzu and engulf the net and this is now something that all the industry majors understand (but not some VC funded startups predicated on that strategy). So at this point the rule in the identity space is safety in numbers. The major waring factions are now spending considerable time and effort to show that the war is over and there is going to be a concerted joint effort. Thus ISOC joining liberty does not represent the IETF taking sides in a Betamax/VHS battle. That would have been an issue three years ago, it is not really an issue at this point. There are however some technical issues that need to be input to the debate that the IETF does need to take a stand on: 1) The DNS is the sole naming system for the Internet. Identity is not an opportunity to roll out a new naming scheme whether the protocols are proprietary or not, whether the registry is open or not. Uniform naming schemes arise very infrequently. We have only had five uniform addressing schemes since the industrial revolution - latitude/longitude, the postal address system, telephone numbers, UPC barcodes and DNS names. If you can think of another, please let me know, I am thinking of writing a brief history of names. Attempting to create a new naming basis inevitably attracts antibodies. My strong belief is that it is only possible to establish a naming system if people are not really paying attention. At this point everything connected to the Internet is scrutinized by people and organizations and governments that much prefer nothing to happen than for something to happen than might subsequently create a control point that is outside their control. 2) Make the base protocol simple One of the big issues I take with many of the schemes out there is that they take an ISAKMP type approach to technology. Rather than commit to an actual decision we have mechanisms to negotiate mechanisms. It is not necessary to do that. Factor the authentication question out of the federation problem. Authentication technology is a bilateral choice between the end user and the authentication service. The relying party does not need to know anything about the technology or protocol employed. 3) Make the protocol comprehensible The most irritating phenomena in the 'identity' world is the proliferation of jargon. Rather than attempting to learn existing nomenclature, some have invented their own. As a result technical progress tends to be slow. -Original Message- From: ietf-boun...@ietf.org on behalf of John C Klensin Sent: Sun 3/1/2009 10:12 PM To: Patrik Fältström; Dave CROCKER Cc: Hannes Tschofenig; ietf@ietf.org; Lynn St. Amour; dai...@isoc.org Subject: Re: Internet Society joins Liberty Alliance Management Board: Why? Patrik, I fear that I need to side with Dave on this (!). For issues at the technology-policy boundary, ISOC is seen in the outside community as the representative and voice of the IETF. That is generally a good thing and it is an impression many of us have worked for years to create. However, its side-effect is that, if ISOC ventures into a management/policy role with one particular consortium, the same folks we have been trying to persuade that ISOC should be seen as the lead policy body in the Internet technical community --in large measure because it does represent the IETF-- are likely to infer (and reasonably so) IETF endorsement of that consortium and its efforts. That ultimately has little or nothing to do with whether the IETF has active work in the area or how that work is organized. It is the presumption
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
s...@resistor.net writes: If there isn't an authoritative reference and there are differences in semantics or syntax between the draft and RFC5321/5322 or future revisions of these documents, it can lead to serious issues. Standards Track documents are around years. The documents may be edited by different authors as they get updated. Errors can happen; the documents can diverge. In my opinion, it is better to clarify that now or else we will end up having discussions ten years from now to determine which interpretation is correct or which standard to follow. So. RFC 3501 (page 50-51), says that the localpart of a From: address is matched case-insensitively when IMAP servers process SEARCH or UID SEARCH commands. RFC 5321 says that SMTP servers process localparts case-sensitively. Both rules go back essentially unchanged to very old RFCs. Do we need to discuss which is correct or which standard to follow? I fail to see any conflict. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-avt-seed-srtp (The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP)) to Proposed Standard
The IESG has received a request from the Audio/Video Transport WG (avt) to consider the following document: - 'The SEED Cipher Algorithm and Its Use with the Secure Real-time Transport Protocol (SRTP) ' draft-ietf-avt-seed-srtp-09.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 substantive comments to the ietf@ietf.org mailing lists by 2009-03-27. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-avt-seed-srtp-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=16505rfc_flag=0 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
On Mon, 2 Mar 2009, John C Klensin wrote: * Machines in the netbook category have gotten very cheap (cheaper than IETF registration fees, for example). While I would not expect your company to change policy, obtaining a few of those machines and imaging them to contain nothing in local storage of corporate interest would seem economic - you are presumably not the only person who travels to the US. I second this idea. Given the duties on some of these systems in the EU, you might consider buying from a US vendor, having the machine shipped to the IETF hotel, and installing your choice of OS when you arrive. And then you entirely avoid taking the system through US customs in the interesting direction. Also consider used laptops: I just picked up a used Dell Latitude for about the same price as a netbook (and half the price of IETF registration), and I'm delighted. -- Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard
s...@resistor.net writes: If there isn't an authoritative reference and there are differences in semantics or syntax between the draft and RFC5321/5322 or future revisions of these documents, it can lead to serious issues. Standards Track documents are around years. The documents may be edited by different authors as they get updated. Errors can happen; the documents can diverge. In my opinion, it is better to clarify that now or else we will end up having discussions ten years from now to determine which interpretation is correct or which standard to follow. So. RFC 3501 (page 50-51), says that the localpart of a From: address is matched case-insensitively when IMAP servers process SEARCH or UID SEARCH commands. RFC 5321 says that SMTP servers process localparts case-sensitively. Both rules go back essentially unchanged to very old RFCs. But that's the problem - this is not what RFC 5321 says. It says: Consequently, and due to a long history of problems when intermediate hosts have attempted to optimize transport by modifying them, the local-part MUST be interpreted and assigned semantics only by the host specified in the domain part of the address. SMTP server do stuff like expand lists all the time. For those tests to be done competently some amount of interpretation of local parts may be needed, such as ignoring the possibility that the local part is case sensitive. Now, if RFC 5321 instead said that interpretation of local parts MUST be limited to comparison operations, and local parts MUST NOT be modified, the problem mostly goes away. (There are probably still some odd corner cases left for gateways, but after thinking about it some more I think we can ignore those.) Do we need to discuss which is correct or which standard to follow? I fail to see any conflict. I have to disagree. While there may not be any conflict between RFC 3501 and RFC 5321 since they deal with separate components, the fact remains that there's a conflict between what real world implementations do and what RFC 5321 says must not be done. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Internet Society joins Liberty Alliance Management Board: Why?
So at this point the rule in the identity space is safety in numbers. The major waring factions are now spending considerable time and effort to show that the war is over and there is going to be a concerted joint effort. Thus ISOC joining liberty does not represent the IETF taking sides in a Betamax/VHS battle. That would have been an issue three years ago, it is not really an issue at this point. So, who is the winner? (Or are there only loosers, more like in a real war?) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Tools to Publish I-Ds with pre-5378 Content
All; Several tools to publish Internet Drafts have implemented the IETF Trust's recent policy changes that provide a work-around to the issues raised by the inclusion of material from contributions published before 10 November 2008. You may have already been aware of one or more of the tools from other lists, or discussions on this list, but the Trust wanted to consolidate the information to ensure its general and aggregated availability, even at this time, just 24 hours before the -00 deadline for IETF 74. If your Internet Draft contains pre-5378 Material as to which the IETF Trust has not been granted, or may not have been granted, the necessary permissions to allow modification of such pre-5378 Material outside the IETF Standards Process then section 6.c.iii from http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf must be included in the draft. Volunteers who created and maintain the tools have implemented the updates: 1. idnits - (thanks Henrik Levkowetz) 2. Word template - (thanks Joe Touch) 3. xml2rfc - (thanks Bill Fenner and Marshall Rose) The tools can be found at: 1. idnits - http://tools.ietf.org/tools/ 2. Word template - http://tools.ietf.org/inventory/author-tools.shtml 3. xml2rfc - http://xml.resource.org/experimental.html A little more info on the xml2rfc variants (borrowed from Julian Reschke - thanks) This version, v1.34pre3, implements the IETF Trust language of November, 2008 and February, 2009. Briefly, you want to set the 'ipr' attribute of the rfc/ element to one of these values: trust200811 noModificationTrust200811 noDerivativesTrust200811 trust200902 noModificationTrust200902 noDerivativesTrust200902 pre5378Trust20090 The final value in the list above is probably the one of interest to most folks. At this point, only the *200902* variants should be relevant (not all of those changed from 200811, but we added all of them for consistency). (1) trust200902 is the value to choose when no restrictions are being made. (2) noModificationTrust200902 adds This document may not be modified, and derivative works of it may not be created, except to format it for publication as an RFC or to translate it into languages other than English. as defined in Section 6.c.i of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf. (3) noDerivativesTrust200902 adds This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. as defined in Section 6.c.ii of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf. (4) pre5378Trust200902 adds This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. as defined in Section 6.c.iii of http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf. This is the new variant that was introduced because of the problems discovered in November with RFC 5378. Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
In message alpine.bsf.2.00.0903021337550.15...@fledge.watson.org, Samuel Weil er writes: On Mon, 2 Mar 2009, John C Klensin wrote: * Machines in the netbook category have gotten very cheap (cheaper than IETF registration fees, for example). While I would not expect your company to change policy, obtaining a few of those machines and imaging them to contain nothing in local storage of corporate interest would seem economic - you are presumably not the only person who travels to the US. I second this idea. Given the duties on some of these systems in the EU, you might consider buying from a US vendor, having the machine shipped to the IETF hotel, and installing your choice of OS when you arrive. And then you entirely avoid taking the system through US customs in the interesting direction. Also consider used laptops: I just picked up a used Dell Latitude for about the same price as a netbook (and half the price of IETF registration), and I'm delighted. -- Sam ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf There is no interesting direction. I'm pretty sure customs gets the same sort of search and ceasure rights on exit and it does on arrival. They do here in Australia. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Running Code
I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt Thanks. -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Repair of Public Mail List Archives Complete
As I mentioned late last week, as a side effect of a recent Mailman upgrade some mail lists with previously public archives had their list configuration reset to private archiving, resulting in inaccessible archives. This archiving issue has now been repaired and the missing archives have been transferred from private to public. All lists with public archives should now have the complete set of messages. As always, please contact me with any questions or concerns. Regards, Alexa --- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amor...@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com http://www.amsl.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Marc, and Henry, I think adding any new mandatory section to all I-Ds is a bad idea. It will quickly become bureaucratic. We've had proposals for mandatory Management Considerations, IPv6 Considerations, and no doubt others that I've forgotten, and they all have the same problem. However, I think it's a very good idea to offer *guidelines* for what should be in technical specifications in this area. In fact, my old commentary on RFC2026 talked about related issues concerning interoperability criteria for promotion to Draft Standard. See the comments on 4.1.2 Draft Standard in http://tools.ietf.org/id/draft-carpenter-rfc2026-practice-00.txt Obviously, the first stage in interoperability is interoperability with yourself ;-). (As far as I am concerned, you are welcome to use any of that material under RFC5378 conditions.) I encourage your draft to become purely a set of guidelines. That would be useful and non-bureaucratic. Brian On 2009-03-04 10:17, Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt Thanks. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Passing of Jim Bound
This is very sad news. Jim was a very strong supporter of the IETF and IPv6. Jim served the community as: - IPv6 Forum Chief Technology Officer - Chair of the North American IPv6 Task Force - Active IETF contributor, including member of the IPng Directorate We will miss him. Russ --- forwarded message --- From: Pouffary, Yanick yanick.pouff...@hp.com Date: March 3, 2009 8:23:07 AM EST To: nav...@ipv6forum.com, memb...@ipv6forum.com Subject: Jim Bound Dear IPv6-ers, Jim Bound passed away yesterday. Jim was only 58 years old. Jim was a symbol of integrity and professionalism. He made a profound impact on our industry and everyone who worked with him. I am very fortunate to have been able to also call Jim friend. Very very sad time, Yanick ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Brian E Carpenter wrote: Marc, and Henry, I think adding any new mandatory section to all I-Ds is a bad idea. It will quickly become bureaucratic. We've had proposals for mandatory Management Considerations, IPv6 Considerations, and no doubt others that I've forgotten, and they all have the same problem. I agree that its sounds bad when presented like this. The main motivation is to provide an incentive for early implementations of a protocol, because I am convinced that this is a very important factor on the quality of a protocol. I had to implement at least three times TURN from scratch during it's development and this is an exhausting task. This explain why a lot of developers simply wait for the protocol to be stable (read: been published as an RFC), and so deprive the protocol design of an important feedback. Giving to early implementers a guaranty that their contributions will not be forgotten is a way to counterbalance the time and effort spent in working on this contributions. However, I think it's a very good idea to offer *guidelines* for what should be in technical specifications in this area. In fact, my old commentary on RFC2026 talked about related issues concerning interoperability criteria for promotion to Draft Standard. See the comments on 4.1.2 Draft Standard in http://tools.ietf.org/id/draft-carpenter-rfc2026-practice-00.txt Obviously, the first stage in interoperability is interoperability with yourself ;-). (As far as I am concerned, you are welcome to use any of that material under RFC5378 conditions.) I encourage your draft to become purely a set of guidelines. That would be useful and non-bureaucratic. Brian On 2009-03-04 10:17, Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt Thanks. -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
--On Wednesday, March 04, 2009 07:51 +1100 Mark Andrews mark_andr...@isc.org wrote: ... There is no interesting direction. I'm pretty sure customs gets the same sort of search and ceasure rights on exit and it does on arrival. They do here in Australia. In principle, probably. In practice, travelers leaving the US don't even get to see customs officials. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Terminal room at IETF74
In message ee08613c757444318d788...@pst.jck.com, John C Klensin writes: --On Wednesday, March 04, 2009 07:51 +1100 Mark Andrews mark_andr...@isc.org wrote: ... There is no interesting direction. I'm pretty sure customs gets the same sort of search and ceasure rights on exit and it does on arrival. They do here in Australia. In principle, probably. In practice, travelers leaving the US don't even get to see customs officials. I beg to differ. I've seen them myself. Not often but on more than one occassion. john -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Harald Alvestrand wrote: Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt There used to be a term for those who attempted to manipulate the shape of the universe by manipulating the names in the Usenet hierarchy. I get the same impression from people who want to manipulate IETF behaviour by manipulating the shape of Internet-Drafts. I do not see how you can have this impression, as the I-D does not try to make implementations mandatory for Internet-Drafts - _that_ would be changing the IETF behavior. What the document says is that early implementers efforts should be rewarded by listing their name, sponsors and access to their code as a thank you for helping improve the protocol. That does not change the IETF behavior - at best that will change the quality of IETF protocols. -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
I admit that I'm no friend of additional I-D sections, as they easily generate into boilerplate and make work projects. If the goal, which does not seem stated, is to acknowledge the contributions of implementations in improving a standards document, we already have a mechanism for that, namely the customary acknowledgements found in most RFCs. I don't think anybody would object to saying something like The authors gratefully recognize the efforts of Joe Programmer, whose XYZ implementation of early versions of the draft helped to remove useless crud from the spec. [well, maybe not quite verbatim like that.] We can never hope to acknowledge all implementations in any event; for example, many are done by students in classes, and are never released (and that's a good thing...). It seems much more useful to capture implementations on WG-related web pages; after all, the value of implementations does not step when the I-D hits the RFC editor's desk. We also certainly don't want to put yet more hurdles into the path of getting drafts published. Does the RFC editor have to verify the URLs and that they still exist? Do we worry about advertising pages and implementations that turn out to be malicious? I'd really rather not have to deal with an RFC where a domain of a fledgling open-source project was taken over by a malware distributor. Henning I do not see how you can have this impression, as the I-D does not try to make implementations mandatory for Internet-Drafts - _that_ would be changing the IETF behavior. What the document says is that early implementers efforts should be rewarded by listing their name, sponsors and access to their code as a thank you for helping improve the protocol. That does not change the IETF behavior - at best that will change the quality of IETF protocols. -- Marc Petit-Huguenin Home: m...@petit-huguenin.org Work: petit...@acm.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: Running Code
I don't see the value of running code quite as others do. For me the value of running code is that the requirement to actually implement stuff does tend to reduce the scope for complexity, you have someone in the room pushing against something that will make work for them. And the other advantage is that there tends to be a closer relationship to actual real world needs. But you do not have to do A to get B and doing A does not guarantee that you get B. Another alternative is to require people to produce a proof of correctness for their protocol. That provides even greater encouragement to be concise and to get it right the first time. The running code strategy can also backfire. I have seen groups where one party has a large development team on call that allows them to drive the specification. And I have also seen groups where no progress can be made because the programmer who wrote the dufus code won't allow the dufus to be deleted from the spec. Coding too early can also be a problem. -Original Message- From: ietf-boun...@ietf.org on behalf of Brian E Carpenter Sent: Tue 3/3/2009 4:54 PM To: Marc Petit-Huguenin Cc: ietf@ietf.org Subject: Re: Running Code Marc, and Henry, I think adding any new mandatory section to all I-Ds is a bad idea. It will quickly become bureaucratic. We've had proposals for mandatory Management Considerations, IPv6 Considerations, and no doubt others that I've forgotten, and they all have the same problem. However, I think it's a very good idea to offer *guidelines* for what should be in technical specifications in this area. In fact, my old commentary on RFC2026 talked about related issues concerning interoperability criteria for promotion to Draft Standard. See the comments on 4.1.2 Draft Standard in http://tools.ietf.org/id/draft-carpenter-rfc2026-practice-00.txt Obviously, the first stage in interoperability is interoperability with yourself ;-). (As far as I am concerned, you are welcome to use any of that material under RFC5378 conditions.) I encourage your draft to become purely a set of guidelines. That would be useful and non-bureaucratic. Brian On 2009-03-04 10:17, Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt Thanks. ___ 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: Running Code
Hallam-Baker, Phillip wrote: I don't see the value of running code quite as others do. I agree. It was valuable in good old days, when implmenting a protocol was purely voluntary with no budget. Existence of multiple independent implementations, then, meant the protocol was widely accepted by the society. However, after the overly introduction of standardization engineering to IETF, people satisfy requirements merely because they are required. So, existence of required running code does not mean much. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yo Masataka! On Wed, 4 Mar 2009, Masataka Ohta wrote: So, existence of required running code does not mean much. Except a basic proof of real functionality and that is valuable. RGDS GARY - --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFJrejvBmnRqz71OvMRAi+VAKCVsUj7BHea+p5/9S/4HFuQLI/iBwCgvHaQ TWSzTobAnC1lNpsvEvqE1iY= =Kysh -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Masataka Ohta wrote: Hallam-Baker, Phillip wrote: I don't see the value of running code quite as others do. I agree. It was valuable in good old days, when implmenting a protocol was purely voluntary with no budget. Existence of multiple independent implementations, then, meant the protocol was widely accepted by the society. However, after the overly introduction of standardization engineering to IETF, people satisfy requirements merely because they are required. So, existence of required running code does not mean much. I disagree. It means the specification is implementable. Since the goal of our work is to produce specifications that will allow multiple independent implementations to inter-operate successfully, I can think of no more valuable review input towards this goal than comments from implementers. I think adequate procedures exist for gathering implementation experience for the IESG to evaluate protocol interoperability. Masataka Ohta Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Harald Alvestrand wrote: Marc Petit-Huguenin wrote: I would like to bring to your attention this proposal to put back running code at the center of Internet protocol design by adding a new Considerations Section in future Internet-Drafts and RFCs: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt There used to be a term for those who attempted to manipulate the shape of the universe by manipulating the names in the Usenet hierarchy. I get the same impression from people who want to manipulate IETF behaviour by manipulating the shape of Internet-Drafts. I do not see how you can have this impression, as the I-D does not try to make implementations mandatory for Internet-Drafts - _that_ would be changing the IETF behavior. On the contrary, that's exactly what it does. Quoting from the draft: The Running Code Considerations section MUST be present in all Internet-Draft and SHOULD be inserted after the Security Considerations and IANA Considerations sections. This section MUST be present even if the document does not describe an implementable protocol and should contain in this case a text explaining why this section is irrelevant. The RFC Editor can remove this Running Code Considerations section before publication as RFC. I'm already on record as oppossing the addition of such bureaucratic folderol in other cases. And while I'm a big believer in running code and always try to implement what's described in my drafts before calling them complete, I think this proposal is an absolutely terrible idea. What the document says is that early implementers efforts should be rewarded by listing their name, sponsors and access to their code as a thank you for helping improve the protocol. That does not change the IETF behavior - at best that will change the quality of IETF protocols. You need to read the draft again because that is not what it says. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Andy Bierman wrote: So, existence of required running code does not mean much. I disagree. It means the specification is implementable. If a protocol is so complex that its implementability is not obvious, you have lost from the beginning. Since the goal of our work is to produce specifications that will allow multiple independent implementations to inter-operate successfully, How can you define successful interoperation of implementations? I think adequate procedures exist for gathering implementation experience for the IESG to evaluate protocol interoperability. Such formalism has killed IETF. To formally confirm that multiple implementations of a protocol interoperate, which is required these days, you really need to have a formal specification of a protocol, which, if any, is very complex even if an informal specification of the protocol is simple. If all you want is informal and vague feeling of interoperability, it is not a very useful review. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Internet Society joins Liberty Alliance Management Board: Why?
On Mar 1, 2009, at 9:04 PM, Eric Rescorla wrote: At Sun, 1 Mar 2009 19:59:00 +0200, Hannes Tschofenig wrote: As you might have noticed, the WebSSO Identity Management space is not running out of organizations and groups. Someone could, for example, come up with the question why ISOC did not join the MIT Kerberos Consortium (see http://www.kerberos.org/), as Kerberos is a technology developed within the IETF, or to support technologies like OpenID, OAuth, etc. that are closer to the Internet deployment. I am sure your team had a lot of conversations with the IAB on what direction would be better for the Internet (with respect to the creation of an identity layer) but I fear that many in the IETF community are at best not informed about what you are doing and why you believe that this is heading into the right direction. Did ISOC in fact have these discussions with the IAB? I'd be very interested to hear the IAB weigh in here. -Ekr Hi Ekr and Hannes, ISOC has been working within the IETF community as a whole on a variety of technical issues, and did not approach the IAB as a body when taking the decision to join Liberty Alliance/NewOrg. ISOC's broad goals here seem largely to fall outside the IETF arena. We are working with these other communities to build a more transparent and open identity organization which serves the broader identity community, and reaches out to adopters and end-users. We are, of course, very open to conversation about advancing these goals with any interested IETFer. And, to be clear we are very supportive of the OAuth efforts and hope to see OAuth chartered in the IETF. I echo Dave's original comments that this discussion is interesting and useful, and Leslie has provided some additional context in another mail. Best, Lynn ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Running Code
We also certainly don't want to put yet more hurdles into the path of getting drafts published. Does the RFC editor have to verify the URLs and that they still exist? Do we worry about advertising pages and implementations that turn out to be malicious? I'd really rather not have to deal with an RFC where a domain of a fledgling open-source project was taken over by a malware distributor. Henning I would like to provide one recent example. In the EMU working group we worked on a protocol, called EAP-GPSK http://www.ietf.org/rfc/rfc5433.txt. The work was done in a design team, it took a very long time (the first design team draft dates back to May 2006). Jouni Malinen implemented the protocol in 8 hours! Jouni also provided a number of suggestions and we put him into the acknowledgments section. Before the draft got published as an RFC the reference to his implementation was removed by the RFC Editor. The RFC Editor also verified the URL and it was not correct anymore (but that's another topic). As mentioned in http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00. txt the problem with feeding experience with running code back into the specification work is elsewhere. There are three main problems: * Almost random changes to the specification make early implementation work almost useless (if your goal is to produce code that aims having code for a specific RFC after all). Since it takes so long to finish the standardization work it is often not possible to wait till the RFC comes out. * Nobody cares if you have running code. Requests to substantially change the specification often come at a late stage. Even IESG members have already re-written specifications during IETF Last Call. As a joke, I suggested to just submit the table of contents to the IESG and then start the work there. * Finally, because it takes so long to finish specifications the 3-level Standards Track process is rarely utilized anymore. That process considers interoperable code but what does it help? Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'ForCES Protocol Specification' to Proposed Standard
The IESG has approved the following document: - 'ForCES Protocol Specification ' draft-ietf-forces-protocol-22.txt as a Proposed Standard This document is the product of the Forwarding and Control Element Separation Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-forces-protocol-22.txt Technical Summary This document specifies the Forwarding and Control Element Separation (ForCES) protocol. ForCES protocol is used for communications between Control Elements(CEs) and Forwarding Elements (FEs) in a ForCES Network Element (ForCES NE). This specification is intended to meet the ForCES protocol requirements defined in RFC3654. Besides the ForCES protocol, this specification also defines the requirements for the Transport Mapping Layer (TML). Working Group Summary No dissent reported. This document is the result of a merger of several proposals from competing design teams and represents a good WG consensus. Protocol Quality There are at least four different implementations of this protocol (see the PROTO writeup in the tracker). This specification has been extensively reviewed, and has been updated based on these reviews including routing directorate reviews by Sue Hares and Alia Atlas, Gen-Art review by Eric Gray, Sec-Dir review by Uri Blumenthal, and IESG review. IANA Note Jamal Hadi Salim [h...@znyx.com] has volunteered to be the designated IANA expert for this document. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: RECHARTER: IP Performance Metrics (ippm)
The charter of the IP Performance Metrics (ippm) working group in the Transport Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. IP Performance Metrics (ippm) Last Modified: 2009-02-19 Status: Active Working Group Additional information is available at tools.ietf.org/wg/ippm Chair(s): Matthew Zekauskas [m...@internet2.edu] Henk Uijterwaal [h...@ripe.net] Transport Area Director(s): Magnus Westerlund [magnus.westerl...@ericsson.com] Lars Eggert [lars.egg...@nokia.com] Transport Area Advisor: Lars Eggert [lars.egg...@nokia.com] Mailing Lists: General Discussion: i...@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/ippm In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/ippm/index.html Description of Working Group: The IPPM WG has developed a set of standard metrics that can be applied to the quality, performance, and reliability of Internet data delivery services. These metrics are designed such that they can be performed by network operators, end users, or independent testing groups. It is important that the metrics not represent a value judgment (i.e. define good and bad), but rather provide unbiased quantitative measures of performance. Functions peripheral to Internet data delivery services, such as NOC/NIC services, are beyond the scope of this working group. The IPPM WG has produced documents that define specific metrics and procedures for accurately measuring and documenting these metrics. This is the current list of fundamental metrics and the existing set of derived metrics. - connectivity - one-way delay and loss - round-trip delay. - delay variation - loss patterns - packet reordering - bulk transport capacity - link bandwidth capacity - packet duplication The working group will advance these metrics along the standards track within the IETF. The WG will document the process of moving documents along the standards track, based on draft-bradner-metricstest. As this process is likely to be needed by other groups as well (in particular BMWG, PMOL), the group will collaborate with other groups in order to ensure that there is consensus amongst all groups expected to use the process. Additionally, the WG will produce Proposed Standard AS documents, comparable to applicability statements in RFC 2026, that will focus on procedures for measuring the individual metrics and how these metrics characterize features that are important to different service classes, such as bulk transport, periodic streams, packet bursts or multimedia streams. Each AS document will discuss the performance characteristics that are pertinent to a specified service class; clearly identify the set of metrics that aid in the description of those characteristics; specify the methodologies required to collect said metrics; and lastly, present the requirements for the common, unambiguous reporting of testing results. The AS documents can also discuss the use of the metrics to verify performance expectations, such as SLA's, report results to specific user groups or investigate network problems. The focus is, again, to define how this should be done, not to define a value judgment. The WG may define additional statistics for its metrics if needed. Specific topics of these AS documents must be approved by the Area Directors as charter additions. The WG will work on documents describing how to compose and decompose the results of its metrics over time or space. The WG has produced protocols to enable communication among test equipment that implements the one- and two-way metrics (OWAMP and TWAMP respectively). OWAMP and TWAMP will be advanced along the standards track. Further development of these protocols will also be done inside the WG. The metrics developed by the WG were developed inside an active measurement context, that is, the devices used to measure the metrics produce their own traffic. However, most metrics can be used inside a passive context as well. No work is planned is this area though, this may be changed with AD approval. The intent of the WG is to cooperate with other appropriate standards bodies and forums (such as ATIS IIF, ITU-T SG 12, 13 and 15, MEF) to promote consistent approaches and metrics. Within the IETF process, IPPM metrics definitions will be subject to as rigorous a scrutiny for usefulness, clarity, and accuracy as other protocol standards. The IPPM WG will interact with other areas of IETF activity whose scope intersect with the requirement of these specific metrics. The WG will, on request, provide input to other IETF WG on the use of these metrics. Goals and Milestones: Done Submit drafts of standard metrics for connectivity and treno- bulk-throughput. Done Submit a framework document describing terms and notions used in the IPPM effort, and the creation of metrics by the working group to IESG for
RFC 5432 on Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP)
A new Request for Comments is now available in online RFC libraries. RFC 5432 Title: Quality of Service (QoS) Mechanism Selection in the Session Description Protocol (SDP) Author: J. Polk, S. Dhesikan, G. Camarillo Status: Standards Track Date: March 2009 Mailbox:jmp...@cisco.com, sdhes...@cisco.com, gonzalo.camari...@ericsson.com Pages: 9 Characters: 17614 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mmusic-qos-identification-03.txt URL:http://www.rfc-editor.org/rfc/rfc5432.txt The offer/answer model for the Session Description Protocol (SDP) assumes that endpoints somehow establish the Quality of Service (QoS) required for the media streams they establish. Endpoints in closed environments typically agree out-of-band (e.g., using configuration information) regarding which QoS mechanism to use. However, on the Internet, there is more than one QoS service available. Consequently, there is a need for a mechanism to negotiate which QoS mechanism to use for a particular media stream. This document defines such a mechanism. [STANDARDS TRACK] This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5443 on LDP IGP Synchronization
A new Request for Comments is now available in online RFC libraries. RFC 5443 Title: LDP IGP Synchronization Author: M. Jork, A. Atlas, L. Fang Status: Informational Date: March 2009 Mailbox:markus.j...@genband.com, alia.at...@bt.com, luf...@cisco.com Pages: 7 Characters: 15475 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mpls-ldp-igp-sync-04.txt URL:http://www.rfc-editor.org/rfc/rfc5443.txt In certain networks, there is dependency on the edge-to-edge Label Switched Paths (LSPs) setup by the Label Distribution Protocol (LDP), e.g., networks that are used for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) applications. For such applications, it is not possible to rely on Internet Protocol (IP) forwarding if the MPLS LSP is not operating appropriately. Blackholing of labeled traffic can occur in situations where the Interior Gateway Protocol (IGP) is operational on a link on which LDP is not. While the link could still be used for IP forwarding, it is not useful for MPLS forwarding, for example, MPLS VPN applications or Border Gateway Protocol (BGP) route-free cores. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This memo provides information for the Internet community. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5484 on Associating Time-Codes with RTP Streams
A new Request for Comments is now available in online RFC libraries. RFC 5484 Title: Associating Time-Codes with RTP Streams Author: D. Singer Status: Standards Track Date: March 2009 Mailbox:sin...@apple.com Pages: 13 Characters: 25408 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-avt-smpte-rtp-15.txt URL:http://www.rfc-editor.org/rfc/rfc5484.txt This document describes a mechanism for associating %time-codes, as defined by the Society of Motion Picture and Television Engineers (SMPTE), with media streams in a way that is independent of the RTP payload format of the media stream itself. [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 5485 on Digital Signatures on Internet-Draft Documents
A new Request for Comments is now available in online RFC libraries. RFC 5485 Title: Digital Signatures on Internet-Draft Documents Author: R. Housley Status: Informational Date: March 2009 Mailbox:hous...@vigilsec.com Pages: 14 Characters: 29582 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-housley-internet-draft-sig-file-08.txt URL:http://www.rfc-editor.org/rfc/rfc5485.txt This document specifies the conventions for digital signatures on Internet-Drafts. The Cryptographic Message Syntax (CMS) is used to create a detached signature, which is stored in a separate companion file so that no existing utilities are impacted by the addition of the digital signature. 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-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
