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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
