Hi, On 18 Jul 2016, at 23:51, Ted Lemon <[email protected]<mailto:[email protected]>> wrote:
I think it's should in the sense that there may be done reason not to do it on some case and we don't want to preclude that because there is no protocol reason to do so, but we expect that it will be allocated unless there is some good reason. We talked about this at length a couple of years ago and captured the intent in the architecture doc, but maybe not in enough detail? The problem with making statements in RFC7368 was doing so while keeping consensus; the more detail you add, the harder it is to keep consensus. There was consensus on “should”, and some rationale was given. Of course since then we’ve found that omitting detail (like more specifics on the routing protocol, in particular) did come back to bite us later in that we really only deferred the decision. Also, RFC7368 does not use RFC2119 language. Tim On Jul 18, 2016 23:28, "Juliusz Chroboczek" <[email protected]<mailto:[email protected]>> wrote: > Why wouldn't you allocate one? I would. ULAs are a goodness. Probably. I'm planning to add ULA generation to shncpd at some future date, and perhaps even enable it by default. The question is about the level of MUSTiness. I only see two reasonable possibilities: 1. ULA is SHOULD, and we cannot rely on their existence; 2. ULA is MUST, which puts an additional requirement on implementations, but allows us to rely on their existence except during reconvergence. No compromise between these two positions is possible. It is not reasonable to say that ULA is SHOULD while simultaneously relying on their existence, which is what we're apparently trying to do. -- Juliusz _______________________________________________ homenet mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
