I support adoption of this work and I'm willing to review and contribute as
needed.
mehmet
On Thu, Nov 16, 2017 at 12:23 AM, tjw ietf wrote:
> All
>
> The author has rolled out a new version addressing comments from the
> meeting on Monday, and we feel it’s ready to move
Hi
The call for adoption for this has ended and the groups has requested
adoption. I will contact the authors about updating their draft with the
new name as well as addressing open issues during the call.
tim
On Thu, Nov 16, 2017 at 3:23 AM, tjw ietf wrote:
> All
>
>
> On Nov 16, 2017, at 3:23 AM, tjw ietf wrote:
>
> This starts a Call for Adoption for draft-huston-kskroll-sentinel
I support the document and will review and provide comments.
Matt
___
DNSOP mailing list
DNSOP@ietf.org
On Nov 27, 2017, 11:47 AM -0800, Richard Barnes , wrote:
> I don't think that it make sense to infer from the failure of RFC 8145 that
> resolver/authoritative telemetry isn't possible
Huh? RFC 8145 wasn’t a failure — it was stunningly successful. Within a few
months of
tjw ietf writes:
> The author has rolled out a new version addressing comments from the
> meeting on Monday, and we feel it’s ready to move this along.
FYI,
I hate this document. I hate the idea of introducing yet another magic
keyword into the DNS protocol that requires
> On Nov 27, 2017, at 11:47 AM, Richard Barnes wrote:
>
> I don't think that it make sense to infer from the failure of RFC 8145 ...
Do you really think RFC 8145 is a failure (even having only recently learned
about its existence)?
No doubt there are complications and
On 27 Nov 2017, at 14:47, Richard Barnes wrote:
> As tempting as it may be to do the easy thing, it's not always the best use
> of resources. Looking at the closest tree might be easy for one observer,
> but when you try to do it with enough observers to have a result that's
>
As I imagine you've heard, part of the problem with resolver-authoritative
telemetry interfaces is that the deployed infrastructure is not so simple; it
also includes forwarders, changed resolvers, caches, middleware that interferes
with the query path and/or drops queries that don't look
Well, that's what I get for providing drive-by feedback. Someone pointed
me off-list to RFC 8145 and the operational issues with that. I still
think that that calls for a better authoritative/resolver telemetry
interface, not some client-side thing.
On Mon, Nov 27, 2017 at 1:10 PM, Richard
George, you should know better than to claim that a mechanism that requires
resolver updates will have "immediate benefit" :)
I do not find this mechanism terribly compelling. It is not useful in the
short run, as noted above. And it has the wrong architecture for the long
run.
What zone
On 16/11/2017, 12:23, tjw ietf typed:
>
> All
>
> The author has rolled out a new version addressing comments from the meeting
> on Monday, and we feel it’s ready to move this along.
>
> This starts a Call for Adoption for draft-huston-kskroll-sentinel
Support adoption too.
Thanks,
Daniel
FYI, I'm taking notes of all the issues raised by folks in this thread
(thank you!) and will hold the authors accountable in addressing them.
tim
On Fri, Nov 24, 2017 at 11:41 AM, Paul Hoffman
wrote:
> I would like to see this draft adopted and worked on by the WG.
I would like to see this draft adopted and worked on by the WG. Some of
Ed's observations ring true for me as well, but I can see ways forward
for all the ones that concern me.
--Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
I support adoption and will review the draft.
-- Benno
On 11/16/2017 09:23 AM, tjw ietf wrote:
> All
>
> The author has rolled out a new version addressing comments from the
> meeting on Monday, and we feel it’s ready to move this along.
>
> This starts a Call for Adoption for
On 16 November 2017 at 00:23, tjw ietf wrote:
> All
>
> The author has rolled out a new version addressing comments from the
> meeting on Monday, and we feel it’s ready to move this along.
>
> This starts a Call for Adoption for draft-huston-kskroll-sentinel
>
>
I support
> the draft uses Vnew Vold Vleg and nonV without description.
> that makes it hard for me as I still do not fully understand the idea ...
Well it is defined/described in section 3 but I agree that a high level
explanation in the terminology section would not hurt.
Manu
tjw ietf:
The draft is available here:
https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/
the draft uses Vnew Vold Vleg and nonV without description.
that makes it hard for me as I still do not fully understand the idea ...
Andreas
I support adoption, will review.
Petr Špaček @ CZ.NIC
On 16.11.2017 09:23, tjw ietf wrote:
> All
>
> The author has rolled out a new version addressing comments from the
> meeting on Monday, and we feel it’s ready to move this along.
>
> This starts a Call for Adoption for
On Thu, 16 Nov 2017, tjw ietf wrote:
The author has rolled out a new version addressing comments from the meeting on
Monday, and we feel it’s ready to move this along.
This starts a Call for Adoption for draft-huston-kskroll-sentinel
The draft is available here:
I support adoption and am willing to contribute and review.
> On Nov 16, 2017, at 16:23, tjw ietf wrote:
>
> All
>
> The author has rolled out a new version addressing comments from the meeting
> on Monday, and we feel it’s ready to move this along.
>
> This starts a Call
I support adoption of this work. Its a sensible, simple proposal which
has immediate benefit, and can be used by anyone to test the ability
of their nominated resolver to recognise specific keys, and their
trust state.
I believe as a community, at large, we need code deployed into the
resolvers
All
The author has rolled out a new version addressing comments from the
meeting on Monday, and we feel it’s ready to move this along.
This starts a Call for Adoption for draft-huston-kskroll-sentinel
The draft is available here:
https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/
22 matches
Mail list logo