Hi Carlos, On 7 Feb 2011, at 6:58, Carlos Pignataro wrote: > > I support this document and think it's important and very well written. > I do have some overall comments and a couple of editorial suggestions:
Thank you. > At a high level, the document is arguing that with no more IANA > unallocated /8s, then existing corresponding filters should be removed, > and then lists special purpose prefixes that should not be router in the > Internet. I think that the document could benefit from making a stricter > classification of "bogons" from the Intro onwards, into "unallocated" > and "martian"; then, "martian filters" do not change, but "unallocated" > do (as continuously do, but now there is a notable milestone). These > unallocated prefix filers now need to be larger than /8, but there is > still value in filtering RIRs unallocated. So there is a choice of > whether no longer filter based on address allocation status at all, or > do it with finer granularity, with pros and cons. I think that the > document should contain the final state (martians only) but list pros > and cons of the transition (filter or not RIR unallocated prefixes). I > do not want to suggest overcomplicating the document, as its simplicity > is a plus, though. I would like to avoid the use of jargon words like "bogons" and "martians" if possible as I expect the total number of people who know and use them is small enough that their inclusion would make it a more difficult read for many. I would appreciate more operator feedback as regards the benefit of using strict filters based on the prefixes allocated by the RIRs. Looking at the latest RIPE NCC enhanced statistics file (http://albatross.ripe.net/delegated-extended/) there are about 250 IPv4 blocks to filter. Not all of these blocks are bit aligned, so the number of prefixes to filter based on the RIPE NCC alone is likely to be higher than that. And there are five RIRs. How many operators are going to be happy maintaining a list of something in the order a thousand prefixes and updating it every day to avoid broken connectivity? > On the more editorial side, I think that perhaps slightly more emphasis > on the fact that this is filtering on the "source" (even on the title) > can prevent potential confusions. Thanks. I will add this. > Similarly, a note of caution as to the > application of filters (as some of the blocks can "appear", but not be > Internet-routed. If I understand you correctly, you'd like to see extra language clarifying that these filters should only be applied at borders and not internally. Right? Many thanks, Leo _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
