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,
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
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
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
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
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
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
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
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
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
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',
[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
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
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
14 matches
Mail list logo