Hi Davey. Thanks for your support. About the identification for resolvers, it's out of scope for this draft, but nothing prevents the use of RRSERIAL and NSID in the resolvers. Last paragraph of RFC5001 section 2.2 says so, and in version -01 of this draft there'll be a relaxation by declaring the use of rrserial in resolvers as undefined, thanks to Shane's comments.
Of course the exact behavior needs to be defined more carefully, but RRSERIAL would be a first step on that path. Hugo On 12:13 03/06, Davey Song wrote: > Hi Hugo, > > I like this draft. And I will continue to review and comment when you have > new versions. > > Generally, it is helpful to figures out who answer my queries in the > troubleshooting process. So the draft is helpful if out-of-sync occurs > between authoritative servers, such as Hidden Masters, primary server, and > secondary servers. > > Some thoughts out of the scope of this draft： I think the out-of-sync > issue is more serious which occurs between the broken cache resolver and > the authoritative servers when the cache resolver violates the TTL. Maybe > my queries are hijacked to that broken server. IMHO, there is a piece > missing to help troubleshooting which cache resolver answered my query and > which version of the zone the cached response is associated with. > > The NSID option is proposed for authoritative sever. Maybe we can propose > an NSID for cache resolver？ Any suggestions? > > Best regards, > Davey > > > On Tue, 1 Jun 2021 at 00:15, Hugo Salgado <hsalg...@nic.cl> wrote: > > > Dear group. > > Thanks for the call for adoption. We the authors are already working > > on -01 with the comments made a few weeks ago. I hope to send it in > > the next days for your review/approval. > > > > Hugo > > > > On 10:26 28/05, Tim Wicinski wrote: > > > All > > > > > > We had a lot of good discussion of this draft when it first came out, and > > > the chairs want to put up a call for adoption. > > > > > > If you have already stated adoption of this draft, we will count those so > > > there is no need to repeat yourself. > > > > > > > > > This starts a Call for Adoption for draft-salgado-dnsop-rrserial > > > > > > The draft is available here: > > > https://datatracker.ietf.org/doc/draft-salgado-dnsop-rrserial/ > > > > > > Please review this draft to see if you think it is suitable for adoption > > by > > > DNSOP, and send comments to the list, clearly stating your view. > > > > > > Please also indicate if you are willing to contribute text, review, etc. > > > > > > This call for adoption ends: 22 June 2021 > > > > > > Thanks, > > > tim wicinski > > > DNSOP co-chair > > > > > _______________________________________________ > > > DNSOP mailing list > > > DNSOP@ietf.org > > > https://www.ietf.org/mailman/listinfo/dnsop > > > > _______________________________________________ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
signature.asc
Description: PGP signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
