Re: An Antitrust Policy for the IETF

>Does this mean that those who have not had a car accident should not carry >auto >insurance? Should those who have not had their house suffer damage from wind, >rain, flood or fire or had someone sue them after slipping on the sidewalk >should not have homeowner's insurance? What does insura

Re: Last Call: (The Canonical Link Relation) to Informational RFC

Hello, I support publication of this document, as my concerns with respect to being too HTTP-centric have been resolved in this version. A tiny issue: you should probable make HTML and RFC 2616 informative references rather than normative, as they are used when introducing examples. Thanks

RE: Consensus Call: draft-weil-shared-transition-space-request

>> If a customer uses a CGN-specific allocation on the inside of their >> network as if it were RFC 1918 space, then, yes, they will have trouble >> if they ever use a provider that uses a CGN. > > Thanks. So my point is, this proposed allocation doesn't solve anything, > it just kicks the can dow

Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request

Date:Fri, 2 Dec 2011 15:20:34 -0800 From:Ted Hardie Message-ID: | Big enterprises buy small ones; sometimes at a great rate. And this itself is a good argument that 1918 space is sufficient (one way or another), not the reverse. What you have there is two 1918

Re: Last Call: (URI Template)

On 3 December 2011 01:47, Mark Nottingham wrote: >> 1.2 >> worth pointing out that 'reserved' and 'unreserved' are formally >> defined in 1.5, to stop people reaching for RFC3986. > If this is an issue, I'd actually prefer to place the notational > conventions section higher in the document. Tho

RE: Last Call: (URI Template)

> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of > t.petch > Sent: Thursday, December 01, 2011 2:51 AM > To: Mark Nottingham > Cc: IETF Discussion > Subject: Re: Last Call: (URI Template) > > The examples are rather complicated. If I have a

Re: Last Call: (URI Template)

On 01/12/2011, at 9:50 PM, t.petch wrote: > 2.3 > Is undefined formally defined? This section suggests that 'undef' or 'null', > inter alia, may be used to undefine a variable while 3.2 uses 'null'. I see > no > more formal definition of how to undefine a variable, as opposed to it having > a

Re: Consensus Call: draft-weil-shared-transition-space-request

In message <30683.1322848...@marajade.sandelman.ca>, Michael Richardson writes: > > Ted, your response does not address what I said at all. Not > > one bit. Let's assume that *every* enterprise used every > > last address of 172.16/12 (and, for that matter ever bit of > > 1918 spac

Re: Last Call: (DKIM Authorized Third-Party Signers) to Experimental RFC

On 11/30/2011 12:34 PM, SM wrote: "Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]." The references to RFC 5598 and RFC 5322 should be normative. Arguably, they already are: the text says "should" and that's a normative term in the document

Re: Consensus Call: draft-weil-shared-transition-space-request

On Dec 2, 2011, at 13:15 , Victor Kuarsingh wrote: > > […] I would like to point out that PMT has worked in a large production > network with much success (as ugly as one may think it is). The reality is > that it works, and works well […] In order to retain a semblance of professional composu

Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request

On Fri, Dec 2, 2011 at 1:31 PM, Warren Kumari wrote: > > > But (also realistically) a "sufficiently large enterprise" that uses all > of RFC1918 is not going to be sitting behind a CGN... > > W > > Big enterprises buy small ones; sometimes at a great rate. Imagine an enterprise that uses this /1

Re: An Antitrust Policy for the IETF

Dave, if the nature of current automotive practice and house construction and outside environment is such that the risks and the risk protection measures are fairly well known, the analogy I am suggesting is there is no need for new types of auto and home insurance, there is just the need for

Re: Consensus Call: draft-weil-shared-transition-space-request

On 12/02/2011 09:50, Ted Hardie wrote: > On Thu, Dec 1, 2011 at 11:08 PM, Doug Barton > wrote: > > On 12/01/2011 22:07, Ted Hardie wrote: > > No, I think that premise is mis-stated. Premise 1: There exists > > equipment that can't handle identical address

Re: Consensus Call: draft-weil-shared-transition-space-request

Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 04:31:56PM -0500 Quoting Noel Chiappa (j...@mercury.lcs.mit.edu): > > From: Nilsson > > > There is no beating up. v4 is dead, move on. > > If you're sure v4 is really dead, why do you car

Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request

