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-cons

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 l

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 hav

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 P

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 up

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 a

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:

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

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 a

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

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?

Re: RFC 3484 section 6 rule 9 causing more operational problems

On Wed, 4 Mar 2009, Andrew Sullivan wrote: > > 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?) I'm happy to say that Arifumi's I-D that Tim linked to already addresses t

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

On Wed, 4 Mar 2009, Florian Weimer wrote: > > I assume you are referring to IPv4 address sorting. It's also wrong to sort IPv6 addresses by longest matching prefix (unless the match is very long) because IPv6 addresses are also not allocated according to network topology. Tony. -- f.anthony.n.fi

Abstract on Page 1?

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 documen

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 a

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

Re: Abstract on Page 1?

On Wed, Mar 4, 2009 at 7:33 AM, 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. Oh, yes please. That would immensely increase the u

Re: Abstract on Page 1?

On 3/4/09 10:33 AM, "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 like this suggestion a lot. Melinda

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

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

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

Re: Abstract on Page 1?

> On Wed, Mar 4, 2009 at 7:33 AM, 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. > Oh, yes please. That would immensely

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

Re: Abstract on Page 1?

On Mar 4, 2009, at 10:38 AM, Stewart Bryant wrote: Will this break any official or unofficial ID processing tools? Yes, they would need to be updated. But, I think we're due for another round of IPR updates once we resolve the current mess. So, perhaps we could queue this improvement a

Re: Running Code

Hallam-Baker, Phillip wrote: > > > 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

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.finchhttp://dotat.at/

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

On Wed, 4 Mar 2009, Paul Vixie wrote: > > neither a client or a server can be guaranteed topology-aware. dns leaves > ordering deliberately undefined and encourages applications to use their > own best judgement. Rule 9 kicks in when the client has no topology information, which is why it is brok

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

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? Th

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 too

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

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.

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 cod

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

I've added the ALTO mailing list to this discussion: What it comes down to is you want "localization", not RFC 3484. On Mar 4, 2009, at 8:05 AM, Ondřej Surý wrote: On Wed, Mar 4, 2009 at 4:17 PM, Paul Vixie wrote: dns-based load balancing is an unfortunate overloading and should never be d

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

On Wed, Mar 4, 2009 at 4:17 PM, Paul Vixie 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 + D

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 D

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

Re: Abstract on Page 1?

Margaret, First, a full support for your idea of having the IPR information at the end rather than on page 1. For this, a practical approach could be, at least in a first phase, to leave the choice open, both formats being accepted (first page or end of document). Then automated tools coul

Re: Running Code

On 3/4/09 12:17 PM, "Marc Petit-Huguenin" 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 th

Re: Abstract on Page 1?

+1 - great idea. On 3/4/09 10:33 AM, "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 le

Re: Running Code

Melinda Shore wrote: > On 3/4/09 12:17 PM, "Marc Petit-Huguenin" 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 obsolete

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

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 tabl

Re: Running Code

On 3/4/09 1:42 PM, "Marc Petit-Huguenin" wrote: > 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. Right. My experience has been that people will work on a protocol bec

RE: Running Code

Melinda, folks in the research community (e.g., students) need some publications and being mentioned in documents is quite important for them. >> Now, I know by experience that even significant contributions to an >> I-D does not guarantee you a place in the acknowledgement section. If the aut

Re: Running Code

> On 3/4/09 12:17 PM, "Marc Petit-Huguenin" 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 ackno

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

Re: Terminal room at IETF74

Dean Willis wrote: 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 aggressiv

Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems

On Wed, 4 Mar 2009, Paul Vixie wrote: > > we've been lifo'ing and round robin'ing dns data in caches and stubs for a > lot longer than 15 years, This is the key feature than RFC 3484 breaks. (I wasn't sure of the history - it was very murky when I tried to find the origin of round-robin DNS.) To

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

On Wed, 4 Mar 2009, Paul Vixie wrote: > > "in my same /24" or "in my same /16" is a pretty good indicator, though. Pity that ain't what the spec says. Tony. -- f.anthony.n.finchhttp://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD. _

Re: [dnsext] RFC 3484 section 6 rule 9 causing more operational problems

For this section to be useful you needs to be done at break points. LAN /64, SITE /56 or /48 and ISP /??. Doing it on every bit boundary is just plain wrong. The intent was good. The specification was wrong. To make this useful you need a protocol to d

Early implementers motivations [was Re: Running Code]

OK, so nearly everybody seems to think that I misunderstood the motivations of early implementation contributors, so let's ask them directly. If you did contribute an early implementation or did think of contributing but finally didn't, please respond to this email with your story. Interesting po

Re: Abstract on Page 1?

Livingood, Jason wrote: +1 - great idea. On 3/4/09 10:33 AM, "Margaret Wasserman" wrote: Then the template has to be changed. Will the IETF still continue to accept documents formatted the old way or will it mandate this change everywhere - and gee - that could be our own little stimulus

RE: Passing of Jim Bound

The IPv6 Forum set up a way for everyone to pay their respect. The IPv6 Forum will collect all the posting and share them with Jim's family. If you are interested, you will find the link on the IPv6 Forum home page: http://www.ipv6forum.com/ Russ From: ietf-boun...@ietf.org [mailto:ietf-bou

Re: Terminal room at IETF74

On Wed, 04 Mar 2009 20:41:21 + Elwyn Davies wrote: >Dean Willis wrote: >> >> 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), an

Re: Terminal room at IETF74

On Wed, 04 Mar 2009 16:58:14 -0500 Scott Kitterman 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 p

Re: Running Code

On 3/4/09 at 12:44 PM -0500, Henning Schulzrinne wrote: We can't force spec writers to code... Ah, for the days where "spec writer" and "coder" were co-referent. That we have spec writers who don't write code is sad. pr -- Pete Resnick Qualcomm Incorpora

Re: Running Code

I would hope that most spec writers also write code (or at least have written code in the past), but maybe not for every draft that they prepare. Also, if we'd want to rule out any protocol contributions by individuals with management responsibilities that make writing production code diffi

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

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 m