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

From: Spencer Dawkins <[email-masked]>
Date: Thu, 19 Sep 2013 16:36:27 -0500

On 9/19/2013 6:00 AM, Daryl Malas wrote:
> Daryl Malas has requested publication of draft-ietf-cdni-requirements-10 as Informational on behalf of the CDNI working group.
>
> Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/
>

Hi, Daryl,

Thank you for the helpful shepherd writeup.

These are my notes from reading through the document. I found it 
well-written and clear (thank you, editors and working group).

I have some pre-IETF Last Call questions that I'd like to ask before 
moving forward. Please consider them, and let me know if the working 
group needs to make any text changes.

I may also be asking questions that would be more appropriate for 
another document in the series, so "great question, but not now" could 
be a fine response.

As a high-order bit, I didn't see any requirements for managing the 
interfaces. That could be OK, or you may have enough requirements in the 
various sections that when you add them together, you don't need any 
additional requirements specifically for management, but I wanted to ask 
before someone else did.

As a high-order bit, my questions about GEN-10/GEN-11, RI-5, LI-9 and 
SEC-1 might require discussion (which would be fine). My other questions 
are either about clarity or nits.

In Section 2.  CDNI Model and CDNI Interfaces

I found the use of two different line types with the same description 
odd in Figure 1. Is this just because the figure looked funny with one 
line type? Or is there something more subtle going on?

    <==>  interfaces inside the scope of CDNI
    ****  interfaces outside the scope of CDNI
    ....  interfaces outside the scope of CDNI

In Section 3.  Generic CDNI Requirements

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

I wasn't sure what this requirement meant (change or upgrade from 
what?). I'm not having a problem with the near-identical GEN-2, only 
with GEN-3. You provide examples in GEN-4. Could you provide an example 
here?

In the same section, I was confused by GEN-10 and GEN-11:

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

Is this "the CDN topology" or "the topology of interconnected CDNs"? I 
noticed this because I was looking at GEN-11, which says

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

If GEN-10 is about "the topology of interconnected CDNs", and doesn't 
guarantee that the topology is loop-free, I was wondering if this 
requirement was about preventing looping or detecting looping.

In 4.  CDNI Control Interface Requirements

    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 used if the Downstream CDN cannot delete
           the content in its storage.

Perhaps s/are used if/are included if/ might be clearer.

In the same section,

    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
           protocols to be used across the CDNs (e.g.  HTTP, HTTPS, FTP,
           ATIS C2).

Is "HTTPS" actually a protocol? And adding a reference for "ATIS C2" 
would be helpful.

In 5.  CDNI Request Routing Redirection Interface Requirements

    RI-1   [HIGH] The CDNI Request Routing Redirection interface shall
           support efficient request-routing for small objects.  This
           may, for example, call for a mode of operation (e.g.  DNS-
           based request routing) where freshness and accuracy of CDN/
           Surrogate selection can be traded-off against reduced request-
           routing load (e.g.  Via lighter-weight queries and caching of
           request-routing decisions).

and

    RI-2   [HIGH] The CDNI Request Routing Redirection interface shall
           support efficient request-routing for large objects.  This
           may, for example, call for a mode of operation (e.g. HTTP-
           based request routing) where freshness and accuracy of CDN/
           Surrogate selection justifies a per-request decision and a
           per-request CDNI Request-Routing protocol call.

I'm not sure what "efficient" implies here, perhaps because I see the 
examples but don't know what other efficiencies might be required.

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.

In the same section,

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

I noticed a nit: s/enforcment/enforcement/

In Section 7.  CDNI Metadata Interface Requirements

    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 is
           not concluded to be in Metadata Interface or Control
           Interface)

I didn't understand the parenthetical note at the end of MI-19 - what 
does "is not concluded to be in" mean? I can guess, but I'm guessing.

In Section 8.  CDNI Logging Interface Requirements

    LI-9   [LOW] The CDNI Logging interface may support aggregate/
           summarized logs (e.g. total bytes delivered for a content
           regardless of individual User Agents to which it was
           delivered).

This requirement is fine, but I didn't see requirements that applied to 
how the Upstream CDN and Downstream CDN communicated what 
aggregates/summarized logs were available. If this is captured under 
"extensible" elsewhere in the section, that's fine.

In Section 9.  CDNI Security Requirements

    SEC-1  [HIGH] All the CDNI interface shall support secure operation
           over unsecured IP connectivity (e.g.  The Internet).  This
           includes authentication, confidentiality, integrity protection
           as well as protection against spoofing and replay.

