[Hipsec] clarification on HIT Suite IDs

[Tom Henderson <[e-mail]>]

In the course of performing recent draft revisions, I had some 
additional questions about the HIT Suite IDs.

http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-19#section-5.2.10

Briefly, RFC 7343 specifies that ORCHIDs consist of the special prefix, 
a 4-bit Orchid Generation Algorithm (OGA), and a 96-bit hash.  RFC 7343 
does not ask IANA to set up a registry for OGA values.  The RFC states 
"... the value of the OGA identifier according to the
    document defining the context usage identified by the Context ID." 
My read of this is that the assignment of OGA identifiers is delegated 
to the documents defining the context usage identified by the Context 
ID; in this case, it would be RFC5201-bis.

The HIT Suite ID in RFC5201-bis is used as the OGA ID in HIP.  The IANA 
considerations section states this, although someone looking explicitly 
for assigned OGA values may have to dig for it.

The reason that the HIT Suite ID is not named the 'OGA ID' in HIP is due 
to the potential growth capability that is defined in section 5.2.10. 
Specifically, the zero value for HIT Suite ID is reserved, to allow for 
growth of the field should the four-bit field be exhausted.  So it 
technically is an 8-bit value, and the 4 higher-order bits are used to 
form the OGA (for now).

Basically, the draft is saying that if HIT Suite ID is zero, then this 
ORCHID encoding:

  ORCHID     :=  Prefix | OGA ID | Encode_96( Hash )

becomes instead:

  ORCHID     :=  Prefix | HIT Suite ID | Encode_92( Hash )

and the bits immediately after the Prefix are used also to identify the 
length of this OGA ID.  It seems to me that this could either be 
clarified further in the draft, or simplified.

For clarification, it might be a good idea to add some text that says 
more explicitly that the OGA ID is formed by taking the four high-order 
bits of the ID found in the HIT_SUITE_LIST, and by making the table read 
something like:


         HIT Suite           4-bit truncated value      8-bit ID
         RESERVED                0                            0
         RSA,DSA/SHA-256         1    (REQUIRED)          65536
         ECDSA/SHA-384           2    (RECOMMENDED)      131072
         ECDSA_LOW/SHA-1         3    (RECOMMENDED)      262144

However, I wonder whether the better choice would be to simplify the 
current encodings and make it a right-aligned field, keep the value 0 as 
reserved, and leave future growth to future updates.  The same kind of 
growth could be accommodated if the (future) extended OGA ID were 
encoded with the nibbles swapped.

Thoughts?

- Tom