Revised ID needed for draft-ietf-opes-end-comm-06.txt

Markus Hofmann <[email protected]>
Newsgroups gmane.ietf.opes
Message-ID <[email protected]>
Folks,

here's the third of our pending drafts. We also deed to revise our 
tracing draft draft-ietf-opes-end-comm-06.txt. Please see ID tracker 
at https://datatracker.ietf.org for details. In summary, it looks like 
the following issues needs to be addressed:

  - The design choice in Section 4 needs to be explained/motivated
    better, i.e. why is a bypass request ignored rather than an error
    message returned when there's no non-opes version.

    Our text explains that it might be impossible for a specific OPES
    intermediary to determine whether a non-opes version is available
    or not. In this case, it makes sense to *not* send an error
    message and ignore the request.

    But if the intermediary can determine that no non-opes version is
    available, there might be scenarios where an error message might
    be preferred over ignoring the bypass.

  - Section 8.2 discusses a threat introduced by using OPES for
    wiretap, but according to RFC 2804, the "IETF has decided not to
    consider requirements for wiretapping as part of the process for
    creating and maintaining IETF standards."

    Seems like removing this specific threat scenario from Section 8.2
    will address this specific comment.

  -  The Security and Authorization requirements should be made
     normative.

Abbie - if you need someone to help with these or need some 
discussion, please let us know. Otherwise, let's get the changes in 
and re-submit.

Thanks,
   Markus
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.