-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Dave CROCKER
Sent: Friday, December 02, 2011 3:59 PM
To: SM
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental
--On Saturday, December 03, 2011 08:43 +1300 Brian E Carpenter
brian.e.carpen...@gmail.com wrote:
...
We should ask a specific concrete question to a litigator who
understands antitrust law: are there any significant gaps in
the IETF process rules, including the formal Note Well warning
Daryl Tanner wrote:
The IPv6 chickens and eggs discussion could (and probably will) go on
forever:
service provider - no content
IPv6 is the right answer,
Wrong.
IPv6 is not operational, which is partly why most service
providers refuse it.
For example, to purposelessly enable
Mark Andrews wrote:
224/10 could be made to work with new equipement provided there was
also signaling that the equipment supported it. That doesn't help
ISP that have new customers with old equipment and no addresses.
Yes, it takes time.
However, 224/4 (or most of it) and 240/4 (except for
- Original Message -
From: Murray S. Kucherawy m...@cloudmark.com
To: IETF Discussion ietf@ietf.org
Sent: Saturday, December 03, 2011 1:50 AM
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
t.petch
Sent: Thursday, December 01, 2011
- Original Message -
From: Mark Nottingham m...@mnot.net
To: t.petch daedu...@btconnect.com
Cc: IETF Discussion ietf@ietf.org;
draft-gregorio-uritempl...@tools.ietf.org
Sent: Saturday, December 03, 2011 1:47 AM
On 01/12/2011, at 9:50 PM, t.petch wrote:
2.3
Is undefined formally defined?
Hi, Murray,
having read the draft I support its publication as experimental RFC. One
suggestion: under 'Security Considerations' add a reference to what is
said about DNSSEC in RFC6376 par. 8.5. In my opinion, the same
consideration applies for this ATPS document.
/rolf
On 12/3/11 9:32 AM,
On 11-12-03 7:25 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
wrote:
Mark Andrews wrote:
224/10 could be made to work with new equipement provided there was
also signaling that the equipment supported it. That doesn't help
ISP that have new customers with old equipment and no
Hi,
I fully support Stewart!
G.8113.1 proposes a OAM solution for MPLS-TP networks.
It uses the MPLS EtherType (when transmitted inband and getting the same
treatment as the data traffic).
The document is built on G.8110.1 (MPLS-TP architecture) which refers to
G.8110 (MPLS architecture), and
Based on my points in my mail below, please note that the proposed
protocol is subject to the provisions of RFC4929 (MPLS
Change Process) and must be reviewed by the MPLS WG using RFC4929.
Please redirect it to the MPLS WG and follow the MPLS Change Process.
Best regards,
Nurit
P.S. please
On Nov 28, 2011, at 11:03 AM, Margaret Wasserman wrote:
I don't know what an antitrust policy is... Could you explain?
Is this something like a conflict of interest policy? Or is it a policy to
avoid situations where we might be engaging in some sort of collusion?
I'm not Russ, but
On 12/3/2011 9:22 AM, Fred Baker wrote:
In the IETF, I would expect that an antitrust policy would prevent individual
companies or blocks of companies from controlling decisions or processes that
might have the effect of preventing or discriminating against competition.
That language looks
Hi Huub and authors of draft-betts-itu-oam-ach-code-point,
Thanks for issuing a publication request and supplying the Secretariat with a
write-up. The document is entered in the datatracker and you can see its status
at http://datatracker.ietf.org/doc/draft-betts-itu-oam-ach-code-point/
You
On 12/3/2011 12:32 AM, Murray S. Kucherawy wrote:
Does a signature by this on behalf of signer mean something different
from a regular DKIM signature? It appears the current text means the
answer to be yes.
Correct, inasmuch as there are some people in the community who think author
domain
- Original Message -
From: Sprecher, Nurit (NSN - IL/Hod HaSharon) nurit.sprec...@nsn.com
To: stbry...@cisco.com; Adrian Farrel adr...@olddog.co.uk
Cc: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; i...@ietf.org;
Ietf@ietf.org
Sent: Saturday, December 03, 2011 5:06 PM
Hi,
I fully
Tom hi,
If this is Ethernet OAM delivered *transparently* over MPLS-TP networks,
then there is *no* need for a code point, they can simply use PWs.
If this is a solution aims to provide an alternative OAM solution for
MPLS-TP networks, and it is based on G.8110.1 and G.8110, and uses the
MPLS
Folks,
On Thursday, December 1, the IESG deferred its decision regarding
draft-weil-shared-transition-space-request to the December 15 telechat. The
decision was deferred because:
- it is difficult. (We are choosing between the lesser of two evils.)
- a lively discussion on this mailing list
Ralph:
Is there evidence that there are deployments today of devices that use
addresses in 10.64.0.0/10?
I have seen addresses in this space used.
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 12/2/2011 8:50 PM, Ross Callon wrote:
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
From: Doug Barton do...@dougbarton.us
Doing the allocation will postpone the pain, until such time as those
folks that we keep hearing have exhausted all of 1918 internally catch
on, and then start using this block as 1918 space.
But if any particular site uses this space for
Victor Kuarsingh wrote:
However, 224/4 (or most of it) and 240/4 (except for 255.255.255.255)
should be released for unicast uses to reduce market price on
IPv4 addresses.
I have not objection to this. But anything that requires replacement of
equipment only will have longer term benefit.
On 12/3/2011 4:49 PM, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
Doing the allocation will postpone the pain, until such time as those
folks that we keep hearing have exhausted all of 1918 internally catch
on, and then start using this block as 1918 space.
From: Doug Barton do...@dougbarton.us
there is nothing to stop customers from using the new block internally
...
because the pain of dealing with customers who are using your CGN block
internally is going to exist anyway, why not just use the least popular
1918
On 12/3/2011 5:26 PM, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
there is nothing to stop customers from using the new block internally
...
because the pain of dealing with customers who are using your CGN block
internally is going to exist anyway,
From: Doug Barton do...@dougbarton.us
This argument has been raised before, but IMO the value is exactly
zero. The fact that you have a finger to wag at someone doesn't make
the costs of dealing with the conflict any smaller.
Perhaps. But I don't know the ISPs' business as
Almost all residential customers will use a standard home router; as long as
that home router does not make the new space available to customers, it will
not be used. Almost all residential users get their home NAT box either from
the ISP (who obviously won't ship such a box) or from one of a
On 12/3/2011 5:54 PM, Henning Schulzrinne wrote:
Almost all residential customers will use a standard home router; as
long as that home router does not make the new space available to
customers, it will not be used. Almost all residential users get
their home NAT box either from the ISP (who
The same thought occurred to me. A very large enterprise will not utilize this
/10 on a whim; they'd talk to their ISP first. A consumer is unlikely to
modify the settings of their home router, except if they download malware that
does it for them :) and a consumer router vendor has such a
On Dec 3, 2011, at 5:18 PM, Doug Barton wrote:
We cannot use 1918 for CGN because some customers use it internally,
and they have CPEs that break if the same block is used on both sides.
Therefore, we need a new, !1918 block for our side of the CGN.
The problem with that argument is that
I think this is indeed all about economics. Role acting ISP for a minute: From
a consumer ISP perspective asked to weigh in here, there are two options beyond
the ones mentioned below:
(1) They can support the new /10, which doesn't cost them anything and reduces
the chance that existing NAT
Noel,
Opinion from an operator. There is a difference, and the reality is that
the space is unlikely to be used by enterprises and consumers.
Here is the difference. RFC1918 has been out (defined) for a long time,
so it's well know by operators, enterprise folks and some consumers.
There is a
I've followed the discussion, both on the OPSAWG list and on the
IETF list, and I have to say that I agree with the comments below by
Henning Schulzrinne and Bernard Aboba.
One question, though, that I wish to address to the authors of
draft-weil-shared-transition-space-request and perhaps
CM
One question, though, that I wish to address to the authors of
draft-weil-shared-transition-space-request and perhaps others: why
would not an allocation from 240/4 (the former Class E address
space) work for CGN space? I'm well aware that it would be very
difficult to use this as ordinary
Ron,
Folks,
On Thursday, December 1, the IESG deferred its decision regarding
draft-weil-shared-transition-space-request to the December 15 telechat.
The decision was deferred because:
- it is difficult. (We are choosing between the lesser of two evils.)
- a lively discussion on this mailing
In message pine.lnx.4.64.1112032019010.23...@shell4.bayarea.net, C. M. Heard
writes:
I've followed the discussion, both on the OPSAWG list and on the
IETF list, and I have to say that I agree with the comments below by
Henning Schulzrinne and Bernard Aboba.
One question, though, that I
35 matches
Mail list logo
