Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 2 Oct 2013 21:40:31 +0000

Hi Spencer. Thanks for your thorough review. Also, I appreciate the discussion on the comments. I've tried to capture all the topics so please inform me if anything is incorrect or missing.

1. Comment: "... need any additional requirements specifically for management ..." 

This hasn't come up in the past, AFAIK. I've assumed that management is out of scope from requirements' perspective. Obviously, anyone can write a draft for management such as MIBs, etc. So "great question, but not now" :)

2. Comment: "... of two different line types with the same description odd in Figure 1..." 

I agree. Having different line types in the figure is more readable, so will change to  "**** and  ....  interfaces outside the scope of CDNI"

3. Comment: "GEN-3 ..."

Requirement is updated:

GEN-3   [HIGH] The CDNI solution shall not require a change, or an
           upgrade, to the Content Service Provider delivering content through
           a single CDN, to benefit from content delivery through interconnected CDNs.

4. Comment: "GEN-10..."

I've changed the requirement  from:

GEN-10  [MED] The CDNI solution should support an arbitrary topology
           of interconnected CDNs (i.e. the CDN topology cannot be
           restricted to a tree, a loop-free topology, etc.).

To:

 GEN-10  [MED] The CDNI solution should support an arbitrary topology
           of interconnected CDNs (i.e. the topology of interconnected CDNs cannot be
           restricted to a tree, ring, star, etc.).

5. Comment: "GEN-11..."

No change to requirement.

 GEN-11  [HIGH] The CDNI solution shall prevent looping of any CDNI
           information exchange.

6. Comment: "CI-4..."

Requirement is updated.

CI-4   [HIGH] The CDNI Control interface shall allow the Downstream
          CDN to report on the completion of these actions (by itself,
          and including downstream cascaded CDNs, in a manner
          appropriate for the action (e.g. synchronously or
          asynchronously).  The confirmation receipt should include a
          success or failure indication.  The failure indication along
          with the reason are included if the Downstream CDN cannot delete
          the content in its storage.

7. Comment: "CI-11..."

Requirement is updated.

CI-11  [LOW] The CDNI Control interface may allow bootstrapping of
          the Content Acquisition interface.  This could, for example,
          include exchange and negotiation of the Content Acquisition
          methods to be used across the CDNs (e.g.  HTTP, HTTPS, FTP,
          ATIS C2).

Informative reference is added for:

   [ATIS-0800042]   ATIS IPTV Content on Demand Service,  December 8, 2010

8. Comment: "RI-1 and RI-2 ... efficient request-routing"

No change to requirements.

9.  Comment: "RI-5..."

Requirement is updated.

RI-5   [MED] In case of detection of a request redirection loop, the CDNI Request Routing Redirection Interface's loop prevention     mechanism should allow redirection of the request on an alternate CDN path (as opposed to the request not being redirected at all).

10. Comment: "RI-6..."

Typo fixed.

RI-6   [MED] The CDNI Request Routing Redirection interface should
          support a mechanism allowing enforcement of a limit on the
          number of successive CDN redirections for a given request.

11. Comment: "MI-19..."

Requirement is updated.

   MI-19  [MED] The CDNI Metadata interface should support an optional
          mechanism allowing the Upstream CDN to indicate to the
          Downstream CDN which CDNI Log fields are to be provided for
          all, for specific sets of, or for specific content items
          delivered using HTTP.  A CDNI implementation that does not
          support this optional CDNI Metadata Distribution Interface
          mechanism shall ignore this log format indication and generate
          CDNI logging format for HTTP Adaptive Streaming using the
          default set of CDNI Logging fields.  (Note: This function may be part of 
          the CDNI Metadata interface or the CDNI Control interface.)

12. Comment: "SEC-1... protect privacy"

I'm not quite sure how to capture privacy protection in the general security requirements section. It seems to be a broad statement in the context of IP and HTTP communications. So I'm open to suggested text. :) The CDNI interface that seems most relevant is the CDNI Logging interface. I've tried to capture this requirement below.

