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
_______________________________________________
Hipsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/hipsec
