Subject: [CDNi] Progressing the CDNI Problem Statement

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 4 Jul 2011 10:07:21 +0100

Colleagues,

Our first milestone is to submit the CDNI Problem Statement for publication. Although I think the current document is in reasonably good shape there are a number of questions (which I have included below) that I think need to be answered as they will affect the final structure and content of the problem statement.

Questions (2), (3) & (4) below are related to the fact that prior to the WG being formed the Problem Statement was used as a sort of "holding area" for material that was relevant to WG formation but that wasn't strictly related to describing the actual problem that CDNI is now chartered to solve.

Therefore, in order to progress the problem statement document it would be useful to get feedback from the group on the following questions:

1) Are the set of protocols (request routing, metadata, logging and control) listed in the problem statement sufficient to implement CDNI? Does the problem statement describe them in sufficient detail (bearing in mind that it is only a problem statement and not a framework/specification and so doesn't need to be exhaustive in its description)?

2) Is it necessary to retain the "Non-Goals for IETF" section as the scope of the work the WG will undertake (and the areas the WG will not undertake) is now documented in the WG's charter?

3) Is it necessary to retain the "Prioritizing the CDNI Work" section as the priority of the work of the WG is now documented in the WG's charter and milestones?

4) Is it necessary to retain the sections on related standardisation and research projects as the ongoing work in other bodies is always a "moving target" and attempting to keep an up to date description could be challenging and will almost certainly become out of date pretty rapidly and therefore it may not be worthwhile trying to capture that material within an RFC?

If we want to point to specific work that could be reused or may be directly relevant to the work on CDNI in IETF then relevant references to work by other bodies is already captured in the Gap Analysis (section 6.3).

5) Are there any significant gaps or additional topics not present in the current document that people think need to be covered by additional sections/text prior to the document being ready for publication?

Thanks
Ben

---

From: <[email-masked]>
Date: Fri, 8 Jul 2011 14:26:24 +0100

>>>I think this is sufficient, in terms of detail I think there is sufficient considering the context of the document.

>>>I think that this is on the one hand repetition but perhaps it adds value to hold this (at least from a HL) in this document should it be used as a landing-point to understand CDNI?

>>>I think that this can be removed.

>>>Personally I don't see value in this section right now, others may do.

>>>Agreed.

>>>>I don't have anything additional that is not already covered elsewhere, use-cases I-D for example.

Cheers.
grant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: 04 July 2011 10:07
To: [email-masked]
Subject: [CDNi] Progressing the CDNI Problem Statement

Colleagues,

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 8 Jul 2011 16:13:26 +0200

(Individual hat on)

Agreed.

One minor point on the editorial side: the charter has converged on a terminology of "interfaces" ("CDNI request-routing interface",  "CDNI metadata interface",  "CDNI logging interface" and "CDNI control interface"), so the problem statement needs to align to that of course.

>>>> I think that this is on the one hand repetition but perhaps it adds value to hold this (at least from a HL) in this document should it be used as a landing-point to understand CDNI?

I could go either way.
If you keep it in, there is a small theoretical risk that it becomes incorrect and in conflict with the charter in case the charter evolves in the future to expend/reduce its scope.
On the positive side it provides a useful discussion on why "acquisition" is out of scope, which is the question that has been raised many times.
My suggestion would be to:
	* remove the section and the list of excluded items (since it is in the charter) 
	* move the discussion at the end re acquisition to another part of the document (ie section 3.1).

>>>> I think that this can be removed.

Agreed.
The idea of "prioritizing the CDNI work" is also introduced in the cdni-requirements anyways.

>>>> Personally I don't see value in this section right now, others may do.

Move to an appendix, as a snapshot of the state of affairs at a given point it time?
Not essential to the document, but possibly useful background material to some.

> If we want to point to specific work that could be reused or may be directly relevant to the work on CDNI in IETF then relevant references to work by other bodies is already captured in the Gap Ana…

Agreed this part shoudl stay in.

>>>>> I don't have anything additional that is not already covered elsewhere, use-cases I-D for example.

I am not aware of additional stuff needed either.

Cheers

Francois

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Wed, 27 Jul 2011 12:40:24 -0700

My comments below.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur (flefauch)
Sent: Friday, July 08, 2011 7:13 AM
To: Grant Watson; Niven-Jenkins Ben
Cc: [email-masked]
Subject: Re: [CDNi] Progressing the CDNI Problem Statement

(Individual hat on)

On 8 Jul 2011, at 15:26, <[email-masked]> wrote:

> 1) Are the set of protocols (request routing, metadata, logging and
control) listed in the problem statement sufficient to implement CDNI?
Does the problem statement describe them in sufficient detail (bearing
in mind that it is only a problem statement and not a
framework/specification and so doesn't need to be exhaustive in its
description)?
>>>> I think this is sufficient, in terms of detail I think there is
sufficient considering the context of the document.

Agreed.

