On Sun, Sep 30, 2007 at 10:32:39PM -0600,
Danny McPherson <danny(_at_)tcb(_dot_)net> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf