On Sun, Sep 30, 2007 at 10:32:39PM -0600, Danny McPherson <danny@xxxxxxx> wrote a message of 51 lines which said: > Section 4's reference to BCP 84, in part, creates a false sense of > useful action on part of the operator, This could be said of all the parts of the I-D which mentions non-DNS issues such as BCP 38. In that respect, I full agree with Stephen Hanna's review (http://www1.ietf.org/mail-archive/web/ietf/current/msg48117.html). > Some more details and recommendations on SOHOish ORNS might be > useful for implementers. Any idea? The current draft mentions "Incoming Interface based selection" and I do not see what to add? > I also agree with Paul Hoffman's comments on some reasons for ORNSs. > There are many reasons why I may want to use a specific resolver > consistently, to include those outlined by Paul/John. Sorry, but their messages are quite off the track. The problem is not wether there is an use case for using a resolver different from the one provided by the current access point. There are, indeed, many reasons for *not* using the default resolver (ISP which violates RFC 4925, section 2.5.2 are a very good example). But ORNS are *not* the proper solution for that use case. TSIG signatures, VPNs, local caching resolvers are the good solutions. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf