Hosjieh, Of three problems that the draft aims to solve, 1st (EUI64 addresses) does not really seem to be much of a problem as everyone does privacy addresses today (you saw stats yourself at ipv6-hackers meeting), the second (not changing the address) is an implementation choice, so the third one remains as an open problem, sort of.
Now: what's the comparison between the amount of nonvolatile storage taken by code implementing the algorithm vs code to store IIDs ? I.e. I am still unclear what's the real-world problem this solves. If it is a particular implementation corner case, maybe makes sense to keep it as such, not updating the core specs. --a P.s. I agree with what Fernando wrote as well. On 08 Aug 2013, at 23:27, "Hosnieh Rafiee" <i...@rozanak.com> wrote: > Hello and thank you so much for your comments. > > I applied your comments and submitted a new version of the ra-privacy draft. > I also removed the text concerning the application layer based lifetime from > this draft. This draft, thus, just focuses on a few updates to RFC 4941 that > address some deficiencies. > > tools.ietf.org/html/draft-rafiee-6man-ra-privacy > > According to my discussions with some people during the IETF meetings, some > people thought that it would be better to have the discussion about the > application layer based lifetime in a separate document as it seems that it > is a new mechanism and should not be an update to RFC 4941. In my update to > that RFC , I just briefly mentioned that the node "MIGHT" follow the other > external policies for the lifetime and “Might” not follow those of RFC 4941. > > > If there are any other issues that I should consider for this draft, please > let me know. > > Thanks, > Best, > Hosnieh
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