Add a new requirement:

LI-18  [MED] The CDNI Logging interface should provide privacy protection
          by not disclosing information that can be used to identify the user
         (e.g. method that anonymize the IP address carried in the logging field ).

If these changes are agreeable, let me know and I'll publish the next version of the draft.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Spencer Dawkins
Sent: Monday, September 23, 2013 10:51 AM
To: Francois Le Faucheur (flefauch)
Cc: Martin Stiemerling; <[email-masked]>; Daryl Malas
Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10

On 9/23/2013 3:29 AM, Francois Le Faucheur (flefauch) wrote:
>
>>>>>> In the same section,
>>>>>>
>>>>>>     RI-5   [MED] In case of detection of a request redirection loop, the
>>>>>>            CDNI Request Routing Redirection interface's loop prevention
>>>>>>            mechanism should allow routing of the request by avoiding the
>>>>>>            loop (as opposed to the request loop being simply interrupted
>>>>>>            without routing the request).
>>>>>>
>>>>>> I'm not understanding what "by avoiding the loop" means. I can 
>>>>>> guess, but I'm guessing.
>>>>> How about:
>>>>> "
>>>>>     RI-5   [MED] In case of detection of a potential request redirection
>>>>> loop, the
>>>>>            CDNI Request Routing Redirection interface's loop prevention
>>>>>            mechanism should prevent or interrupt the loop and 
>>>>> allow routing of the request (as opposed to the request loop being 
>>>>> simply interrupted
>>>>>            without routing the request).
>>>>> "
>>>> I'm not clearly explaining what's not clear to me. Let me guess again ...
>>>>
>>>> I'm pretty sure I'm choking because I'm reading "allow routing of 
>>>> the request" as "you sent me a request that loops when I route it, 
>>>> so I either prevent or interrupt the loop *and continue to route 
>>>> the request*, like I suddenly know how to route the request that 
>>>> was looping, without looping".
>>>>
>>>> Is RI-5 saying that if you send a request that loops, you get a 
>>>> response that tells you that the request looped, as opposed to 
>>>> having the loop prevention mechanism drop the request to protect 
>>>> the CDN, but you get nothing back? Or am I missing this completely?
>>> [DM] I think I understand your concern; and, after reviewing the 
>>> requirement again, I agree with you.  If the CDN knew how to avoid 
>>> the loop in the first place, why would it send a request purposely 
>>> in a direction that causes a loop.  Perhaps the requirement should 
>>> state something more like:
>>>
>>> [MED] In case of detection of a request redirection loop, the
>>>             CDNI Request Routing Redirection interface's loop prevention
>>>             mechanism should notify the requesting CDNs of the loop, 
>>> so the requesting CDN could attempt a difference dCDN.
>> After looking at the original requirement again, what I was struggling with is that the text sounds like the interface is avoiding the loop that the request caused, but the same interface is still routing the same request with no changes.
>>
>> Your suggestion would work for me (if it works for others, of course), because it doesn't use the same word for what happens before and after a request redirection loops.
> The text suggested by Daryl could work for me too. Although I would prefer:
> "
> [MED] In case of detection of a request redirection loop, the
>             CDNI Request Routing Redirection interface's loop prevention
>             mechanism should allow the uCDN to attempt a different dCDN.
> "
>
> This is because the loop detection might actually be done by the uCDN itself based on information received in the RI request, so the uCDN never really receive a "notification" of loop (ie the uCDN may look at the information in the received RI request, and realises that the "initially selected dCDN" would result in a loop - because it already appears in the received RI request).

This text makes sense to me, and would also work for me if it works for others.

I'm not sure how it's equivalent to the original RI-5, but since I said I couldn't understand the original RI-5, that's probably a good thing :-)

Spencer
_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 02 Oct 2013 22:51:08 -0500

> Hi Spencer. Thanks for your thorough review. Also, I appreciate the discussion on the comments. I've tried to capture all the topics so please inform me if anything is incorrect or missing.

Just to cut to the chase, "yes, please submit an updated draft" :-)

