Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
I'm still quite confused.
All references to GOST signature algorithms of the kind
[GOST3410] ought to be fixed to say [GOST3410-2001].
I think that can de done, despite the fact that there is no other
algorithm coded as GOST 3410,
At 2:18 PM -0500 2/12/10, Edward Lewis wrote:
At 10:57 -0500 2/12/10, Stephen Kent wrote:
If we look at what the CP developed in the SIDR WG for the RPKI says, the
answer is the IESG (going forward, after an initial set of algs are adopted
based on the SIDR WG process). In the IPSEC, TLS, and
At 8:50 AM -0800 2/12/10, David Conrad wrote:
On Feb 12, 2010, at 7:57 AM, Stephen Kent wrote:
Who gets to decide on what algorithms get first class status and
based on what criteria?
If we look at what the CP developed in the SIDR WG for the RPKI
says, the answer is the IESG
So, they're
-Original Message-
This document:
http://tools.ietf.org/html/draft-dolmatov-cryptocom-gost34102001-08
says
section 1.1:
4. GOST R 34.10-2001 replaces GOST R 34.10-94.
section 1,2:
On one point in this discussion...
I'm not saying that everyone will SEE it, but there actually is an errata
process for RFCs, and the omission of the year-version suffix in RFC 4357
seems like something that would be really helpful to submit an errata for.
Submission page is at
Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
I'm still quite confused.
All references to GOST signature algorithms of the kind [GOST3410]
ought to be fixed to say [GOST3410-2001].
I think that can de done, despite the fact that there is no other
algorithm coded as GOST 3410,
In message 201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex writes
:
OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?)
parameter sets are explicitly listed in last paragraph of section 2
of draft-ietf-dnsext-dnssec-gost-06. However, it does _NOT_ say what
Mark Andrews wrote:
In message 201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex
writes
:
OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?)
parameter sets are explicitly listed in last paragraph of section 2
of draft-ietf-dnsext-dnssec-gost-06.
At 16:50 14-02-10, Masataka Ohta wrote:
Perhaps, a threat will be by an ISP trying to advertise someone
else's address range as its own.
Quoting Sandra Murphy [1]:
Political and business fears don't have to be rooted in technical
truth, unfortunately.
At 19:48 14-02-10, Phillip
At 19:48 14-02-10, Phillip Hallam-Baker wrote:
IANA and ICANN have a really, really bad record when it comes to setting up
root authorities.
Oh? Examples please.
Regards,
-drc
___
Ietf mailing list
Ietf@ietf.org
On 15/02/2010 6:37 PM, Martin Rex wrote:
Mark Andrews wrote:
In message201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin Rex writes
:
OK, I'm sorry. For the DNSsec GOST signature I-D, the default/prefered (?)
parameter sets are explicitly listed in last paragraph of section 2
of
On Feb 15, 2010, at 4:40 PM, Phillip Hallam-Baker wrote:
PEM (Five years and counting before the project faded away without a
definitive declaration of failure)
DNSEC (Ten years and counting)
So, you're blaming IANA and/or ICANN for the failure to deploy both PEM and
DNSSEC.
Seriously?
On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote:
It is now generally accepted that PEM was undeployable because the
single root model is not workable.
And this is the fault of IANA and/or ICANN how?
ICANN was well aware that the lack of opt-out would prevent deployment
of DNSSEC in
I have been selected as the General Area Review Team (Gen-ART) reviewer for
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments you
may receive.
Document:
Phillip Hallam-Baker wrote:
There are two separate functions in the routing layer. There are
security issues in both cases.
interdomain routing security, for which SIDR WG was scoped,
is the second one, though its charter is totally confused.
The second problem is a much harder one to
On 16 feb 2010, at 03.11, David Conrad wrote:
On Feb 15, 2010, at 5:21 PM, Phillip Hallam-Baker wrote:
It is now generally accepted that PEM was undeployable because the
single root model is not workable.
And this is the fault of IANA and/or ICANN how?
Philip, yes, because people did not
16 matches
Mail list logo
