> On 21 Oct 2018, at 17:40, fujiw...@jprs.co.jp wrote:
>
>> From: Vladimír Čunát
>> On 10/17/18 11:18 PM, fujiw...@jprs.co.jp wrote:
>>> 4. In my opinion, Ed25519 is best algorithm some yars later.
>>> If the document describes both current RECOMMENDATIONS and
>>> RECOMMENDATIONS some years
Fujiwara-san,
I don’t exactly understand why such table would be better than existing text
that say:
> 3.2. DNSKEY Algorithm Recommendation
>
>Operation recommendation for new and existing deployments.
>
>Due to industry-wide trend to move to elliptic curve cryptography,
>the ECDS
> From: Vladimír Čunát
> On 10/17/18 11:18 PM, fujiw...@jprs.co.jp wrote:
>> 4. In my opinion, Ed25519 is best algorithm some yars later.
>>If the document describes both current RECOMMENDATIONS and
>>RECOMMENDATIONS some years later, we can plan.
>
>
> I agree, but the last paragraph of
On 10/17/18 11:18 PM, fujiw...@jprs.co.jp wrote:
> 4. In my opinion, Ed25519 is best algorithm some yars later.
>If the document describes both current RECOMMENDATIONS and
>RECOMMENDATIONS some years later, we can plan.
I agree, but the last paragraph of 3.1 seems to express that already:
What I want to say about draft-ietf-dnsop-algorithm-update-02 are below:
1. About chapter composition
If section 3.2 is "recommendations for operators",
Section 3.1 and Section 3.3 are recommendations for software developpers
and TLD/Root operators.
# Sometimes TLD/Root do not accept
I have read the draft and support it advancing. It is a good
replacement for RFC 6944.
Scott
On 2 Oct 2018, at 8:51, Tim Wicinski wrote:
The chairs and the authors of this document feel that the
document is in solid shape to proceed to WGLC.
This starts a Working Group Last Call for
draft
WGLC comment to draft-ietf-dnsop-algorithm-update-02
Section 3.2 is "recommendations for operators".
There is texts that discuss ECDSAP256SHA256 only in section 3.2.
However, RSASHA256 is still usable.
Please add text about other algorithms.
if there is a table similar to section 3.1, it will hel
I've been using the document for the DNSSD Service Registration Protocol
work; it's useful, and should be published.
On Sun, Oct 14, 2018 at 5:55 AM Tim Wicinski wrote:
> Follow up on WGLC for draft-ietf-dnsop-algorithm-update:
>
> We're still looking for comments from the WG on advancing or not
Tim,
I have reviewed the document and it is ready for publication
Olafur
On Tue, Oct 2, 2018 at 2:51 PM Tim Wicinski wrote:
>
> The chairs and the authors of this document feel that the
> document is in solid shape to proceed to WGLC.
>
>
> This starts a Working Group Last Call for draft-ietf-
Hi Loganaden,
while I understand what you are asking for, I don’t understand how it would
improve the document.
IETF RFCs are static and if we include any current “numbers” they quickly
become invalid. Adding figures to the document doesn’t improve readability or
the content. While it would
Follow up on WGLC for draft-ietf-dnsop-algorithm-update:
We're still looking for comments from the WG on advancing or not advancing
this document through the standards process.
While a percentage of the WG is at OARC (and maybe even RIPE), why not take
a few moments and elicit some comments
on thi
On Tue, Oct 2, 2018 at 4:51 PM Tim Wicinski wrote:
>
>
> The chairs and the authors of this document feel that the
> document is in solid shape to proceed to WGLC.
>
>
> This starts a Working Group Last Call for draft-ietf-dnsop-algorithm-update
>
> Current versions of the draft is available here:
The chairs and the authors of this document feel that the
document is in solid shape to proceed to WGLC.
This starts a Working Group Last Call for draft-ietf-dnsop-algorithm-update
Current versions of the draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-algorithm-update
13 matches
Mail list logo
