Re: [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02

[Sheng Jiang <[e-mail]>]

>I think that if the device wants a PA, it should supply an IA_PA in
>its Solicit.  The device needs to specify an IAID.  An ORO is
>insufficient.

Hi, Andre,

You are right that ORO is insufficient here. In the latest modification, we have removed ORO model. The client needs to include an IA_PA with IAID specified. There is no prefix announcement/advertise model in the current draft anymore.

Best regards,

Sheng


>On Tue, Aug 14, 2012 at 8:12 PM, Sheng Jiang <[e-mail]>
>wrote:
>>
>> >-----Original Message-----
>> >From: Sheng Jiang [mailto:[e-mail]]
>> >Sent: Monday, August 13, 2012 1:05 PM
>> >To: Gaurav Halwasia (ghalwasi); Ted Lemon; dhc WG
>> >Subject: RE: WGLC: draft-ietf-dhc-host-gen-id-02
>> >
>> >Hi, Gaurav,
>> >
>> >Thanks for your carefully review. Reply in lines. With all your comments
>> >addressed, would you support this document forward?
>> >[Gaurav] Certainly. I support the document forward.
>> >
>> >>I like the idea but I do have few comments:-.
>> >>
>> >>1.) Abstract does not seems clear to me.
>> >>This document introduce a procedure for configuring hosts' IPv6
>> >>   address which the prefix is assigned from a DHCPv6 server through
>> >>   DHCPv6 protocol while the interface identifiers are independently
>> >>   generated by the hosts.
>> >
>> >Reworded: This document introduces a new DHCPv6 procedure to
>configure
>> >hosts' IPv6 addresses. In this new procedure, the prefix is advertised from
>a
>> >DHCPv6 server through DHCPv6 protocol while the interface identifiers are
>> >independently generated by the hosts.
>> >
>> >>2.) Section 1 . Introduction. Change "host-genarated" to
>"host-generated"
>> >>3.) Section 1 . Introduction. Change "separats" to "separates"
>> >>4.) Section 1 . Introduction. Change "ingerface identifiers" to
>> >>"interface identifiers"
>> >
>> >All changed.
>> >
>> >>5.) Section 4.  This section talks about the new IA_PA option but does
>> >>not explicitly say that this option needs to be inserted in SOLICIT
>message.
>> >
>> >Have added a sentence for this. However, this is only a MAY. "A host MAY
>> >include a Option Request Option in a Solicit or Request message to request
>a
>> >IA_PA explicitly." The prefix assignment could be in advertise model. It is
>not
>> >necessary that a host request a IA_PA.
>> >[Gaurav] I don't understand this part completely. So you are saying that
>host
>> >can send "DHCP REQUEST" message as well instead of SOLICIT.? Can you
>> >please elaborate it in detail.
>>
>> <Sheng>Yes. After discovery a DHCPv6 server with solicit message, a host
>can use a Request message to request prefix assignment by include a IA_PA,
>instead of IA_NA or IA_TA. The server then return prefix information rather
>than address. In our understanding, this procedure is one way of address
>configuration, not other information.
>>
>> Oops... With this, it seems we update RFC3315 a little bit. Maybe we should
>include an update header in the document.
>>
>> The above sentence needs a little bit revise: "A host MAY include a Option
>Request Option in a Solicit or IA_PA in a Request message to request a prefix
>assignment explicitly."
>>
>> When the prefix assignment in advertise model, even if a host does not
>request, DHCPv6 server can push it initiatively.
>>
>> >>6.) As this procedure is indeed "state less" from the DHCPv6
>> >>perspective, why don't we want to use "Information-Request" message
>> >>instead of SOLICIT from the host.?
>> >
>> >Request message is possible, too. See the above new sentence.
>> >
>> >[Gaurav] I was referring to "Information-Request(11)" message not
>> >"Request(3)"
>>
>> As explained above, we think this procedure is address associated. So,
>Request is more proper.
>>
>> Sheng
>>
>> >>7.) What should the host do after timers expire.? And is the DHCPv6
>> >>RECONFIGURE message supported for this option type. I think this should
>> >>be clarified in the draft.
>> >
>> >Have added two sentences in Section 4 to describe the potential follow up
>> >operation:
>> >
>> >When the host reaches T1 or T2 defined in Section 5.1, it SHOULD use the
>> >same message exchanges, as described in section 18, "DHCP
>Client-Initiated
>> >Configuration Exchange" of [RFC3315], to obtain or update prefix(es) from
>a
>> >DHCPv6 server.
>> >
>> >A DHCPv6 server MAY initiatively send a reconfiguration message to the
>host,
>> >as described in section 19, "DHCP Server- Initiated Configuration
>Exchange"
>> >of [RFC3315], to cause prefix(es) information update.
>> >
>> >Best regards,
>> >
>> >Sheng
>> >
>> >>Thanks,
>> >>Gaurav
>> >>
>> >>-----Original Message-----
>> >>From: [e-mail] [mailto:[e-mail]] On
>> >Behalf
>> >>Of Ted Lemon
>> >>Sent: Monday, August 13, 2012 7:35 AM
>> >>To: dhc WG
>> >>Subject: [MARKETING] [dhcwg] WGLC: draft-ietf-dhc-host-gen-id-02
>> >>
>> >>The authors have requested a working group last call for this draft.
>The
>> >>draft provides a mechanism whereby the DHCP server can indicate to the
>> >>DHCP client which prefix it should use for autoconfiguration, for instance
>for
>> >>CGA address generation.   This draft has been hanging around for a
>while,
>> >>and could definitely use more eyes on it.   Please take the time to
>review it;
>> >>if you think it's a good idea, please indicate your support for advancing
>the
>> >>draft.   If you think it's a bad idea, please indicate that you do not
>support
>> >>advancing it.   If you have comments, they would be very much
>> >appreciated.
>> >>
>> >>We will determine consensus on August 27.
>> >>
>> >>_______________________________________________
>> >>dhcwg mailing list
>> >>[e-mail]
>> >>https://www.ietf.org/mailman/listinfo/dhcwg
>> >>_______________________________________________
>> >>dhcwg mailing list
>> >>[e-mail]
>> >>https://www.ietf.org/mailman/listinfo/dhcwg
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
>
>--
>Andre Kostur