Sorry, I forgot one additional comment.
While there seems not be a solid definition of what the “Updates” means in the
RFC header, it always seems to me that “Updates” means you are changing
something in those documents, rather than just extending them with new
capabilities within the original
Hi:
I have reviewed the document. In general, it is well written and ready to be
advanced, though there are some nits that the authors should review and
consider:
Section 1: Not sure why Stateful is capitalized in the following line:
transport protocol. Each Stateful operation is communicated
On 1 February 2018 at 16:20, Andrew Sullivan wrote:
> I am not convince that "it should not" is true, and having thought
> about this a little more it seems to me that an IANA registry should
> have been created in the first place for this sort of miserable
> in-label hack. If it had been, we co
On Tue, Feb 13, 2018 at 1:49 PM, Wessels, Duane wrote:
>
>> On Feb 13, 2018, at 9:10 AM, Bob Harold wrote:
>>
>> If an entry could be put in the root zone, that is signed only with the new
>> key, then could users query that and always get a yes/no answer to whether
>> they will be affected?
>
> On Feb 13, 2018, at 9:10 AM, Bob Harold wrote:
>
> If an entry could be put in the root zone, that is signed only with the new
> key, then could users query that and always get a yes/no answer to whether
> they will be affected?
This doesn't work because when the new key is published in t
On 13 Feb 2018, at 12:10, Bob Harold wrote:
> Thanks, the explanation helped. I finally realized that it only works if all
> (or most) validating resolvers are updated to support this new feature,
> otherwise we have a bunch of responses that are uncertain.
Based on numbers of queries arrivin
On 02/13/2018 06:10 PM, Bob Harold wrote:
> [...] If an entry could be put in the root zone, that is signed only
> with the new key, then could users query that and always get a yes/no
> answer to whether they will be affected?
I don't think that's possible. This is about the _single_ root DNSKE
On Mon, Feb 12, 2018 at 3:28 PM, Warren Kumari wrote:
>
>
> Hi all,
>
> Sorry it has taken so long to get a new version of this document
> posted - you deserve better.
>
> Anyway, we've finally posted an updated version -
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
>
>