Re: [DNSOP] [v6ops] Fwd: New Version Notification for draft-v6ops-xie-network-happyeyeballs-00.txt

[Davey Song <[e-mail]>]

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