Subject: Re: [dhcwg] [CGA-EXT] Follow up request for review ofdraft-ietf-csi-dhcpv6-cga-ps

From: Sheng Jiang <[email-masked]>
Date: Thu, 16 Sep 2010 11:08:21 +0800

> >> Your second concern is the big compute job may overload 
> the server. 
> >> True. Actaully, in this draft, we state "The DHCPv6 server 
> could then 
> >> either compute the Modifier by itself, or redirect the computation 
> >> requirement to another server." The second server may be dedicated 
> >> computational server. Again, this draft only lists the 
> possibilities. 
> >> If you want, we can add more analysis on the issues of this 
> >> possibility.
> 
> No, that's not the second issue.  The second issue is whether 
> or not it's appropriate to use DHCP as a way of distributing 
> CPU load.   The analysis I'd like to see of this is a 
> presentation of what other alternatives were considered, and 
> why they were rejected.

I am afraid this is out of the original scope of draft-ietf-csi-dhcpv6-cga-ps. This document is
aiming to only the possible interactions between DHCP and CGA. So, all this document can do is,
first, list the DHCP as a way of distributing CPU load as a possibility and analyze the advantages
and issues. If you want, we may add more text on the issues. It may conclude or suggest that DHCP
is not an appropriate choice. (A question, what is your opinion regarding to that DHCP server plays
a redirect proxy? I think the DHCP protocol is a choice to carry offloading
informations/interactions.) That's all relevant to this document.

Regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Sep 2010 02:39:08 -0700

> informations/interactions.) That's all relevant to this document.

It makes sense that you didn't want to include non-DHCP solutions in a DHCP-specific document.   However, the actual decision process should include an analysis like the one I described. So it would be good if the problem statement mentioned this.   I don't think you can either accept or reject DHCP as a solution without considering other alternatives.

---

From: Sheng Jiang <[email-masked]>
Date: Thu, 16 Sep 2010 18:36:17 +0800

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]] 
> Sent: Thursday, September 16, 2010 5:39 PM
> To: Sheng Jiang
> Cc: [email-masked]; [email-masked]
> Subject: Re: [CGA-EXT] [dhcwg] Follow up request for review 
> ofdraft-ietf-csi-dhcpv6-cga-ps
> 
> > I am afraid this is out of the original scope of 
> > draft-ietf-csi-dhcpv6-cga-ps. This document is aiming to only the 
> > possible interactions between DHCP and CGA. So, all this 
> document can 
> > do is, first, list the DHCP as a way of distributing CPU load as a 
> > possibility and analyze the advantages and issues. If you 
> want, we may 
> > add more text on the issues. It may conclude or suggest 
> that DHCP is 
> > not an appropriate choice. (A question, what is your 
> opinion regarding 
> > to that DHCP server plays a redirect proxy? I think the 
> DHCP protocol 
> > is a choice to carry offloading
> It makes sense that you didn't want to include non-DHCP 
> solutions in a DHCP-specific document. 

I guess, this means the current document is acceptable for you. In current text, we don't draw any
conclusion in this document, only say this is possible interactions and its has benefit and issues.
>From the current document, we do NOT request to define mentioned possible interactions.

> However, the actual 
> decision process should include an analysis like the one I 
> described. So it would be good if the problem statement 
> mentioned this.   I don't think you can either accept or 
> reject DHCP as a solution without considering other alternatives.=

For sure. I fully agree with you. My another draft was aiming to define the delegation process. It
was discussed in DHC WG in March meeting. There was question why uses DHCP. I did not analyze the
other alternatives by that time. If I am going to push that draft again, I will include comparing
analysis both DHCP and non-DHCP solutions.

Regards,

Sheng

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Sep 2010 08:02:34 -0700

> analysis both DHCP and non-DHCP solutions.

Works for me.  Thanks!