Open Pluggable Edge Services (OPES) Treatment of IAB Considerations
draft-ietf-opes-iab-05

[Ballot comment]
I'm not sure how this text in 7.:

  In some environments, it is technically
  possible to adapt URIs (and other kinds of identifiers or addresses)
  using documented OPES mechanisms. The OPES framework cannot
  effectively prohibit any specific adaptations.

relates to the IAB requirement.  If they mean "URI adaptation" occurs
before URI resolution and may, thereby influencing that resolution,
then a clearer statement of that seems to be required.  If they mean
something else, a pointer to the definition here would be useful.

As it is, the requirement says: 

  "OPES documentation must be clear in describing these services as
  being applied to the result of URI resolution, not as URI resolution
  itself."[RFC3238]


Did they really mean to imply the Cable company would have terms of use that
demanded you look at their advertisements for porn (section 5.1)?

  For example, a Cable Company Internet Service Provider (Cable ISP) may
  provide a user-configurable porn filtering service to its subscribers
  while having an agreement with the parent Cable Company to send
  notifications to the content provider when clients (content
  consumers) use the same filter to block Company's advertisement
  images.  If the Cable Company deems such subscriber actions
  inappropriate, the company may contact individual subscribers and
  enforce their ISP usage policy according to the terms of the service
  agreement.

I can read it other ways, but this seems like they might want to fix it.
Not a blocking comment as this is certainly an arresting example,
but it seems unintended.  Shifting it "to block access to the
Company's general-purpose advertisement images" might help.

[Ballot comment]
'm not sure how this text in 7.:

  In some environments, it is technically
  possible to adapt URIs (and other kinds of identifiers or addresses)
  using documented OPES mechanisms. The OPES framework cannot
  effectively prohibit any specific adaptations.

relates to the IAB requirement.  If they mean "URI adaptation" occurs
before URI resolution and may, thereby influencing that resolution,
then a clearer statement of that seems to be required.  If they mean
something else, a pointer to the definition here would be useful.

As it is, the requirement says: 

  "OPES documentation must be clear in describing these services as
  being applied to the result of URI resolution, not as URI resolution
  itself."[RFC3238]


Did they really mean to imply the Cable company would have terms of use that
demanded you look at their advertisements for porn (section 5.1)?

  For example, a Cable Company Internet Service Provider (Cable ISP) may
  provide a user-configurable porn filtering service to its subscribers
  while having an agreement with the parent Cable Company to send
  notifications to the content provider when clients (content
  consumers) use the same filter to block Company's advertisement
  images.  If the Cable Company deems such subscriber actions
  inappropriate, the company may contact individual subscribers and
  enforce their ISP usage policy according to the terms of the service
  agreement.

I can read it other ways, but this seems like they might want to fix it.
Not a blocking comment as this is certainly an arresting example,
but it seems unintended.  Shifting it "to block access to the
Company's general-purpose advertisement images" might help.

[Ballot discuss]
I'm not sure how this text in 7.:

  In some environments, it is technically
  possible to adapt URIs (and other kinds of identifiers or addresses)
  using documented OPES mechanisms. The OPES framework cannot
  effectively prohibit any specific adaptations.

relates to the IAB requirement.  If they mean "URI adaptation" occurs
before URI resolution and may, thereby influencing that resolution,
then a clearer statement of that seems to be required.  If they mean
something else, a pointer to the definition here would be useful.

As it is, the requirement says: 

  "OPES documentation must be clear in describing these services as
  being applied to the result of URI resolution, not as URI resolution
  itself."[RFC3238]

[Ballot discuss]
I'm not sure how this text in 7.:

  In some environments, it is technically
  possible to adapt URIs (and other kinds of identifiers or addresses)
  using documented OPES mechanisms. The OPES framework cannot
  effectively prohibit any specific adaptations.

relates to the IAB requirement.  If they mean "URI adaptation" occurs
before URI resolution and may, therefore effect that resolution,
then a clearer statement of that seems to be required.  As it is, the
requirement says: 

  "OPES documentation must be clear in describing these services as
  being applied to the result of URI resolution, not as URI resolution
  itself."[RFC3238]

So if they are saying http://www.example.com/bar.txt" triggers an
adaptation to h

[Ballot comment]
Did they really mean to imply the Cable company would have terms of use that
demanded you look at their advertisements for porn (section 5.1)?

  For example, a Cable Company Internet Service Provider (Cable ISP) may
  provide a user-configurable porn filtering service to its subscribers
  while having an agreement with the parent Cable Company to send
  notifications to the content provider when clients (content
  consumers) use the same filter to block Company's advertisement
  images.  If the Cable Company deems such subscriber actions
  inappropriate, the company may contact individual subscribers and
  enforce their ISP usage policy according to the terms of the service
  agreement.

I can read it other ways, but this seems like they might want to fix it.
Not a blocking comment as this is certainly an arresting example,
but it seems unintended.  Shifting it "to block access to the
Company's general-purpose advertisement images" might help.

[Ballot comment]
Comment from Spencer Dawkins, Gen-ART:

If this draft needs to be published as an RFC (why? especially since
it has normative references that will prevent its publication until
OPES is finished anyway), it's close to OK to publish. I have two
comments:

- Section 3 on "one-party consent" seems unresponsive to the IAB
concern. The authors can identify situations where one-party consent
isn't reasonable or practical, but don't name situations where
one-party consent DOES make sense. The rest of the sections seemed
like the WG "gets it". This section does not.

- The last paragraph in Section 5.1 was unclear to me. It might help
if the two entities named were not the Cable Company ISP and the Cable
Company, but it took about four reads before I could even start to
guess what this example had to do with notifications vs trace.

[Ballot discuss]
RFC 3238 has a lot to say about data integrity.  It says, for example:
  >
  > One of the goals of the OPES architecture must be to maintain the
  > robustness long cited as one of the overriding goals of the Internet
  > architecture [Clark88].  Given this, we recommend that the IESG
  > require that the OPES architecture protect end-to-end data integrity
  > by supporting end-host detection and response to inappropriate
  > behavior by OPES intermediaries.
  >
  Yet, the word 'integrity' does not appear in this document.

  The security considerations are inadequate.  At a minimum, I would like
  to see pointers to sections that discuss of integrity and confidentiality.