Hi Jinmei, Thanks for your comments. I once had same questions in my mind when this draft is conceived. I reply inline.
Some quick observations: > > - I don't see why the intended status is Standards Track. It seems to > be a document about an operational practice rather than a new > protocol feature. > I agree with your observation here if the draft intends to share information and practice. It now goes with Standards Track because the authors would like to provide a new HE feature(or a framework) on network side as a peering funtion of client-side HE. I would like to see more feadback on this issues. - In general, I wouldn't be excited about placing such complicated > functionality in the network rather than end hosts. Sometimes it > may be justified as a least evil option, but the current description > of the draft didn't fully convince me > Before I put down this draft, I talked with some CPs (content/app providers) and ISPs, they have motivations and requirement on this. One example is Tencent, they are planning to deploy a complicated measurement network to info their Apps (with a SDK ) which address family they should try first (their apps use dns over http). I'm told that Tencent think HE implemented on each client is too complicated (they have comlicated apps) and resource consuming. ISP's motivation is easy to understood, they always try to improve their network connenctivity on both IPv4 and IPv6. I have no more comment on your saying of evil option：） Any technology can be used as evil purpose I think. - I suspect the discussion on breaking DNSSEC is way too hand-waving. > In my general understanding it's generally not accepted at dnsop to > justify breaking DNSSEC just by saying "it's okay as validation at > end hosts is not typical". Especially if it really intends to be > published as Standards Track I suspect some more detailed discussion > with a stronger justification will be needed. > Sorry, I admit current txt on breaking DNSSEC is weak. Now it is put into Security Considerations as well as the issues on incoherency. I think one way to avoid it as suggested in Security Considerations is to artificially delay the AAAA answers, other than omitting the AAAA record and its RRSIG Best regards, Davey
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
