Dear HOMENET and DNSOP WG(s), Wearing the INT AD hat.
Firstly, thank you to the DNSOP WG for the deep review, thoughts, and considered responses to my request for review. Secondly, my apologies for not sharing my throughs before the HOMENET session. It would have been impractical to do so as this is a very (VERY) fluid situation with IETF leadership also engaged in discussions. This is simply an iteration of my description of the current situation as delivered yesterday. Do be aware that conversations are continuing and you should NOT take this as a declarative statement. During the HOMENET WG session I specified that for this topic I am comfortable answering _ clarifying _ questions. The same applies here. My answers may or may not change due to the fluid nature of the concern and I hope you appreciate that. My summary of the situation is this. 1) .homenet _COULD_ be added to the special use domain registry based on RFC6761 2) The expected future operation of HOMENET resolution for DNSSEC validating stub resolvers requires a break in the DNSSEC chain of trust. 3) To achieve "2", the document _additionally_ asks IANA to insert an insecure delegation into the root zone 4) The ask for "3" is not covered in IETF policy terms, in fact it tries to put an entry into someone else's registry (the root zone), and will require a set of collaborative discussions with the ICANN community and a new process that handles this situation. There are no expectations that this process will be defined in a reasonable time for the uses of HOMENET. Options, possibly not an exhaustive list A) seek a .homenet special use domain with the request for an insecure delegation in the root zone. (This is what the document asks for NOW, and here we are) B) seek a .homenet special use domain WITHOUT the delegation request AND ask the IETF/IESG/IAB to commence the discussion with the ICANN community to achieve an insecure delegation c) seek a <SOMETHING>.arpa insecure special use delegation d) go for "B" and if that doesn't work shift to "C" Each of these have different positive and negatives in a raw technical sense, UI design desires, and policy and political frames. Again, this situation is fluid and as discussions evolve I will provide more information when it is appropriate. In the mean-time I would very much like everyone to take a calming breath and understand that I am taking a very pragmatic view of this concern. Cheers, Terry INT AD
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
