e ICANN / IETF divide, so IETF shouldn't wade >> into ICANN territory. > > We don't know what ICANN considers an attempt to "wade into ICANN territory," > and there's nothing the WG can do to resolve this question. Such questions > are why we have liaisons, which the IAB administers for the IETF. > > There's a perfectly healthy liaison relationship between the IETF and ICANN, > which we can ask to exercise when/if we have something specific from the WG > to share. > > Our part is to stop speculating on the views of another independent body, and > decide whether we need .alt from a technical (protocol and operations) point > of view. Legal and liaison resources are available as needed, but none of > those conversations will go anywhere without a concrete technical assessment. > > It would be helpful if we could focus on technical/operational impacts and on > whether .alt would in fact solve the problems that the draft claims to > address.
I believe "solve the problems" is too high a bar for any idea in this problem space. But providing alternatives that reduce the occurrence of the problems is good enough, IMHO. In this context, there will be some use cases .alt won't solve; there will be some where .alt would solve, but the developers end up not using it anyway. But if the intersection, problems that .alt do solve and some developers use it, is expected to be noticeable, then it's ok to move forward, at least in my book. Rubens
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
