Re: [multrans] Proposed organization of requirements document

[<[e-mail]>]

Dear all,

Apologies for the late reply. Thanks to Tom for his comments. A couple of preliminary responses from my side in the text below. 

[snip]

I'll mention that I have many purely editorial comments at the micro level (e.g., better ways to say some things in English, spelling out of acronyms and abbreviations on first use). Christian, you can advise me on the form in which you want to see this: as an XML file, by marked-up text, or whatever.

CJ: marked-up text is fine.

My primary concern is that the current organization lacks focus because it considers the delivery infrastructures without separating the concerns posed by source and group address acquisition, interworking and forwarding of control messages, and distribution of content. In addition, requirements seem to be scattered through the document rather than grouped in one place.

Just looking at the table of contents, I have these proposals:

a) Instead of 2. Discussion, you should have 2. Service Requirements. 
This is the part the operator owns.

CJ: Section 2 is meant to introduce the problem. I would keep it as is (possibly revisiting some of the text). As for the service requirements, I agree with you that we need to be as explicit as possible and group all these requirements into a dedicated section. My feeling is that the logic of (1) introducing the issue, (2) further elaborating on the issue by means of various use cases and then (3) deriving requirements accordingly makes sense, and I would suggest we keep this organization in mind.

b) 4.1 Fast Zapping, 4.5 SLA Considerations, 4.6 Load Balancing, and 4.7 Bandwidth Consumption should all be moved into the Service Requirements section. If there is material there that belongs in later sections it can be extracted and moved.

CJ: agreed.

c) Section 4 should be organized into three subsections:
    -- Group and Source Discovery Considerations
    -- Control Signalling and Multicast Tree Computation
    -- Content Distribution
The benefit of doing this is that features common to the various use cases may emerge where they do not at present because grouping everything together makes every case seem to be unique.

CJ: I agree with this taxonomy which is currently somewhat reflected by sections 4.2 to 4.4.

d) Within these subsections, the implications of the different use cases should be explored. That probably means grabbing some of the content from Section 3.

CJ: agreed. If I understand correctly, you're suggesting that the use cases section should be limited to a description of the use cases themselves, while the accompanying analysis (e.g. tables of figures 3 and 4) should be moved to the above Section 4 as an elaboration of the different subsections - correct? If so, I support this approach.

Fellow co-authors, in light of the above comments, I'd like to suggest we revisit the draft organization accordingly, targeting the first half of May for the publication of the updated version - please advise.

In the meantime, I also invite Tom (and others) to detail their comments.

Cheers,

Christian.


********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************