One minor point on the editorial side: the charter has converged on a
terminology of "interfaces" ("CDNI request-routing interface",  "CDNI
metadata interface",  "CDNI logging interface" and "CDNI control
interface"), so the problem statement needs to align to that of course.

KL> Agree that coverage is sufficient.

> 2) Is it necessary to retain the "Non-Goals for IETF" section as the
scope of the work the WG will undertake (and the areas the WG will not
undertake) is now documented in the WG's charter?
>>>> I think that this is on the one hand repetition but perhaps it adds
value to hold this (at least from a HL) in this document should it be
used as a landing-point to understand CDNI?

I could go either way.
If you keep it in, there is a small theoretical risk that it becomes
incorrect and in conflict with the charter in case the charter evolves
in the future to expend/reduce its scope.
On the positive side it provides a useful discussion on why
"acquisition" is out of scope, which is the question that has been
raised many times.
My suggestion would be to:
	* remove the section and the list of excluded items (since it is
in the charter) 
	* move the discussion at the end re acquisition to another part
of the document (ie section 3.1).

KL> I like having the description in the document.  People typically
don't reference the WG charter when reading specifications.  Also
charters do change over time.  The section provides some context for
consideration at the time of documentation.  Perhaps rename section to
"Out of Scope"?

> 
> 3) Is it necessary to retain the "Prioritizing the CDNI Work" section
as the priority of the work of the WG is now documented in the WG's
charter and milestones?
>>>> I think that this can be removed.

Agreed.
The idea of "prioritizing the CDNI work" is also introduced in the
cdni-requirements anyways.

KL> I agree with removing section.  Prioritization should belong in the
requirements document.

> 
> 4) Is it necessary to retain the sections on related standardisation
and research projects as the ongoing work in other bodies is always a
"moving target" and attempting to keep an up to date description could
be challenging and will almost certainly become out of date pretty
rapidly and therefore it may not be worthwhile trying to capture that
material within an RFC?
>>>> Personally I don't see value in this section right now, others may
do.

Move to an appendix, as a snapshot of the state of affairs at a given
point it time?
Not essential to the document, but possibly useful background material
to some.

> 
> If we want to point to specific work that could be reused or may be
directly relevant to the work on CDNI in IETF then relevant references
to work by other bodies is already captured in the Gap Analysis (section
6.3).

KL> I like having the references to other work in the spec.  I agree
with moving to appendix as reference of the snapshot of status.

> 
> 5) Are there any significant gaps or additional topics not present in
the current document that people think need to be covered by additional
sections/text prior to the document being ready for publication?

KL> I don't see anything significant missing.  Overall, the draft looks
to be in good shape.  Here are my comments on ver-02:

1. Spec consistency.  "end users" should be "End Users" in document
(e.g. Abstract, Intro sections)
2. Spec consistency. "CDN Interconnection" vs "CDN Interconnect".
Currently used interchangebly.
3. Sect 1 Intro: Typos for Section 6 and Section 7 in the last sentence
4. Spec consistency. "Pre-Position" to "Pre-position"
5. Sect 1.1 Terminology: typo "indepedent" to "independent"
6. In context of CDNI ... "CDN acquires distribution metadata for
content".  Technically, this is "CDNI Metadata" for content.  
7. "CSP's Service" to "CSP's service"
8. "Dedicated content applications" to "dedicated content applications"
9. "connectivity/services to Users" to "connectivity/services to End
User"
10. Extra space in "a Logging System and a CDN control system ."
11. Should the term "Authoritative CDN" (reference later in sect 3.2) be
included in section? I think it's valuable to have term that can be used
by CDNI specs.
12. Should the term "Cascaded CDNs" be included?
13. "Iterative" and "Recursive" Request Routing should be included?  In
general, all terms relevant to CDNI should be located in one spec.
13. "user agent" to "User Agent"
14. Sect 3 CDNI Model Figure: CDNI protocol -> CDNI interface.  An
interface may have served by multiple protocols.
15. Typo "CDNI Metatdata" to "CDNI Metadata"
16. Missing Control to Surrogate interface, marked as out of scope
(e.g., content removal)
17. Need Request Interface from dCDN Surrogate to uCDN Req-Routing (e.g.
cache miss on dCDN)?
18. Sect 3.1 Candidate CDNI: "protocol" to "interface"
19. Typo "Pre-postioned"
20. Sect 3.2 Non-Goals: Editorial nit, should be "Internal CDN Protocols
(i.e. protocols within one CDN)"
21. Sects 4.3-4.6: "API" to "Interface"
22. Sect 4.4 CDNI Metadata: "element of the Metadata protocol" to
"element of the CDNI Metadata protocol"
23. Sect 4.6 CDNI Control: "Allow the downstream CDN to communicate
information about its delivery capabilities, resources and policies".
Is this part of Request Routing Interface?  These are parameters that
are needed by Request Routing System.
24. Sect 6.3 Gap Analysis: Remove or update "<TODO>" bullet.

Kent