Reviewer: Qin Wu
Review result: Has Nits
I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written with the intent of improving the operational aspects of the IETF
drafts. Comments that are not addressed in last call may be included in AD
reviews during the IESG review. Document editors and WG chairs should treat
these comments just like any other last call comments.
This document specifies procedures for representing and verifying the
application services identity in TLS interaction with PKI X.509 certificates.
I believe this document is well written and ready for publication.
Major issue:
No
Minor issues:
1.Section 1.2 Applicability
s/ cetrificate/certificate
2. Delegated domain definition
“ For example, a server at mail.example.net could be a delegated domain for
connecting to an IMAP server hosting an email address of u...@example.net. ” I
can not parse this sentence, is the server a delegated domain? Which domain is
the source domain? Which domain is delegated domain ? please make this clear in
the example. 3.Section 2 Identifying Application Service What is meaning
difference between _direct_ and direct or _indirect_ and indirect? In section
2, sometimes _direct_/_indirect_ is used, sometimes direct/indirect is used.
4.Section 2 said:
“ We can categorize the three identifier types as follows:
* A DNS-ID is direct and unrestricted.
* An IP-ID is direct and unrestricted.
* An SRV-ID is typically indirect but can be direct, and is
restricted.
* A URI-ID is direct and restricted.
”
Three identifier types or four identifier types? My impression is the latter.
5.Section 2
s/possibile/possible
6.Section 3 said:
“In this case, applications need
to be aware that the textual representation of an IPv4 address can
appear to be a valid DNS name, though it is not. ”
it in the text ‘though it is not’ is referred to digit representation of an
IPv4 address? Or not?
7.Section 7.1
I am surprised there is no protection measures to mitigate risk of vouching for
rogue or buggy hosts in this document?
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
