Hi S.M., Pls. see below.
On Mon, Jun 23, 2014 at 10:32 AM, S Moonesamy <[email protected]> wrote: > <snip> > > >> > 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. 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." [...] >> 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. Will update saying the prefix was returned in 2014. _______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
