Re: [multrans] Proposed organization of requirements document

[Jacni Qin <[e-mail]>]

Dear all,

Please see inline below,

On Mon, Apr 18, 2011 at 4:04 PM, <[e-mail]>wrote;wrote:

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

Jacni>: There is a slight difference between the Problem and the Service
Requirements. So maybe we can split it into two sub-sections and filled them
accordingly.


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

Jacni>: +1


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

Jacni>: Yes, we can reorganize the Section 4 and leave the functional
requirements in it.


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

 Jacni>: I revised the Use Cases a little, based the discussion during the
meeting. Please check the slides attached. I can convert it xml format
later.


Cheers,
Jacni


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