Subject: Re: [MBONED] Fwd: I-D Action:draft-ietf-mboned-rfc3171bis-06.txt

From: Alfred Hönes <[email-masked]>
Date: Mon, 23 Mar 2009 20:51:25 +0100 (MEZ)

Hello all,

> Today, Marshall Eubanks wrote:
>
> We regard this draft as now ready to go to the IESG, and will
> so announce in session today.
>
> I plan to do this after the close of this week (after Friday).
> Please consider this as a informal "mini-last call" to make
> sure that all of the issues raised were addressed.
>
> Regards
> Marshall

I had raised an (IMHO) important technical issue for the -05 version
of the rfc3171bis draft and now see it has _not_ been addressed.

!  The only significant sub-topic left open in the -05 draft version
!  is the remaining (single) gap in the multicast address space covered
!  by the table in Section 3; for completeness and clarity, the tagged
!  line shown below should be inserted at the indicated place:
!
!  ----snip----
!   224.2.0.0 - 224.2.255.255     (/16)      SDP/SAP Block
!  |
!  |224.3.0.0 - 224.251.255.255   (249 /16)  RESERVED
!  :
!  :224.252.0.0 - 224.255.255.255 (/14)      RESERVED
!  ----snip----
!
!  Or is this address range designated for other purposes?
!
!  The third range is the ex "DIS Transient Groups" range returned
!  to IANA. If the missing long range shall remain in the RESERVED
!  state, conceivably the latter two ranges could be joined:
!
!  ----snip----
!   224.2.0.0 - 224.2.255.255     (/16)      SDP/SAP Block
!  |
!  |224.3.0.0 - 224.255.255.255   (253 /16)  RESERVED
!  ----snip----

For reference, please see:

  http://www.ietf.org/mail-archive/web/mboned/current/msg00779.html
  http://www.ietf.org/mail-archive/web/mboned/current/msg00780.html

for the original message (including other minor issues as well)
and Michelle's call for comments on the list.
Browsing the MBONED list archive, I unfortunately could not find
any follow-up messages filed there;
thus, the flaw should not be blamed to the draft authors.

++++>>  WG, please take care of this gap and advice the authors.
++++>>  Thanks!

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 23 Mar 2009 13:34:38 -0700

As part of the mini-last call Marshall just announced in the WG meeting here in San Francisco, we need to sort this out now.
Can someone let us know if something needs to be done regarding the gap Alfred describes?  This needs to be sorted out before Friday so that Marshall can submit to the IESG.

Thanks!

Michelle
IANA

On 3/23/09 12:51 PM, "[email-masked]" <[email-masked]> wrote:

Hello all,

Kind regards,
  Alfred HÎnes.

--

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 23 Mar 2009 14:12:58 -0700

Bill Fenner and I (Michelle Cotton) will sit down in the next couple days and make sure that what is in the table in the document and what appears in the registry matches up perfectly.  I will send the result to the list in the next day or so....

Michelle

On 3/23/09 1:34 PM, "Michelle Cotton" <[email-masked]> wrote:

Thanks!

Michelle
IANA

Hello all,

Kind regards,
  Alfred HÎnes.

--

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 25 Mar 2009 11:47:56 +0530

Hi Michelle,

       I hope I am not too late to take a look at this draft. Overall it looks pretty good. I have few questions and suggestions on this.

• In section 3, in the table, it will be better if we either use number of multicast addresses available fo use or '/x' method to represent the size of a given block.

• In section 5.1, s/for protocol control that/for protocol control traffic that/

• In section 9.2, in the following line "Addresses within this block MUST NOT appear on the public Internet.". Are we talking about the AD-HOC Block II when we say 'this block'? I think not. Can we clarify this?

• In section 12.2, A small typo in "temporary assignment or the addresses assigned", 'or' -> 'of'

• In section 12.2, after the one month period, can the registrant who was using these addresses, get allocated these addresses again? It is mentioned that this won't be available for one calender year but as it is not being used by anyone so can the last registrant can get it before this period ends.

Thanks,
Bharat
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Michelle Cotton [[email-masked]]
Sent: Tuesday, March 24, 2009 2:04 AM
To: [email-masked]; Leo Vegoda; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MBONED] Fwd: I-D Action:draft-ietf-mboned-rfc3171bis-06.txt

Thanks!

Michelle
IANA

Hello all,

Kind regards,
  Alfred HÎnes.

--

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 25 Mar 2009 14:56:55 -0700

Hi Bharat,

On 24/03/2009 11:17, "Bharat Joshi" <[email-masked]> wrote:

[...]

> ? In section 3, in the table, it will be better if we either use number of
> multicast addresses available fo use or '/x' method to represent the size of a
> given block.

We've tried to use CIDR slash notation where the address range is a single
prefix. However, where the range is not a single prefix we have used the
number of individual addresses in the range rather than using a series of
ever smaller CIDR prefixes. For example, we have:

224.0.2.0 - 224.0.255.255     (65024)    AD-HOC Block I

Whereas, if we used multiple prefixes it would be:

224.0.2.0 - 224.0.255.255     (/17,/18,/19,/20,/21,/22,/23)    AD-HOC Block
I

The latter obviously has line length issues, which makes it awkward for use
in a table. I realise that the table uses two different mechanisms for
showing the same thing but had hoped that it was a reasonable compromise
between readability and brevity.

> ? In section 5.1, s/for protocol control that/for protocol control traffic
> that/

I'm happy to make this change if no-one else minds. It's in section 5 rather
than 5.1, though.
 
> ? In section 9.2, in the following line "Addresses within this block MUST NOT
> appear on the public Internet.". Are we talking about the AD-HOC Block II when
> we say 'this block'? I think not. Can we clarify this?

Can you please suggest alternative wording to achieve the effect you would
like? Or if you think it is just the location of the statement, I suppose we
could create a section 9.2.1 to add clarity.

> ? In section 12.2, A small typo in "temporary assignment or the addresses
> assigned", 'or' -> 'of'

Good catch. Thanks.

> ? In section 12.2, after the one month period, can the registrant who was
> using these addresses, get allocated these addresses again? It is mentioned
> that this won't be available for one calender year but as it is not being used
> by anyone so can the last registrant can get it before this period ends.

I think that sounds reasonable. The reason for the quarantine is to try and
minimise the chance of a later user of the address space having problems
with side effects from a previous user's use. In this case, that seems not
to be a problem.

What do people think about this change:

"Addresses returned to the IANA when a temporary assignment ends MUST NOT be
assigned to anyone other than the last registrant for at least one calendar
year."

Best regards,

Leo Vegoda

---

From: Bharat Joshi <[email-masked]>
Date: Thu, 26 Mar 2009 09:37:06 +0530

Hi Leo,

     Thanks for your response. Please see my response in line.

Thanks,
Bharat

> between readability and brevity.

I think if other people are fine with it, let us leave it like this.

> I'm happy to make this change if no-one else minds. It's in section 5 rather

Actually just the previous section use 'control traffic' and so I suggested.

> could create a section 9.2.1 to add clarity.

I think 'this block' in this statement is meant for 233.252.0.0/24 and not the whole AD-HOC Block II. If my understanding is correct, it is just the location of this statement. Some how we need to clarify that this statement is just for this block of addresses and not for full AD-HOC Block II.

> assigned to anyone other than the last registrant for at least one calendar

This looks good to me.