An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID)
RFC 4843

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' **)
No email
send info
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' **)
No email
send info
  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

Comment (2006-09-14)
No email
send info
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.