Just a very quick note to say thank you for the OpsDir review; it's much appreciated.
W On Fri, Dec 16 2022 at 6:09 AM, Qin Wu <nore...@ietf.org> wrote: > 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? > > _______________________________________________ > OPS-DIR mailing list > ops-...@ietf.org > https://www.ietf.org/mailman/listinfo/ops-dir >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
