On Mon, Apr 25, 2016 at 4:50 PM, Tim Wicinski <tjw.i...@gmail.com> wrote:
> This starts a Working Group Last Call for draft-ietf-dnsop-isp-ip6rdns > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ > > Please review the draft and offer relevant comments. Also, if someone > feels the document is *not* ready for publication, please speak out with > your reasons. > > There was a large amount of feedback on the draft prior to it being > adopted, and we feel the author addressed all the outstanding issues. > Please let us know if this is not the case. > > This starts a two week Working Group Last Call process, and ends on > 9 May 2016. > > The last sentence in section 2.3, at the top of page 5: "There is no standard way to indicate to a host what server it should send dDNS updates to." I thought it was standard for the client to do an SOA query to find the master server for the zone. (Or see https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-00.txt ) And that method is spelled out in the second paragraph of section 2.3.1. That also seems to conflict with the last sentence of section 2.3.2 "Host behavior is unchanged; the host sends the same dynamic updates, either to the ISP's server (as provided by the gateway), or to the gateway for it to forward." Why would a host send an update to its resolver, instead of the host listed in the SOA record? Section 3 similarly says: "Dynamic DNS updates can provide accurate data, but there is no standard way to indicate to residential devices where to send updates, if the hosts support it, and if it scales." -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop