Content Delivery Networks Interconnection
charter-ietf-cdni-03

[Ballot comment]
The last sentence (a change from the internal review) is now quite odd.  "The working group will accept new work only when the Area Director approves the new work and adds the relevant milestones."  While it is late in the process, I believe this should be corrected.

I agree with that part of Eric Vynke's abstain.

[Ballot comment]
I was on PTO during the first ballot, so, balloting an non-blocking ABSTAIN as it is a little too late to BLOCK on:

The intended status of RFC publication is rather vague as "specification" hints to "proposed standard" but it is only a hint.

`The working group will accept new work only when the Area Director approves the new work` is against the (usual) process of rechartering with the complete IETF community and IESG consensus and not a "act of state" by the AD.

[Ballot comment]
I was on PTO during the first ballot, so, balloting an ABSTAIN as it is a little too late to BLOCK on:

The intended status of RFC publication is rather vague as "specification" hints to "proposed standard" but it is only a hint.

`The working group will accept new work only when the Area Director approves the new work` is against the (usual) process of rechartering with the complete IETF community and IESG consensus and not a "act of state" by the AD.

[Ballot comment]
“The working group will accept new work only when:
* The work falls within the scope described above;
* The Working Group Chairs judge that there is consensus to take on the item; and”

What scoping does this provide?  Why is the required IETF process being restated? All new work always has to fall into the charter’s scope (per bullet point one) and WG chairs also always have to ensure consensus in adopting new work (per bullet point two).

[Ballot comment]
Why are these bullet points required:

* The work falls within the scope described above;
* The Working Group Chairs judge that there is consensus to take on the item; and
* The Area Director approves the new work and adds the relevant milestones.

The first two bullet points always apply to WGs. The third is sort of what an AD does,
so not sure why this needs to be pointed out in the charter?

[Ballot comment]
The CDNI WG has been progressing through it's current charter and this update has been discussed by the WG to clarify the next work items.

[Ballot comment]
My blocking comment used to read...

  We seem to have repeated discussions about what "routing" means
  in the CDNi context. Since the work item here discusses communication
  with the "routing system" w need to be pretty clear what we are talking
  about and, if necessary, nail down the interaction with the Routing Area.

Having read and re-read the charter and the background material, I conclude that it would be addressed by changing

> upstream CDN request routing system

to either

> upstream CDN Request-Routing System

or preferably

> upstream CDN system

---

Shouldn't you have removed the work items that have already been completed?

[Ballot block]
A very easily resolved issue...

We seem to have repeated discussions about what "routing" means in the CDNi context. Since the work item here discusses communication with the "routing system" w need to be pretty clear what we are talking about and, if necessary, nail down the interaction with the Routing Area.

[Ballot block]
We seem to have repeated discussions about what "routing" means in the CDNi context. Since the work item here discusses communication with the "routing system" w need to be pretty clear what we are talking about and, if necessary, nail down the interaction with the Routing Area.

[Ballot comment]
Just to make sure you thought about.

    The working group will focus on the following items:

    - A "problem statement" document providing a description of the problem
      and a common terminology.
 
    - A "use case" document describing scenarios for usage and applications
      of the CDNI solution and protocols.

Well, the WG will not focus on these, since they're done.
If you want to keep track of the documents in the charter, maybe
    After the "problem statement" and "use case" documents, the working
    group will focus on the following items:
   
    ...

Note: the draft-ietf-cdni-requirements-12 will hopefully be approved soon...

[Ballot comment]
Just to make sure you thought about.

    The working group will focus on the following items:

    - A "problem statement" document providing a description of the problem
      and a common terminology.
 
    - A "use case" document describing scenarios for usage and applications
      of the CDNI solution and protocols.

Well, the WG will not focus on these, since they're done.
If you want to keep track of the documents in the charter, maybe
    After the "problem statement" and "use case" documents, the working
    group will focus on the following items

Note: the draft-ietf-cdni-requirements-12 will hopefully be approved soon...

[Ballot comment]
I have no objection to the rechartering, but I do have to note one thing:
I see that the "short timeframe" phrase remains, but there's no longer an estimate of what that timeframe might be.  We have passed the original estimate of 18-24 months, and what we have are problem statement, use cases, and requirements documents.  How close are we to (or how far from) a "targeted, deployable solution" at this point?

[Ballot comment]
I'd like to call particular attention of the SEC and APP areas to the added deliverable for "CDNI URI Signing".

My understanding is that this was discussed between TSV and SEC perhaps a year ago, and the answer was "please write a draft". The working group is likely to consider http://tools.ietf.org/id/draft-leung-cdni-uri-signing-03.txt for adoption to fulfill this deliverable.

Early surprises are best :-)