Re: Time to dump X.400 support?

2013-09-25 Thread Dave Cridland
On Tue, Sep 24, 2013 at 5:25 PM, Phillip Hallam-Baker hal...@gmail.comwrote: Looking at the extreme breach of trust by US govt re PRISM, I think it is time to do something we should have done decades ago but were stopped at US Govt request. Lets kill all support for X.400 mail. Actually,

Re: Last Call: draft-kolkman-proposed-standards-clarified-03.txt (Characterization of Proposed Standards) to Best Current Practice

2013-09-25 Thread Benoit Claise
Dear all, Thanks for this important, which I support. In section 2, I would add that only a few protocols moved from Proposed Standard to Internet Standard, even if those protocols were widely deployed in the Internet. This proves the points that: 1. the specifications were stable 2. the

Re: DRAFT-IETF-GEOPRIV-RADIUS-LO-23

2013-09-25 Thread todd glassey
On 04/08/2009 12:12 PM, Anthony Leibovitz wrote: As an example, Section 1 states that location information needs to be protected against unauthorized access and distribution, yet nowhere in the document are the implications of this statement for the RADIUS protocol laid out. D Anthony

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

2013-09-25 Thread Tony Tauber
On Tue, Sep 24, 2013 at 2:53 PM, Randy Bush ra...@psg.com wrote: hi wes, why does proximity matter? Is this just an extension of the trust domain and limited dependence on routing protocols? If so, I'd dispense with recommending close because it confuses the issue and just keep the

Re: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14

2013-09-25 Thread Yakov Rekhter
David, Yakov, First of all, thank you for overlooking the off-by-one error on the year :-) - Review Date: September 23, 2012 IETF LC End Date: September 23, 2012 Of course, 2013 was intended, twice ;-). :-) On the two items (both are editorial, IMHO): (1) The techniques in

RE: Transport Directorate review of: draft-ietf-l2vpn-vpls-mcast-14

2013-09-25 Thread Black, David
Yakov, How about if I'll add the following at the end of 5.5: Aggregation procedures would require two labels stack. This does not introduce any new implications on MTU, as even VPLS multicast supported by ingress replication requires two labels stack. Sure, minor suggestion - two

RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

2013-09-25 Thread George, Wes
From: Randy Bush [mailto:ra...@psg.com] are you really saying that i should be comfortable configuring a seattle router to use a cache in tokyo even though both are in my network and there is a pretty direct hop? [WEG] not necessarily. But I'm also not saying that there would *never* be a

RE: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

2013-09-25 Thread George, Wes
From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] [CLM] In the RPKIcache example, 'consumer' is 'routers in your network'. 'Close' is 'close enough that bootstrapping isn't a problem', balanced with 'gosh, maybe I don't want to put one on top of each router! plus

ISOC fellowship - Attracting new people and work into the IETF (was: In person vs remote participation to meetings)

2013-09-25 Thread S Moonesamy
Hi Alessandro, At 00:22 28-09-2012, Alessandro Vesely wrote: IMHO, participation of individuals and small businesses is not less important than that of newcomers from emerging and developing economies. I noticed that you asked a question about the ISOC fellowship about a year ago. There is

Re: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04

2013-09-25 Thread Rifaat Shekh-Yusef
We have just submitted a new version (v05) that addresses all the comment we received so far. http://www.ietf.org/id/draft-yusef-dispatch-ccmp-indication-05.txt Please, let us know if you have any further comments. Regards, Rifaat On Tue, Sep 24, 2013 at 5:38 PM, Ben Campbell b...@nostrum.com

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

2013-09-25 Thread Christopher Morrow
On Wed, Sep 25, 2013 at 12:38 PM, George, Wes wesley.geo...@twcable.com wrote: From: christopher.mor...@gmail.com [mailto:christopher.mor...@gmail.com] [CLM] In the RPKIcache example, 'consumer' is 'routers in your network'. 'Close' is 'close enough that bootstrapping isn't a problem',

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

2013-09-25 Thread Randy Bush
[WEG] that's part of my issue - the only way that you get close enough that bootstrapping isn't a problem is when the cache and router are directly there's some baseline that's acceptable, you intimate that IGP comes up before EGP below. that makes some sense, and thus maybe the target is

Re: [sidr] Last Call: draft-ietf-sidr-origin-ops-21.txt (RPKI-Based Origin Validation Operation) to Best Current Practice

2013-09-25 Thread Randy Bush
how about To relieve routers of the load of performing certificate validation, cryptographic operations, etc., the RPKI-Router protocol, [RFC6810], does not provide object-based security to the router. I.e. the router may not validate the data cryptographically from a well-known

Re: [ietf-privacy] New Version Notification for draft-cooper-ietf-privacy-requirements-00.txt

2013-09-25 Thread Stephen Farrell
Hi Avri, On 09/25/2013 01:08 PM, Avri Doria wrote: Hi Very much support the draft and the idea of creating a BCP. Have also appreciated the discussion on opportunistic encryption, which I consider akin to a holy grail. Been thinking about it in a DTN context for a while, but don't feel