Re: [multrans] Proposed organization of requirements document

[Jacni Qin <[e-mail]>]

Re-,

On Wed, Apr 20, 2011 at 1:19 AM, Tina Tsou <[e-mail]> wrote:

> Hi Jacni et al,
>
> Would dual stack and IPv6 only case be covered?
>

Jacni>: I guess these have been mentioned in the current text, the problems
of dual stack model for mcast and, IPv6 only cases are covered in
"Mono-Stack" section. Sorry, what's your point? You propose to remove it?


Cheers,
Jacni


>
>
>
>
> We keep our promises with one another – no matter what!
>
>
>
> Best Regards,
>
> Tina TSOU
>
> http://tinatsou.weebly.com/contact.html
>
>
>
> *From:* Jacni Qin [mailto:[e-mail]]
> *Sent:* Tuesday, April 19, 2011 9:37 AM
> *To:* [e-mail]
> *Cc:* Tina Tsou; Tom Taylor; Lee, Yiu; BOUCADAIR Mohamed OLNC/NAD/TIP;
> [e-mail]
>
> *Subject:* Re: Proposed organization of requirements document
>
>
>
> Dear all,
>
> Please see inline below,
>
> On Mon, Apr 18, 2011 at 4:04 PM, <[e-mail]>
> 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.
>
>
>
>
>