Early Review of draft-ietf-dnsop-structured-dns-error-03
review-ietf-dnsop-structured-dns-error-03-secdir-early-salowey-2023-06-30-00

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

This document is well written and useful. The document does have a good
security considerations section but I think it could be improved.

1. I think it would be good to provide more context for the recommendations in
the security considerations section (and for the processing rules in section
5.3).  For example, the information in if untrusted information in the c, j and
o fields are presented to an end user they may be used to misdirect the user to
contact a malicious party to resolve their problem which could result in
further compromise to the user's security (this could be worded better and
there may be better examples).  I think this may help readers to understand the
implications of not following the recommendations.

2. I find the SHOULD NOT make text clickable difficult.  I don't think that the
text should be clickable in general, but the contact field is essentially a
series of link so the temptation is going to be to make it clickable.  I think
the document should describe better under what conditions the link can be
clickable.  Also its probably worth saying that the fields are rendered as text
and not HTML.

3. Since links involved could be customized to the individual case privacy
considerations may be needed. Following the contact links could possibly reveal
information to another party.

4. A little bit of a nit- In section 5.3 it says if the C and J fields are
missing then discard the whole message, yet later there are cases where you
MUST ignore the C and J fields and yet can still handle the S field.  This
seems a little contradictory to me,  however I think technically its not a
problem and would be implementable as it is.