Subject: Re: [Hipsec] Last Call: <draft-ietf-hip-rfc4843-bis-05.txt> (An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers Version 2 (ORCHIDv2)) to Proposed Standard

From: S Moonesamy <[email-masked]>
Date: Sat, 07 Jun 2014 08:22:47 -0700

At 09:04 28-05-2014, The IESG wrote:
>The IESG has received a request from the Host Identity Protocol WG (hip)
>to consider the following document:
>- 'An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers
>    Version 2 (ORCHIDv2)'
>   <draft-ietf-hip-rfc4843-bis-05.txt> as Proposed Standard
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action. Please send substantive comments to the
>[email-masked] mailing lists by 2014-06-11. Exceptionally, comments may be

I took a quick look at the draft.

In Section 1.1:

   "While being technically possible to use ORCHIDs between consenting
    hosts without any co-ordination with the IETF and the IANA, the
    authors would consider such practice potentially dangerous."

The document is intended as an IETF RFC.  I suggest framing the about 
from an IETF perspective instead of the authors' perspective.

   "A specific danger would be realised if the IETF community later
    decided to use the ORCHID prefix for some different purpose.  In
    that case, hosts using the ORCHID prefix would be, for practical
    purposes, unable to use the prefix for the other new purpose."

My reading of the above is that the working group is trying to make a 
case for some free IPv6 addresses.  According to the sixth paragraph 
in that section ORCHIDs are about allowing people to experiment.  The 
question that arises is why is an intended Proposed Standard being 
used to describe an experiment.  I don't understand the "danger" 
argument.  Is the ORCHID request for an experiment or for a prefix to 
be set aside for people using the technology?

In Section 3:

   "Router software MUST NOT include any special handling code for
    ORCHIDs.  In other words, the non-routability property of ORCHIDs, if
    implemented, MUST be implemented via configuration and NOT by
    hardwired software code.  At this time, it is RECOMMENDED that the
    default router configuration not handle ORCHIDs in any special way.
    In other words, there is no need to touch existing or new routers due
    to ORCHIDs.  If such a reason should later appear, for example, due
    to a faulty implementation leaking ORCHIDs to the IP layer, the
    prefix can be and should be blocked by a simple configuration rule."

There is, in my opinion, excessive usage of RFC 2119 key words in the 
above.  I suggest using RFC 2119 key words for the main points.

The IANA Considerations in Section 6 could do with a few 
changes.  Please see RFC 6890 for the information requirements for 
having a reservation in the IPv6 Special-Purpose Address Registry.

The termination date for the ORCHID assignment is March 2014.  It may 
be easier to note the fact that the experiment has ended instead of 
saying that the prefix is to be returned to IANA in 2014.

Regards,
S. Moonesamy

---

From: Julien Laganier <[email-masked]>
Date: Thu, 19 Jun 2014 07:24:29 -0700

On Sat, Jun 7, 2014 at 8:22 AM, S Moonesamy <[email-masked]> wrote:
> The document is intended as an IETF RFC.  I suggest framing the about from
> an IETF perspective instead of the authors' perspective.

s/the authors/the IETF/ ?

> My reading of the above is that the working group is trying to make a case
> for some free IPv6 addresses.  According to the sixth paragraph in that
> section ORCHIDs are about allowing people to experiment.  The question that
> arises is why is an intended Proposed Standard being used to describe an
> experiment.  I don't understand the "danger" argument.  Is the ORCHID
> request for an experiment or for a prefix to be set aside for people using
> the technology?

HIP _was_ an experiment supported by ORCHIDs. The experiment has
concluded and HIP is going to proposed standard, requiring a propose
standard ORCHID, so the sixth paragraph can be adapted accordingly:

OLD:

ORCHIDs are
   designed to address this situation: to allow people to experiment
   with protocol stack extensions, such as secure overlay routing, HIP,
   or Mobile IP privacy extensions, without requiring them to update
   their applications.  The goal is to facilitate large-scale
   experiments with minimum user effort.

NEW:

ORCHIDs are
   designed to address this situation: to allow people to implement
   protocol stack extensions, such as secure overlay routing, HIP,
   or Mobile IP privacy extensions, without requiring them to update
   their applications.  The goal is to facilitate large-scale
   deployments with minimum user effort.

> There is, in my opinion, excessive usage of RFC 2119 key words in the above.
> I suggest using RFC 2119 key words for the main points.

Specific suggestions would be welcome w.r.t. to what is excessive, and
the proposed remedy.

> The IANA Considerations in Section 6 could do with a few changes.  Please
> see RFC 6890 for the information requirements for having a reservation in
> the IPv6 Special-Purpose Address Registry.

IANA considerations will be clarified based on the forthcoming IANA review.

> The termination date for the ORCHID assignment is March 2014.  It may be
> easier to note the fact that the experiment has ended instead of saying that
> the prefix is to be returned to IANA in 2014.

This provides useful information on the need for an allocation for
the time being, and I believe can be edited as you suggest as an
editorial change during AUTH48 once the draft has been approved by
IESG.

--julien

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jun 2014 11:43:13 -0400

