Subject: [Hipsec] clarification on HIT Suite IDs

From: Tom Henderson <[email-masked]>
Date: Mon, 22 Sep 2014 13:27:42 -0700

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

---

From: Tom Henderson <[email-masked]>
Date: Mon, 22 Sep 2014 22:34:32 -0700

On 09/22/2014 02:28 PM, Francis Dupont wrote:

> => no, it doesn't say that: the current wording is:
>
>     The ID field in the HIT_SUITE_LIST is defined as eight-bit field as
>     opposed to the four-bit HIT Suite ID and OGA field in the ORCHID.
>     This difference is a measure to accommodate larger HIT Suite IDs if
>     the 16 available values prove insufficient.  In that case, one of the
>     16 values, zero, will be used to indicate that four additional bits
>     of the ORCHID will be used to encode the HIT Suite ID.  Hence, the
>     current four-bit HIT Suite-IDs only use the four higher order bits in
>     the ID field.  Future documents may define the use of the four lower-
>     order bits in the ID field.

Perhaps we can agree that it is ambiguous; elsewhere it also states:

       For the time being, the HIT Suite uses only four bits because
       these bits have to be carried in the HIT.  Using more bits for the
       HIT Suite ID reduces the cryptographic strength of the HIT.

which implied to me that the HIT suite ID may in the future consume more 
bits presently allocated to hash.

>
> So there is nothing very clear about what will happen if one will need
> more than 15 HIT Suite-IDs... BTW according to appendix E I should add
> "at the same time" (appendix E proposes to reuse values, making unlikely
> to really need more than 15 values).

I'm not sure where you are proposing to add the clause; can you point 
out the sentence?

> => it is trade-off between defining OGAs from HIT Suite-IDs vs.
> defining HIT Suite-IDs from OGAs. The second was chosen...
>
> => no, the current choice makes more sense with the HIT Suite-IDs
> from OGAs. But it is a matter of taste for sure...
>

Perhaps we could start by trying to resolve whether the plan should be 
to reuse four-bit values if the space is eventually exceeded, or whether 
the HIT suite ID may grow in the future (and how that affects the 
ORCHID).  Maybe we do not need to specify the plan in this draft; maybe 
we could just avoid the problem for now and just keep value 0 reserved 
and state that what to do when the HIT_SUITE_ID space is exhausted is 
for further study, with deprecated value reuse and expansion of the HIT 
Suite ID being two possibilities.

Another basic question I have is whether the table 11 in Appendix E 
should be merged with the unlabeled table at the end of 5.2.10 (and 
located in 5.2.10), and whether Appendix E text in general ought to be 
brought forward in the draft to section 3.2 and/or 5.2.10.

- Tom

---

From: Julien Laganier <[email-masked]>
Date: Tue, 23 Sep 2014 07:49:51 -0700

Hi Tom,

Please see inline.

> bits presently allocated to hash.

The statement about using more bits of the ORCHID to encode a HIT
suite ID seems to be factually incorrect, or at least it isn't
supported by the ORCHIDv2 generation scheme as published in RFC 7343.

Since this document (5201-bis) doesn't seem to be the right place to
specify (future) ORCHID generation (a revision of ORCHIDv2 would), I'd
like to suggest that plans for future enhancements be removed from the
paragraph, and to only keep text necessary to ensure future
enhancements are not prevented. For this, reserving the value zero
seems to be enough. (and Appendix E already has a discussion of OGA ID
reuse for the purpose of ID space exhaustion).

Accordingly, the paragraph would read:

     the 16 available values prove insufficient.  Hence, the

(and that is beyond this discussion, but given that adding more suite
IDs presumably addresses a need for _increased_ security, it is
counter intuitive to already decide to achieve that by _reducing_ the
size of the encoded hash output, but I digress)

<snip>

> Perhaps we could start by trying to resolve whether the plan should be to
> reuse four-bit values if the space is eventually exceeded, or whether the
> HIT suite ID may grow in the future (and how that affects the ORCHID).
> Maybe we do not need to specify the plan in this draft; maybe we could just
> avoid the problem for now and just keep value 0 reserved and state that what
> to do when the HIT_SUITE_ID space is exhausted is for further study, with
> deprecated value reuse and expansion of the HIT Suite ID being two
> possibilities.

IMHO it is premature to plan for the ID space exhaustion while it has
not happened and we do not have an understanding of what will cause
the ID space to be exhausted (if it ever does.) E.g., if none of the
hash functions chosen in HIP suites provided enough security in 96
bits truncated output, will there be a new hash function that will? So
the discussion on contingency plan seems moot at this point in time.

