Re: MUST is an aspiration

[Fred Baker <[e-mail]>]

On Sep 12, 2019, at 5:19 AM, Mark Smith <[e-mail]> wrote:
> If they don't exist (they don't), then such a MUST in an RFC is an aspiration. It's a theoretical goal, one that in practice has been proven not to be 100% true in similar scenarios where things "MUST" not leak  (RFC 1918 leaks, route leaks, DNS PTR lookup for private addresses etc.)

For the record, I doubt that “MUST” was ever something observed, at least following the publication of RFCs 1122/1123/1812. The first use was in RFC 1122/1123 and 1812, and in those it was something that was true of an algorithm - if <something> wasn’t the case (such as if ARP was sent FROM a broadcast address), something decidedly and demonstrably failed. In subsequent specifications, it was always something those participating in the relevant consensus wanted to be true, and gave them a tool to say to a developer or vendor that they had to MAKE true. Hence the logic behind “SHOULD”; the developer could point out a case where a “MUST” requirement didn’t work, and they were asked to document it. 

Something I have observed about specifications that presumed that they only applied in a defined corner of the Internet (usually in enterprise or residential networks, but in this case is an AS that uses the capability) was that they invariably made it out of the hinterlands onto the backbone. The most obvious cases are private and Martian addresses, but they are not the only ones, by a long shot. Hence, it seems to me that while the requirement is that “the hinterland should not let this out”, the practical requirement is that if you connect in some way with such a hinterland, you should implement defensive measures in case they do. Again, BGP is the obvious example - “you should not advertise ULA or private addresses”, and “you should filter out announcements from your neighbor of private and ULA addresses” - barring an agreement to the contrary.