Re: about draft-bagnulo-multi6dt-hba-00.txt

 In your previous mail you wrote:

   >    we are planning to implement HBA, so this would be really helpful.
   >    I will contact you later.
   >
   > => I had some free time in this long weekend so I wrote the code
   
   great!
   are you planning to make it public?
   
=> yes but I don't know how (i.e., where).

   > now I have some new comments:
   >  - draft-ietf-send-cga-06.txt is not clear enough about where the 
   > extension
   >    fields are included in the hash (here the multi-prefix extension) :
   
   Well, as i read it, the new extensions should be included both in the 
   cga generation and verification, only that since at this point there 
   are no extension specified, the algorithm presented in the spec doesn't 
   explicitely include them.
   
=> so the text (in draft-ietf-send-cga-06.txt) should be clarified to
explicitely include them...

   >    So in draft-bagnulo-multi6dt-hba-00.txt the extension is in Hash2
   >    (good decision) but not in Hash1 (does it matter?):
   
   well, this is my mistake, thanks for catching it
   The multiprefix extension should be included both in the generation and 
   the verification of HAsh1
   i will fix this in the next version
   
=> well.

   AFAIU, the multiprefix extension should be included both in the 
   generation and verification of Hash1 and Hash2
   
=> this is only a problem in specifications (all everywhere should
say the same thing, here that all extensions are included).
   
   >  - the second point is about the Ext Type (TBD IANA): we have to 
   > propose
   >    a common value in order to get interoperability (and examples :-).
   >
   
   Ok, would you propose a value that you like? ( i mean what did you use 
   in your implementation? :-)
   
=> I use 0x12 but it can be easily changed (I have only to fix the define
and to recompute the example in the test).

   >  - the last point is about the collision count: I believe it should be
   >    per HBA not global as described:
   
   I can see that there is an advantage in making the collision count per 
   HBA as you suggest, since in the case that DAD fails, then you only 
   need to regenerate a single HBA and not the whole set.

=> yes, this is the issue... and with a common collision count I have
to add a new function to compute explicitely the addresses (today it
is done by an optional side-effect per HBA). This doesn't really matter
but the point needs (needed) to be clarified.

Thanks

[email protected]