Thus it seems keeping zero reserved is good enough for now.

> Another basic question I have is whether the table 11 in Appendix E should
> be merged with the unlabeled table at the end of 5.2.10 (and located in
> 5.2.10), and whether Appendix E text in general ought to be brought forward
> in the draft to section 3.2 and/or 5.2.10.

I think that makes sense since it is normative.

--julien

---

From: Tom Henderson <[email-masked]>
Date: Tue, 23 Sep 2014 10:39:59 -0700

Hi Julien,

I agree generally with your recommendations but I have a modified 
proposal (below):

On 09/23/2014 07:49 AM, Julien Laganier wrote:

<snip>
>       order bits in the ID field.

What I think is still lacking in the draft is a clear distinction 
between the OGA ID and the HIT Suite ID, and perhaps some clearer 
wording that the ID field in the HIT_SUITE_LIST is not yet another 
parameter needing a registry.

HIT Suite IDs are a combination of hash function, HMAC, and signature 
algorithm(s).  Francis stated that they are an extension of (or derived 
from) the OGA ID.  The HIT_SUITE_LIST IDs are specific eight-bit 
encodings of the HIT Suite ID values.

Accordingly, would you agree to a modification to your proposal, as follows?

      The ID field in the HIT_SUITE_LIST is an eight-bit field that
      encodes a HIT Suite ID value in its higher-order four bits,
      leaving the lower-order four bits reserved.  The encoding is
      a measure to allow for possibly larger HIT Suite IDs in the
      future, although such expansion is outside the scope of this
      document.  The lower-order four bits of the ID field are set
      to zero by the sender and ignored by the receiver.

      The HIT Suite IDs are an expansion of the OGA IDs that denote
      which hash function corresponds to a given HIT.  The OGA ID
      encodes, in four bits, the value of the HIT Suite ID that
      corresponds to the hash function (and other algorithms) in use.
      A registry for the OGA ID is not separately established since
      the values are aligned with those of the HIT Suite ID.

      The four-bit OGA ID field only permits 15 HIT Suite IDs
      (the HIT Suite ID with value 0 is reserved) to be used at
      the same time.  If 15 Suite IDs prove to be insufficient,
      future documents will specify how additional values can
      be accommodated.

And if acceptable, make other editorial alignments to these statements...

- Tom

---

From: Julien Laganier <[email-masked]>
Date: Tue, 23 Sep 2014 12:37:27 -0700

Hi Tom,

Please see inline.

On Tue, Sep 23, 2014 at 10:39 AM, Tom Henderson <[email-masked]> wrote:
> Hi Julien,
>
> I agree generally with your recommendations but I have a modified proposal
> (below):
>
> What I think is still lacking in the draft is a clear distinction between
> the OGA ID and the HIT Suite ID, and perhaps some clearer wording that the
> ID field in the HIT_SUITE_LIST is not yet another parameter needing a
> registry.
>
> from) the OGA ID.  The HIT_SUITE_LIST IDs are specific eight-bit encodings
> of the HIT Suite ID values.

I may be lacking the background behind tying the OGA ID to the HIT
suite ID, but IMHO it makes little sense to tie an identifier for a
combination of hash, HMAC, and signature (the HIT Suite ID), with that
of the identifier for a hash function (the OGA ID), especially when
the ID space for the latter is of such a small size.

It implies that if we wanted to create a new HIT suite that just
changes the signature algorithm, because the hash function in use is
still perfectly good, we in effect burn one OGA ID in the small
15-number space for no extra hash agility w.r.t ORCHID. To me it seems
like a bad thing to do.

Why can't the HIP specification  creates a HIP registry for its OGA
ID, and allocate value 1, 2, and 3 to the OGA SHA256, SHA384 and SHA1
on one hand, and on the other hand define a HIP registry for the HIT
suite, and allocate ID 1, 2 and 3 as follows:

        HIT Suite
        RESERVED                                            0
        RSA,DSA/SHA-256/OGAID1                  1
        ECDSA/SHA-384/OGAID2                      2
        ECDSA_LOW/SHA-1/OGAID3               3

This decouples the burn rate for the HIT suites from that of the OGA
ID (small) space, thus making it possible to define in the future HIT
suite 4 with ECDSA/SHA-512 but still OGAID1....

>      future documents will specify how additional values can

If a receiver ignores the low order four bits of the suite ID field,
if in the future we decide to use the remaining low order four bits,
won't they be required to be used with the reserved value zero for the
4 high order bits?

That would limit the HIP Suite ID to a total of 31 legitimate values
instead of the full 255 available. Shouldn't we rather have a receiver
treat the low order bits not set to zero as an error instead?

--julien