On 12/2/11 13:31 , Warren Kumari wrote: > > On Dec 2, 2011, at 1:51 PM, Joel jaeggli wrote: > >> On 12/2/11 09:59 , Michael Richardson wrote: >>> Ted, your response does not address what I said at all. Not one bit. Let's assume that *every* enterprise used every last address of 172

Re: Consensus Call: draft-weil-shared-transition-space-request

> From: Nilsson > There is no beating up. v4 is dead, move on. If you're sure v4 is really dead, why do you care if other people want to re-arrange a few limbs? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/lis

Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request

On Dec 2, 2011, at 1:51 PM, Joel jaeggli wrote: > On 12/2/11 09:59 , Michael Richardson wrote: >> >>> Ted, your response does not address what I said at all. Not >>> one bit. Let's assume that *every* enterprise used every >>> last address of 172.16/12 (and, for that matter ever bit of >>> 1918

Re: Consensus Call: draft-weil-shared-transition-space-request

Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 04:07:47PM -0500 Quoting Noel Chiappa (j...@mercury.lcs.mit.edu): > > Which is v6. > Yes, beating up on IPv4 has been such a success in getting IPv6 deployed, > hasn't it? There is no beati

Re: Consensus Call: draft-weil-shared-transition-space-request

James, > In simpler terms, what I want is a document that clearly implies 6to4-PMT > is not applicable with this new Shared CGN Address Space. No, I am not > joking, and I'm very sorry that I had to bring up the topic of 6to4 again. > > I appreciate your position. I am also biased as much as y

Re: Consensus Call: draft-weil-shared-transition-space-request

> From: Nilsson >> On this basis, it's a case of looking for the least-problematic >> solution. > Which is v6. Yes, beating up on IPv4 has been such a success in getting IPv6 deployed, hasn't it? Let's dial the way-back machine back to 1994, when IPv6 was adopted - i.e. 17 yea

Re: Consensus Call: draft-weil-shared-transition-space-request

On 2 dec 2011, at 21:38, Måns Nilsson wrote: > Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: > Fri, Dec 02, 2011 at 04:56:55PM + Quoting Daryl Tanner > (daryl.tan...@blueyonder.co.uk): > >> I don't like CGN, but the reality is that we're stuck with it. On t

Re: Consensus Call: draft-weil-shared-transition-space-request

Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 04:56:55PM + Quoting Daryl Tanner (daryl.tan...@blueyonder.co.uk): > I don't like CGN, but the reality is that we're stuck with it. On this > basis, it's a case of looking for the least-probl

Re: An Antitrust Policy for the IETF

On 2011-12-03 06:12, Marshall Eubanks wrote: > On Thu, Dec 1, 2011 at 10:24 PM, John Levine wrote: >>> Rather than trying to set up rules that cover all hypothetical >>> developments, I would suggest >>> a practical approach. In our process, disputes are materialized by an >>> appeal. Specific l

RE: An Antitrust Policy for the IETF

> This appears to be based on the view that an external legal process is > amenable to the IETF's internal procedures. Of course, it isn't. > > Once there is a lawsuit, we are locked in to the procedures and authority of > the courts and to the existing facts leading up to the lawsuit. Post-hoc

Re: Consensus Call: draft-weil-shared-transition-space-request

On Nov 28, 2011, at 13:25 , Ronald Bonica wrote: > […] I will submit the draft to the full IESG for its consideration at its > December 1 teleconference. The draft will be published as a BCP if a > sufficient number of IESG members ballot "Yes" or "No Objection", and if no > IESG member ballots

Re: Consensus Call: draft-weil-shared-transition-space-request

--On Friday, December 02, 2011 10:06 -0800 Ted Hardie wrote: >... >> In that context, questions like Pete's make perfect sense >> because they are questions about how to patch around said >> legacy gear while causing minimum damage to today's >> assumptions about, e.g., routable and non-routabl

Re: An Antitrust Policy for the IETF

I side with those who focus on solving real problems not hypothetical problems, Does this mean that those who have not had a car accident should not carry auto insurance? Should those who have not had their house suffer damage from wind, rain, flood or fire or had someone sue them after sl

Re: Consensus Call: draft-weil-shared-transition-space-request

