Re: Running Code
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 I like the idea. However, I'd put some comments: * Acknowledgments already have their section, thus it would be preferable to use that to mention any authors and sponsors who contributed code for a specific protocol. There is no need to remove such acknowledgments upon publication. * Obsolete code is useless. Anyone interested in knowing what code was available for version 00 can browse that version of the draft, or the historical sections at any referenced URLs. * It may be worth mentioning development problems, implementation strategies, compatibility or integration issues, test suites, and the like. Should that section be the preferred place for discussing implementation issues, quoting code snippets while pointing to complete projects? * IMHO, rather than being a throw-away section, Running Code Considerations should evolve into sections possibly published in the final RFCs, for two types of content: (i) mentions of established packages that implement the (final) protocol, and (ii) any guidelines and caveats for implementors. Just my 2p ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Terminal room at IETF74
From: John C Klensin [mailto:john-i...@jck.com] 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. Putting aside whether I could buy such a machine, and assuming taking it out of the US would be OK policy-wise (that I'd have to check, I suspect it's within the letter but not the spirit of the policy) as soon as it's outside the US it's a company machine I couldn't take back in. Puchasing a laptop per trip is not very economic. 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: Running Code
Hi, On 2009-3-3, at 22:54, Brian E Carpenter wrote: 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. agree with Brian. Also, RFC4858 already recommends that the Document Quality section of the document announcement that is emailed out when the IESG approves a document describe implementation status. So it's not like we don't have a way in which to document implementation status; we simply don't do it very often. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Hannes, 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! Not a good spec time / implementation time ratio! There are also examples of people starting and *finishing* their PhD on the topic of an RFC *before* the RFC comes out. Not a good sign of the effort required to publish an RFC... Picture about the process for this particular draft can be found in http://www.arkko.com/tools/lifecycle/draft-ietf-emu-eap-gpsk-timing.html -- what can we do to make the process smoother? 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? These are issues. And my opinion is that we have to take implementation experience very seriously. I would like to disagree with you on the assertion nobody cares if you have running code, however. I think all of us care. But running code does not necessarily override ALL other concerns. If there's a serious bug in the spec, it needs to be fixed, even if it is noticed late in the process. Personally, I find that we waste most of the time waiting (for reviews, for the author to revise a spec, for the AD to respond, etc). If we reduce that we can get the process much faster. The entire value of the IETF specification effort is that you get comments and as a result the specification improves. That necessarily implies that there may be changes from your initial implementation. If the goal is absolute minimum publication time and no changes to implementation, we should all just be publishing protocol specifications on our web pages or talking to the RFC Editor -- and this is what we do in many cases, but it is not the right approach for producing a standard. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 3484 section 6 rule 9 causing more operational problems
It seems that Vista implements RFC 3484 address selection, including the requirement to sort IP addresses. This breaks a great deal of operational dependence on DNS-based load balancing, as well as being based on an incorrect understanding of how IP addresses are allocated. RFC 3484 needs to be updated to delete this rule, so that the order returned from the DNS is honoured when the client has no better knowledge about which address is appropriate. See http://drplokta.livejournal.com/109267.html http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html http://lists.debian.org/debian-ctte/2007/11/msg00029.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Dear colleagues, On Tue, Mar 03, 2009 at 01:17:07PM -0800, Marc Petit-Huguenin wrote: http://www.ietf.org/internet-drafts/draft-petithuguenin-running-code-considerations-00.txt I oppose this draft, on the following grounds: 1. It adds yet another required section to I-Ds. If we have not already passed it, we are certainly approaching the point at which the required sections and boilerplate make up more of the document than the substantive parts in a short draft. 2. It imposes a requirement that is impossible to guarantee one has satisfied: it requires that all implementations MUST be listed. I am personally familiar with at least one case where an early implementation was completed in house and scrapped without telling anyone it had been done. 3. It implicitly requires that the running code be publicly available. This is contrary to the traditional IPR agnosticism of the IETF. I understand the point of the draft, and I think the goal is laudable. But if we want to encourage early implementations, running code, and interoperability tests, that goal will not be served by making the drafting process more bureaucratic (or indeed by generally adding more process rules). I think others have made these points in their remarks, too, so you can just add my voice to the chorus. Best regards, Andrew -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Ned Freed wrote: 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. A Running Code Considerations section can be empty, this is the reason of the last sentence (this is similar to what is done for the IANA Consideration Section). If a protocol described in an I-D has no implementation then the section is empty, and people can decide to invest in this protocol using this information. This to say, again, that the text does not implies that implementations are mandatory, just that their existence must be documented in the I-D. I'm talking about the mandatory nature of the section. What the seection says is irrelevant. More mandatory sections are bad and that's exactly what this proposal calls for. If a draft author wants to describe implementation work and how it has helped produce the document, that can be done in the acknowledgements section. So, while I entirely support the development of codde in parallel with specifications, I am totally opposed to ideas put forward in this draft. The absolute last thing we need is ANYTHING that makes getting documents through the process more difficult. We have too much piled on crap as it is. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
On 3/3/09 9:08 PM, Masataka Ohta wrote: Andy Bierman wrote: 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? IMHO you define it by running code -- that is, code which is used to run a functioning communications network. For me the canonical example is the medium we're using right now: email. In general (there are always exceptions!), you don't know or care what email clients people use, what email servers they use, whether they retrieve their email using POP or IMAP, etc. It just works, at least for the core use cases. And I think that's why running code (not just compiling code or functioning code, but a working network) is so important. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Running Code
Hi Jari, Hannes, 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! Not a good spec time / implementation time ratio! Nope. That's also what I thought. There are also examples of people starting and *finishing* their PhD on the topic of an RFC *before* the RFC comes out. Not a good sign of the effort required to publish an RFC... Picture about the process for this particular draft can be found in http://www.arkko.com/tools/lifecycle/draft-ietf-emu-eap-gpsk-ti ming.html 2 years and 8 months -- super fast in comparison with other documents. -- what can we do to make the process smoother? Good that you ask (and this was not arranged). Here is the draft with throughts from Henning, Markus and myself: http://www.ietf.org/internet-drafts/draft-tschofenig-rai-reducing-delays-00. txt 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? These are issues. And my opinion is that we have to take implementation experience very seriously. I would like to disagree with you on the assertion nobody cares if you have running code, however. Maybe this is just reflecting a bit my frustration. My recent example: http://www.ietf.org/mail-archive/web/emu/current/msg0.html Timeline for that document: http://www.arkko.com/tools/lifecycle/draft-ietf-geopriv-radius-lo-timing.htm l I think all of us care. But running code does not necessarily override ALL other concerns. If there's a serious bug in the spec, it needs to be fixed, even if it is noticed late in the process. I agree. It is certainly not black and white. Personally, I find that we waste most of the time waiting (for reviews, for the author to revise a spec, for the AD to respond, etc). If we reduce that we can get the process much faster. The entire value of the IETF specification effort is that you get comments and as a result the specification improves. That necessarily implies that there may be changes from your initial implementation. If the goal is absolute minimum publication time and no changes to implementation, we should all just be publishing protocol specifications on our web pages or talking to the RFC Editor -- and this is what we do in many cases, but it is not the right approach for producing a standard. You are certainly correct. I am certainly not asking for instant publication of everything. I would, however, like to reduce the publication delay from 5+ years down to something more reasonable. Ciao Hannes Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 3484 section 6 rule 9 causing more operational problems
[It seems to me that this discussion needs to happen in dnsext, so I've added a Reply-To header to that effect.] On Wed, Mar 04, 2009 at 02:09:22PM +, Tony Finch wrote: RFC 3484 needs to be updated to delete this rule May I assume that we'll see your I-D specifying the change as soon as possible, then? (I appreciate that it's a little late for a -00, but maybe after the queue re-opens?) Best regards, A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Peter Saint-Andre wrote: On 3/3/09 9:08 PM, Masataka Ohta wrote: Andy Bierman wrote: 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? You gather implementation reports. You conduct interoperability tests and bake-offs. This used to happen a lot more, back when advancing to Draft or Full Standard was considered important. IMHO you define it by running code -- that is, code which is used to run a functioning communications network. For me the canonical example is the medium we're using right now: email. In general (there are always exceptions!), you don't know or care what email clients people use, what email servers they use, whether they retrieve their email using POP or IMAP, etc. It just works, at least for the core use cases. And I think that's why running code (not just compiling code or functioning code, but a working network) is so important. Peter Andy ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
On Wed, 4 Mar 2009, Paul Vixie wrote: i disagree. dns-based load balancing is an unfortunate overloading and should never be done. RFC 3484 is correct as it is. Why is it right for topology-ignorant clients to override topology-aware DNS servers based on wishful thinking about RIR address allocation policies? Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
Margaret Wasserman wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. Margaret ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Margaret Will this break any official or unofficial ID processing tools? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On Wed, Mar 4, 2009 at 7:33 AM, Margaret Wasserman m...@lilacglade.org wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. Oh, yes please. That would immensely increase the usability of RFCs. -Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On 3/4/09 10:33 AM, Margaret Wasserman m...@lilacglade.org wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I like this suggestion a lot. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On Mar 4, 2009, at 10:38 AM, Stewart Bryant wrote: Margaret Wasserman wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. Margaret ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf Margaret Will this break any official or unofficial ID processing tools? They would have to be modified. Hopefully, not just before the I-D deadline. I like this idea a lot. +1 from me. The question I have is, would this require a change to RFC 5378 ? Or could it just be done ? Regards Marshall Stewart ___ 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: Abstract on Page 1?
Margaret Wasserman wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. Margaret After having suffered from the latest boilerplate change turmoil (which is not yet finished), and the next one already announced (RFC boilerplate), I really have to ask: you are joking, right? Note: Section 6 of http://trustee.ietf.org/docs/IETF-Trust-Legal-Provisions-Clean-2-12-09.pdf says: The following text must be included on the first page of each IETF Document as specified below: BR, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On Wed, Mar 04, 2009 at 04:50:19PM +0100, Julian Reschke wrote: The following text must be included on the first page of each IETF Document as specified below: Some of us may regard the requirement of standard legal boilerplate taking precedence over technical content to be a symptom of a problem, rather than something to be accepted quietly. (But I have a great deal of sympathy for the toolbuilders, and think that maybe just now is not a good time to be making more changes. Perhaps the next time one is required anyway, though?) A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
On Wed, Mar 4, 2009 at 7:33 AM, Margaret Wasserman m...@lilacglade.org wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. Oh, yes please. That would immensely increase the usability of RFCs. -Tim +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Henry Sinnreich wrote: Brian, Having running code only as a guideline has not served the IETF well lately, since it is largely ignored. I am still cringing during the IETF SIMPLE meetings when we use Jabber IM that has the code free and available. Would the SIMPLE WG have had the mandatory requirement of running code, SIMPLE would be much further ahead. Which remind me of this quote from A. Lyman Chapin (in [1]): It didn't take long to recognize the basic irony of OSI standards development: there we were, solemnly anointing international standards for networking, and every time we needed to send electronic mail or exchange files, we were using the TCP/IP-based Internet! [1] Malkin, G., Who's Who in the Internet: Biographies of IAB, IESG and IRSG Members, RFC 1336, May 1992. -- 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: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems
On Wed, 4 Mar 2009, Paul Vixie wrote: you'll see roundrobin and lifo, among others, in many caches including stub caches. Large numbers of sites have been depending on this behaviour for over 15 years, so it was wrong of RFC 3484 to break it. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Ned Freed wrote: Ned Freed wrote: 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. A Running Code Considerations section can be empty, this is the reason of the last sentence (this is similar to what is done for the IANA Consideration Section). If a protocol described in an I-D has no implementation then the section is empty, and people can decide to invest in this protocol using this information. This to say, again, that the text does not implies that implementations are mandatory, just that their existence must be documented in the I-D. I'm talking about the mandatory nature of the section. What the seection says is irrelevant. More mandatory sections are bad and that's exactly what this proposal calls for. If a draft author wants to describe implementation work and how it has helped produce the document, that can be done in the acknowledgements section. So, while I entirely support the development of codde in parallel with specifications, I am totally opposed to ideas put forward in this draft. The absolute last thing we need is ANYTHING that makes getting documents through the process more difficult. We have too much piled on crap as it is. It seems that this is the consensus. Now, I know by experience that even significant contributions to an I-D does not guarantee you a place in the acknowledgement section. So what is the incentive into developing code that 1) will probably be obsoleted by the next version of the I-D and 2) will not be acknowledged at all in contributing to the improvement of the protocol? As I understand it, it is considered very offensive in the academic world to not properly cite sources. It should be the same for early implementation when designing a protocol. -- 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: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
i disagree. dns-based load balancing is an unfortunate overloading and should never be done. RFC 3484 is correct as it is. Why is it right for topology-ignorant clients to override topology- aware DNS servers based on wishful thinking about RIR address allocation policies? The order of records in a DNS response is, at best, a hint. Relying on it as if it were a mandate to clients is a gamble. It is quite legitimate for clients to consider the entire list of addresses and try to pick the best ones, based on their knowledge of topology. We may argue whether the specific algorithm in RFC 3484 is the correct one, and I hope that future clients will implement something smarter than prefix matching. But if service operators want to balance load on their servers, they need to consider something a bit more sophisticated than merely reordering the records in the DNS response... -- Christian Huitema ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF speed -- was Re: Running Code
In message http://www.IETF.ORG/mail-archive/web/ietf/current/msg55986.html, Hannes Tschofenig wrote: 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). Hannes, you are saying very long time -- but according to my limited experience, the IETF timeline you mention in fact seems to be unusually _fast_ ! I have recently seen new, rather short RFCs that took more than 5 years from first WG discussion to RFC. Sadly, that apparently are _not_ extreme outliers. (And according to filed records, they have not been subject to substantial normative MISSREF stalls.) I do not want to blame anybody, but in the TSV area I am aware of documents in at least two different WGs that describe common (and recommended) _existing_ implementation practice and have not even been submitted to the IESG after more than 4 years of consideration. Reportedly, other WGs in other areas show similar 'performance' occasionally (or worse). Sigh! Contrary to that, I am aware of a young WG 'ab initio' committed to a policy rule that adopted work items should be forwarded to the IESG within roughly one year -- or abandoned. Very laudable! Kind regards, Alfred. -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ 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
Ned Freed writes: But that's the problem - this is not what RFC 5321 says. It's not what 3501 says either ;) More of a one-sentence simplification than a full and exact description. ... 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. Oh, this makes sense. I wasn't aware of that. I ran into the same issue whem implementing group reply in a MUA, but hadn't realised that MTAs could run into that. 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. I agree with that. Email-arch, however, deals with both, and attempts to describe the running code too, so IMO it can't just cite 5321. That would be overly simplistic. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
* Tony Finch: It seems that Vista implements RFC 3484 address selection, including the requirement to sort IP addresses. This breaks a great deal of operational dependence on DNS-based load balancing, as well as being based on an incorrect understanding of how IP addresses are allocated. I assume you are referring to IPv4 address sorting. This has previously been discussed on DNS-related IETF WGs. The general belief is that this is not a DNS issue. I find this a rather strange conclusion, but we have to live with it. RFC 3484 is being revised in one or more of the IPv6-related WGs. I don't know how far this effort has evolved. There does not seem to be a way to address the IPv4 part of the issue indepedently. So right now it seems that the IETF is structurally incapable of correcting this badly engineered specification. -- Florian Weimerfwei...@bfk.de BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
Brian, Having running code only as a guideline has not served the IETF well lately, since it is largely ignored. I am still cringing during the IETF SIMPLE meetings when we use Jabber IM that has the code free and available. Would the SIMPLE WG have had the mandatory requirement of running code, SIMPLE would be much further ahead. Henry On 3/3/09 4:43 PM, Marc Petit-Huguenin petit...@acm.org wrote: 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: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
On Wed, Mar 4, 2009 at 4:17 PM, Paul Vixie vi...@isc.org wrote: dns-based load balancing is an unfortunate overloading and should never be done. Here I agree. RFC 3484 is correct as it is. Here I don't. The idea behind is good, the implementation is not. Client would have to know BGP path to DA + DB and decide on basis of routing protocol. Selection based on longest matching prefix will work in only very small percent of case, all other cases are based on pure luck. Ondrej. It seems that Vista implements RFC 3484 address selection, including the requirement to sort IP addresses. This breaks a great deal of operational dependence on DNS-based load balancing, as well as being based on an incorrect understanding of how IP addresses are allocated. RFC 3484 needs to be updated to delete this rule, so that the order returned from the DNS is honoured when the client has no better knowledge about which address is appropriate. See http://drplokta.livejournal.com/109267.html http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html http://lists.debian.org/debian-ctte/2007/11/msg00029.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-requ...@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/ -- to unsubscribe send a message to namedroppers-requ...@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/ -- Ondrej Sury technicky reditel/Chief Technical Officer - CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.s...@nic.cz http://nic.cz/ sip:ondrej.s...@nic.cz sip%3aondrej.s...@nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 - ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems
i disagree. dns-based load balancing is an unfortunate overloading and should never be done. RFC 3484 is correct as it is. re: It seems that Vista implements RFC 3484 address selection, including the requirement to sort IP addresses. This breaks a great deal of operational dependence on DNS-based load balancing, as well as being based on an incorrect understanding of how IP addresses are allocated. RFC 3484 needs to be updated to delete this rule, so that the order returned from the DNS is honoured when the client has no better knowledge about which address is appropriate. See http://drplokta.livejournal.com/109267.html http://www.ietf.org/mail-archive/web/ietf/current/msg51874.html http://www.ietf.org/mail-archive/web/discuss/current/msg01035.html http://www.ietf.org/mail-archive/web/dnsop/current/msg05847.html http://lists.debian.org/debian-ctte/2007/11/msg00029.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. -- to unsubscribe send a message to namedroppers-requ...@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: http://ops.ietf.org/lists/namedroppers/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Abstract on Page 1?
+1, after San Francisco. Let's give the volunteer tool authors some breathing space. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
I think the developer should be acknowledged if they indeed contributed to the spec development. (Many implementations are done well outside the IETF, with essentially no feedback loop.) If they are not, this seems like a behavior for the WG chair to encourage. We need to recognize that the value of implementations differs greatly depending on the nature of the specification. They are very valuable for new protocols and higher-risk efforts (e.g., new algorithms), but less so for the more routine maintenance activities, such as adding a DHCP option. I don't see how making implementations mandatory helps, as Henry seems to be advocating. We can't force spec writers to code and we can't force those outside the IETF to implement our drafts. Thus, all we'd get is further delay, as we wait for this gating condition, or specs that are dropped in the early stages. It would, however, likely mean that only entities with more resources, who can more easily commandeer a developer for their draft to do a token implementation, get to write the specs. We should encourage implementations, e.g., by having implementors speak during WG meetings or by hosting interoperability events, plug fests, code spurts and similar activities around the IETF, as well as by eating our own dog food. Henning Now, I know by experience that even significant contributions to an I-D does not guarantee you a place in the acknowledgement section. So what is the incentive into developing code that 1) will probably be obsoleted by the next version of the I-D and 2) will not be acknowledged at all in contributing to the improvement of the protocol? As I understand it, it is considered very offensive in the academic world to not properly cite sources. It should be the same for early implementation when designing a protocol. -- 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
Melinda Shore wrote: On 3/4/09 12:17 PM, Marc Petit-Huguenin petit...@acm.org wrote: Now, I know by experience that even significant contributions to an I-D does not guarantee you a place in the acknowledgement section. So what is the incentive into developing code that 1) will probably be obsoleted by the next version of the I-D and 2) will not be acknowledged at all in contributing to the improvement of the protocol? I tend to assume people will be interested in a protocol for some other reasons than garnering acknowledgements and fluffing their resumes, and those other reasons will presumably be sufficient motivation. Implementing something will tend to be a pretty good way to find bugs, inefficiencies, or other problems with a protocol specification. If you're interested in kudos, take the issues you find to the mailing list rather than directly to the author. I'm pretty surprised by this argument. I assumed that acknowledgement would be a good enough incentive for developers to contribute early implementations, but you seem to think that there would be other reasons. The fact is that feedback from early implementations is rare, so what other reasons do you think early implementers would have? Cannot be money - early implementations are very likely to become obsolete at the next version of the I-D, and so have to be rewritten. -- 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 Mar 2, 2009, at 12:51 PM, Samuel Weiler wrote: 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. Given that sometimes the border goons use some aggressive data recovery approaches, used laptops are somewhat interesting. Are you SURE that some erased sector doesn't contain a vestigial image of something embarassing? If it does, can you prove it wasn't you that left it there? Note that some of the secure facilities I've worked in dispose of used drives by software erasing, beating them with a sledgehammer, degaussing, baking in a ceramics kiln, degaussing again, and then beating with a sledgehammer again. Worried about what might be recoverable from those drives? -- Dean Willis ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IANA Office Hours at IETF-74 in San Francisco
Greetings! The IANA will be holding Office Hours at the IETF-74 in San Francisco. This will continue to give everyone an opportunity to discuss IANA Considerations in your documents, requests for registrations in existing registries or any other questions you may have. The IANA will have a table near the IETF registration area, staffed during the following hours: Monday - Wednesday, 0900 - 1600 (May also have additional hours on Thursday) Thank you and see you soon! Michelle Cotton Manager, IETF Relations Internet Assigned Numbers Authority ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
On 3/4/09 12:17 PM, Marc Petit-Huguenin petit...@acm.org wrote: Now, I know by experience that even significant contributions to an I-D does not guarantee you a place in the acknowledgement section. If that's indeed the case then that's a problem independent of this proposal. Failure to properly acknowledge significant contributions is wrong no matter how you slice it. That said, I have on more than one occasion gotten requests from someone that their name be removed from an acknowledgements section. In fact in one case I was tempted in one case to replace the name with Alan Smithee, but on further consideration I decided that was a bad idea... So what is the incentive into developing code that 1) will probably be obsoleted by the next version of the I-D and 2) will not be acknowledged at all in contributing to the improvement of the protocol? I tend to assume people will be interested in a protocol for some other reasons than garnering acknowledgements and fluffing their resumes, and those other reasons will presumably be sufficient motivation. And if you do an implementation of a protocol nothing prevents you from listing that fact on a resume. I don't see why mention in an RFC would be a prequiisite for this. And if authors are required to list all implementations per this proposal independent of whether or not that work actually contributes to the specification, the value of such citations drops to almost nothing anyway. Implementing something will tend to be a pretty good way to find bugs, inefficiencies, or other problems with a protocol specification. If you're interested in kudos, take the issues you find to the mailing list rather than directly to the author. +1 I'm pretty surprised by this argument. +1 Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Running Code
I assumed that acknowledgement would be a good enough incentive for developers to contribute early implementations, but you seem to think that there would be other reasons. The fact is that feedback from early implementations is rare, THat may be true in your neck of the woods, but not in mine. I try and do at least a preliminary implementation for every specification I write (the notable exception for me on this was RFC 2231, and boy do I wish I had done one in that case), and I routinely receive notes from other implementors saying they've iimplemented some draft of mine long before publication or even WG last call. so what other reasons do you think early implementers would have? Cannot be money - early implementations are very likely to become obsolete at the next version of the I-D, and so have to be rewritten. Again, if there's a problem with people not getting proper recognition for having contributed to a specification, irrespective of whether that contribution is based on implementation work or just reading the specification, that needs to be addressed independently of this proposal. It is wrong to take credit for someone else's work. Ned ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Terminal room at IETF74
Indeed I recently read an indignant complaint from one country concerning commercial espionage conducted by a second. Said conduct having been exposed by the employment by similar espionage tactics by the first against the second. -Original Message- From: ietf-boun...@ietf.org on behalf of Steven M. Bellovin Sent: Wed 3/4/2009 5:05 PM To: Scott Kitterman Cc: ietf@ietf.org Subject: Re: Terminal room at IETF74 On Wed, 04 Mar 2009 16:58:14 -0500 Scott Kitterman sc...@kitterman.com wrote: Based on the address used in the message that kicked off this thread, the individual that started this thread works for a company that has a significantly greater reason for concern than an average traveller. Indeed. In the past, various countries -- note carefully; I used the plural -- have been mentioned in the press as using various government agencies to advance national economic interests. --Steve Bellovin, http://www.cs.columbia.edu/~smb ___ 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: Abstract on Page 1?
On 4 mrt 2009, at 16:33, Margaret Wasserman wrote: I would like to propose that we re-format Internet-Drafts such that the boilerplate (status and copyright) is moved to the back of the draft, and the abstract moves up to page 1. I don't believe that there are any legal implications to moving our IPR information to the back of the document, and it would be great not to have to page down at the beginning of every I-D to skip over it. If someone wants to check the licensing details, they could look at the end of the document. FWIW: On my todo list is coordination of the implementation of draft-iab- streams-headers-boilerplates and in addition the consolidation of boilerplate material in RFCs and I-Ds. Part of the equation is figuring out if and where copyright and license boilerplate material can be moved. The plan is under construction. --Olaf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
WG Review: Recharter of Network File System Version 4 (nfsv4)
A modified charter has been submitted for the Network File System Version 4 working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Wednesday, March 11, 2009. Network File System Version 4 (nfsv4) == Last Modified: 2009-02-10 Current Status: Active Working Group Chair(s): Brian Pawlowski be...@netapp.com Spencer Shepler spencer.shep...@sun.com 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 Technical Advisor(s): Leif Johansson le...@it.su.se Mailing Lists: General Discussion: nf...@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/nfsv4 Archive: http://www.ietf.org/mail-archive/web/nfsv4/index.html Description of Working Group: NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the working group is chartered to (1) maintain the existing NFSv4, NFSv4.1 and related specifications, such as RPC and XDR, (2) progress these specifications along the standards track, (3) develop a protocol to create a federated namespace using NFSv4's existing referral mechanisms. (1) NFS version 4.0 maintenance Under this charter item, the WG correct errors and ambiguities in the protocol currently specified in RFC 3530 and advances it along the standards track. Extensions of any other kind are out of scope under this charter item. (2) NFS Version 4.1 Maintenance As with NFSv4.0, the WG will address errors or ambiguities in the NFSv4.1 protocol and related specifications in support of progressing implementations. (3) RPC and XDR protocol maintenance The NFSv4 protocol depends on two related specifications: ONC RPC and XDR. Similar to charter item (1), the WG may correct errors and ambiguities in the ONC RPC and XDR protocols currently specified by RFCs 1831, 1833 and 2203. In conjunction with the advancement of the NFSv4 specification along the standards track, the WG will also work on the advancements of its ONC RPC and XDR dependencies. The WG will also update the ONC RPC specification for compatibility with IPv6. Additionally, it will create an IANA registry for RPC program numbers and seed it with a registry Sun has been maintaining. (4) Federated Namespace The NFSv4 protocol provides a referral mechanism that allows a server to redirect a client to another server. The working group will produce documents describing a mechanism for creating a federated namespace (single global name space for a set of NFSv4 servers) using the NFSv4 protocol's referral capabilities. The file system federation protocol will enable file access and namespace traversal across collections of independently administered fileservers. No modifications will be made to the NFS client to server protocol. Milestones: DONE WG Last Call for RPC and NFS RDMA drafts DONE WG Last Call for rfc1831bis (RPC version 2) DONE WG Last Call for NFSv4 minor version 1 DONE WG Last Call for NFSv4.1 block/volume layout DONE WG Last Call for NFSv4.1 Object-based layout DONE Submit NFS Minor Version 1 to IESG for publication as a Propoased Standard DONE Submit pNFS Block/Volume Layout to IESG for publication as a Propoased Standard DONE Submit Object-based pNFS Operations to IESG for publication as a Proposed Standard Sep 2009 WG Last Call for rfc3530bis (NFS version 4) May 2009 WG Last Call for Requirements for Federated File Systems draft-ietf-nfsv4-federated-fs-reqts-01 Oct 2009 WG Last Call for Administration Protocol for Federated Filesystems draft-ietf-nfsv4-federated-fs-admin-00.txt Oct 2009 WG Last Call for NSDB Protocol for Federated Filesystems draft-ietf-nfsv4-federated-fs-protocol-00.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
