On 2017-12-18 21:52, Viktor Dukhovni wrote: > > >> On Dec 18, 2017, at 11:42 AM, Leif Johansson <[email protected]> wrote: >> >> Certainly we can do changes to the document but the IETF consensus >> process depends on multiple people making their voices heard - this >> is the rough part of "rough consensus and running code". Sometimes >> under-specified is actually good enough. >> >> As somebody who implements specifications I totally sympathize with >> your desire to have a specification that is as specific as possible... >> >> However as chair, the later in the process we get the more I'm going >> to insist on putting "pen to paper" in order to progress the document. > > I am sympathetic to your perspective, and indeed an effective chair is > one who moves ready documents along, fending off spurious late changes.
Great. I suggest we spend the time reading and reviewing specific text instead of spending additional time re-iterating "bugreports". Putting some words together is arguably less work than you're spending arguing that they are necessary :-) > > However, in this case, I think we have a situation in which despite > appearances the document is not actually ready. There were not enough > eyeballs to make all the bugs shallow. > > * The MIME issues should be resolved, and there should not be any > semantics associated with any optional "filename" for the report. > The requisite metadata should be explicit in the Content-Type > and (in the case of HTTP) Content-Encoding. The Content-Disposition > (where any optional filenames lives) should be entirely optional. > > * The "policy-string" is poorly specified, the below: > > o "policy-string": A string representation of the policy, whether > TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: > TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ > 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D > )"" MTA-STS: ""version: STSv1\nmode: report\nmx: > mx1.example.com\nmx: \ mx2.example.com\nmx: mx.backup- > example.com\nmax_age: 12345678"" > > is not a sound way to specify the format, and JSON has array types, > that obviate the need to "stringify" record-oriented data. As I > already mentioned, the exammple TLSA syntax carries needless extra > syntax that just makes parsing more difficult. Since the TLSA base > domain is potentially subject to CNAME expansion, there needs to > be text that asks the sender to specify the QNAME used to locate > the TLSA RRset. > > I did suggest a better format for the policy string, though not a BNF > grammar, but I think that the final step is easy enough. > > * I provided suggested text for "dane-required". > > * The IP address of the MX host should be included in the report schema. > _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
