I think thats pretty well completely fair Terry. I think you capture the qualities well.
But if you put DNSSEC back in the equation, add sufficient value to the assertive-trust side of what would be said inside it, and the follows-the-delegation-chain aspect, I think it has potential to have more value. But only potential. Its very very latent. -G On Tue, Nov 4, 2014 at 12:32 AM, Terry Manderson <terry.mander...@icann.org> wrote: > Hi George, and all. > > I've just caught up on this thread, and it strikes me that there is (it > seems) an operational gap with the omission of the problem statement. > > > On 3/11/2014 2:36 pm, "George Michaelson" <g...@algebras.org> wrote: > > [snip] > > > > >We don't have any failure to delegate the parent blocks facing down: Its > >people's willingness to invest energy on the various different approaches > >to the sub-delegation engines inside your own block management, be it > >embedded in the NMS or some kind of > > customer facing provisioning web portal or whatever. > > Problem 1: Operator unwillingness to invest energy to the sub-delegation > engines > > [snip] > > > > >Personally, and it is only my personal view, I like some of the older > >ideas for semi-machine generated and wildcarded reverse I saw presented > >at the RIPE ROME meeting. And I see some value in sign-on-the-fly work. > > > Problem 2: uniform generation of PTR (with the presumption that they are > useful in some form) > > > > > > >I think rDNS remains potential for big value. I can't verbalize it well, > >but it has qualities about trust which for me could be useful. Its > >volountarist nature is a huge counter argument as you've all exposed > >here: can't depend on it. coverage is low. > > > Problem 3: The non-specific non-commital approach (or lack thereof) to > coverage by operators. > > Problem 4: The inability to document 'big value' or trust qualities in > reverse DNS. > > I see the use of reverse DNS as various forms of blacklisting/whitelisting > or similarly adjudicating the reputation of a TCP connection (SMTP or > otherwise) an interesting approach to remove a level of pain (where pain > levels are individually variable). I don't necessarily believe this > evolution has legs, but I don't believe they are very long. > > Suffice to say that I've used that as a pain fix in past, but now question > its scale going forward for IPv6. I don't mind the concept of stable > services addresses having stable and well formed reverse. However in a > customer realm, see Problem 1 closely followed by problem 3. > > As to utility? I've stopped looking at reverse DNS, as a quality, and as > an information source. Really, if I want to get a sense of who and where I > tend to look toward whois/rdap and a sh ip bgp <blah> and look to the ASN. > > So as a sales job trying to sell reverse DNS IPv6 to the masses, and that > isn't the IETF's job IMHO, we won't be living well on the commission. > > As to the IETF's job of documenting the problem, and then a possible > solution for the operational aspects - I think that worth putting cycles > toward, however I don't see that it will be at all easy. If this thread is > any indication. > > Cheers > Terry > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
