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

[S Moonesamy <[e-mail]>]

Hi Julien,

{Ted, sorry for the slow reply]

At 07:24 19-06-2014, Julien Laganier wrote:
>s/the authors/the IETF/ ?

Yes.

>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.

Ok.


> > 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.
>
>Specific suggestions would be welcome w.r.t. to what is excessive, and
>the proposed remedy.

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.

>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.

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

Regards,
S. Moonesamy