Subject: [MBONED] Fwd: http://www.ietf.org/internet-drafts/draft-cotton-v4mcast-guideline s-00.txt

From: Marshall Eubanks <[email-masked]>
Date: Sun, 10 Feb 2008 10:02:33 -0500

This is really 3171bis, and will be renamed appropriately in due course.

>
> http://www.ietf.org/internet-drafts/draft-cotton-v4mcast- 
> guidelines-00.txt
>

I would appreciate comments and also feedback about adopting this as  
a WG item. Thanks
to Michelle and Leo for putting this together.

Regards
Marshall

_______________________________________________
MBONED mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mboned

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 10 Feb 2008 10:02:33 -0500

Regards
Marshall

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 10 Feb 2008 18:48:02 -0500

> -----Original Message-----
> From: Marshall Eubanks [mailto:[email-masked]] 

> > http://www.ietf.org/internet-drafts/draft-cotton-v4mcast- 

I'm confused about the extended ad-hoc block.

In Section 9.2, I think it should say that this block now follows the
guidelines of Section 6, not 5. And in Section 3, shouldn't the GLOP
block be reduced in size now, to read 233.0.0.0 to only 233.251.255.255?

Editorial:

11.1

   Occasionally, more than one multicast address is required.  In these
   cases multiple addresses are available.  Where are very large number
   of addresses is required,

Should be "where a very large number ..."

12.2.

   It is occasionally appropriate to make temporary assignments that are
   can be renewed if appropriate.

I'd drop the "are" and replace "if appropriate" with "as necessary."

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 10 Feb 2008 18:48:02 -0500

Editorial:

11.1

12.2.

Bert

---

From: Pekka Savola <[email-masked]>
Date: Mon, 11 Feb 2008 09:02:06 +0200 (EET)

> to Michelle and Leo for putting this together.

It's a good starting point.

The document header should include "Obsoletes: RFC3171".  The BCP 
number of that RFC (51) should be recycled so this document can use 
the same number.  Not sure if a note abou this should be added in some 
section.

The text is messed up; it has no newlines.  This fixes it:

cat draft-cotton-v4mcast-guidelines-00.txt | tr '\r' '\n'

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
______________________________________From [email-masked]  Sun Feb 10 23:00:52 2008
Date: Mon, 11 Feb 2008 09:02:06 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: Marshall Eubanks <[email-masked]>
Cc: [email-masked]
Subject: Re: [MBONED] Fwd:
 http://www.ietf.org/internet-drafts/draft-cotton-v4mcast-guideline s-00.txt
Sender: [email-masked]

> to Michelle and Leo for putting this together.

It's a good starting point.

The document header should include "Obsoletes: RFC3171".  The BCP 
number of that RFC (51) should be recycled so this document can use 
the same number.  Not sure if a note abou this should be added in some 
section.

The text is messed up; it has no newlines.  This fixes it:

cat draft-cotton-v4mcast-guidelines-00.txt | tr '\r' '\n'

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
MBONED mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mboned

_________
MBONED mailing list
[email-masked]

---

From: Dave Price <[email-masked]>
Date: Mon, 11 Feb 2008 11:36:48 +0000

Dear Marshall and All,

	http://www.ietf.org/internet-drafts/draft-cotton-v4mcast-guidelines-00.txt

I have noted in the past (I think once to this list)
that we seem to have "lost" some multicast addresses
in some parts of the document...

The block  224.0.255.1  -> 224.0.255.255
has become lost in one table.....

The Ad-Hoc block
is only shown as going as far as 224.0.255.0
in the table in section 3, and there
has the odd size of  64769 (it says).

This matches to the heading of a table in

http://www.iana.org/assignments/multicast-addresses

for Ad-Hoc block,  but the text
of that table in that document
allocates all the way to   224.0.255.255

224.0.255.000-224.0.255.255 Intelsat IPTV                   [Elad]  31 March 2006

Section 6 of the present document is correct,
but as I comment, I think the table in section 3
of the new document is wrong.

Dave Price

-- 
Dave Price, 
Email: [email-masked] PHONE: +44 1970 622428 FAX: +44 1970 628536
Post: Computer Science, Aberystwyth University,
      Penglais, Aberystwyth, WALES, UK, SY23 3DB.

---

From: Dave Price <[email-masked]>
Date: Mon, 11 Feb 2008 11:36:48 +0000

Dear Marshall and All,

The Ad-Hoc block

Dave Price

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 17 Feb 2008 10:44:07 -0500

I would like to propose a new block, the Local Network Application  
Block, to be carved from the current eGLOP space, and would propose  
allocating 233.255.255/24 to this purpose :

The Local Network Application Block is for assignment of multicast  
addresses for applications that should either be link local or local  
network local, and thus require addresses that should never appear in  
interdomain networking.

