On Mon, 9 Jul 2012 14:27:49 -0400
Alissa Cooper acoo...@cdt.org wrote:
(incorporating some responses to
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg06599.html as a
LC comment)
It would be helpful if this document could further motivate the need for
proxies to generate
On Mon, 09 Jul 2012 13:59:43 -0700
SM s...@resistor.net wrote:
Also, this statement in 8.3 is not really true and probably better left out:
Proxies using this extension will preserve the information of a
direct connection, which has an end-user privacy impact, if the end-
user or
On Mon, 09 Jul 2012 22:48:59 +0100
Stephen Farrell stephen.farr...@cs.tcd.ie wrote:
So I have a question about this draft that wasn't
resolved on apps-discuss and is maybe more suited
for IETF LC anyway.
With geopriv, we've gone to a lot of trouble to
support end-users having some
On Mon, 09 Jul 2012 09:28:48 -0700
The IESG iesg-secret...@ietf.org wrote:
1. While RFC Required forces new registrations through the IETF RFC
process, and might discourage registrations from individuals or
organizations that are unfamiliar with or averse to that process,
Specification
Hi Andreas,
On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
The first statement above gets at this, but it seems to me that the
middle ground between random generation per request and permanent
unique token is worth emphasizing if there will be proxies that want
to keep per-client
On Tue, 10 Jul 2012 10:54:53 -0400
Alissa Cooper acoo...@cdt.org wrote:
Hi Andreas,
On Jul 10, 2012, at 7:27 AM, Andreas Petersson wrote:
The first statement above gets at this, but it seems to me that the
middle ground between random generation per request and permanent
unique token is
On Jul 10, 2012, at 12:07 PM, Andreas Petersson wrote:
The first half of the statement is basically a refinement of the previous
sentence in the section (The Forwarded HTTP header field, by design,
exposes information that some users consider privacy sensitive), so I don't
see what is lost
Hi Andreas,
At 04:28 10-07-2012, Andreas Petersson wrote:
I interpret it the other way around.
It makes a deployer aware that there is also end user expectations
to take into considerations.
Removing it may work as well, but I think that less well reflects the
discussion on the apps-list.
On 07/03/2012 08:24 AM, Alexey Melnikov wrote:
I found the justification for REQ-6 hard to read/understand. Why does
access to
servers being on the internal network need to go through CGN at all?
Here's the thing: the server is not on the internal network. It's on the
external network, but it
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
On Mon, Jul 09, 2012 at 10:48:59PM +0100, Stephen Farrell wrote:
So I have a question about this draft that wasn't
resolved on apps-discuss and is maybe more suited
for IETF LC anyway.
With geopriv, we've gone to a lot of trouble to
support end-users having some control over their
We are pleased to announce Bits-N-Bites, a new community networking
experimental event that will take place for the first time at IETF 84 in
Vancouver.
This event will bring together IETF participants, with exhibitors, product
vendors, and service providers to share information, and showcase
(adding p...@ietf.org to the recipients list...)
Sam,
Thanks for the review, comments inline...
On 07/10/2012 02:16 PM, Sam Hartman wrote:
Requirement 9 requires a Port Control Protocol (PCP) server. I think we
need to say somewhat more about that in order for PCP to be secure on a
CGN. In
On 07/10/2012 04:03 PM, Sam Hartman wrote:
and MUST NOT support the third-party option.
Simon I think pcp-base-26 added restrictions to THIRD_PARTY so that it
could
Simon be used in CGN scenarios. If that is right, wouldn't it then make
Simon sense to allow THIRD_PARTY on
Then that still permits the case of third_party for administration
motivating the text in 13.1.
Makes sense to me.
+1
How about adding a sentence like...
CGN as described in this document does not provide any security
benefits over either single-user NAT or no NAT at all.
I agree with
A new IETF working group has been formed in the Real-time Applications
and Infrastructure Area. For additional information please contact the
Area Directors or the WG Chairs.
Sip Traversal Required for Applications to Work (straw)
Current Status:
A new Request for Comments is now available in online RFC libraries.
RFC 6645
Title: IP Flow Information Accounting and
Export Benchmarking Methodology
Author: J. Novak
Status: Informational
Stream: IETF
A new Request for Comments is now available in online RFC libraries.
RFC 6644
Title: Rebind Capability in DHCPv6 Reconfigure
Messages
Author: D. Evans, R. Droms,
S. Jiang
Status: Standards Track
We are pleased to announce Bits-N-Bites, a new community networking
experimental event that will take place for the first time at IETF 84 in
Vancouver.
This event will bring together IETF participants, with exhibitors, product
vendors, and service providers to share information, and showcase
A new IETF non-working group email list has been created.
List address: tc...@ietf.org
Archive: http://www.ietf.org/mail-archive/web/tcmtf/
To subscribe: https://www.ietf.org/mailman/listinfo/tcmtf
Purpose: This list is for discussing TCMTF, and the potential for a working
group to focus on
20 matches
Mail list logo