This is excellent, as far as it goes. You might consider whether the 
requirements go far enough to protect privacy, in a "pervasive passive 
monitoring" world - perhaps the combination of "unsecured IP 
connectivity" plus unsecured HTTP as a supported transport has 
implications for privacy that affect CDNI at the requirements level? (If 
not, you might consider pointing that out in the Security Considerations 
section, because that conversation now will be less painful than the 
same conversation during evaluation of a protocol draft :-)

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 20 Sep 2013 14:58:49 +0000

Hi Spencer,

Great to have a review performed with a fresh eye. My personal thoughts embedded below:

On 19 Sep 2013, at 23:36, Spencer Dawkins <[email-masked]> wrote:

> These are my notes from reading through the document. I found it well-written and clear (thank you, editors and working group).
> 
> I have some pre-IETF Last Call questions that I'd like to ask before moving forward. Please consider them, and let me know if the working group needs to make any text changes.
> 
> I may also be asking questions that would be more appropriate for another document in the series, so "great question, but not now" could be a fine response.
> 
> As a high-order bit, I didn't see any requirements for managing the interfaces. That could be OK, or you may have enough requirements in the various sections that when you add them together, you don't need any additional requirements specifically for management, but I wanted to ask before someone else did.
> 
> As a high-order bit, my questions about GEN-10/GEN-11, RI-5, LI-9 and SEC-1 might require discussion (which would be fine). My other questions are either about clarity or nits.
> 
> I found the use of two different line types with the same description odd in Figure 1. Is this just because the figure looked funny with one line type? Or is there something more subtle going on?

It was purely to make the figure more readable. The figure shows different interafces that crosses each other and it just seemed easier to read it with different symbols.
We use the same pictorial convention in RFC6707 (CDNI Problem Statement), so I'd usggest keeping it as is.

> I wasn't sure what this requirement meant (change or upgrade from what?).

I believe that what this is trying to say is that if a CSP currently uses a single CDN for content delivery, then if that CDN decides to leverages other CDNs via CDNI, the solution should allow this to happen transparently. To illustrate the point, if the CDNI solution imposed that all URIs be structured in some rigid way and therefore imposed that the CSP modifies all their URIs listed in their content portal, that would be a bad solution.

> I'm not having a problem with the near-identical GEN-2, only with GEN-3. You provide examples in GEN-4. Could you provide an example here?
> 
> Is this "the CDN topology" or "the topology of interconnected CDNs"?

It is the "the topology of interconnected CDNs". I agree text can make that more explicit.

> I noticed this because I was looking at GEN-11, which says
> 
> If GEN-10 is about "the topology of interconnected CDNs", and doesn't guarantee that the topology is loop-free, I was wondering if this requirement was about preventing looping or detecting looping.

Well, I think the key requirement here is that the ongoing looping of information be prevented. There are multiple ways this might be achieved (eg have a solution that absolutely guarantees it never happens even during transient situations, or have a solution that detects it if/when it happens and then interrupts it). In fact, different CDNI interfaces may use different mechanisms to prevent such loops. I don't think this particular requirement needs to mandate one approach.

> Perhaps s/are used if/are included if/ might be clearer.

Agreed.

> Is "HTTPS" actually a protocol?

Not sure there is a well-accepted definition of protocol. To me "HTTP over TLS" would probably qualify as a protocol. If you prefer we could just s/Content Acquisition protocols/Content Acquisition methods.

> And adding a reference for "ATIS C2" would be helpful.
> 
> I'm not sure what "efficient" implies here, perhaps because I see the examples but don't know what other efficiencies might be required.

As suggested by the examples, the "efficiency" referred to is indeed in terms of trade-offs between request routing load and accuracy of the request routing decision.
But at the same time, i don't think it is bad if the requirement doesn't completely close the door on other efficiencies (which may be understood when finalising teh details of CDNI interfaces). 

> 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 didn't understand the parenthetical note at the end of MI-19 - what does "is not concluded to be in" mean? I can guess, but I'm guessing.

It was questioned whether this requirement (ie "a mechanism allowing the Upstream CDN to indicate to the Downstream CDN which CDNI Log fields are to be provided") should be realised by the Metadata interface or whether it shoudl possibly actually be realised by the Control interface. At this stage the WG has not concluded that discussion (and the discussion has been paused since this will not be part of the first version of the interfaces).
The note could be improved to make this clearer.

> This requirement is fine, but I didn't see requirements that applied to how the Upstream CDN and Downstream CDN communicated what aggregates/summarized logs were available. If this is captured under "extensible" elsewhere in the section, that's fine.

I would say this is covered by MI-19. This woudl indicate which "aggregate" fields are to be provided.

> This is excellent, as far as it goes. You might consider whether the requirements go far enough to protect privacy, in a "pervasive passive monitoring" world - perhaps the combination of "unsecured IP connectivity" plus unsecured HTTP as a supported transport has implications for privacy that affect CDNI at the requirements level? (If not, you might consider pointing that out in the Security Considerations section, because that conversation now will be less painful than the same conversation during evaluation of a protocol draft :-)

