Russ Housley writes: In section 3.1, the definition of "unicast routable address" uses the term "site-local scope." I thought we deprecated this concept. Also, can we simply delete section 4.6? ------------------------- Jari Arkko responds to Russ Housley: > In section 3.1, the definition of "unicast routable address" > uses the term "site-local scope." I thought we deprecated this concept. > Also, can we simply delete section 4.6? Good question. I've been wondering about this. We made the decisions about site locals in MIP specifications before the SL deprecation took place. In fact, we were one of the folks who suffered from the SL issue when we at first tried to specify exactly how and when you can use SLs with mobility. It always turned out that we run into various problems, so we finally settled on the SHOULD NOT that appears in 4.6 but still left the theoretical possibility that folks who want to go against a SHOULD NOT could do so, given that its not a MUST NOT and the definition of the unicast routable address. I'm open to either just removing SLs alltogether from the ura definition and killing 4.6, or keeping the current approach. There's no major difference given the SHOULD NOT but killing SLs from this document would make things a bit more clear. However, I'm not quite sure how to proceed given that the SL discussion seems to be still continuing on the IPv6 and IETF lists. As far as I understand, the consensus in the meeting was to kill site-locals alltogether, but having looked at a few of the messages on those lists lately, I'm no longer 100% this is the case on the official list. Anyone know? In any case, I'm open to doing this either way and probably the WG as well, please advise us on how to proceed. ------------------------- Russ Housley responds to Jari Arkko: > In any case, I'm open to doing this either way and probably the WG as well, > please advise us on how to proceed. I am sure that you know that there is a thread on the IPv6 mail list trying to confirm working group consensus. I hope that site-local will die. We will see... ------------------------- Basavaraj Patil writes: Based on the consensus for site-local in the IPv6 WG I think the site-local aspects in the base spec should be deleted. ----------------------- Pekka Savola responds to Basavaraj Patil: Note: the consensus is yet to be seen (and might lead to follow-ups, etc). We should avoid a lot of text on site-locals, but ripping it out completely might be premature: assuming things go well, we might end up revising the spec in a year or two anyway. But either way is ok with me. ----------------------- Charlie Perkins writes: I also agree that site-locals should be deleted from the base specification, if it is procedurally reasonable to do so. We did, after all, already complete working group Last Call for the recent document. Would such a change be major enough to require another working group last call? If yet another Last Call is required, then I would be more comfortable with the base specification as is. We really have to try avoid the requirement to hit every moving target in sight. I think that operationally there is almost no danger that someone reading the specification as it is would do the "wrong thing" on site-locals. ----------------------- Ed Remmell responds to Charlie Perkins: IMHO, support for site locals has already been effectively removed, see: http://www.piuha.net./~jarkko/publications/mipv6/issues/issue258.txt It is in there currently as a HA requirement: site-local traffic "SHOULD NOT be tunneled to the mobile node" also as a MN requirement: "Therefore, site-local addresses SHOULD NOT be used as home or care-of addresses." The main change implemented in issue report #258 was to permanently close the door on requiring any support in the HA for site-local tunneling - there used to be a MUST in the spec that the HA MUST be configurable to enable support for site-local tunneling, but this was removed from the spec. So, just going through the spec and deleting all existing references to site-local support does not change the intent of the current spec, IMHO there is no need for another last call if these modifications are made. ----------------------- Thomas Narten writes: From a process perspective, it is too early to say they are deprecated. For this document, I'd minimize the text related to SLs (which is where we've already been moving towards), but not try to remove mention entirely, if that becomes awkward. We can't really do that until the IPv6 WG formally deprecates SLs via Last Called documents, etc. Let's hope we have that option in the future! ----------------------- Jari Arkko responds to Thomas Narten: Right. My recommendation is then that we keep the current text, given that * It tries to be minimal. And the SHOULD NOT gives the kind of warning side the reader needs, if he is not aware of the danger otherwise... * The current text is equipped to handle either outcome at IPv6, should the worst thing happen... ----------------------- ----------------------- ----------------------- ----------------------- -----------------------