> ... If we fail to provide good ways, consenting adults might (and > usually do) come up with worse ways. is that how you characterize NAT, firewalls, and application layer gateways? utk-mail11 may have seemed to you like a way to extend the internet, but to the greybeards of the time who had crapped upon bitnet and uucp, decnet mail11 (for example, DECWRL.ENET.DEC.COM) was an abuse of the MX RR, not a "good way" to use the technology. firewalls and NAT, by making it harder to carry real packets from one endpoint to another, were seen as heresy. do you think that these are "worse ways" that wouldn't've come about had the IETF provided "good ways"? if so can i hear an example of a better way that wouldn't be seen as a total departure from "the internet way of doing things", just to help me frame your position? > It's not that consenting adults shouldn't be able to solve their own > problems, it's that some kinds of solutions can and do cause harm for the > Internet, particularly when they're widely deployed. i can see how a *.COM wildcard, or any TLD wildcard, fits that description. i can't see how DNSSEC DLV, or ULA-C, fits that description. at the moment, they are all condemned using the same buzzwords. i'm asking that the ones without objectively verifiable immediate harm not be crapped on. > p.s. And FWIW, in the message where I said 'It's hard for me to buy the idea > of there not being a "core" portion of the Internet from which all public > addresses are reachable' what I meant was that I have a hard time imagining > the conditions which would make it happen, not that I would try to stop it > from happening. I'd be hard pressed to support it given my current > understanding of it (not that either my support or opposition is worth very > much). But I'd be curious to explore the idea further and see where it > might lead. that's a useful clarification. but it changes nothing. if other people, who are not you, and who are consenting adults, want to interoperate using prefixes under the ULA /7 prefixes but having, unlike RFC 4193 ULA prefixes, globally visible whois and in-addr support, then it's not your place to tell them they shouldn't want that or shouldn't have that. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf