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 this along.
>
> This st
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
>
> The author has rolled o
> 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
https://www.ietf.org/mailman
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 publication it provided
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 special handling.
Tha
> 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 implementation hiccups b
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
> useful for the
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
useful for the King of the Jungle, you end up with similar tangles.
I don't
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 normal
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 Barne
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 operat
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. Some of
> Ed's observations
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
https://www.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 draft-huston-kskr
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 adoption, and I'm willin
> 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 draft-huston-kskrol
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:
https://datatracker.ietf.org/d
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 for Adoption for dra
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 i
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/
P
23 matches
Mail list logo