Subject: Re: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts (IndividualSubmissions) / Agenda Time Request

From: JiangSheng 66104 <[email-masked]>
Date: Thu, 17 Jul 2008 15:31:05 +0800

Hi, Bernie,

If it is a single-vendor mechanism, why do it need to be a standard
RFC? Vendor A can always achieve it in its devices with whatever format it
wants. Vendor B can also achieve it in its own devices in whatever format it
wants without consider the consistency with Vendor A or a standard, even there
is a standard available. And the non-standard way has probably less security
issues.

If you do agree cross-vendor mechanism is a useful scenario, but don't want
to do it in these two draft, we may do it together with new drafts to the DHC
WG/IETF.

Cheers,

Sheng 

>>-----Original Message-----
>>From: Bernie Volz (volz) [mailto:[email-masked]]
>>Sent: Thursday, July 17, 2008 11:27 AM
>>To: JiangSheng 66104; [email-masked]
>>Cc: Ralph Droms (rdroms)
>>Subject: RE: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts
>>(IndividualSubmissions) / Agenda Time Request
>>
>>Hi:
>>
>>I actually disagree that this is a cross-vendor mechanism. If you're 
>>planning to do that, why not go to the DHC WG/IETF and standardize it?
>>
>>I do admit that it may be possible for an organization, such as 
>>CableLabs or the DSLForum, to define messages and the format of the 
>>data to allow application specific exchanges (such as Cablelabs DOCSIS 
>>3.0 made use of the vendor options). But, I would discourage that as 
>>it is likely that other technologies will likely find these new 
>>messages to be useful as well and hence they should be defined through 
>>the IETF.
>>
>>I suspect that this is exactly what people feared would happen and we 
>>do need to avoid that.
>>
>>- Bernie
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]] On Behalf 
>>Of JiangSheng 66104
>>Sent: Wednesday, July 16, 2008 11:12 PM
>>To: Bernie Volz (volz); [email-masked]
>>Cc: Ralph Droms (rdroms)
>>Subject: Re: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts
>>(IndividualSubmissions) / Agenda Time Request
>>
>>Hi, Bernie,
>>
>>I have just quitely reviewed these two drafts. They looks quite 
>>interesting for me. Your "to allow communication between DHCP entities 
>>for data that would not normally be standardized or there is little 
>>interest for" is a useful scenario for us too.
>>
>>However, for me, these two drafts does not give enough technical 
>>solution as it is now. If I understand you correctly, the most 
>>important scenario is to allow communication between DIFFERENT 
>>vendors' devices (the communication between the devices from the same 
>>vendor can be achieveed by vender's own implementation, no need to 
>>define a standard message type). Your current draft is lack of the 
>>support for intercommunication. As suggestion, for the "vendor-data " 
>>field, more detailed definitions or recommandations on how to 
>>describe/organize these vendor data should be given so that a DHCP 
>>entity from vendor A MAY be able to understand a vendor message sent 
>>by another DHCP entity from vendor B.
>>
>>Best regards,
>>
>>Sheng JIANG, Ph.D.
>>
>>IP Research Department, Networking Research Department, Network 
>>Product Line, Huawei Technologies Co. Ltd.
>>
>>PS: I also cc this message to Ralph because a, he will represent 
>>Bernie's draft; b, my emails to DHC rarely get through and show up on 
>>the maillist recently due to some problems between my email server and 
>>IETF email server.
>> 
>>
>>>>-----Original Message-----
>>>>From: [email-masked]
>>[mailto:[email-masked]] On Behalf
>>>>Of Bernie Volz (volz)
>>>>Sent: Thursday, July 17, 2008 6:26 AM
>>>>To: [email-masked]
>>>>Subject: [dhcwg] DHCPv6 and DHCPv4 Vendor Message Drafts
>>>>(IndividualSubmissions) / Agenda Time Request
>>>>
>>>>Folks:
>>>> 
>>>>I recently submitted an updated
>>>>draft-volz-dhc-dhcpv6-vendor-message-01.txt and also a new 
>>>>draft-volz-dhc-dhcpv4-vendor-message-00.txt.
>>>>
>>>>The DHCPv6 draft was originally presented at the Prague IETF
>>>>(IETF-68) and wasn't warmly received. One of the issues was the 
>>>>reserved option space, which has been removed. The more significant 
>>>>concern, if I recall correctly, was that vendors would use these 
>>>>messages in place of going the standards route, and while I
>>can't say
>>>>that isn't a valid concern, I suspect that in most cases
>>that won't be
>>>>an issue. My purpose for this message is to allow communication 
>>>>between DHCP entities for data that would not normally be
>>standardized
>>>>or there is little interest for. For example, it could be
>>used by DHCP
>>>>servers to exchange configuration data or implement
>>failover (we know
>>>>the long and tortured road that DHCPv4 failover has
>>followed and while
>>>>there was a LOT of value to that work, we still don't have
>>a standards
>>>>track document and there's little interest to doing the
>>work necessary
>>>>to get it done).
>>>>
>>>>The DHCPv4 draft is new and was a natural extension. Of
>>course, DHCPv4
>>>>is a bit different from DHCPv6, so there are some
>>differences (a new
>>>>option is needed to convey the enterprise-id number).
>>>>
>>>>I will not be at the Dublin IETF and may try to participate
>>virtually
>>>>(it will be 4AM for me, but I likely shouldn't complain as
>>most will
>>>>still be jet lagged).
>>>>
>>>>I've asked Ralph (with his working co-chair hat off) to present 
>>>>something briefly. Hopefully he and John can work it into
>>the schedule
>>>>if time permits (it is a very late agenda addition).
>>>>
>>>>If anyone on the list supports the concept (as several folks did 
>>>>privately communicate interest to me), please speak up -
>>either at the
>>>>meeting or on the list.
>>>>
>>>>- Bernie
>>>>_______________________________________________
>>>>dhcwg mailing list
>>>>[email-masked]
>>>>https://www.ietf.org/mailman/listinfo/dhcwg
>>>>
>>_______________________________________________
>>dhcwg mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/dhcwg
>>
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: JiangSheng 66104 <[email-masked]>
Date: Thu, 17 Jul 2008 15:32:33 +0800

