Speaking as regular ol' member
Some comments on draft-ietf-sidr-rfc6485bis-01.txt
Most of my comments are related to the attempt to add a new OID to
RFC6485, which previously had only one to specify.
* The signature algorithm used in certificates, CRLs, and signed
objects is RSA
And one I forgot:
CAs and RPs SHOULD be capable of supporting a transition to allow for
the phased introduction of additional encryption algorithms and key
specifications,
Is this any different than the algorithm agility in RFC6916? If so, I'd think
a reference would be good. If not,
coming back to this discussion...
On Fri, Feb 7, 2014 at 10:17 PM, Randy Bush ra...@psg.com wrote:
perhaps people should use a dictionary and look up per se.
(from dictionary.com, or wherever bing.com 'define per se' comes from)
per se
1. by or in itself or themselves; intrinsically.
so, as I
I could easily replace per se with 'intrinsically' like:
yes. do we need to play synonyms when, ab definito, they mean the same
thing? i chose my words. as you point out, they are correct.
Is there a reason to keep the mention of route-leaks in this document?
i think it was shane who
On Mon, Apr 14, 2014 at 11:00 AM, Randy Bush ra...@psg.com wrote:
while checking the docco, i found
3.14 While the trust level of a route should be determined by the
BGPsec protocol, local routing preference and policy MUST then
be applied to best path and other routing
The CPS was written well before 6916 was finished.
A reference to that RFC now makes sense.
Steve
On 4/14/14 10:43 AM, Sandra Murphy wrote:
And one I forgot:
CAs and RPs SHOULD be capable of supporting a transition to allow for
the phased introduction of additional encryption
