Subject: Re: [dhcwg] Review of draft-ietf-6man-addr-select-opt-01

From: Arifumi Matsumoto <[email-masked]>
Date: Wed, 15 Feb 2012 20:59:04 +0900

Hi,

I'm sorry for replying late.

I compiled the revision of this document.
This version hopefully captures the comments from two reviewers in dhcwg.

You can find it here.
http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-02

On 2011/12/02, at 1:29, jouni korhonen wrote:

> 
> Hi,
> 
> I promised to make a review of this I-D. My comments can be found here:
> http://deadcoderssociety.net/6man.pdf
> 
> There are two main things:
> 1) I suggest to remove all text that references into the future regarding ongoing work etc. That will look a bit weird when actual RFCs come out etc.

About this point, I see several RFCs that refer to internet drafts.
Do we really need to remove all the refereces for i-ds ?

Thanks !

> 2) It is not clear what happens when DASP_OPTION is received from multiple sources and in all cases Section 4.2. "trust" requirements are met. Will the last received policy overwrite all previously learned?
> 
> Also I did not quite get the "leak of privacy information". Could you elaborate that a bit further in the I-D. And finally, regarding the prefix encoding in the option I would myself prefer 1 octet granularity over 4.. or is there a specific reason for selecting 4? (DHCPv6 options do not have alignment requirements)
> 
> - Jouni
> 
> On Nov 9, 2011, at 10:21 AM, Arifumi Matsumoto wrote:
> 
>> All,
>> 
>> at Quebec, Tim Chown presented about address selection documents
>> discussed in 6man WG, and requested reviewers for the draft
>> draft-ietf-6man-addr-select-opt-01.
>> 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
>> undecided.
>> 
>> 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: [email-masked]
>> TEL +81-422-59-3334 FAX +81-422-59-6364
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> 

--
松本 存史 <[email-masked]>
 NTTサービスインテグレーション基盤研究所
 次世代ネットワーク方式SEプロジェクト
  ネットワークアーキテクチャグループ
  TEL 0422-59-3334  FAX 0422-59-6364

---

From: Matthew Ryan <[email-masked]>
Date: Wed, 15 Feb 2012 10:38:29 -0800

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.

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.

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.

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

 - Matt

---

From: jouni korhonen <[email-masked]>
Date: Wed, 15 Feb 2012 22:44:50 +0200

Hi,

> Do we really need to remove all the refereces for i-ds ?

I mainly mean text formulation such in abstract that says:
   "While RFC 3484 is in the process of being updated, .."
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You still can have references to in progress work, no problem with that. 

- Jouni

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 16 Feb 2012 11:32:10 +0900

Jouni,

I got it.
Thanks !

---

From: Arifumi Matsumoto <[email-masked]>
Date: Thu, 16 Feb 2012 11:35:34 +0900

All,

I failed to mention that I hope this version will be
used for WGLC at dhcwg from the dhcwg perspective,
followed by WGLC at 6man.

Thanks.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Tue, 21 Feb 2012 11:20:53 +0900

Matthew,
thank you for looking at it.

> the text was not updated when the format was changed.

Ops. Thank you for pointing out.

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

> where there already exists code to handle the form used in

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.

> end (and there are no other sub-options).

I understand.
As far as the z-bit is the only bit, we do not need it.

Kindest regards,