Viktor,
Rather than deal with each of your responses to my comments individually,
I'll just provide some overall responses.
1. My comments on the abstract are not about blame, but about clarity in
writing. It is important to distinguish between standards and what is
deployed,
especially because we can control only the former.
2. I have seen considerable feedback from various sources, including the
GEN-ART
review, that does not suggest that the doc is fine "as-is."
3. I've rarely seen someone suggest that being more precise in terminology
is a bad thing. I think we owe it to readers of RFCs to be a clear as
possible.
Clarity in writing, and concision, yield good docs. You seem to believe that
making a doc more precise makes it verbose. That is not a necessary outcome.
4. The term "collection" is generally defined as passive wiretapping, so
encryption
suffices, irrespective of using other security services.
5. Yes, you are not alone in making an erroneous statement that conflates
PKIX standards and the Web PKI. However, that does not justify perpetuating
such errors in an RFC.
6. The definition of OS appears at the end of Section 3, after all of
the background.
My comments argued that it appear sooner, which is not the same as
saying that it needs
appear in the Intro, contrary to your complaints.
7. I called into question the phrase "reasonably configured peer." Your
reply was
wordy and missed the point of my criticism.
8. You seem to have misunderstood why I found the term "many" to be
confusing; changing it
to "non-negligible number" misses the point. The point is that the text
is clearer is one
discusses a pair of peers trying to communicate. Also, I note that
another person cited the
same problem; it's not just me!
9. The phrase "security settings" is vague, since it means different
things in
different security protocol contexts. You later seem to acknowledge this
when you observe
that TLS and SMTP security settings are different. Saying that OS can be
deployed "organically"
suggests spreading around a lot of manure :-).
10. yes, do drop the term "application" when there is no intent to
restrict solutions to
be app-specific.
11. Your effort to clarify what you mean by "misconfigured" was a
revelation to me.
I did not get any sense of that meaning from the text.
12. Saying that an OS-capable peer may demand more than unauthenticated
encryption does
conflict with the stated goal of not requiring coordination (between
administrators). I think
this is an example of trying to make the term OS all encompassing.
13. Your attempts to reconcile what you refer to as "no ceiling" for OS
and the
simple notion of unauthenticated encryption between OS-capable peers
yields text
that is confusing, borderline contradictory. I noted several examples.
Your replies
either insist there is no problem (and that the meaning is clear) or
offer additional
text that is marginally better.
14. I said that the suggestion to use PFS was out of place in the goal
where it
appeared. Your reply missed the point entirely.
15. I observed that the closing MTA example is inappropriate in a doc of
this sort.
I should also have noted that the use of MUST here makes no sense in an
informational
RFC defining terminology. Your reply suggests that you again missed the
point.