Date:Thu, 01 Dec 2011 23:08:51 -0800
From:Doug Barton do...@dougbarton.us
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
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
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
--On Friday, December 02, 2011 04:17 -0800 John E Drake
jdr...@juniper.net 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.
...
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
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
-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 the
Original Message -
From: Thomas Nadeau tnad...@lucidvision.com
To: Huub helvoort huub.van.helvo...@huawei.com
Cc: Adrian Farrel adr...@olddog.co.uk;
draft-betts-itu-oam-ach-code-po...@tools.ietf.org; The IESG
iesg-secret...@ietf.org; Ietf@ietf.org
Sent: Friday, December 02, 2011 2:40 PM
On 02/12/2011 13:29, t.petch wrote:
Original Message -
From: Thomas Nadeautnad...@lucidvision.com
To: Huub helvoorthuub.van.helvo...@huawei.com
Cc: Adrian Farreladr...@olddog.co.uk;
draft-betts-itu-oam-ach-code-po...@tools.ietf.org; The IESG
iesg-secret...@ietf.org;Ietf@ietf.org
Sent:
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
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
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) vendors in
+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
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
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
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
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
On Thu, Dec 1, 2011 at 10:24 PM, John Levine jo...@iecc.com 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
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 to
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
On Thu, Dec 1, 2011 at 11:08 PM, Doug Barton do...@dougbarton.us 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
On Dec 2, 2011, at 9:12 AM, Marshall Eubanks wrote:
On Thu, Dec 1, 2011 at 10:24 PM, John Levine jo...@iecc.com 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.
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: Connectivity /
On Thu, Dec 1, 2011 at 11:44 PM, John C Klensin john-i...@jck.com 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
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 whether
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
For those people that do not read ietf-announce ...
Begin forwarded message:
From: IAB Chair iab-ch...@iab.org
Date: December 2, 2011 12:53:35 PM EST
To: ietf-annou...@ietf.org
Subject: IAB Seeks Executive Director
Reply-To: iab-ch...@iab.org
The Internet Architecture Board (IAB) is
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 does not
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
--On Friday, December 02, 2011 10:06 -0800 Ted Hardie
ted.i...@gmail.com 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
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
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
On 2011-12-03 06:12, Marshall Eubanks wrote:
On Thu, Dec 1, 2011 at 10:24 PM, John Levine jo...@iecc.com 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
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
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 this
From: Nilsson mansa...@besserwisser.org
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
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 you
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 beating
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 space). That's
From: Nilsson mansa...@besserwisser.org
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
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.16/12 (and, for
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 mansa...@besserwisser.org
There is no beating up. v4 is dead, move on.
If you're sure v4 is really
On 12/02/2011 09:50, Ted Hardie wrote:
On Thu, Dec 1, 2011 at 11:08 PM, Doug Barton do...@dougbarton.us
mailto:do...@dougbarton.us 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
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
On Fri, Dec 2, 2011 at 1:31 PM, Warren Kumari war...@kumari.net 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
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 composure,
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...
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 space).
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
-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: draft-gregorio-uritemplate-07.txt (URI Template)
The examples are rather
On 3 December 2011 01:47, Mark Nottingham m...@mnot.net 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
Date:Fri, 2 Dec 2011 15:20:34 -0800
From:Ted Hardie ted.i...@gmail.com
Message-ID:
ca+9kkmajnup60nczwctokzstctk1lrdvrfqjzmbzpfbgoo5...@mail.gmail.com
| Big enterprises buy small ones; sometimes at a great rate.
And this itself is a good argument that 1918 space is
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 down the
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.
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 insurance
The IESG has approved the following document:
- 'OTP Pre-authentication'
(draft-ietf-krb-wg-otp-preauth-21.txt) as a Proposed Standard
This document is the product of the Kerberos Working Group.
The IESG contact persons are Stephen Farrell and Sean Turner.
A URL of this Internet Draft is:
The Internet Architecture Board (IAB) is seeking a candidate
to succeed Dow Street as IAB Executive Director. Dow has been
in the role for nearly 4 years and is planning to step down
due to other commitments.
We are looking for a replacement to start working with the IAB as
of January
The IESG has approved the following document:
- 'Supporting Authentication Trailer for OSPFv3'
(draft-ietf-ospf-auth-trailer-ospfv3-11.txt) as a Proposed Standard
This document is the product of the Open Shortest Path First IGP Working
Group.
The IESG contact persons are Stewart Bryant and
A new Request for Comments is now available in online RFC libraries.
RFC 6442
Title: Location Conveyance for the Session
Initiation Protocol
Author: J. Polk, B. Rosen,
J. Peterson
Status: Standards
A new Request for Comments is now available in online RFC libraries.
RFC 6457
Title: PCC-PCE Communication and PCE Discovery
Requirements for Inter-Layer Traffic Engineering
Author: T. Takeda, Ed.,
A. Farrel
60 matches
Mail list logo
