On 19-Jul-16 18:10, Ted Lemon wrote:
> Please read draft-lemon-sutldr-ps, and participate in the discussion
> about this on the dnsop mailing list. Discussions about the RFC6761
> problem are off-topic for the homenet mailing list. We are customers
> of the existing IETF consensus process as documented in RFC 6761. We
> get into enough ratholes on the homenet mailing list; please don't get
> us into this rathole as well.
I have done my reading. Not only of your draft, the discussion in DNSOP
and the other drafts. Do not know why you presumed i hadn't. Why, I
have even read RFC6761, several times.
I am also happy to avoid rat holes, but as far as I understand the case,
you did not follow the requirements of RFC6761 and thus this unassigned
usage does not have the imprimatur even of RFC6761, for whatever that
ends up being worth. It was a decision made by this WG for this group's
reasons. And it was missed in the review cycle. Unfortunately I find I
only ended up working on this issue on 23 October, just as IET was
ending its last call. Though I might have missed it as well.
I would also like to point out that the studies done for ICANN are by no
means the end of the story and do not represent a consensus decision of
ICANN at this point. While there may be a 'restraining order' from the
ICANN Board on assigning the names at this point, that is not a
permanent consensus decision and is a situation that people in ICANN are
still actively working on. To allocate a name that is under discussion
and contention and had been applied for in 2012, at this point seems to
me to constitute an infringement of the policy prerogative given to
ICANN by RFC2860. And while the recent 2015 study may have recommended
that ICANN ask IETF to reserve then name, an incredibly bad idea when
ICANN has its own policy development methods for reserving names, the
ICANN Board has not to my knowledge made any such formal request.
While IETF can certainly assign a name as a protocol parameter according
to RFC6761 ( despite any dispute that may or may not exist on the
validity of that process ) that does not mean they have the ability to
chose any name they wish, only that they may assign a name. I would
recommend in the spirit of RFC2860 that you chose a name that is not the
point of a disagreement and that had not been applied for in 2012. I
assume there is no technical reason why .home and only .home must be
used for protocol reasons alone. As a protocol parameter, I would
assume any relationship between a string and dictionary word was just an
unhappy coincidence, and one to avoid.
If you want to hardcode a name into your protocol, I suggest you pick a
neologism like .homenet or even .hmnt it you want something short and
pithy, and avoid the rat hole that is .home.
cheers,
avri
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
