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

[<[e-mail]>]

Dear Tim,

I agree with you an update note is needed to be added to the draft for 3306 and 3956. The consequence of this change, and in order to accommodate future extensions, I have changed also the text for ASM mode to reserve a bit and not a prefix. I see this as an incentive for applications to check the bit and not match a prefix.

For the SSM mode, I maintained the same /96 as in -03.

I will submit a new version with these new changes (+ other minor modifications).

Thanks.

Cheers,
Med


________________________________
De : [e-mail] [mailto:[e-mail]] De la part de Tim Chown
Envoyé : mardi 21 août 2012 18:09
À : [e-mail]
Objet : Re: [MBONED] draft-ietf-mboned-64-multicast-address-format-03.txt

On 21 Aug 2012, at 03:42, Jacni Qin <[e-mail]<mailto:[e-mail]>> 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, 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.

In response to Behcet's email, I agree the update(s) is/are implicit.

Tim