An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
Note: This ballot was opened for revision 07 and is now closed.
(Jari Arkko) Yes
(Ross Callon) No Objection
(Brian Carpenter) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) No Objection
(Sam Hartman) No Objection
Comment (2006-09-12 for -** No value found for 'p.get_dochistory.rev' **)
I do not like the dependence on sha-1 without an upgrade path. Why can't the hash function be an input along with the bit string and context ID? Each context would be required to choose a hash function.
(Russ Housley) No Objection
Comment (2006-09-14 for -** No value found for 'p.get_dochistory.rev' **)
I would rather not be locked to SHA-1. Can the following work? Input := any bitstring Hash_Input := Context_ID | Hash_Alg_ID | Input Hash_Value := Hash( Hash_Input ) ORCHID := Prefix | Encode_n( Hash_Value ) Where, Hash is the function identified by Hash_Alg_ID, and SHA-1 MUST be supported, and other hash functions MAY also be supported.
(David Kessens) No Objection
(Dan Romascanu) No Objection
(Mark Townsley) No Objection
Magnus Westerlund No Objection
(Ted Hardie) (was Discuss) Abstain
(Cullen Jennings) (was No Objection, Discuss) No Record
It seems like 100 bits is far more than is needed for an experiment. If there is some analysis on this is the right size, I am glad to clear. I did not understand the explanation I got about why a 100 was needed but it does not seem that allocating a /28 causes harm in this case so I have cleared on the basis it causes no harm.