In message <de9077a2-34f4-4153-8f8c-64e8a371c...@hopcount.ca>, "Joe Abley" writ
es:
> Hi Petr,
>
> I have reviewed this draft.
>
> A couple of minor editorial nits aside, I think it does a good job at
> providing a solution to the problem it identifies.
>
> [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.]
>
> 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?
UPDATE is a general protocol. You need to decide if you are updating
the data at the CNAME owner or the CNAME target. There is no correct
thing to do in the general case.
You almost certainly don't want to follow the CNAME in this case.
update add example.net. 3600 CNAME example.com.
For this one you wouldn't want to follow the CNAME.
update delete example.net. CNAME
update add example.net. 3600 NS foo.example.com.
If you are using a zone management tool you almost certainly don't
want to follow a CNAME if it is present.
If you are updating the name associated with a machine you are starting
with a IP address and wanting to update the PTR record after following
the CNAME chain if any. This is a specific case where you know that
you want to change the target of the CNAME chain if it is present.
> 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.
>
> 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 Nam
> e
> > 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.tx
> t
> > 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.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
> > _______________________________________________
> > 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
