Petr Spacek <[email protected]> wrote:
Thanks for your thoughts!
> > Note that my 2317bis draft has a slightly different take on UPDATE vs
> > classless reverse DNS. The UPDATE section of my draft is entirely due to
> > Petr's draft, so I'm very grateful to him for pointing out the problem.
> > I'm interested in opinions about
> >
> > - should this be a separate draft or is it sensible to put it in rfc2317bis?
>
> It could be combined with rfc2317bis because there is very tight relation
> between these two. However spacek-update-clarif is more generic and IMHO we
> should extend rfc2317bis to incorporate the generic-ness before dropping
> spacek-update-clarif.
>
> > - is the indirection problem specific to classless reverse DNS (which is
> > the approach I took) or does it apply everywhere (which is what
> > Petr Spacek's draft says)?
>
> Personally I do not see why it should be specific to ARPA sub-tree ...
> Conceptually it is the question if client wants to update RR at the terminal
> node or on the node client can name beforehand ("reverse DNS query name" is
> one example of a name known beforehand).
Right. I was partly reacting to Mark's comments
(http://www.ietf.org/mail-archive/web/dnsop/current/msg15333.html)
and I probably went too far in being specific rather than generic, sort of
deliberately to give us a concrete alternative to think about.
> Thinking about it a bit more ... I can see that RFC2317bis should make
> canonicalization mandatory for reverse sub-trees and all other cases should be
> left to the implementation to decide. Let's see if we can do it in one
> document.
Good idea, yes.
> > - is my detailed suggested UPDATE behaviour sensible?
> > https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis-00#section-9
>
> Most importantly, I believe that limiting the new behavior ("canonicalize
> first") to PTR RR type is a bad idea. We have DHCID, EUI48, EUI64 and people
> are certainly using other RR types in the reverse sub-trees too (TXT comes to
> mind...).
>
> Even if we decide in the end to mandate the new behavior to ARPA sub-tree we
> surely should not limit ourselves to PTR.
Absolutely, very good point.
> I'm proposing to use following text (few nitpicks included):
Thanks, I'll incorporate those suggestions.
I'm trying to think of a good term for PTR-like records, or
non-delegation-non-alias records, because I would like to be
reasonably specific about what this does and doea not apply to.
> Additionally, Security Considerations section does not mention risks
> mentioned in
> https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01#section-6
>
> It would be nice to copy&paste/incorporate the text from there. These risks
> should be explicitly mentioned.
Yes.
> I believe that we can drop draft-spacek-dnsop-update-clarif in favor of
> rfc2317bis if concerns above can be resolved.
Groovy :-)
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/
East Dogger, Fisher, German Bight, Humber: Southerly or southwesterly 4 or 5,
increasing 6 at times. Slight or moderate. Rain or showers, fog patches.
Moderate or good, occasionally very poor.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