For single-vendor scenario, an implementation using non-standard DHCP message
with the regular port or even using non-standard DHCP option with standard DHCP
message header can meet the purpose, and there is no extra deployment problems.
Firewalls or reply agents do not check whether the contents of a DHCP message
are standard or not.

Don't get me worry. I am not here against your drafts. I just think cross-vendor
scenarios are consistent with single-vendor scenarios. Adding them together will
make the foundation/requirements of these drafts to be more solid.

Cheers

Sheng

>>Sent: Thursday, July 17, 2008 12:20 PM
>>To: Sheng Jiang; [email-masked]
>>Cc: Ralph Droms (rdroms)
>>Sure, you can always use a separate protocol. Or send the "DHCP"
>>messages over a different port.
>>
>>But that complicates deployments because it requires customers to 
>>potentially open additional firewall ports or protect other ports. And 
>>it means you have to get a new port assignment or "hijack" a value you 
>>believe no one else is using (and allowing customers to change it 
>>should there be an issue).
>>
>>And, it means more ports open on the clients and servers. 
>>And, you can't use the relay agent to forward the packets between 
>>network elements.
>>
>>And, you may get fragmented behavior if normal DHCP traffic flows but 
>>this "other" traffic doesn't (such as because of firewalls or other 
>>misconfigurations).
>>
>>Those are the main reasons why using a DHCPv4/DHCPv6 message would be 
>>benefical.
>>
>>- Bernie
>>
>>From: Sheng Jiang [mailto:[email-masked]]
>>Sent: Wednesday, July 16, 2008 11:58 PM
>>RFC?
>>Vendor A
>>can always achieve it in its devices with whatever format it wants.
>>Vendor B can
>>also achieve it in its own devices in whatever format it wants without 
>>consider the consistency with Vendor A or a standard, even there is a 
>>standard available. And the non-standard way has probably less 
>>security issues.
>>
>>If you do agree cross-vendor mechanism is a useful scenario, but don't 
>>want to do it in these two draft, we may do it together with new 
>>drafts to the DHC WG/IETF.
>>
>>Cheers,
>>
>>Sheng
>>