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

[Bharat Joshi <bharat_joshi at infosys.com>]

Hi Leo,

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

Thanks,
Bharat

On 24/03/2009 11:17, "Bharat Joshi" <bharat_joshi at infosys.com> 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.
> 

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

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

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

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

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.

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

This looks good to me.

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