Re: [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt

On 8/22/2012 Wednesday 12:09 AM, Tim Chown wrote:
> On 21 Aug 2012, at 03:42, Jacni Qin <jacni@jacni.com 
> <mailto:jacni@jacni.com>> wrote:
>
>> Hi Tim,
>>
>> On 8/21/2012 Tuesday 6:39 AM, Tim Chown wrote:
>>> I think the same applies to RFcC3956 too, as bits 17-20 are reserved, and you're using those.  Actually also nteresting to read Appendix A of that RFC ;)
>> I guess we won't need a "RFC3956 updated", since Appendix A just says, "
>>     Instead of using flags bits ("FF70::/12"), one could have used the
>>     leftmost reserved bits instead ("FF3x:8000::/17").
>> "
>> and doesn't say anything about the 4bit rsvd elsewhere.
>>
>> Or I misunderstand it?
>
> I'm not sure what the proper process is here.  My point was just that 
> RFC3956 states that bits 17-20 are reserved,
The 3956 doesn't really make that statement on the 4 bits itself, 
instead, more like inheriting from 3306.
While I don't think this issue matters that much technically, we can 
follow a proper process if anyone have one.

> but the proposed range of addresses used by this draft involves 
> setting a bit within that range, hence we should have an "updated by" 
> note.  Also that RFC3956, unlike RFC3306, doesn't explicitly say the 
> reserved bits must be set to zero.
>
> The irony of Appendix A of RFC3956 is that it mentioned that one could 
> have used precisely the same range of addresses for Embedded-RP as is 
> proposed for this draft, but instead a flag bit was used.
So, following this logic, we'll be perfectly fine using a flag. ;-)


Cheers,
Jacni

>
> In response to Behcet's email, I agree the update(s) is/are implicit.
>
> Tim
>
>
>
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned