Markus,
I will start working on these issues and will post suggested
changes. I hope I can fix all of them except I am not quite sure about
the "inadequate security considerations section" comment. I can
address the latter by providing a list of Security Sections in the
other drafts, but doing so seems silly/redundant.
The example you suggest may not be appropriate because
pro-actively notifying 3rd parties of viruses and such is becoming less
and less popular idea (there were some IETF drafts about that IIRC).
Thank you,
Alex.
P.S. I did not receive Hilarie's and another message for some reason.
Found both in the list archive. Others may want to check that
they did not miss any recent posts.
On Tue, 30 Mar 2004, Markus Hofmann wrote:
Folks,
as pointed out earlier, the IETF ID tracker shows that a revised
version of our IAB considerations document is needed. I don't have any
more information that what the IETF tracker at
http://datatracker.ietf.org/
shows, so let's work from there.
[Ted - if you've any more information and/or advice on what exactly
we're expected to do, please let us know! Thanks.]
From looking at the comments in the ID tracker, and as summarized by
Hilarie, it seems we need to address the following issues:
- We need to re-work the notification example given in Section 5.1,
the comment we received is certainly valid and I'd suggest to use
a different example. What about using an example in which the
content provider receives notification that her content was rejected
by an OPES virus scanning service? This would give the content
provider the opportunity to verify its content, and if there's an
error with the virus scanner, to inform the OPES service provider.
This example also seems to be close to the one used in the original
IAB document.
- Clarification is need on our Section 7 (URI adaption vs. URI
resolution).
- Section 3 needs some clarification. I don't believe that there's a
fundamental problem here, re-wording might do it.
- The security considerations section was considered "inadequate" by
a reviewer and it was asked to add "pointers to sections that
discuss [...] integrity and confidentiality". Can we do that?
Please also see Hilarie's comments (cited below).
Alex, Abbie - can you start working on an updated version that will
address these issues and share it with the group? When do you think
we'd be able to have such updated version?
Ted - please let us know if there's anything that would help us in
making sure the updated version will pass IESG.
Thanks,
Markus
The Purple Streak, Hilarie Orman wrote:
The main objection seemed to be the confusing example about
notifications, which seems to have little relevance to OPES
protocol issues. The example calls for a note to be sent from a
child ISP to a parent company when a user reconfigures his
preferences in such a way as to subvert a policy of the parent
company. OPES is only indirectly involved, if at all. Is there a
better example?
I'm not sure if the IESG comments about "one-party consent" are an
objection or not. The architecture is clearly in compliance with
the IAB recommendation, and perhaps that could be stressed more.
The last paragraph of the one-party consent section is a little
confusing. It calls copying an "adaptation" that cannot be
detected. I think that the issue is more simply described as
content privacy.
Hilarie