> i think this document is just silly. and highly subjective. there is > no way to edit it to correct its problems -- it should just quietly > die. IAB should preserve its relevance and integrity by limiting its > focus to objective technical matters (such as the excellent work on > wildcards back when COM and NET each had wildcards), rather than fluff > like this. I think the intent of the document is timely and appropriate, though I think it needs another rev before publication. Mostly it could be condensed to: "automata should not make any assumptions about the meaning of a domain name" ...but then nobody would read it because it would get lost in the boilerplate. Still, maybe they should add this in a final section, and put it in the vertical center of the page with 4 inches of white space above and below, just on the off chance that people will get it. other comments: section 1, bottom of page 3: the comment about SRV records seems misleading and possibly specious. there's an important difference between a client making an assumption about the meaning of a domain name, and the owner of a domain name encoding some information about that domain name. yes, SRV records can be misleading in that they can get out of sync with reality, but it's entirely reasonable for a client to believe the SRV record and then fail when the SRV record turns out to be wrong. what's not reasonable is for a client to second-guess a SRV record. if the protocol says to use a SRV record, the client should follow the protocol even if the SRV record is wrong. if the protocol doesn't say to use the SRV record, the client should never consult it. in all cases the right thing to do is to follow the specification for that protocol. (similarly for MX records - if a MX record is malformed or points to a nonexistent domain, it is NOT appropriate for the sender to assume something else and e.g. talk to the SMTP server at that A or AAAA record. the appropriate thing to do is to bounce the message) easiest fix is to not mention SRV records. the document is cleaner if it only talks about how the DNS names (as opposed to the RRs) are used. section 2: the model shown here is such a limited case that it may do more harm than good to use it. far too many analyses make the assumption that apps are two-party (e.g. client-server). many more problems crop up in many-party (distributed) apps or p2p apps. for instance, if there are conflicts between the way that hosts in a many-party app interpret dns names or dns records, those apps will experience failures which would not be observed in a two-party app. (anytime someone uses an analysis like this it should raise a red flag. something important is almost certainly being missed) section 3: the analysis is incomplete due to limiting assumptions in section 2, and is missing cases relevant to many-party apps. section 3.3: the server can also make unreasonable assumptions about the client's domain name, or about the domain name associated with the client's source IP address. section 4: other possible consequences: degraded security (weak encryption algorithm assumed by client or server due to domain name) possibly leading to compromised data and further security breaches (e.g. leaked passwords), degraded performance (inappropriate assumptions about available bandwidth or QoS made by looking at domain name). section 5: there is often a need for hosts to keep their domains when migrating from one network (or network interface) to another. this has two implications: one is that it's unreasonable to expect a host to have a domain name which reflects the kind of network to which it is attached; another is that it's unreasonable to trust that a domain name that appears to claim a particular capability. section 5.3 is fine regarding sub-delegation, but the point about the lack of centralized control is broader than just sub-delegation. in particular the people who control domain names and the people who control hosts are usually different, which makes it difficult to keep hosts and domains in sync. (it's hard enough just to make name-to-address lookups work). the more demand we create for hosts and DNS to be in sync, the harder it is to get apps to interoperate. section 6. make the point clearer - the behavior of the protocol engine should not change based on the dns name of a host. follow the protocol spec. (in addition, protocol specs should not expect hosts to be named in a particular way. however, protocol specs may require additional DNS records to be created in order for the protocol to operate properly, and such specifications may define meanings of those DNS names - provided those DNS records are only intended to be used for that protocol and are ancillary to the DNS names used to name hosts) the third point is misleading (as applied to SRV) and needs to be reworded. again, follow the protocol spec. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf