Randy,
On 11/30/11 6:09 AM, Randy Bush wrote:
skype etc. will learn. This does prevent the breakage it just makes
it more controlled. What's the bet Skype has a patched released
within a week of this being made available?
cool. then, by that logic, let's use 240/4. the apps will patch
On 30 November 2011 00:44, Mark Nottingham m...@mnot.net wrote:
Not sure what you're saying here; the URI escape syntax is % HEXDIG HEXDIG.
ACK, sorry for the confusion, I used the same ABNF hex. constructs as in
the literals section for the square brackets.
If the literal character [ occurs
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
value or having an empty value.
1.2
worth pointing out
On 1 December 2011 05:09, Murray S. Kucherawy m...@cloudmark.com wrote:
so long as experimental-status drafts are allowed to make IANA
registrations. (I thought they weren't, which is why it is the
way it is right now.)
Depends on the registry, some registrations need standards track,
others
On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote:
Randy,
On 11/30/11 6:09 AM, Randy Bush wrote:
skype etc. will learn. This does prevent the breakage it just makes
it more controlled. What's the bet Skype has a patched released
within a week of this being made available?
cool.
Ralph,
Where we ran into trouble the last time on this was that the OSS systems
themselves that manage the edge devices needed to be able to actually
communicate with those devices using the reserved space (reachability
testing, what-have-you). All that stuff runs on a variety of h/w,
including
On Dec 1, 2011, at 8:10 AM 12/1/11, Eliot Lear wrote:
Ralph,
Where we ran into trouble the last time on this was that the OSS systems
themselves that manage the edge devices needed to be able to actually
communicate with those devices using the reserved space (reachability
testing,
On 11/28/11 12:58 , Jorge Contreras wrote:
On Mon, Nov 28, 2011 at 2:35 PM, GTW g...@gtwassociates.com
mailto:g...@gtwassociates.com wrote:
__
Ted, I like your approach of enquiring what problem we are striving
to solve and I like Russ's concise answer that it is Recent suits
From: IETF Chair [ch...@ietf.org]
The IETF legal counsel and insurance agent suggest that the IETF ought
to have an antitrust policy. To address this need, a lawyer is
needed.
My first observation is that the IETF legal counsel is a lawyer, so we
have that covered. Then I thought about it
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 some
companies.
I believe that our current rules are fine. They were
The IESG has received a single nomination for the IAOC position. Given this
situation, we are extending the deadline to nominations to 7 December 2011.
In addition, we are opening the comment period on the single willing candidate
that we have before us: Ole Jacobsen.
Please send new
Ralph,
I'm not sure what would take longer - getting new subscriber gws
supporting 240/4 or IPv6 into the field, and I know which one I'd prefer
vendor engineers to be working on ;-).
Chris
On 12/1/11 6:06 AM, Ralph Droms rdroms.i...@gmail.com wrote:
Those subscriber GWs would have to
On 29 Nov 2011, at 18:54, Ronald Bonica wrote:
I think that our time would be used much more productively if we discussed
whether to make the allocation or not. The proposed status of the document is
a secondary issue.
yes, it is, and yes, we should.
I've slept on it, but it's no good.
I will add one more concern with this allocation.
IPv4 address allocation is a market (supply exceeds demand in this
case), and thus a strategic game (like chess) to gather limited
resources .
We have known for a long time how IPv4 was not an acceptable long term solution.
We have known for a
Document Writeup for draft-betts-itu-oam-ach-code-point-01.txt
As required by RFC-to-be draft-iesg-sponsoring-guidelines, this is the
current template for the Document Shepherd Write-Up for individual
submissions via the IESG.
Changes are expected over time. This version is dated February 5,
From: Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com
IPv4 is now practically dead.
The logic here doesn't seem to follow. If it's basically dead, why do you
care how the remaining address space is allocated?
From: Cameron Byrne cb.li...@gmail.com
I do not believe this
Notes below.
On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick presn...@qualcomm.com wrote:
**
Daryl,
The problem described in the draft is that CPEs use 1918 space *and that
many of them can't deal with the fact that there might be addresses on the
outside interface that are the same as on
This draft proposes a way to semi-redact personal information in spam
reports by replacing the address or other string by a hash. It's a
reasonable idea, but as far as I know, it has not been implemented.
Speaking as one of the authors of RFC 5965, which this draft would
update if it were on
As shown at
https://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ballot/,
a few (heh) members of the IESG want to have more discussion on the draft.
Maybe we should wait for one of them (likely Ron) to give direction to that
discussion.
--Paul Hoffman
On 12/1/11 4:02 PM, Paul Hoffman wrote:
As shown at
https://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/ballot/,
a few (heh) members of the IESG want to have more discussion on the
draft. Maybe we should wait for one of them (likely Ron) to give
direction to that
This is not a new proposal. People have been asking for the same thing
for a long time. Draft-bdgks does a good job spelling out the history
(below). To say that we're trying to change the rules at the last minute
is wrong. People have been asking for such an allocation considering this
use
Ted,
There are enterprises that currently use
172.16/12.
Yes, but I thought the topic of discussion when I wrote was the
default prefix used by mass-market NAT CPE boxes. That's a very
different problem than dealing with enterprise networks or even
ISPs that have intentionally deployed
On Dec 1, 2011 4:02 PM, Chris Donley c.don...@cablelabs.com wrote:
This is not a new proposal. People have been asking for the same thing
for a long time. Draft-bdgks does a good job spelling out the history
(below). To say that we're trying to change the rules at the last minute
is wrong.
On 1 Dec 2011, at 21:41, Noel Chiappa wrote:
From: Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com
IPv4 is now practically dead.
The logic here doesn't seem to follow. If it's basically dead, why do you
care how the remaining address space is allocated?
I don't. The marketeers do.
+1
On Dec 1, 2011, at 1:44 PM, 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
some
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 much more practical than
abstract rulemaking.
+1
This has
On 12/1/11 4:27 PM, Ted Hardie wrote:
On Wed, Nov 30, 2011 at 6:14 PM, Pete Resnick presn...@qualcomm.com
mailto:presn...@qualcomm.com wrote:
The problem described in the draft is that CPEs use 1918 space
*and that many of them can't deal with the fact that there might
be
On 12/01/2011 19:47, Pete Resnick wrote:
The current draft says that the reason 1918 space can't be used is that
equipment that deals in 1918 address space is hosed if 1918 addresses
are used on their external interface.
Let's assume that's true for a second (I haven't seen any evidence of
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 these addresses are
Would you take a check for $50 million USD instead of the /10? Sounds like
they are equivalent value.
http://www.detnews.com/article/20111201/BIZ/112010483/1361/Borders-selling-Internet-addresses-for-$786-000
___
Ietf mailing list
Ietf@ietf.org
https
On 12/1/11 10:12 PM, Doug Barton wrote:
On 12/01/2011 19:47, Pete Resnick wrote:
The current draft says that the reason 1918 space can't be used is that
equipment that deals in 1918 address space is hosed if 1918 addresses
are used on their external interface.
Let's assume that's
On 12/1/11 20:28 , Pete Resnick wrote:
On 12/1/11 10:12 PM, Doug Barton wrote:
On 12/01/2011 19:47, Pete Resnick wrote:
The current draft says that the reason 1918 space can't be used is that
equipment that deals in 1918 address space is hosed if 1918 addresses
are used on their external
Total of 263 messages in the last 7 days.
script run at: Fri Dec 2 00:53:02 EST 2011
Messages | Bytes| Who
+--++--+
4.18% | 11 | 3.52% |71750 | julian.resc...@gmx.de
3.80% | 10 | 2.86% |58256 |
On Thu, Dec 1, 2011 at 7:47 PM, Pete Resnick presn...@qualcomm.com wrote:
**
I wrote a response to Brian's original statement then deleted it because I
assumed others would ignore it as clearly last minute and ill-researched.
Apparently, that was wrong. There are enterprises that currently
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 in the future
for customers using any part of the RFC 1918
Ted,
I've been trying to stay out of this round of this debate too,
but...
--On Thursday, December 01, 2011 22:07 -0800 Ted Hardie
ted.i...@gmail.com wrote:
...
An enterprise that has numbered into this space and gets put
behind a CGN by a provider will have no direct control over
this
The IESG has received a request from the IP Performance Metrics WG (ippm)
to consider the following document:
- 'IPPM standard advancement testing'
draft-ietf-ippm-metrictest-05.txt as a BCP
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The IESG has approved the following document:
- 'Definitions of Managed Objects for VRRPv3'
(draft-ietf-vrrp-unified-mib-10.txt) as a Proposed Standard
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Adrian Farrel.
A URL
The IESG has received a request from the Messaging Abuse Reporting Format
WG (marf) to consider the following document:
- 'Redaction of Potentially Sensitive Data from Mail Abuse Reports'
draft-ietf-marf-redaction-03.txt as an Informational RFC
The IESG plans to make a decision in the next few
The IESG has received a request from the Sieve Mail Filtering Language WG
(sieve) to consider the following document:
- 'Sieve Email Filtering: Include Extension'
draft-ietf-sieve-include-13.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
The IESG has approved the following document:
- 'TCP Candidates with Interactive Connectivity Establishment (ICE)'
(draft-ietf-mmusic-ice-tcp-16.txt) as a Proposed Standard
This document is the product of the Multiparty Multimedia Session Control
Working Group.
The IESG contact persons are
The IESG has received a single nomination for the IAOC position. Given this
situation, we are extending the deadline to nominations to 7 December 2011.
In addition, we are opening the comment period on the single willing candidate
that we have before us: Ole Jacobsen.
Please send new
The IESG has received a request from an individual submitter to consider
the following document:
- 'The Canonical Link Relation'
draft-ohye-canonical-link-relation-04.txt as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
The IESG has received a request from an individual submitter to consider
the following document:
- 'Collection Synchronization for WebDAV'
draft-daboo-webdav-sync-06.txt as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.
The Internet Architecture Board is pleased to announce the appointment of
Heather Flanagan as the RFC Series Editor (RSE). Ms. Flanagan will assume
the responsibilities from the Acting RSE, Olaf Kolkman, and begin her tenure
on January 1, 2012. The contract negotiated by the IAOC includes an
Colleagues,
Under the RFC Editor model (RFC5620) the IAB periodically reviews the
performance of the Independent Series Editor (ISE), currently Nevil
Brownlee.
If you have any feedback on the performance of the ISE, please send email to
the IAB chair iab-ch...@iab.org before December 10,
http://tools.ietf.org/html/draft-hansen-privacy-terminology Privacy
Terminology has been adopted as an IAB document. Comments can be sent to
the IAB mailto:i...@iab.org?subject=Comments%20on%20Privacy%20Terminology
or the ietf-privacy mailto:ietf-priv...@ietf.org mailing list, which can
be
47 matches
Mail list logo