> editorial change during AUTH48 once the draft has been approved by

SM, are you satisfied with Julien's response?

Julien, I'd prefer that you update the draft--it would be highly unusual to address IETF last call comments during AUTH48.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 23 Jun 2014 09:18:57 -0700

Ted, the specific comment here is w.r.t. a statement in the IANA
considerations that reads "The prefix that was temporarily allocated
for the experimental ORCHID is to be returned to IANA in 2014
[RFC4843]."

Do we really need an update of the draft for the sake of "s/is to be/was/"?

--julien

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jun 2014 13:12:45 -0400

> Do we really need an update of the draft for the sake of "s/is to be/was/"?

Well, see Barry's DISCUSS... :)

The other way to address comments like this is in an RFC Editor note, but if you update the draft, then you don't have to worry about the information accidentally being lost.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Jun 2014 13:44:59 -0400

On Jun 23, 2014, at 1:40 PM, S Moonesamy <[email-masked]> wrote:
> I would not consider my comments about the RFC 2119 key words as addressed (re. Section 6 of RFC 2119).  I commented about that a few minutes ago.

Fair enough.   Do you think the text as written will create interoperability problems?

---

From: Julien Laganier <[email-masked]>
Date: Mon, 23 Jun 2014 10:45:33 -0700

Hi S.M.,

Pls. see below.

On Mon, Jun 23, 2014 at 10:32 AM, S Moonesamy <[email-masked]> wrote:
>  <snip>
>> > above.
> The second RFC 2119 requirement restates the requirement in the first
> sentence.  There is then a RFC 2119 recommendation.  I am short of time or
> else I would have verified some RFCs to see how this was previously tackled.
> I suggest having a requirement (if you want to have one) which states that
> there must be a configuration knob and define a default setting.  You could
> keep the rest of the text as an explanation to the reader.

How about this:

"Router software MUST NOT include any special handling code for
ORCHIDs.  In other words, the non-routability property of ORCHIDs, if
implemented, is to be implemented via configuration rather than by
hardwired software code.  At this time, it is RECOMMENDED that the
default router configuration not handle ORCHIDs in any special way.
In other words, there is no need to touch existing or new routers due
to ORCHIDs.  If such a reason should later appear, for example, due
to a faulty implementation leaking ORCHIDs to the IP layer, the
prefix can be and should be blocked by a simple configuration rule such as,
e.g., an Access Control List entry."

[...]

> That's an unusual usage of AUTH48.  I'll defer to the Responsible Area
> Director.

Will update saying the prefix was returned in 2014.

---

From: Julien Laganier <[email-masked]>
Date: Mon, 23 Jun 2014 12:54:03 -0700

On Mon, Jun 23, 2014 at 11:41 AM, S Moonesamy <[email-masked]> wrote:
>
> At 10:45 23-06-2014, Julien Laganier wrote:
>>
>> How about this:
>>
> The first two sentences look fine.  I suggest trying to look at the
> "recommendation" part as something after the document is published.  I am
> not thinking clearly enough to suggest text. :-(  I would avoid the "should"
> in the last sentence.

How about this then:

"Router software MUST NOT include any special handling code for
 ORCHIDs.  In other words, the non-routability property of ORCHIDs, if
 implemented, is to be implemented via configuration rather than by
 hardwired software code, e.g., the ORCHID prefix can be blocked by
 a simple configuration rule such as an Access Control List entry."

Please let me know if this is Ok so that I can publish an update
carrying agreed upon changes.

--julien

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Jun 2014 10:32:49 -0700

Hi Julien,

{Ted, sorry for the slow reply]

>s/the authors/the IETF/ ?

Yes.

>    deployments with minimum user effort.

Ok.

The second RFC 2119 requirement restates the requirement in the first 
sentence.  There is then a RFC 2119 recommendation.  I am short of 
time or else I would have verified some RFCs to see how this was 
previously tackled.  I suggest having a requirement (if you want to 
have one) which states that there must be a configuration knob and 
define a default setting.  You could keep the rest of the text as an 
explanation to the reader.

>IANA considerations will be clarified based on the forthcoming IANA review.

Ok.

>editorial change during AUTH48 once the draft has been approved by

That's an unusual usage of AUTH48.  I'll defer to the Responsible 
Area Director.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Jun 2014 10:40:27 -0700

Hi Ted,

Thanks for following up on this.

>SM, are you satisfied with Julien's response?

I would not consider my comments about the RFC 2119 key words as 
addressed (re. Section 6 of RFC 2119).  I commented about that a few 
minutes ago.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Jun 2014 11:41:40 -0700

Hi Ted,
>interoperability problems?

I would say avoid that type of phrasing as it may lead to problems.

The first two sentences look fine.  I suggest trying to look at the 
"recommendation" part as something after the document is 
published.  I am not thinking clearly enough to suggest text. :-(  I 
would avoid the "should" in the last sentence.

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 23 Jun 2014 13:06:16 -0700

Hu Julien,
>  a simple configuration rule such as an Access Control List entry."

The above looks fine.

Regards,
S. Moonesamy