I think that such a block is needed as applications do not belong in  
224.0.0/24 - the Local Network Control Block -
and it is not possible to assign them in 239/8.

I would also recommend that the higher order part of 233.255 be kept  
free of assignments to give
this block room to expand downwards if necessary.

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Sun, 17 Feb 2008 10:44:07 -0500

Regards
Marshall

---

From: Pekka Savola <[email-masked]>
Date: Mon, 18 Feb 2008 09:06:28 +0200 (EET)

On Sun, 17 Feb 2008, Marshall Eubanks wrote:
> this block room to expand downFrom [email-masked]  Sun Feb 17 23:06:44 2008
Date: Mon, 18 Feb 2008 09:06:28 +0200 (EET)

> this block room to expand downwards if necessary.

Seems like a good idea; maybe the initial block size could be even 
larger than /24 but if there's room for growth, that's a good start as 
well.

wards if necessary.

Seems like a good idea; maybe the initial block size could be even 
larger than /24 but if there's room for growth, that's a good start as 
well.

---

From: Prashant Jhingran <[email-masked]>
Date: Wed, 20 Feb 2008 18:56:52 +0530

Hi All,

Few comments: 

1-
 As per my understanding, the "225.0.0.0   - 231.255.255.255
7 /8s RESERVED" addresses are the ones which are going to be
widely used for ASM multicast by various multicast content
providers (channels/data-sources). 
Who (whether IANA or someone else) is going to
monitor/provide these addresses to the multicast content
providers because content providers must use unique
addresses for each channel globally.

---

From: Prashant Jhingran <[email-masked]>
Date: Wed, 20 Feb 2008 18:56:52 +0530

Hi All,

Few comments: 

1-

Shouldn't this be clarified?

3-
Section 8.1.  Assignment Guidelines

"Because the SSM model essentially makes the entire
multicast address space local to the host, no IANA
assignment policy is required."

Once again, SSM addresses should also be globally unique and
thus someone should monitor these as well. Shouldn't this be
clarified?

3-
Section 9. GLOP Block (233/8)

Typo "by mapping a domain's autonomous the number"  =>
probably it means "by mapping a domain's autonomous number"

Regards,
Prashant Jhingran

Huawei Technologies India Pvt Ltd
+91 - 80 - 41117676 Ext - 1458
+91 - 9448927814

============================================
"If you have not studied physics you lose out something, 
  but if you have not studied spirituality you lose out on
everything "
 - www.artoflivingresearch.org  
===========================================

This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity
whose address is listed above. Any use of the information
contained herein in any way (including, but not limited to,
total or partial disclosure, reproduction, or dissemination)
by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete
it!

===================EOM===========================

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marshall
Eubanks
Sent: Sunday, February 10, 2008 8:33 PM
To: [email-masked]
Subject: [MBONED]
Fwd:http://www.ietf.org/internet-drafts/draft-cotton-v4mcast
-guideline s-00.txt

This is really 3171bis, and will be renamed appropriately in
due course.

> http://www.ietf.org/internet-drafts/draft-cotton-v4mcast- 

I would appreciate comments and also feedback about adopting
this as  
a WG item. Thanks
to Michelle and Leo for putting this together.

Regards
Marshall

Shouldn't this be clarified?

3-
Section 8.1.  Assignment Guidelines

"Because the SSM model essentially makes the entire
multicast address space local to the host, no IANA
assignment policy is required."

Once again, SSM addresses should also be globally unique and
thus someone should monitor these as well. Shouldn't this be
clarified?

3-
Section 9. GLOP Block (233/8)

Typo "by mapping a domain's autonomous the number"  =>
probably it means "by mapping a domain's autonomous number"

Regards,
Prashant Jhingran

Huawei Technologies India Pvt Ltd
+91 - 80 - 41117676 Ext - 1458
+91 - 9448927814

============================================
"If you have not studied physics you lose out something, 
  but if you have not studied spirituality you lose out on
everything "
 - www.artoflivingresearch.org  
===========================================

This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity
whose address is listed above. Any use of the information
contained herein in any way (including, but not limited to,
total or partial disclosure, reproduction, or dissemination)
by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete
it!

===================EOM===========================

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Marshall
Eubanks
Sent: Sunday, February 10, 2008 8:33 PM
To: [email-masked]
Subject: [MBONED]
Fwd:http://www.ietf.org/internet-drafts/draft-cotton-v4mcast
-guideline s-00.txt

This is really 3171bis, and will be renamed appropriately in
due course.

> http://www.ietf.org/internet-drafts/draft-cotton-v4mcast- 

I would appreciate comments and also feedback about adopting
this as  
a WG item. Thanks
to Michelle and Leo for putting this together.

Regards
Marshall