In fact, the CDNI Logging interface includes a specific privacy mechanism (in the form of anonymization of IP addresses).
Perhaps a requirement for privacy of CDNI LOgging information should be added?

Cheers

Francois

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

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 20 Sep 2013 14:02:01 -0500

> Great to have a review performed with a fresh eye. My personal thoughts embedded below:

Thanks for a quick response with personal thoughts :-)

We're in sync on everything but my question about RI-5. This is going 
really well!

Please see inline ...

>>    ....  interfaces outside the scope of CDNI

"More readable" was my guess, so definitely not suggesting a change to 
the figure itself.

The editors might consider something like

<==> interfaces inside the scope of CDNI
**** and .... interfaces outside the scope of CDNI

as the legend. I was guessing the text for "...." was a cut-and-paste 
error from the previous line, and I think that's the most likely 
response from any first-time reader.

> I believe that what this is trying to say is that if a CSP currently uses a single CDN for content delivery, then if that CDN decides to leverages other CDNs via CDNI, the solution should allow thi…

Your explanation helped a LOT. Somewhat frustratingly, almost all the 
words in your explanation are in the requirement I couldn't understand :D

What you added, which made the same words clearer, was the point about a 
CSP using a single CDN and then deciding to leverage interconnected CDNs.

Perhaps the editors could consider a better version of

"The CNDI 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."

That answers my "from what?" question.

> It is the "the topology of interconnected CDNs". I agree text can make that more explicit.

Ack.

> Well, I think the key requirement here is that the ongoing looping of information be prevented. There are multiple ways this might be achieved (eg have a solution that absolutely guarantees it neve…

I agree, but I was reading "prevent looping" in the text as requiring an 
absolute guarantee, so mandating one approach.

Perhaps something like "shall prevent persistent looping" would capture 
what you're describing?

>> Perhaps s/are used if/are included if/ might be clearer.

Ack.

> Not sure there is a well-accepted definition of protocol. To me "HTTP over TLS" would probably qualify as a protocol. If you prefer we could just s/Content Acquisition protocols/Content Acquisition…

Your suggested "s/Content Acquisition protocols/Content Acquisition 
methods" works better than anything I was able to suggest. Thanks!

> But at the same time, i don't think it is bad if the requirement doesn't completely close the door on other efficiencies (which may be understood when finalising teh details of CDNI interfaces).

I think you're right. I also think I've spent too much time listening to 
people argue about whether something "really" satisfies a requirement, 
and I had a Pavlovian response to "efficient" ("how the heck would I 
know?"). My apologies.

If the working group doesn't expect to have such arguments, I'm fine 
with the existing text :-)

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

> The note could be improved to make this clearer.

That was close to one of my guesses.

Is it correct to say "this function may be part of the Metadata 
Interface or the Control Interface"?

> I would say this is covered by MI-19. This woudl indicate which "aggregate" fields are to be provided.

If that works for the working group, that works for me.

> Perhaps a requirement for privacy of CDNI LOgging information should be added?

Perhaps, and I should say "you folks are the experts" at this point. It 
may be that there are loads of privacy considerations that don't show up 
at the requirements level, too.

I do suggest that the working group keep in mind that on each telechat, 
the IESG has two SEC ADs, including the one who's sponsoring the 
"perpass" mailing list, plus an IAB Chair who's a former SEC AD, plus an 
IETF Chair who's done press interviews about pervasive passive 
monitoring as recently as this morning.

And that's before anyone outside the IESG asks at Last Call time whether 
the working group thought about privacy in our Brave New World.

As long the answer is "yes, they thought about it", I'll be happy with 
pretty much anything you decide :-)

Spencer

---

From: Daryl Malas <[email-masked]>
Date: Sat, 21 Sep 2013 10:06:49 +0000

In-line, removing agreed actions for improved clarity. --Daryl

On 9/20/13 9:02 PM, "Spencer Dawkins" <[email-masked]>
wrote:

>>>> Daryl Malas has requested publication of
>>>>draft-ietf-cdni-requirements-10 as Informational on behalf of the CDNI
>>>>working group.
>>>>
>>>> Please verify the document's state at
>>>>http://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/
>>>>
>>> Hi, Daryl,
>>>
>>>interfaces. That could be OK, or you may have enough requirements in
>>>the various sections that when you add them together, you don't need
>>>any additional requirements specifically for management, but I wanted
>>>to ask before someone else did.
>>>
>>>SEC-1 might require discussion (which would be fine). My other
>>>questions are either about clarity or nits.
>>>
>> It was purely to make the figure more readable. The figure shows
>>different interafces that crosses each other and it just seemed easier
>>to read it with different symbols.
>> We use the same pictorial convention in RFC6707 (CDNI Problem
>>Statement), so I'd usggest keeping it as is.
>>

