In message <6.2.5.6.2.20130828044224.06ee3980@xxxxxxxxxxxx>, S Moonesamy writes : > Hello, > > It's difficult, some might say impossible, to get agreement on > draft-ietf-spfbis-4408bis. I would like to ask each of you, and > anyone else, to provide your opinion about the following: > > RFC 5507 primarily raises three concerns about TXT records: > > 1. The data in TXT is unstructured and subject to > misinterpretation by other > applications. > > 2. Wildcard issues. > > 3. Size issues. > > The draft addresses (3) by discussing size considerations, and > tangentially addresses (1) in Section 3.4. > > I would like to ask everyone not to turn this into a debate by not > discussing about the opinion stated by someone else. > > Regards, > S. Moonesamy (as document shepherd) I would start by saying that the list of issues identified by RFC 5507 is not complete. RFC 5507 addresses selection of data to be returned by the nameserver. It fails to address the issues of updating data in the server using RFC 2136 + RFC 2845. For prefix, suffix and a new types this is pretty straight forward as you have a <name,type,class> tuple that is unique to the application and nameservers have access control mechanisms that are designed to allow / disallow updates at this level so you can hand out the ability to update records without having unintended consequences. When you place selectors inside records which have a shared purpose you lose the ability to hand out selective update without risking unintended consequences or you require nameserver vendors to develop new access control mechanisms which work on the record contents in addition to the <name,type,class> tuple. You can't say delete all records of this type at this name then add this replacement set in a single transaction. It becomes read the data at the tuple, workout what to delete, send a update message that selectively deletes then adds records. This introduces race conditions etc. As for wildards. Spf is often used to say that names generated by wildcards do not send email. This essentially precludes the use of a prefix. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx