Re: [6man] #1: Proper source for an Interface Identifier

#1: Proper source for an Interface Identifier Changes (by fg...@si6networks.com): * status: new = closed * resolution: = fixed Comment: The Interface Identifier has now been replaced with a generic Net_Iface parameter, and we describe what are the required properties for this ID.

Re: [6man] #4: Normative section / Informational section

#4: Normative section / Informational section Changes (by fg...@si6networks.com): * status: new = closed * resolution: = fixed Comment: My response to this post is available at: http://www.ietf.org/mail- archive/web/ietf/current/msg78813.html That said, as noted in another ticket,

Re: [6man] #2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers)

#2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers) Changes (by fg...@si6networks.com): * status: new = closed * resolution: = fixed Comment: The introduction of this document has been augmented to make the problem statement for evident.

Re: [6man] #3: Need for DAD counter

#3: Need for DAD counter Comment (by fg...@si6networks.com): Actually, it makes the algorithm simpler. By including DAD_counter, it's trivial to generate another Interface-ID with the same algorithm. Whereas if we were to select a random interface ID upon a DAD failure, the code would

Re: [6man] #3: Need for DAD counter

#3: Need for DAD counter Changes (by fg...@si6networks.com): * status: new = closed * resolution: = wontfix -- -+- Reporter: otr...@employees.org | Owner: draft-ietf-6man- Type: defect

[6man] #3: Need for DAD counter

#3: Need for DAD counter Your draft attempts to make the fallback predictable, by incorporating a DAD counter in the seeds of your nominal algorithm. But that means redefining the solution a only a guarantee that the visiting host will have one of the same 2 or 3 addresses on the visited

[6man] #4: Normative section / Informational section

#4: Normative section / Informational section After reading the document again, the main issue is that the document specifies a solution to a problem by detailing a specific implementation, but does not explain the design choices behind that solution. As such, we end up with an over

[6man] #1: Proper source for an Interface Identifier

#1: Proper source for an Interface Identifier Version -06 of the document includes the interface index in the expression F() that generate the stable privacy IIDs. It has been noted that interface indexes might not be stable, and that, in any case, mandating a specific source for tan

[6man] #2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers)

#2: Description of issues with traditional SLAAC addresses (embedding IEEE identifiers) Some folks have noted that this I-D should clarify what are the issues with traditional SLAAC addresses (addresses that embed link-layer addresses). This is deemed as key to clarify which of them are