> I note that the descriptions for the 'suboption-zone-index'
> and 'z-bit' in Section 2 say that if the z bit is present,
> the zone-index field is inserted between prefix-len and prefix.
> This does not appear to be borne out by the diagram. I assume
> the text was not updated when the format was changed.
Ops. Thank you for pointing out.
> Also, the 'suboption-len' field "specifies the length of
> the suboption fields in bytes". If there is the desire to
> potentially include multiple suboptions, this will not be
> sufficient, because you have no way of telling them apart.
> If this option is to have sub-options, then they should be
> formatted as in other options that have sub-options: each
> sub-option prefixed by a code and a length.
This was intended to be skipped when a new option was defined
other than the suboption-zone-index and an old implementation
does not know how to deal with it.
I agree that normal suboption style should be better.
I'll change it that way, if we agree on it.
> As for the prefix, I think it should follow the same form as
> in the IA_PD Prefix option [RFC-3633 section 10]. That is, a
> single octet indicating prefix length in bits, followed by a
> fixed-length 16 octet address. Having a variable-length address
> complicates implementation, especially when the length field
> unit is bits, not octets. It would require server implementers
> to write custom code simply to handle the option usefully,
> where there already exists code to handle the form used in
> the IA_PD Prefix option.
hmmmm, it is clearly trade-off.
We do not expect a lot of prefixes for IA_PD option, but
we can expect more than ten options are included to deliver
the policy table.
> Finally, I'm not sure I see the need for the "z-bit", since
> the zone-index is at the end. You don't need it to indicate
> the presence of zone-index, since you easily see if zone-index
> is present while parsing the packet, regardless of whether
> it is a sub-option, or just an optional 32-bit value at the
> end (and there are no other sub-options).
As far as the z-bit is the only bit, we do not need it.
> - Matt
> On Nov 9, 2011, at 00:21 , Arifumi Matsumoto wrote:
>> at Quebec, Tim Chown presented about address selection documents
>> discussed in 6man WG, and requested reviewers for the draft
>> slides are http://tools.ietf.org/agenda/81/slides/dhc-13.pdf >>
>> IIRC, one reviewer was chosen at that time, and the other was left
>> So, my questions are
>> the review was submitted somewhere ?
>> the other reviewer was chosen ?
>> Arifumi Matsumoto
>> NGN System Architecture Project
>> NTT Service Integration Laboratories
>> E-mail: arifumi@... >> TEL +81-422-59-3334 FAX +81-422-59-6364
>> dhcwg mailing list
>> dhcwg@... >> https://www.ietf.org/mailman/listinfo/dhcwg >
NGN System Architecture Project
NTT Service Integration Laboratories
E-mail: arifumi@... TEL +81-422-59-3334 FAX +81-422-59-6364