On Apr 3, 2014, at 4:00 PM, Suzanne Woolf wrote:
> Understood that wordsmithing is needed, and getting the wording right is an
> important detail, but I think we're even more interested in whether the item
> should be there at all: should DNSOP, in appropriate collaboration with all
> relevant
Paul (and Andrew),
On Apr 3, 2014, at 6:42 PM, Paul Hoffman wrote:
> On Apr 3, 2014, at 2:50 PM, Andrew Sullivan wrote:
>
>> Given that "liaison" is a term of art around the IETF, perhaps the
>> latter sentence needs to be phrased another way? I'm not sure exactly
>> what you have in mind, or
On Apr 3, 2014, at 2:50 PM, Andrew Sullivan wrote:
> On Thu, Apr 03, 2014 at 05:39:58PM -0400, Suzanne Woolf wrote:
>
>> operated on Internet networks. This will include root zone
>> name servers, TLD name servers, name servers for other DNS
>> zones, iterative DNS resolvers, and recursive
On Thu, Apr 03, 2014 at 05:39:58PM -0400, Suzanne Woolf wrote:
>operated on Internet networks. This will include root zone
>name servers, TLD name servers, name servers for other DNS
>zones, iterative DNS resolvers, and recursive DNS resolvers.
Is there a reason to call out these part
Colleagues,
Here is draft text for the new charter we've been talking about for DNSOP.
When we have something the WG is comfortable with, we get to ask our AD to take
it to the IESG, so please review and comment.
(If you want to comment off-list, please send to dnsop-cha...@tools.ietf.org,
cc'
Last summer I believed that this draft was vitally important, but, and as the
editor’s know, I am less optimistic.
Below is a minor nit to start and then trying to re-write (for my benefit) the
protocol this is describing. I did the latter to try to clean up a lot of
loose language and in the
In your previous mail you wrote:
> The verification performance is bad, P256 takes 24x times longer to verify a
> signature than 2048 bit RSA key.
=> I got a different figure (6x) for my ECC paper, and:
- it was published the 3 may 2013 so one can expect ECC performance
has been improved s
On Wed, Apr 2, 2014 at 11:24 PM, Phillip Hallam-Baker wrote:
>
>
>
> On Wed, Apr 2, 2014 at 10:48 PM, Andrew Sullivan
> wrote:
>
>> On Wed, Apr 02, 2014 at 09:07:07PM -0400, Phillip Hallam-Baker wrote:
>> > 1) Client -> Resolver
>>
>> > Changing 1 is the easiest and also the part that is most in
On 3 Apr 2014, at 12:09, Patrik Fältström wrote:
> What does "would be a good idea" mean in RFC 1918 speak? :-)
Hmm...not enough coffee...RFC 2119 of course.
Patrik
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP
On 3 April 2014 04:18, David Conrad wrote:
> Paul,
>
> On Apr 3, 2014, at 12:38 AM, Paul Wouters wrote:
Saving space and time does matter. Roughly half the operators I studied
would include a backup key on-line because "they could" with the shorted
length. And performance does
First of all, let me thank the people that have been working so hard on this. I
have followed the process, but now again re-read the whole thing, and because
of that have some comments. Ignore or think about... :-)
>This document describes a method for automating maintanance of the
>dele
11 matches
Mail list logo
