Hi Peter, > On 20 Jun 2016, at 15:08 , Peter Koch <[email protected]> wrote: >
<snip> > while the intent is laudable, making it a requirement under 5.1 mixes > the formal part and the informational in a confusing way. That said, > does "should reserve at least part of this allocation for interoperability > with > networks that are only reachable using IPv4" mean "should assign at least part > of this allocation ... to itself"? That mix is for all it's pros and cons, intentional. LIRs 'must' be informed (the must part of that point) about the special condition this block is being allocated in, much in the same way as they 'must' make assignments from the allocation - whether to customers, self or infrastructure. The 'should' part is phrased in such a way that because I didn't want an explicit reference to any other standard or technology in the IPv4 allocation policy. Whether the space is used for IPv6 migration or whatever protocol next century makes no difference, if you want to talk to IPv4 here's the block of space to do that with. > And further along the lines of educational text: the references in section > need > some re-adjustment (this isn't new in 2.0, but for good housekeeping) since > RFC 3330 has been finally obsoleted by RFC 6890 (and may or may not be > applicable > anyway) and RFC 2993 isn't really the final word on NAT any more, especially > with that earlier remark on "for interoperability with networks that are only > reachable using IPv4". > Noted. > The clarification part remains complicated because of indirections: 5.3 > refers to > 5.1 only, but the new "ALLOCATED FINAL" then extends the validity across the > remaining sections. I'd suggest to give up 5.3 and merge the new text with > the > final paragraph of 5.2 accordingly. The IPv4 allocation policy as it stands is not what I'd call a thing of beauty, and if rewritten in its entirety should probably look a lot different. The way I see it, paragraphs 5.2 and 5.3 serve different purposes, and merging them removes that bit of much needed clarity. To be clear - it's not my intention to rewrite the whole policy; just adding some bits and pieces that I felt were needed. If I can clean up a paragraph that I'm editing anyway, so much the better. Thanks for your feedback. Best regards Remco
signature.asc
Description: Message signed with OpenPGP using GPGMail
