Hi Joe, On 31.8.2015 23:44, Joe Abley wrote: > [You might consider using "initiator" rather than "requestor", incidentally; I > think I first saw "initiator" and "responder" in one of Vixie's drafts, and I > like them to describe the actors that engage in a single DNS transaction.]
Well, RFC 2136 is using term "requestor" and here I believe that it is a good idea to use the very same term when clarifying the behavior. > People are (I think) used to seeing CNAMEs in the "forward" namespace. People > are apparently less familiar with them in the "v4 reverse" namespace (or else > you wouldn't have been motivated to write this draft). > > Since the core problem here is that people are not realising that there really > is no "forward" and "reverse" namespace (there's just a single namespace plus > some conventions) it seems slightly odd that this document explicitly > addresses the problem with reference to the IN-ADDR.ARPA domain. The advice > holds true for the whole namespace, so why restrict it? > > I realise the specification in section 4 doesn't specify that it's only for > use under the IN-ADDR.ARPA domain, but that's where the preamble leads you, > and the example given in the first paragraph is still an IPv4 reverse one. I wholeheartedly agree with you in this aspect. The clarification should not be limited to in-addr.arpa at all. I'm just trying to find a balance between the abstract description of the problem and the most prominent example of the problem we see in practice (which might be easier to understand for implementers). Here I'm certainly open to suggestions how to improve this: Do you have any specific changes in mind? I would be happy to update the draft :-) Would it help if we change the abstract from: This document clarifies interaction among Dynamic Updates in the Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation, and Secure Domain Name System (DNS) Dynamic Update in the presence of CNAME/DNAME redirections. to something like this? This document clarifies interaction among Dynamic Updates in the Domain Name System (DNS UPDATE) and Secure Domain Name System (DNS) Dynamic Update in the presence of CNAME/DNAME redirections. Most prominent example of this situation is classless IN-ADDR.ARPA delegation. Eh, I cannot say if the new text is significantly better or not but do not have idea how to improve it even more. Maybe the Introduction could paraphrase the Mark's e-mail from 01 Sep 2015 08:18:37 +1000. What about this text as replacement for whole Introduction? --- Intro --- This document clarifies interaction among Dynamic Updates in the Domain Name System (DNS UPDATE) and Secure Domain Name System (DNS) Dynamic Update in the presence of CNAME/DNAME redirections. It was identified that common implementations using DNS update protocol often ignore existence of CNAME/DNAME redirections and, as a result, fail to update records if redirection is used. DNS UPDATE is a general protocol. The requestor needs to decide if he intends to update the data at the CNAME/DNAME owner or the CNAME/DNAME target. There is no correct thing to do in the general case. For example: If the requestor is using a zone management tool he almost certainly don't want to follow a CNAME if it is present. On the other hand, if the requestor is updating the name associated with a machine, he might be starting with a IP address and wanting to update the PTR record after following the CNAME/DNAME chain (if any). This is a specific case where the requestor knows that he wants to change the target of the CNAME/DNAME chain if it is present. [RFC2317] describes how to use the CNAME records in IN-ADDR.ARPA DNS zones to split administrative control over IN-ADDR.ARPA data for classless networks. This is the most prominent example of situation where DNS update requests need special handling described in this document. Applicability: This clarification is applicable to parties wanting to update records in IN-ADDR.ARPA and other zones without changing existing CNAME/DNAME redirections. This clarification is not applicable to cases where the purpose of the DNS update is to change CNAME/DNAME redirection. Any suggestions are more than welcome! Thank you for your time. Petr Spacek > In answer to the actual question you asked, I support adoption, and I'll > support adoption again when the chairs actually ask for it, at which point I > can review again if anybody wants me to :-) > > > Joe > > On 27 Aug 2015, at 6:39, Petr Spacek wrote: > >> Dear DNSOP Chairs, >> >> I'm requesting a call for adoption of draft-spacek-dnsop-update-clarif. >> >> We did not have time allocated for discussing this in Prague but the draft is >> so short and easy (to quote Mark's words: "blatantly obvious") that I do not >> feel that postponing this till Yokohama is necessary. >> >> Thank you. >> Petr Spacek >> >> >> A new version of I-D, draft-spacek-dnsop-update-clarif-01.txt >> has been successfully submitted by Petr Spacek and posted to the >> IETF repository. >> >> Name: draft-spacek-dnsop-update-clarif >> Revision: 01 >> Title: Clarifications to the Dynamic Updates in the Domain Name >> System (DNS >> UPDATE) specification >> Document date: 2015-08-27 >> Group: Individual Submission >> Pages: 5 >> URL: >> https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-01.txt >> Status: >> https://datatracker.ietf.org/doc/draft-spacek-dnsop-update-clarif/ >> Htmlized: >> https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-spacek-dnsop-update-clarif-01 >> >> Abstract: >> This document clarifies interaction among Dynamic Updates in the >> Domain Name System (DNS UPDATE), Classless IN-ADDR.ARPA delegation, >> and Secure Domain Name System (DNS) Dynamic Update in the presence of >> CNAME/DNAME redirections. -- Petr Spacek @ Red Hat _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
