Re: [Uta] Adam Roach's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

["Chris Newman" <[e-mail]>]

On 23 Oct 2017, at 21:13, Keith Moore wrote:

>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Balloting "Yes" because I think this is a very welcome and important 
>> update to
>> its antecedent documents -- but I think there are a few simple 
>> changes needed
>> before it's ready to go.
>>
>> Most importantly; section 3.2 contains the following text:
>>
>>     Clients MUST
>>     implement the certificate validation mechanism described in 
>> [RFC3501]
>>     and SHOULD implement the certificate validation mechanism 
>> described
>>     in [RFC7817].
>>
>> I'm not sure this is kosher. The relevant portion of RFC3501 has been 
>> removed
>> by RFC7817 and replaced by the procedures from RFC7817. My 
>> understanding is
>> saying that you MUST implement RFC3501 for validation implies that 
>> you MUST
>> implement RFC7817 for validation, since RFC3501 has been formally 
>> updated.
>> Putting them at different normative levels in this document doesn't 
>> make sense.
>
> I think Chris wrote this text, so perhaps he will comment.  I'm 
> guessing that 7817 was new enough at the time the text was written 
> that making it a MUST requirement seemed a bit much to ask.  "MUST 
> 7817" is probably more reasonable by now.

That was written when the document was an Internet draft. I'm fine with 
MUST 7817 now.

		- Chris

>> Section 4.3 says what the "value included in this additional clause 
>> SHOULD be"
>> but doesn't indicate that the clause itself SHOULD be included. I 
>> assume this
>> is an oversight?
>>
>> Sections 4.5 and 4.5.1 use the word "recommended" in a non-normative 
>> fashion
>> (correctly, I believe). For avoidance of doubt, I recommend replacing 
>> the
>> RFC2119 boilerplate with the newer RFC8174 boilerplate.
> agree, this will be fixed in -10
>> Section 4.5.3 normatively specifies the use of DNSSEC, which makes 
>> some or all
>> of RFCs 4033-4035 normative references, I believe.
> I already added a reference to 4033 in -10 and will consider adding 
> the others.
>> Section 4.5.4 normatively specifies the use of TLSA, which makes 
>> RFC6698 a
>> normative reference, I believe.
> good catch; thanks.
>
> Keith