On 6/26/2014 10:26 AM, Jim Fenton wrote: >> The existing base specification is being submitted as an Independent >> Submission to become an Informational RFC. > > I'm not sure if this belongs in the charter, but in any case I wonder if > it creates market confusion to pursue both an Informational Independent > Submission and a Standards-track working group RFC. Are there other > examples of where that has been done? As a counter-example, note that > the publication of DomainKeys (RFC 4870) was delayed until DKIM > published to avoid confusion, and there the names were somewhat different.
Well, it's not the most common tidbit to put into a charter. However a charter needs to establish context. In this case, the context includes a related, contemporaneous activity. Hence the intent is to help the reader avoid confusion, by knowing about both the independent and wg activities. A common model for bringing existing work into the IETF is exactly what this draft describes: publish the existing spec as independent, informational; do a wg standards-targeted follow-on. An obvious example is DKIM and Domainkeys, though yes, the example skips the intermediate, 'private' version of DKIM. One of the first IETF imports was NFS and it followed this template. I'm sure there have been plenty of others over the years. >> The base specification relies on the ability of an email receiver to >> determine the organizational domain responsible for sending mail. An >> organizational domain is the basic domain name obtained through a public >> registry, such as example.com or example.co.uk. While the common >> practice is to use a "public suffix" list to determine organizational >> domain, it is widely recognized that this solution will not scale, and >> that the current list often is inaccurate. The task of defining a >> standard mechanism for identifying organizational domain is out of scope >> for this working group. However the working group can consider extending >> the base DMARC specification to accommodate such a standard, should it >> be developed during the life of this working group. > > I don't see how this can be considered out of scope without a viable > alternative. The identification of the Administrative Domain is a > normative requirement in DMARC, and if this problem is not solved, the > specification will be stuck. Having tried and failed to solve this > problem several years ago, I am convinced that this is a very difficult > problem. I'd like to agree with you. I certainly /do/ agree with your assessment of the issue being a normative requirement for DMARC. The problem is that the issue is larger than DMARC. It absolutely requires a single, global solution and therefore needs to solicit and obtain a different range of participation and community consensus about how to deal with the requirement. >> Phase II: >> >> Specification of DMARC improvements to support better >> interoperability >> >> Review and refinement of the DMARC specification > > Does this include the publication of a standards-track specification? I was told the ADs wanted to see phases and so thought it best for an initial draft to put the phases into the most general terms. A finer-grained approach to milestones will might note targeting document status. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