On 12/2/11 09:59 , Michael Richardson wrote: > > > Ted, your response does not address what I said at all. Not > > one bit. Let's assume that *every* enterprise used every > > last address of 172.16/12 (and, for that matter ever bit of > > 1918 space). That's irrelevant and still d

Fwd: IAB Seeks Executive Director

For those people that do not read ietf-announce ... Begin forwarded message: > From: "IAB Chair" > Date: December 2, 2011 12:53:35 PM EST > To: > Subject: IAB Seeks Executive Director > Reply-To: iab-ch...@iab.org > > The Internet Architecture Board (IAB) is seeking a candidate > to succeed D

Re: An Antitrust Policy for the IETF

Please see Christian's relevant post I have reposted here. I side with those who focus on solving real problems not hypothetical problems, thus my original post to the list what was the source of concern; to which was responded as far as I can ascertain so far a case in current litigation see

Re: Consensus Call: draft-weil-shared-transition-space-request

> Ted, your response does not address what I said at all. Not > one bit. Let's assume that *every* enterprise used every > last address of 172.16/12 (and, for that matter ever bit of > 1918 space). That's irrelevant and still does not address my > question. The question is whet

Re: Consensus Call: draft-weil-shared-transition-space-request

On Thu, Dec 1, 2011 at 11:44 PM, John C Klensin wrote: > > Assume that no vendor in its collective right mind would deploy > new address translation gear (or firmware) that couldn't cope > with having addresses from the same pool on the "inside" and > "outside" and that we are willing to let the

Re: Consensus Call: draft-weil-shared-transition-space-request

> > Which problem did ISPs create? > > By dragging their feet to the inevitable roll-out of v6 they checked > the demand for consumer electronics compatible with v6. If v6 connectivity > had been norm 6 years ago we'd have more v6-ready devices deployed today. > > The problem is three part: Connect

Re: An Antitrust Policy for the IETF

On Dec 2, 2011, at 9:12 AM, Marshall Eubanks wrote: > On Thu, Dec 1, 2011 at 10:24 PM, John Levine wrote: >>> Rather than trying to set up rules that cover all hypothetical >>> developments, I would suggest >>> a practical approach. In our process, disputes are materialized by an >>> appeal. Sp

Re: Consensus Call: draft-weil-shared-transition-space-request

On Thu, Dec 1, 2011 at 11:08 PM, Doug Barton wrote: > On 12/01/2011 22:07, Ted Hardie wrote: > > No, I think that premise is mis-stated. Premise 1: There exists > > equipment that can't handle identical addresses on the interior and > > exterior interface. Premise 2: it may be deployed now or

Re: An Antitrust Policy for the IETF

On 11/29/2011 7:24 AM, Andrew Sullivan wrote: Tue, Nov 29, 2011 at 08:37:09AM -0500, Donald Eastlake wrote: (c) The IETF does not have any members The governance of the I* is complicated but I don't think any court would have any trouble finding that, for some purposes, the membership of the

RE: An Antitrust Policy for the IETF

On 1 Dec 2011, at 17:09, Worley, Dale R (Dale) wrote: > Unfortunately, lawyers on the whole tend to > suggest solutions to problems that create additional legal work. Not that other specialists are free of this problem... > Programmer's Secret Understanding > > 1 It's more fun

Re: An Antitrust Policy for the IETF

On Thu, Dec 1, 2011 at 10:24 PM, John Levine wrote: >>Rather than trying to set up rules that cover all hypothetical developments, >>I would suggest >>a practical approach. In our process, disputes are materialized by an appeal. >>Specific legal >>advice on the handling of a specific appeal is m

Re: An Antitrust Policy for the IETF

On 1 Dec 2011, at 17:09, Worley, Dale R (Dale) wrote: > Unfortunately, lawyers on the whole tend to > suggest solutions to problems that create additional legal work. … such as, an antitrust policy for the IETF... ___ Ietf mailing list Ietf@ietf.org ht

Re: Netfilter (Linux) Does IPv6 NAT

Does it support RFC 6296? Jumping into this discussion - it doesn't support RFC 6296 yet, but I'm currently looking into this as an additional option. Also I'm looking into doing only port assigments instead of "Full NAT" for IPv6, as suggested by Rusty Russell. Please keep my CCed, I'm not sub

RE: Netfilter (Linux) Does IPv6 NAT