I have a couple of things I'd like for you to look at, but you're ready 
for me to forward the draft after you do that.

> This hasn't come up in the past, AFAIK. I've assumed that management is out of scope from requirements' perspective. Obviously, anyone can write a draft for management such as MIBs, etc. So "great…

That's fair, especially if the answer is that CDNI doesn't require 
anything special that we don't already know how to manage.

> I agree. Having different line types in the figure is more readable, so will change to  "**** and  ....  interfaces outside the scope of CDNI"

Thanks!

>             a single CDN, to benefit from content delivery through interconnected CDNs.

Thanks!

>             restricted to a tree, ring, star, etc.).

Thanks!

>   GEN-11  [HIGH] The CDNI solution shall prevent looping of any CDNI

That's fine, and I want to emphasize that the discussion on this 
requirement was helpful to me. I'm still learning how to review 
requirement drafts :-)

>            the content in its storage.

This is a little rough. I'm counting two left parens and one right 
paren, and I think it would be

The failure indication and the reason are included if ...

but with minor fixes, this will be fine.

>     [ATIS-0800042]   ATIS IPTV Content on Demand Service,  December 8, 2010

So, this is the reference for ATIS C2? That linkage wasn't clear to me.

> No change to requirements.

That's fine, and again, the discussion on this requirement was helpful 
to me.

> RI-5   [MED] In case of detection of a request redirection loop, the CDNI Request Routing Redirection Interface's loop prevention     mechanism should allow redirection of the request on an alterna…

This is OK, I think. Early in the discussion, the distinction I was 
making was "as opposed to the request being dropped, so you get an error 
indication instead of a timeout". If that's clearly the same as "not 
being redirected at all", that's fine, and it could be clearly the same ;-)

>            number of successive CDN redirections for a given request.

Thank you.

>            the CDNI Metadata interface or the CDNI Control interface.)

I THINK

           which CDNI Log fields are to be provided for
           all, for specific sets of, or for specific content items
           delivered using HTTP

is correct, but I wonder if

           which CDNI Log fields are to be provided for
           all content items, for specific sets of content items, or for specific content items
           delivered using HTTP

would be easier for readers. Your call.

>           (e.g. method that anonymize the IP address carried in the logging field ).

The IAB plenary in Vancouver will include discussion of pervasive 
passive monitoring, which is your signal that we are still figuring 
privacy out. For that reason alone, I don't think this is the time to 
work really hard figuring out requirements for privacy.

I suspect your new requirement is appropriate. We may get more guidance 
as we go through the publication cycle.

Thank you for working on this.

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 02 Oct 2013 22:53:11 -0500

> Hi Spencer. Thanks for your thorough review. Also, I appreciate the discussion on the comments. I've tried to capture all the topics so please inform me if anything is incorrect or missing.

Sorry for sending two notes back to back.

It's appropriate for me to say that this review cycle was really easy 
for me to follow. Thank you for that, too!

Spencer

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 3 Oct 2013 20:12:42 +0000

Hi Kent,

>         (e.g. method that anonymize the IP address carried in the logging field ).

I suggest you tweak the text to make it clear that it will be up to a given deployment to decide whether the privacy protection mechanism is actually used or not. In other word, the pricavy protection mechanism woudl be "Optional to Use".
The text above might be understood as saying that the CDNI Logging interface needs to _never_ disclose information that can be used to identify the user. I don't think we want to say that. We just want the interface to allow to not disclose that information when and where that is required.

Thanks

Francois

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 03 Oct 2013 19:29:15 -0500

> The text above might be understood as saying that the CDNI Logging interface needs to _never_ disclose information that can be used to identify the user. I don't think we want to say that. We just…

Ordinarily I wouldn't poke my nose in while you folks are chatting, but 
since I asked Kent to do a revision before Francois sent this note, 
perhaps I should say that I'd be OK with words that said something like 
that, if the working group goes for it.

Spencer

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 4 Oct 2013 05:52:28 +0000

Hi Kent,

Thanks

Francois