---

From: Tom Henderson <[email-masked]>
Date: Tue, 23 Sep 2014 12:54:43 -0700

Julien, responses inline below.

> suite 4 with ECDSA/SHA-512 but still OGAID1....

IMHO the above is better than what I proposed, if the WG is willing to 
make this kind of a change at this point.

Perhaps we should ask at this point for other WG opinions on whether the 
above decoupling is acceptable?

> treat the low order bits not set to zero as an error instead?

I just suggested that handling based on the traditional way of 
specifying reserved bits (be liberal in what you accept...).  But I 
agree with you that there is a difference here with respect to the 
existing non-reserved values, so thank you for catching this.  I propose 
to amend the above by deleting "and ignored by the receiver".  We could 
go further by explicitly stating a response if the bits are set, or just 
leave it as an implicit "Parameter Problem" case just as if a value 
outside of 1,2 or 3 were received.

- Tom

---

From: Julien Laganier <[email-masked]>
Date: Wed, 24 Sep 2014 21:21:32 -0700

Hi Tom,

Please see inline

> Julien, responses inline below.

<cutting thru a bit>

> IMHO the above is better than what I proposed, if the WG is willing to make
> this kind of a change at this point.
>

Yes we should.

But does silence implies consent? :)

> I just suggested that handling based on the traditional way of specifying
> reserved bits (be liberal in what you accept...).  But I agree with you that
> there is a difference here with respect to the existing non-reserved values,
> so thank you for catching this.  I propose to amend the above by deleting
> "and ignored by the receiver".  We could go further by explicitly stating a
> response if the bits are set, or just leave it as an implicit "Parameter
> Problem" case just as if a value outside of 1,2 or 3 were received.

Having the receiver reply with a "parameter problem" when it receives
a Suite ID value outside of the set of values it understands sounds
good. For now that is 1, 2, and 3, but can be amended in the future.

--julien

---

From: Rene Hummen <[email-masked]>
Date: Thu, 25 Sep 2014 12:24:19 +0000

Hi all,

just wondering if the decision was made for us, as RFC5201-bis was approved yesterday:

===

The IESG has approved the following document:
- 'Host Identity Protocol Version 2 (HIPv2)'
 (draft-ietf-hip-rfc5201-bis-19.txt) as Proposed Standard

This document is the product of the Host Identity Protocol Working Group.

The IESG contact persons are Ted Lemon and Brian Haberman.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/

===

BR
René

On 25 Sep 2014, at 06:21, Julien Laganier <[email-masked]> wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Sep 2014 08:35:06 -0400

> just wondering if the decision was made for us, as RFC5201-bis was approved yesterday:

The kind of deliberation that you are doing post-IESG-approval on a draft really isn't appropriate.   If there is an error in the draft, you should certainly tell me you need to fix it.   But if you are having a policy debate about something that wasn't resolved prior to the end of working group last call and IETF last call, I'm afraid it really belongs in a -bis document.  And that's what this discussion looks like to me.

That said, the reason I approved the document yesterday was because when I went hunting through my email for comments relating to the review of the document, I didn't find any, because this discussion hasn't been referring to the document.   If there is some *appropriate* fix that needs to be made to the document, I can pull it out of the RFC editor queue or we can address it during AUTH48.   But the sort of changes that would be appropriate in that context are quite restricted.   

In order to make substantive changes that represent a new working group consensus, we would have to do a new last call and re-review it in the IESG.   I expect that could be done quite expeditiously if the working group decided it was necessary, but you need to tell me now if that's what you want.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 Sep 2014 13:49:52 +0100

Thanks for your note, Ted.

Group, approving this draft now and starting a new "tris" draft right
away does not really make sense. Shall we give Tom a couple of weeks to
put together a revision of the draft and then go through a new IETF LC
and IESG evaluation?

As Ted said, this new process would be easier since the diff would not
be that large.

Cheers,

Gonzalo

---

From: Rene Hummen <[email-masked]>
Date: Thu, 25 Sep 2014 13:15:23 +0000

Thanks Ted for clarifying.

> As Ted said, this new process would be easier since the diff would not

Should we first agree that we indeed want to separate the HIT suite ID from the OGA ID and that a simple clarification of how a HIT suite ID maps to an OGA ID does not suffice? The latter would probably be a minor edit that could still be fixed without starting a new evaluation round.

---

From: Rene Hummen <[email-masked]>
Date: Thu, 25 Sep 2014 13:27:31 +0000

>> this kind of a change at this point.

Separating the OGA ID from the HIT suite ID certainly has its advantages regarding the small OGA ID space. However, it also has implications on HIPv2 crypto-agility. For example, how should the Initiator select the destination HIT if it receives multiple Responder HITs from DNS but only supports ECDSA?