[DM] I agree with you, after reviewing the diagram again it is redundant.
The description for one of the "outside the scope" should be changed, or
the relative lines should be aligned for consistency.  I'll defer to the
authors/editors for their recommendation on this.

>>>what?).
>> I believe that what this is trying to say is that if a CSP currently
>>uses a single CDN for content delivery, then if that CDN decides to
>>leverages other CDNs via CDNI, the solution should allow this to happen
>>transparently. To illustrate the point, if the CDNI solution imposed
>>that all URIs be structured in some rigid way and therefore imposed that
>>the CSP modifies all their URIs listed in their content portal, that
>>would be a bad solution.
>

[DM] I'm fine with this change.

>> Well, I think the key requirement here is that the ongoing looping of
>>information be prevented. There are multiple ways this might be achieved
>>(eg have a solution that absolutely guarantees it never happens even
>>during transient situations, or have a solution that detects it if/when
>>it happens and then interrupts it). In fact, different CDNI interfaces
>>may use different mechanisms to prevent such loops. I don't think this
>>particular requirement needs to mandate one approach.
>

[DM] Spencer, I read both your question and Francois' response, and my
perception is we are splitting hairs on this one.  Adding "persistent", to
me, changes the requirement.  This requirement says, "define a way to
avoid loops" (e.g., Max-Forwards in SIP).  The change you suggest
indicates to me that we define a solution for attempting to avoid dCDNs
that cause loop after a loop has been already detected and shut down.  Are
you suggesting we add a requirement for loop detection or change this one
to better align with the latter?

>> As suggested by the examples, the "efficiency" referred to is indeed in
>>terms of trade-offs between request routing load and accuracy of the
>>request routing decision.
>> But at the same time, i don't think it is bad if the requirement
>>doesn't completely close the door on other efficiencies (which may be
>>understood when finalising teh details of CDNI interfaces).
>

[DM] How can you ever predict what a working group will argue about?? ;-)

>>           mechanism should prevent or interrupt the loop and allow
>>routing of the request (as opposed to the request loop being simply
>>interrupted

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

>>> I noticed a nit: s/enforcment/enforcement/

[DM] Ack. Easy editor fix.

>> It was questioned whether this requirement (ie "a mechanism allowing
>>the Upstream CDN to indicate to the Downstream CDN which CDNI Log fields
>>are to be provided") should be realised by the Metadata interface or
>>whether it shoudl possibly actually be realised by the Control
>>interface. At this stage the WG has not concluded that discussion (and
>>the discussion has been paused since this will not be part of the first
>>version of the interfaces).
>>>implications for privacy that affect CDNI at the requirements level?
>>>(If not, you might consider pointing that out in the Security
>>>Considerations section, because that conversation now will be less
>>>painful than the same conversation during evaluation of a protocol
>>>draft :-)
>> In fact, the CDNI Logging interface includes a specific privacy
>>mechanism (in the form of anonymization of IP addresses).

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 21 Sep 2013 09:01:31 -0500

> In-line, removing agreed actions for improved clarity. --Daryl

Likewise. And thank you for the quick response.

I like that these e-mails are getting shorter, by the way ...

> authors/editors for their recommendation on this.

As will I. I note that "ascii art" is a synonym for "barely art", so I 
understand this isn't easy :-)

> to better align with the latter?

So, I'm not suggesting to change the requirement or to add a new 
requirement.

For background, I lived through at least part of the conversation 
between IEEE 802.1, with no hop count, so they had to avoid loops, and 
TRILL, with hop counts, so they could mitigate the effects of forming 
loops, and that conversation was more memorable than it should have been

I understood Francois to be saying that at the requirement level, the 
working group didn't need to choose between avoiding loops and 
mitigating the effect of forming loops.

I'm OK with that. My struggle was that I was reading "avoid loops" as 
mandating the choice that Francois didn't think you should be mandating.

If the working group doesn't read "avoid loops" as mandating that 
choice, or reads it as mandating that choice and thinks that's OK, 
either way is fine.

> [DM] How can you ever predict what a working group will argue about?? ;-)

Daryl, that's easy. Predicting what a working group WON'T argue about is 
hard :p

That's not an actionable comment, by the way :-) ...

> 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. Other text would work, too.

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Mon, 23 Sep 2013 08:29:30 +0000

All,

> As will I.

Works for me too.

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

Francois

> Other text would work, too.

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 23 Sep 2013 12:51:06 -0500

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

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