Re: [multrans] Proposed organization of requirements document

[Tina Tsou <[e-mail]>]

Hi Jacni,
Thanks. That was just double check.
 
 
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: Wednesday, April 20, 2011 8:52 AM
To: Tina Tsou
Cc: [e-mail]; Tom Taylor; Lee, Yiu; BOUCADAIR
Mohamed OLNC/NAD/TIP; [e-mail]
Subject: Re: Proposed organization of requirements document
 
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.