On 2011-12-06 22:06, Benson Schliesser wrote:
ISPs need to use addressing within this scope that does not cause (additional)
problems for their existing customers (and their customers' equipment). And in
the event of an addressing conflict, operators (on both sides) need a common
reference to
Based on the discussion on the 82 attendees list, I put together a draft that
provides a list of common questions (but not necessarily answers) that people
ask when preparing to travel to a meeting. As the draft states, this is an
attempt to provide a list of ideas for folks who can contribute
On 12/7/2011 6:09 AM, George, Wes wrote:
I'm also open to suggestions as to the appropriate publication track for
thisdocument, whether I should look to have it sponsored as a GenArea doc or
simply
put it forward as an individual submission.
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Wednesday, December 07, 2011 9:28 AM
To: George, Wes
Cc: IETF Discussion
Subject: Re: Travel/Attendees list FAQ
However I suggest that the document cast itself as a snapshot of an on-
going
documentation process, with the master copy
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/07/2011 06:27 AM, Dave CROCKER wrote:
On 12/7/2011 6:09 AM, George, Wes wrote:
I'm also open to suggestions as to the appropriate publication track for
thisdocument, whether I should look to have it sponsored as a GenArea doc or
simply
What is the value in publishing a living document as an RFC (which inherently a
static, archival document)? Wouldn't it make more sense to convert the
contents of this document to a Wiki page that we could jointly edit and
maintain going forward?
Margaret
On Dec 7, 2011, at 9:27 AM, Dave
On 12/7/2011 6:40 AM, George, Wes wrote:
However I suggest that the document cast itself as a snapshot of an on-
going documentation process, with the master copy being an IETF Wiki; the
document should contain a point to the wiki.
[WEG] There is currently a pointer to the wiki, but I'll have
The IESG has received a third willing nominee for the IAOC position. Imran
Ahmed Shah would like to serve the community as an IAOC member. Please send
comments on the three candidates that we have so far to i...@ietf.org. The
three willing nominees are:
-- Ole Jacobsen
-- Tobias Gondrom
On Dec 7, 2011, at 7:11 AM, Margaret Wasserman wrote:
What is the value in publishing a living document as an RFC (which inherently
a static, archival document)? Wouldn't it make more sense to convert the
contents of this document to a Wiki page that we could jointly edit and
maintain
Folks,
I'm the newest IAOC/Trust member (from last year). The previous year I was on
Nomcom. This year I am the IAOC Liaison to Nomcom. All of this has sensitized
me about how little I and others have tended to know about the concrete work of
the IAOC and Trust.
As a simple aid, I
On 7 December 2011 18:08, Dave CROCKER d...@dcrocker.net wrote:
here's the cryptic list of terms that covers it:
Administration
Not limited to http://trustee.ietf.org/minutes.html, but it's
an interesting place to get a rough idea confirming Dave's list;
and why it is not a part of
From: Dave CROCKER d...@dcrocker.net
Subpoenas
Subpoenas? Really? Wow!
Well, that should scare a few people off... :-)
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On Dec 7, 2011, at 7:11 AM, Margaret Wasserman wrote:
What is the value in publishing a living document as an RFC (which
inherently a static, archival document)? Wouldn't it make more sense
to convert the contents of this document to a Wiki page that we could
jointly edit and maintain
On 12/7/2011 9:28 AM, George, Wes wrote:
This is a list of the*questions* because they do not change much from one
meeting to the next. The document already recommends that the*answers* which
will be different for every venue be kept in a place where they are more easily
updated.
I
On Wed, Dec 07, 2011 at 09:36:01AM -0800, Dave CROCKER wrote:
But note that there needs to be a different wiki for each IETF
meeting. That includes a different URL. We should preserve each
meeting's wiki as part of the meeting archive, rather than replacing
one meeting's content with the
On 12/07/2011 11:48 AM, Andrew Sullivan wrote:
On Wed, Dec 07, 2011 at 09:36:01AM -0800, Dave CROCKER wrote:
But note that there needs to be a different wiki for each IETF
meeting. That includes a different URL. We should preserve each
meeting's wiki as part of the meeting archive, rather
On 12/7/2011 9:48 AM, Andrew Sullivan wrote:
On Wed, Dec 07, 2011 at 09:36:01AM -0800, Dave CROCKER wrote:
But note that there needs to be a different wiki for each IETF
meeting. That includes a different URL. We should preserve each
meeting's wiki as part of the meeting archive, rather
Benson == Benson Schliesser bschl...@cisco.com writes:
Benson However, there is one essential point that I'd like to
Benson clarify: We need a common standard for numbering CGN NAT444
Benson deployments.
Benson For NAT444 deployments of CGN, we are talking about a new
Benson
Wes,
On Dec 7, 2011, at 9:28 AM, George, Wes wrote:
On Dec 7, 2011, at 7:11 AM, Margaret Wasserman wrote:
What is the value in publishing a living document as an RFC (which
inherently a static, archival document)? Wouldn't it make more sense
to convert the contents of this document to a
Incidentally I get
acsmt358.oracle.com #5.1.1 SMTP; 550 5.1.1 Recipient unknown
for marc.had...@oracle.com
and
r...@fireeye-mail.emps.mitre.org: delivery temporarily suspended: connect to
fireeye-mail.emps.mitre.org[129.83.4.94]:25: Connection timed out
for mhad...@mitre.org;
which may or may
On 2011-12-08 06:26, Noel Chiappa wrote:
From: Dave CROCKER d...@dcrocker.net
Subpoenas
Subpoenas? Really? Wow!
Well, that should scare a few people off... :-)
Subpoenas served on the IETF (Trust) about prior art or IPR disclosure,
not on individuals. It was never a problem
Michael,
On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote:
The CGN space seems like a very good place to use 240.0/10.
I believe the main driver behind this discussion is the need to deal with
deployed non-field-upgradable CPE that has issues with having RFC 1918 space
being assigned on
The flip side of this argument is that it could be viewed as a helpful
guide for the hosts/sponsors at any given venue. (This is the kind of
information you should provide.)
At APRICOT, we've developed an Ops Manual[1] that covers everything
from room setup to no kareoke at the social event.
Hi Doug,
We have local source address selection mechanisms in recent Windows
versions that use randomized IIDs on outbound connections today. This
doesn't prevent exposure of the information regarding the internal
network structure, but nor do firewalls at publically addressed IPv4
Hi Martin,
As long as the current IPv4 characteristics are not transparently
available with IPv6, it will probably deter adoption of IPv6 for the
installed base.
I would argue that this is a commonly held incorrect view: The problem is not
that feature sets are unavailable, but that
On 12/07/2011 10:33 AM, Ole Jacobsen wrote:
The flip side of this argument is that it could be viewed as a helpful
guide for the hosts/sponsors at any given venue. (This is the kind of
information you should provide.)
I don't see any reason that couldn't be wikified, either.
I am not sure
I am not arguing against the wiki, I am just saying that there is
value in having a single file, or document, or maybe checklist
that can be retrieved (and printed) too. And we have lots of docs
that could hardly be described as formal.
But a template for the required information would indeed
David == David Conrad d...@virtualized.org writes:
David On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote:
The CGN space seems like a very good place to use 240.0/10.
David I believe the main driver behind this discussion is the need
David to deal with deployed
On 12/7/2011 11:44 AM, Melinda Shore wrote:
I'm also pretty sure (not 100%, but somewhere north
of 50%) that there really aren't any serious archival requirements
for the material under discussion.
formal requirements, perhaps not.
however the collection of information that is provided for
On 12/07/2011 10:51 AM, Ole Jacobsen wrote:
But a template for the required information would indeed be useful.
I guess I'm not seeing anything here that looks to me like
requirements, or anything here that can't be satisfied with
something totally open, like a wiki.
This whole business of
On Dec 7, 2011, at 2:33 PM, Ole Jacobsen wrote:
The flip side of this argument is that it could be viewed as a helpful
guide for the hosts/sponsors at any given venue. (This is the kind of
information you should provide.)
+ lots...
I work for a company that is sponsoring an upcoming
On Dec 7, 2011, at 7:46 AM, Simon Perreault wrote:
On 2011-12-06 22:06, Benson Schliesser wrote:
ISPs need to use addressing within this scope that does not cause
(additional)
problems for their existing customers (and their customers' equipment). And
in
the event of an addressing
- Original Message -
From: Brian E Carpenter brian.e.carpen...@gmail.com
To: Noel Chiappa j...@mercury.lcs.mit.edu
Cc: ietf@ietf.org
Sent: Wednesday, December 07, 2011 8:15 PM
On 2011-12-08 06:26, Noel Chiappa wrote:
From: Dave CROCKER d...@dcrocker.net
Subpoenas
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Melinda Shore
I think it's great that Wes put together
a proposal and I hope that it's seen as a starting point for
a wiki or some such rather than as yet something else that
needs an editor and needs an approval
On 2011-12-08 08:41, t.petch wrote:
- Original Message -
From: Brian E Carpenter brian.e.carpen...@gmail.com
To: Noel Chiappa j...@mercury.lcs.mit.edu
Cc: ietf@ietf.org
Sent: Wednesday, December 07, 2011 8:15 PM
On 2011-12-08 06:26, Noel Chiappa wrote:
From: Dave CROCKER
OK, so now we have a data point from someone who is the target customer for
this work. It sounds like they want a stable document (with quotes).
Dave started the thread towards wiki, but didn't define if wiki meant
anyone in the IETF community could edit it or a non-editable web page that
Yes,
I would be happy to say to a host/sponsor: We have a baseline
document X, it's been out there for a while and some additions,
suggestions etc can be found at Wiki W. Please have a look at
X and W, and see example E for how host foo did this at IETF
nn.
Ole
Ole J. Jacobsen
Editor and
On Wed, 7 Dec 2011, Melinda Shore wrote:
On 12/07/2011 10:33 AM, Ole Jacobsen wrote:
The flip side of this argument is that it could be viewed as a helpful
guide for the hosts/sponsors at any given venue. (This is the kind of
information you should provide.)
I don't see any reason
From: Michael Richardson m...@sandelman.ca
The CGN space seems like a very good place to use 240.0/10.
A single organization often controls and specifies all equipment which
will use the address space
Not _exclusively_ 240/, though, because as has been pointed out numerous
Subject: Re: Consensus Call (Update):
draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at
11:31:11AM -0800 Quoting David Conrad (d...@virtualized.org):
Michael,
On Dec 7, 2011, at 10:39 AM, Michael Richardson wrote:
The CGN space seems like a very good place to use
In message 20111207220317.3530b18c...@mercury.lcs.mit.edu, Noel Chiappa write
s:
From: Michael Richardson m...@sandelman.ca
The CGN space seems like a very good place to use 240.0/10.
A single organization often controls and specifies all equipment which
will use the
From: Mark Andrews ma...@isc.org
And it needs a seperate I-D which indicates how equipement can signal
that it supports 240.0/10. Returning such a address to equipment that
is not prepared to receive is a *very* bad idea.
I wasn't suggesting using general use for 240/
In message 20111207223526.gj20...@besserwisser.org, =?utf-8?B?TcOlbnM=?= Nils
son writes:
Subject: Re: Consensus Call (Update): draft-weil-shared-transition-space-re=
quest Date: Wed, Dec 07, 2011 at 11:31:11AM -0800 Quoting David Conrad (drc=
@virtualized.org):
Michael,
=20
On Dec 7,
On Dec 7, 2011, at 6:57 PM, Noel Chiappa wrote:
I wasn't suggesting using general use for 240/ addresses, as endpoint names -
that's a hopeless cause, there are too many things out there that can't deal
with them. Who wants an address lots of people can't talk to (with, or
without, a
Sabahattin Gucukoglu wrote:
1. If you just want to camouflage internal clients,
do it with privacy addresses or a socks proxy and clients.
I don't see a purpose to camouflage internal clients from
internal peers. And my ISP would probably and rightfully refuse
to route my IP datagrams if he
On 12/7/2011 1:12 PM, Ole Jacobsen wrote:
Yes,
I would be happy to say to a host/sponsor: We have a baseline
document X, it's been out there for a while and some additions,
suggestions etc can be found at Wiki W. Please have a look at
X and W, and see example E for how host foo did this at
On 12/7/2011 12:46 PM, Brian E Carpenter wrote:
Subpoenas served on the IETF (Trust) about prior art or IPR disclosure,
not on individuals. It was never a problem when I was on the IAOC, just
a matter of being aware.
What about 'anti-trust' actions? Who cops it for those, were a
On 12/7/11 11:39 AM, Michael Richardson m...@sandelman.ca wrote:
Benson == Benson Schliesser bschl...@cisco.com writes:
Benson However, there is one essential point that I'd like to
Benson clarify: We need a common standard for numbering CGN NAT444
Benson deployments.
Benson
We're requesting a /10, not a /12 or /15 (devices attached to one CGN
might use the whole /15). Such an allocation would be too small for a
regional CGN deployment at a larger ISP, and would likely result in
double-CGN. Shared CGN Space really needs to be a /10.
Second, many ISPs do not control
Noel Chiappa wrote:
I was suggesting them purely for infrastucture use, in (probably _very_
limited) usage domains where their visibility would be over a limited scope,
one where all devices can be 'pre-cleared' for using them.
More generally, class E should be used for unicast only when
You really don't know what IPv6 boxes are capable of. Below is the
start of a netstat of the active IPv6 connections. The first
connection is a internal connection. The stack automatically choose
to use the ULA address (fd92) over the non-ULA address as it was a
connection to a internal host.
--On Wednesday, December 07, 2011 10:41 -0800 Bob Hinden
bob.hin...@gmail.com wrote:
...
Also, if it gets published as an RFC, it is going to be viewed
as a specification. I think it's best to avoid that and
just have a wiki.I would be surprised if this topic
continues to be as active
Subject: Re: Consensus Call (Update):
draft-weil-shared-transition-space-request Date: Wed, Dec 07, 2011 at
08:17:47PM -0700 Quoting Chris Donley (c.don...@cablelabs.com):
We're requesting a /10, not a /12 or /15 (devices attached to one CGN
might use the whole /15). Such an allocation would
Subject: Re: Consensus Call (Update):
draft-weil-shared-transition-space-request Date: Thu, Dec 08, 2011 at
12:30:05PM +1100 Quoting Mark Andrews (ma...@isc.org):
Does anybody know of any evidence to the contrary?=20
This is not a ISP/CUSTOMER problem. This is a ISP/CUSTOMER/WORK problem.
The IESG has received a request from an individual submitter to consider
the following document:
- 'Generic Connection Admission Control (GCAC) Algorithm Specification
for IP/MPLS Networks'
draft-ash-gcac-algorithm-spec-03.txt as an Experimental RFC
The IESG plans to make a decision in the
The IESG has approved the following document:
- 'Data for Reachability of Inter/tra-NetworK SIP (DRINKS) Use cases and
Protocol Requirements'
(draft-ietf-drinks-usecases-requirements-06.txt) as an Informational
RFC
This document is the product of the Data for Reachability of
The IESG has approved the following document:
- 'Media Gateway Control Protocol (MGCP) Voiceband Data Package (VBD) and
General Purpose Media Descriptor Parameter Package'
(draft-stone-mgcp-vbd-10.txt) as an Informational RFC
This document has been reviewed in the IETF but is not the product
The IESG has received a third willing nominee for the IAOC position. Imran
Ahmed Shah would like to serve the community as an IAOC member. Please send
comments on the three candidates that we have so far to i...@ietf.org. The
three willing nominees are:
-- Ole Jacobsen
-- Tobias Gondrom
58 matches
Mail list logo
