Subject: [multrans] Comments on draft-jaclee-behave-v4v6-mcast-ps-01

From: Tom Taylor <[email-masked]>
Date: Sat, 9 Apr 2011 13:43:33 -0400

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.

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.

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.

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.

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.

Tom

---

From: <[email-masked]>
Date: Mon, 18 Apr 2011 10:04:41 +0200

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.

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

---

From: Jacni Qin <[email-masked]>
Date: Tue, 19 Apr 2011 09:37:13 +0800

Dear all,

Please see inline below,

On Mon, Apr 18, 2011 at 4:04 PM, <[email-masked]>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.
>
> 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.
>
> 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.

> section. If there is material there that belongs in later sections it can be
> extracted and moved.
>
> CJ: agreed.
>

Jacni>: +1

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

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

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

---

From: Tina Tsou <[email-masked]>
Date: Wed, 20 Apr 2011 01:11:42 +0800

Hi all,
Comments:
1) Do we need to include deployment scenarios?
2) Do we need to cover mVPN?
3) Do we need to list the work items that cannot be solved only in
PIM/MBONED/SOFTWIRE/BEHAVE?

We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From: Jacni Qin [mailto:[email-masked]] 
Sent: Tuesday, April 19, 2011 9:37 AM
To: [email-masked]
Cc: Tina Tsou; Tom Taylor; Lee, Yiu; BOUCADAIR Mohamed OLNC/NAD/TIP;
[email-masked]
Subject: Re: Proposed organization of requirements document
 
Dear all,

Please see inline below,
On Mon, Apr 18, 2011 at 4:04 PM, <[email-masked]>
wrote:
Dear all,

[snip]

Jacni>: +1

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

Cheers,
Jacni

Cheers,

Christian.

---

From: Tina Tsou <[email-masked]>
Date: Wed, 20 Apr 2011 01:19:57 +0800

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

Best Regards,
Tina TSOU

Dear all,

Please see inline below,

[snip]

Jacni>: +1

Cheers,
Jacni

Cheers,

Christian.

---

From: Jacni Qin <[email-masked]>
Date: Wed, 20 Apr 2011 08:51:57 +0800

Re-,

> 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
>
> *From:* Jacni Qin [mailto:[email-masked]]
> *Sent:* Tuesday, April 19, 2011 9:37 AM
> *To:* [email-masked]
> *Cc:* Tina Tsou; Tom Taylor; Lee, Yiu; BOUCADAIR Mohamed OLNC/NAD/TIP;
> [email-masked]
>
> *Subject:* Re: Proposed organization of requirements document
>
>
>
> Dear all,
>
> Please see inline below,
>

---

From: Tina Tsou <[email-masked]>
Date: Thu, 21 Apr 2011 07:11:56 +0800

Hi Jacni,
Thanks. That was just double check.

Best Regards,
Tina TSOU
 
From: Jacni Qin [mailto:[email-masked]] 
Sent: Wednesday, April 20, 2011 8:52 AM
To: Tina Tsou
Cc: [email-masked]; Tom Taylor; Lee, Yiu; BOUCADAIR
Mohamed OLNC/NAD/TIP; [email-masked]
Subject: Re: Proposed organization of requirements document
 
Re-,

Cheers,
Jacni

 
Best Regards,
Tina TSOU

 
Dear all,

Please see inline below,

[snip]

Jacni>: +1

Cheers,
Jacni

Cheers,

Christian.