Is the problem that they don't get what IPv6 is for? Or that we haven't articulated the use cases appropriately? Alternatively, Is there something they are trying to achieve other than "more=good?" Greg Daley > -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf

Re: Consensus Call: draft-weil-shared-transition-space-request

The IPv6 "chickens and eggs" discussion could (and probably will) go on forever: service provider -> no content content provider -> no customers manufacturers -> no content or customers IPv6 is the right answer, but for all of the above it costs money to implement, with no return on investment (w

Re: An Antitrust Policy for the IETF

+1 Bob On Dec 1, 2011, at 10:44 AM, Christian Huitema wrote: > Note that the suit does not complain about the 3GPP and ETSI rules. It > alleges instead that the rules were not enforced, and that the leadership of > these organization failed to prevent the alleged anti-competitive behavior of

Re: Consensus Call: draft-weil-shared-transition-space-request

>> And yes, I realize that Step 3 is going to be incredibly unpopular for >> the ISPs, but they created the problem, so they should have to live with >> the results. > Which problem did ISPs create? big broadband providers sitting on thumbs for a decade instead of looking their (mostly edge) vendo

Re: Consensus Call: draft-weil-shared-transition-space-request

Subject: RE: Consensus Call: draft-weil-shared-transition-space-request Date: Fri, Dec 02, 2011 at 09:15:16AM -0500 Quoting Lee Howard (l...@asgard.org): > Which problem did ISPs create? By dragging their feet to the inevitable roll-out of v6 they checked the demand for consumer electronics com

RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

This document proposes an additional OAM for MPLS networks using an ACH code point. As this protocol is intended to operate and manage MPLS networks, this protocol is subject to the provisions of RFC4929 (MPLS Change Process) and must be reviewed by the MPLS WG using RFC4929. I call upon the nomin

Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

On 02/12/2011 13:29, t.petch wrote: Original Message - From: "Thomas Nadeau" To: "Huub helvoort" Cc: "Adrian Farrel"; ; "The IESG" ; Sent: Friday, December 02, 2011 2:40 PM I disagree with the document shepherd's evaluation of this document. This document sets out to standardize an ad

Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

Original Message - From: "Thomas Nadeau" To: "Huub helvoort" Cc: "Adrian Farrel" ; ; "The IESG" ; Sent: Friday, December 02, 2011 2:40 PM > > I disagree with the document shepherd's evaluation of this document. This document sets out to > standardize an additional code point to support

RE: Consensus Call: draft-weil-shared-transition-space-request

> -Original Message- > From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Doug Barton > Step 1: Determine the most popular inside prefixes for CPEs > Step 2: Use the least popular RFC 1918 prefix for the CGN network > Step 3: If your customer has somehow chosen

Re: Last Call: (DKIM Authorized Third-Party Signers) to Experimental RFC

Dave CROCKER wrote: On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote: As the draft says, the point is to make the idea available and see if it sticks to anyone or anything. If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report

Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

I disagree with the document shepherd's evaluation of this document. This document sets out to standardize an additional code point to support a type of OAM for MPLS, and as such the MPLS WG must review the document for technical correctness. As far as I understand things, all MPLS d

RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

--On Friday, December 02, 2011 04:17 -0800 John E Drake wrote: > Huub, > > In your email, below, you state: > > "This protocol has been defined in the ITU-T and should not be > considered to be a MPLS protocol and therefore should not > subject to the provisions of RFC 4929." >... > Doesn't t

RE: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

Huub, In your email, below, you state: "This protocol has been defined in the ITU-T and should not be considered to be a MPLS protocol and therefore should not subject to the provisions of RFC 4929." The subject protocol is used to provide OAM for MPLS networks. You seem to be saying that bec

Re: Request to publish draft-betts-itu-oam-ach-code-point-01.txt

Adrian "It is the opinion of the document shepherd that discussion of this document on the working group lists would be a distraction from the technical protocol work that the working groups need to do." I disagree with the document shepherd in his evaluation. The draft clearly sets out to enab

Re: Consensus Call: draft-weil-shared-transition-space-request

Date:Thu, 01 Dec 2011 23:08:51 -0800 From:Doug Barton Message-ID: <4ed87983.4090...@dougbarton.us> | Step 3: If your customer has somehow chosen the same prefix, tell them | they can't do that. Another alternative there is for the ISP to simply pick a different p