In article <[email protected]> you write: >For working group review, I suggest folk consider the draft in terms of >3, basic concerns: > > Clarity: Does the draft adequately explain its purpose and > adequately explain its approach for satisfying that purpose > (separate from its whether it achieves that goal well > enough?) > > Efficacy: Does the draft's approach seem sufficient to it's task? > > Completness: Does the draft have all of the necessary detail and is > all that detail correct?
I think it's pretty good. I'd change all of the SHOULD to MUST, as in you have to do this if you want to interoperate. (You don't have to do it if you have a private agreement, but private agreements are out of the scope of standards.) In section 1 you might want to add a sentence or two pointing out that every rrtype has its own _name namespace, something that took a lot of us quite a while to figure out. In section 3.1 on SRV it says about Proto "any name defined by Assigned Numbers or locally may be used (as for Service)." Urrgh. I'd say that any protocol whose name is in the attrleaf registry is valid. If you want to use SRV records for a different protocol, you have to register its name. The registry is "Protocol Numbers" rather than Assigned numbers, and you might want to add a pointer to it, https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml For URIs, I'd add all of the existing enumservice type names to the draft-ietf-dnsop-attrleaf initial name list in section 3.1, and in this draft add a note that any new enumservice types added MUST be added to this registry if URIs can refer to them. There's currently 24 type names. It happens that none of them collide with other top level names but since they only apply to URI it wouldn't matter if they did. R's, John _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
