> > If we standardize a technology, we are saying that technology solves > > some problem. and that its usage has well understood and accepted > > consequences. > > It has to be acceptable to *the people who are involved*. People who > are doing things contrary to contracts that they have signed, TOSes, > AUPs, employment agreements, etc, should not have standing and > should not be able to change the rough consensus of the IETF. I think you have it backwards. Contracts, TOSes, AUPs, etc. can and do change frequently, as conditions change. IETF's job is to help the Internet adapt to changing needs and conditions. IETF should not make it more difficult for the Internet to adapt to changing conditions by standardizing protocols that only work in a narrow set of conditions - even when those conditions are reflected in some providers' current contracts or policies. In many cases contracts, TOSes, etc. act against the legitimate needs of end users - forcing users to give up valuable functionality and giving them a crippled Internet. IETF should design protocols in such a way as to maximize benefit for all parties, not to favor some network operators' perceived interests over those of users. In particular, just because some network operators impose constraints on particular kinds of usage does not mean that IETF should standardize a protocol that encourages those kinds of constraints. Nor should network operators be compelled by IETF to impose Procustean policy constraints on all of their users simply because an IETF standard was not flexible enough to accommodate diversity of needs. Contracts, TOSes, etc. often inhibit the growth of new applications. IETF protocols should not standardize protocols that deny valuable new functionality to the public without careful consideration of the tradeoff between functionality lost and functionality gained. In general, IETF protocols should promote the continued ability for the Internet to support new applications that can benefit the public. -- One problem that most of these DNS-based blacklists have in common is that they're too inflexible. A domain might represent anywhere between zero and a billion or so email addresses. Such a large set of users can be extremely diverse. It's not reasonable for IETF to standardize a protocol that specifies policy for user of email addresses on a per-domain basis only because that doesn't accommodate a diversity of users' legitimate needs. Even if some large domains don't mind imposing such a policy on all of their users at the present time, that doesn't mean it's a good idea for IETF to impose that lack of flexibility on all domains. Nor should IETF compel domains to accept a choice between either restricting the way in which all of their users send mail (even though they have legitimate reasons to do otherwise) or having the domains' reputations suffer for failure to specify an inflexible domain-wide policy. Many of the DNS-based schemes seem to suffer from a dubious assumption - that because DNS exists and is widely deployed and it's easy to add information in TXT records, that a useful policy specification and filtering mechanism can be implemented quickly. This is dubious for two reasons: one is that per-domain policy is often too inflexible, and DNS and its infrastructure were not designed to specify things on a per-user basis. The second is that it ignores the work required to define the behavior of other components in such a way that they'll work reliably at distinguishing illigitimate mail from legitimate mail, and to deploy those components. Trying to make DNS do too much doesn't save you time - it costs you time. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf