Re: Revised ID Needed for draft-ietf-opes-iab-04?

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
> >
>
>