Plus, end-hosts would have to support multiple hash functions to cater to a situation where the HIP hash function does not match the hash function indicated by the OGA ID (which admittedly only is a minor issue for Internet hosts).

So, I propose to _not_ make any major modifications at this point.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 25 Sep 2014 14:36:03 +0100

Hi,

sure, the idea is to finish the discussions. If the conclusion is that
there is no need to significantly change the draft, then a new IETF LC
will not be needed.

Cheers,

Gonzalo

---

From: Julien Laganier <[email-masked]>
Date: Thu, 25 Sep 2014 07:46:57 -0700

> Separating the OGA ID from the HIT suite ID certainly has its advantages regarding the small OGA ID space. However, it also has implications on HIPv2 crypto-agility. For example, how should the Ini…

I don't see how this (an initiator having to select a HIT out of a set
of HITs generated with different OGA IDs) would be impacted by
decoupling or not the OGA ID from the HIT suite ID. Irrespective of
the decoupling, an initiator that receives a set of HITs for a
responder has to select one for which it supports the OGA ID.

> Plus, end-hosts would have to support multiple hash functions to cater to a situation where the HIP hash function does not match the hash function indicated by the OGA ID (which admittedly only is…

This isn't a bug, it's a feature - hash agility.

> So, I propose to _not_ make any major modifications at this point.

I am not feeling strongly either way; from my perspective it is fine
to worry about the need for more hash functions when the need arise
which isn't the case now.

(I was just trying to make sense of the seemingly contradictory
decision to tie the burn rates of the small OGA ID space to the larger
HIP suite ID space, where the HIP suite ID space is presumably made
larger to increase future security, at the cost of shrinking the hash
output which to me decreases security.)

Regardless, I think that the text talking about using more bits of the
ORCHIDs to encode a HIP suite ID should be removed as this is not
supported by the ORCHID generation scheme (and would IMHO be a bad
thing to do, but that is beyond the point.)

--julien

---

From: Francis Dupont <[email-masked]>
Date: Mon, 22 Sep 2014 21:28:26 +0000

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

=> HIT/ORCHID stuff is more in section 3 and appendix E.

> a 4-bit Orchid Generation Algorithm (OGA), and a 96-bit hash.

=> yes.

> RFC 7343 does not ask IANA to set up a registry for OGA values.

=> yes and the reason is OGA values are not globally defined: they
are related to a Context ID (HIP in this case).

> The RFC states 

=> exactly.

> for assigned OGA values may have to dig for it.

=> section 3.2 says:

   ... The set of hash function, signature algorithm, and the
   algorithm used for generating the HIT from the HI depends on the HIT
   Suite (see Appendix E) and is indicated by the four bits of the
   ORCHID Generation Algorithm (OGA) field in the ORCHID.

so the OGA table is in the appendix E (note the appendix E itself
was a bit broken in previous RFC 5201 bis versions, but there was
such a table in it).

Regards

Francis Dupont <[email-masked]>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 23 Sep 2014 11:27:46 +0000

>        HIT Suite ID reduces the cryptographic strength of the HIT.

=> yes, there is a long discussion in RFC 7343 about this tradeoff.

> bits presently allocated to hash.

=> the fact the problem could exist doesn't mean it will exist...

> I'm not sure where you are proposing to add the clause; can you point 

=> one will need more than 15 HIT Suite-IDs ->
one will need more than 15 HIT Suite-IDs at the same time

> ORCHID).

=> clearly the current plan is the first (reuse 4 bit values).
The second is just a provision in the case the first fails.

> Maybe we do not need to specify the plan in this draft; maybe 

=> perhaps it was considered as too optimistic? BTW I have no idea
about the future need in new values in the HIT_SUITE_ID / OGA space
(but does somebody already have one?)

> brought forward in the draft to section 3.2 and/or 5.2.10.

=> it is a question for the hipsec mailing list (I subscribed to it
but from my personal e-mail).

Regards

---

From: [email-masked]
Date: Mon, 29 Sep 2014 18:20:23 +0200

Hello,

I'd like to confirm some of your statements. The thought was really to 
show both options a) reuse of OGAs and b) what could happen if we need 
more bits. However, the wording and the current set of IDs was chosen so 
that it discourages the use of more IDs at the same time so the option to 
take more bits from the OGA was really just a last resort. Nothing anybody 
would really want.

See my comments below.

