> 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.
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.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
