In message <32707.1421975...@dash.isi.edu>, John Heidemann writes:
>
> [Warning to rubberneckers: seems like at least two topics here: about
> the spec and about TCP as a DoS.]
>
> On Wed, 21 Jan 2015 14:29:22 -0800, Paul Vixie wrote:
> >#
> >John Heidemann
> >Wednesday, January 21
[Warning to rubberneckers: seems like at least two topics here: about
the spec and about TCP as a DoS.]
On Wed, 21 Jan 2015 14:29:22 -0800, Paul Vixie wrote:
>#
>John Heidemann
>Wednesday, January 21, 2015 1:53 PM
>On Wed, 21 Jan 2015 09:30:44 +, Ray Bellis wrote:
>
>
At Wed, 21 Jan 2015 07:54:18 -0800,
Paul Hoffman wrote:
> On Jan 21, 2015, at 6:52 AM, Colm MacCárthaigh wrote:
> > RRSet: Are the RRs in an RRSet required to have different data? For
> > types such as A//SRV/MX this makes sense, but maybe not for TXT. I
> > also think views and other imple
IESG state changed to Approved-announcement to be sent from IESG Evaluation
ID Tracker URL:
http://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-key-timing/
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
On Wed, 21 Jan 2015, David Conrad wrote:
Thanks very much for this note. The issue of the ZSK length is something that
has popped up on various radars on various occasions and given the recent
publicity over at imperialviolet and sockpuppet on 1024 bit RSA, it'd be good
to explore this in mor
On Thu, Jan 22, 2015 at 12:06:44PM -0500, Tim Wicinski wrote:
>
> The two options are alternative proposals - there should never be a reality
> where both proposals exist as supported options.
Right. The question is whether you think people are going to behave
well (which is more or less what Ra
On 1/22/15 10:54 AM, Alexander Mayrhofer wrote:
* PROTOCOL: Is the expected behaviour (MUST) from both client and server
that they should add the Option to every single request / response during a
keepalive session? Please clarify the intended behaviour..
Two final comments, sorry:
* EDITORI
> * PROTOCOL: Is the expected behaviour (MUST) from both client and server
> that they should add the Option to every single request / response during a
> keepalive session? Please clarify the intended behaviour..
Two final comments, sorry:
* EDITORIAL/PROTOCOL: Shouldn't the option (as well as t
Looks good. The only point I don't understand is why it the zones could
not be signed, and all the anycast sites used slave copies. I realize that
would require separate zones instead of one "empty" zone, but it seems
doable. I don't think DNAME breaks that. Zone refresh and retry and
expire co
Hi,
I've reviewed the keepalive draft. Generally, i do like the concept a lot
because: a) there's certainly a use case that covers real operational issues
b) it's a space-efficient and c) unobstrusive. However, i think the document
could improve on clarity in certain aspects - see below for d
Stephen Farrell has entered the following ballot position for
draft-ietf-dnsop-dnssec-key-timing-06: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please
11 matches
Mail list logo