Von:    Francis Dupont <[email-masked]>
An:     Tom Henderson <[email-masked]>, 
Kopie:  HIP <[email-masked]>, Francis Dupont <[email-masked]>, 
[email-masked]
Datum:  26.09.2014 12:39
Betreff:        Re: [Hipsec] clarification on HIT Suite IDs
Gesendet von:   "Hipsec" <[email-masked]>

TH=> This was just to cover all options. It is not a desired or intended 
action.

TH=> Exactly. The intention is to reuse the HIT Suite IDs once they are 
reasonably out of use. Appendix E describes this rollover.

TH=> Yes. I can confirm this.

TH=> I am fine with not specifying the extension of the ID but to leave 0 
as reserved instead.

TH=> Moving the table to 5.2.10 is fine from my perspective. 

Best regards,

Tobias

DISCLAIMER:
Privileged and/or Confidential information may be contained in this
message. If you are not the addressee of this message, you may not
copy, use or deliver this message to anyone. In such event, you
should destroy the message and kindly notify the sender by reply
e-mail. It is understood that opinions or conclusions that do not
relate to the official business of the company are neither given
nor endorsed by the company.
Thank You.

---

From: Tom Henderson <[email-masked]>
Date: Mon, 29 Sep 2014 10:06:48 -0700

On 09/29/2014 09:20 AM, [email-masked] wrote:
> that it discourages the use of more IDs at the same time so the option
> to take more bits from the OGA was really just a last resort. Nothing
> anybody would really want.
>
> See my comments below.
>
>
>
>
> ------------------------------------------------------------------------
>
>
>
> Tom Henderson writes:

There is discussion of this in the IANA considerations section; perhaps 
this could be modified as follows:

Old text:

       If 16 Suite IDs prove insufficient and
       more HIT Suite IDs are needed concurrently, more bits can be used
       for the HIT Suite ID by using one HIT Suite ID (0) to indicate
       that more bits should be used.  The HIT_SUITE_LIST parameter
       already supports 8-bit HIT Suite IDs, should longer IDs be needed.
       Possible extensions of the HIT Suite ID space to accommodate eight
       bits and new HIT Suite IDs are defined through IETF Review.

New text:

       If 15 Suite IDs (the zero value is initially reserved) prove
       to be insufficient and
       more HIT Suite IDs are needed concurrently, more bits can be used
       for the HIT Suite ID by using one HIT Suite ID (0) to indicate
       that more bits should be used.  The HIT_SUITE_LIST parameter
       already supports 8-bit HIT Suite IDs, should longer IDs be needed.
       However, RFC 7343 does not presently support such an extension,
       and the rollover approach described in Appendix E is suggested to
       be tried first.
       Possible extensions of the HIT Suite ID space to accommodate eight
       bits and new HIT Suite IDs are defined through IETF Review.

> reasonably out of use. Appendix E describes this rollover.

So for this proposal by Francis, we would change Appendix E text from:

    Since
    the 4-bit OGA field only permits 15 HIT Suites (the HIT Suite with ID
    0 is reserved) to be used in parallel, phased-out HIT Suites must be
    reused at some point.  In such a case, there will be a rollover of

to:

    Since
    the 4-bit OGA field only permits 15 HIT Suites to be used at the
    same time (the HIT Suite with ID 0 is reserved), phased-out HIT
    Suites must be
    reused at some point.  In such a case, there will be a rollover of

> TH=> I am fine with not specifying the extension of the ID but to leave
> 0 as reserved instead.

Julien suggested that if we consider non-zero bits as an error at the 
receiver, it may facilitate use of the four non-zero high-order bits in 
future extensions.

in 5.2.10, it says:

                     The four
                     lower-order bits are reserved and set to 0 and
                     ignored by the receiver.

The proposal would be to change this to:

                     The four
                     lower-order bits are reserved and set to 0 by
                     the sender.   The reception of an ID with
                     the four lower-order bits not set to 0 should be
                     considered as an error that MAY result in a
                     NOTIFICATION of type UNSUPPORTED_HIT_SUITE.

Any comments/concerns with this potential change?

> TH=> Moving the table to 5.2.10 is fine from my perspective.

I tend to prefer this; I will work up a proposal for this.

- Tom

---

From: Julien Laganier <[email-masked]>
Date: Mon, 29 Sep 2014 10:53:54 -0700

Hi Tom,

FWIW your proposal looks good to me.

--julien

On Mon, Sep 29, 2014 at 10:06 AM, Tom Henderson <[email-masked]> wrote:
> There is discussion of this in the IANA considerations section; perhaps this
> could be modified as follows:
>
> Old text:
>

---

From: Miika Komu <[email-masked]>
Date: Tue, 30 Sep 2014 00:21:38 +0300

Hi,

seems ok to me too.