RE: [dhcwg] BCMCS server option drafts

["Kuntal Chowdhury" <[e-mail]>]

Hello Ralph,

>The 3GPP2 standards bodies are free to define any syntax or 
>semantics for the 3GPP2 OPTION_VENDOR_OPTS.  So, if 3GPP2 
>coule require that a client sends a 3GPP2 OPTION_VENDOR_OPTS 
>request, which the server parses and responds with 3GPP2 
>OPTION_VENDOR_OPTS containing information for the client.

If I understand what your are saying, the semantics to request/respond
vendor specific information should also be vendor specific. I guess this is
well understood to the DHCP implementers. It was not clear to me when I read
RFC 3115.

The syntax of OPTION_VENDOR_OPTS is defined in 3315:

"
   The encapsulated vendor-specific options field MUST be encoded as a
   sequence of code/length/value fields of identical format to the DHCP
   options field.  The option codes are defined by the vendor identified
   in the enterprise-number field and are not managed by IANA.  Each of
   the encapsulated options is formatted as follows:

       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          opt-code             |             option-len        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                          option-data                          .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

So, I don't understand your statement "3GPP2 is free to define the syntax of
OPTION_VENDOR_OPTS".  The syntax of OPTION_VENDOR_OPTS when it appears in a
request message from the client is not clear. 

The suggested behavior of a 3GPP2 DHCP server sending all 3GPP2 specific
information to the client (blindly) is not an ideal one. The approach where
the client sends specific information request and the server returns the
requested information only is a better one, IMHO.

-Kuntal

>-----Original Message-----
>From: Ralph Droms [mailto:[e-mail]] 
>Sent: Friday, October 29, 2004 6:49 AM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: Bernie Volz; [e-mail]
>Subject: RE: [dhcwg] BCMCS server option drafts
>
>
>Kuntal - in both DHCPv4 and DHCPv6, there are no required 
>semantic ties between the message from the client to the 
>server and the response from the server.  That is, the client 
>is not required to include any option request information or 
>vendor identification (I'm using general terms rather than 
>specific options because of the differences between DHCPv4 and 
>DHCPv6) to cause the server to send certain options or 
>vendor-specific information back to the client.  The server 
>uses any option request information or vendor identification 
>or vendor-specific information as input ("hints") to the rules 
>the server uses to send a response to the client.  The server 
>is free to send information that has not been specifically 
>requested by the client, based on other information the server 
>gleans from the message it receives from the client.
>
>So, in the DHCPv6 case, the client is not required to send an 
>OPTION_ORO requesting OPTION_VENDOR_OPTS (although it may do 
>so) and the server, based on other information, is free to 
>send OPTION_VENDOR_OPTS.  In a 3GPP2 deployment, if the DHCPv6 
>server sees a request from a part of the network topology 
>known to be using 3GPP2, the server may assume that the device 
>sending the request is a 3GPP2 device and send 3GPP2 
>OPTION_VENDOR_OPTS to that client.  And, if, for some reason, 
>the client is not a 3GPP2 device, the client can simply ignore 
>the 3GPP2 OPTION_VENDOR_OPTS.
>
>The 3GPP2 standards bodies are free to define any syntax or 
>semantics for the 3GPP2 OPTION_VENDOR_OPTS.  So, if 3GPP2 
>coule require that a client sends a 3GPP2 OPTION_VENDOR_OPTS 
>request, which the server parses and responds with 3GPP2 
>OPTION_VENDOR_OPTS containing information for the client.
>
>
>- Ralph
>
>
>At 03:08 PM 10/28/2004 -0400, Kuntal Chowdhury wrote:
>>Hello Bernie,
>>
>>Thanks for the response. I guess what is not clear to me is 
>how a DHCP 
>>client requests vendor specific information from the DHCP server:
>>
>>"
>>- A Client includes OPTION_VENDOR_CLASS to identify itself.
>>- A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific 
>>data (other than classing information) to communicate.
>>- A Server includes OPTION_VENDOR_OPTS for matching 
>enterprise IDs (and 
>>class data, if appropriate). This is only REQUIRED if the ORO 
>includes 
>>the OPTION_VENDOR_OPTS code (the ORO doesn't say which 
>vendors; that is 
>>handled by OPTION_VENDOR_CLASS). "
>>
>>Second bullet seems to say that the DHCP client includes 
>>OPTION_VENDOR_OPTS to convey some vendor specific information to the 
>>DHCP server beside the vendor class info (which is in 
>>OPTION_VENDOR_CLASS). It does not state that OPTION_VENDOR_OPTS is 
>>included in a DHCP message (such as information
>>request) to REQUEST for vendor specific info from the server. 
>It is true
>>that opcode for OPTION_VENDOR_OPTS can be included in ORO, 
>but that won't
>>necessarily indicate to the server which vendor specific 
>codes it needs to
>>return to the client. Also, the format of the 
>OPTION_VENDOR_OPTS when it
>>appears in the REQUEST message is unclear.
>>
>>A clear description of how to use OPTION_VENDOR_OPTS to 
>request vendor 
>>specific information (such as broadcast server address) will be 
>>required by SDOs such as 3GPP2.
>>
>>Regards,
>>Kuntal
>>
>>
>> >-----Original Message-----
>> >From: Bernie Volz [mailto:[e-mail]]
>> >Sent: Wednesday, October 27, 2004 8:34 PM
>> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms'
>> >Cc: [e-mail]
>> >Subject: RE: [dhcwg] BCMCS server option drafts
>> >
>> >
>> >Hi:
>> >
>> >I believe the original model was for OPTION_VENDOR_CLASS to be 
>> >similar to DHCPv4 Vendor class identifier option (option 
>60) and for 
>> >OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor Specific 
>> >Information (option 43).
>> >
>> >You might refer to draft-ietf-dhc-vendor-03.txt, while for 
>DHCPv4, it 
>> >does have some additional information about how the options 
>might be 
>> >used. That work is modeled on the DHCPv6 options. In 
>particular, see 
>> >section 4:
>> >
>> >4.  Vendor-Identifying Vendor-Specific Information Option
>> >
>> >   DHCP clients and servers may use this option to exchange vendor-
>> >   specific information.  Either party may send this 
>option, as needed.
>> >   While a typical case might be for a client to send the
>> >   Vendor-Identifying Vendor Class option, to elicit a useful
>> >   Vendor-Identifying Vendor-Specific Information Option, 
>there is no
>> >   requirement for such a flow.
>> >
>> >It would be good to get general agreement on this as you're perhaps 
>> >the first user. And, it would be best to set a "standard" 
>for others 
>> >to follow.
>> >
>> >I kind of liked the DHCPv4 model, as it is much easier and 
>clearly to 
>> >understand (and implement for clients and servers):
>> >- A Client includes OPTION_VENDOR_CLASS to identify itself.
>> >- A Client MAY include OPTION_VENDOR_OPTS if it has vendor specific 
>> >data (other than classing information) to communicate.
>> >- A Server includes OPTION_VENDOR_OPTS for matching enterprise IDs 
>> >(and class data, if appropriate). This is only REQUIRED if the ORO 
>> >includes the OPTION_VENDOR_OPTS code (the ORO doesn't say which 
>> >vendors; that is handled by OPTION_VENDOR_CLASS).
>> >- I'm not sure why a server would ever need to include 
>> >OPTION_VENDOR_CLASS, though perhaps it could tell the client what 
>> >implementation the server is so that perhaps the client knows it 
>> >could use some extended capabilities? Or, the server could 
>send back 
>> >whatever the client sent to it?
>> >
>> >But, as draft-ietf-dhc-vendor-03.tx states, this is not the only 
>> >possible model.
>> >
>> >Note that in your case, I would assume that the OPTION_VENDOR_CLASS 
>> >would have your enterprise ID and some class information to 
>indicate 
>> >what capabilities the client supports (and therefore the server 
>> >should provide configuration for in the OPTION_VENDOR_OPTS).
>> >
>> >So, this is a good issue for the DHC WG to resolve and 
>clarify for a 
>> >future RFC 3315bis.
>> >
>> >- Bernie
>> >
>> >> -----Original Message-----
>> >> From: [e-mail] [mailto:[e-mail]] On 
>> >> Behalf Of Kuntal Chowdhury
>> >> Sent: Wednesday, October 27, 2004 4:33 PM
>> >> To: Ralph Droms; [e-mail]
>> >> Cc: [e-mail]
>> >> Subject: RE: [dhcwg] BCMCS server option drafts
>> >>
>> >>
>> >> I have a few questions on the possible use of DHCPv6 
>> >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor 
>> >> specific info:
>> >>
>> >> 1. Since the enterprise number is included in OPTION_VENDOR_OPTS, 
>> >> will it suffice to use only this option in the 
>information request 
>> >> message from the DHCP client? Is the use of OPTION_VENDOR_CLASS 
>> >> mandatory while vendor specific options are requested?
>> >>
>> >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the 
>information 
>> >> request message indicate to the DHCP server that the DHCP 
>client is 
>> >> requesting for some specific vendor specific options?
>> >>
>> >> 3. O-R-O has the format where each of requested option codes are 
>> >> listed in it. However, in OPTION_VENDOR_OPTS the encapsulated 
>> >> vendor-specific options field MUST be encoded as a sequence of 
>> >> code/length/value fields. What value does the DHCP client 
>use while 
>> >> requesting for a vendor specific option?
>> >>
>> >> These things are not clearly defined in RFC3315.
>> >>
>> >> Regards,
>> >> Kuntal
>> >>
>> >> >-----Original Message-----
>> >> >From: [e-mail] [mailto:[e-mail]] On 
>> >> >Behalf Of Ralph Droms
>> >> >Sent: Wednesday, October 27, 2004 2:29 PM
>> >> >To: [e-mail]
>> >> >Subject: RE: [dhcwg] BCMCS server option drafts
>> >> >
>> >> >
>> >> >
>> >> >What about the deployment issue? The 3GGP2 specification will be 
>> >> >ratified in November, with deployment following soon.  Some 
>> >> >service providers already have DHCP servers in place that must be
>> >updated for
>> >> >any new options.  The options defined in the current drafts can 
>> >> >likely be supported without code changes to existing servers, 
>> >> >allowing for faster deployment.  Use of a VIVSO sub-option would 
>> >> >require code changes to existing servers.  How long would
>> >it take to
>> >> >deploy DHCP server that can support VIVSO?
>> >> >
>> >> >BTW, we need more discussion of this issue *soon* due to 
>the time 
>> >> >constraints of the upcoming 3GPP2 standards process and 
>> >> >deployment.
>> >> >
>> >> >- Ralph
>> >> >
>> >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote:
>> >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed
>> >> and pushing
>> >> >>these options to using it would be a step at making this
>> >> >happen (as one
>> >> >>would expect 3GPP2 vendors to have some significant 
>input to the 
>> >> >>decisions of DHCP server vendors).
>> >> >>
>> >> >>It also means that 3GPP2 is free to define other VIVSO
>> >> options in the
>> >> >>future within their own forum and need not go to the IETF
>> >> >(and DHC WG).
>> >> >>I suspect that this would provide much faster deployment
>> >for them in
>> >> >>the future.
>> >> >>
>> >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS
>> >> >are already
>> >> >>there for DHCPv6.
>> >> >>
>> >> >>BTW, 3GPP2 already has an enterprise-id number:
>> >> >>
>> >> >>5535
>> >> >>   3rd Generation Partnership Project 2 (3GPP2)
>> >> >>     Allen Long
>> >> >>       [e-mail]
>> >> >>
>> >> >>So, they'd be good to go!
>> >> >>
>> >> >>- Bernie
>> >> >>
>> >> >> > -----Original Message-----
>> >> >> > From: [e-mail] [mailto:[e-mail]] 
>> >> >> > On Behalf Of Ralph Droms
>> >> >> > Sent: Thursday, October 21, 2004 2:35 PM
>> >> >> > To: [e-mail]
>> >> >> > Subject: [dhcwg] BCMCS server option drafts
>> >> >> >
>> >> >> >
>> >> >> > We need to have a short WG conversation about two options
>> >> >that were
>> >> >> > discussed at the WG meeting in San Diego.  The 
>outcome of the 
>> >> >> > conversation will be to determine consensus about taking
>> >> on these
>> >> >> > two
>> >> >> > drafts:
>> >> >> >
>> >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt
>> >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt
>> >> >> >
>> >> >> > as dhc WG work items or recommending that 3GPP2 define 
>> >> >> > vendor-identifying vendor-specific option (VIVSO; option code
>> >> >> > 125) sub-options to carry the information described in
>> >> the drafts.
>> >> >> >
>> >> >> > If the WG consensus is to take on the drafts as WG 
>work items 
>> >> >> > drafts, are they acceptable as currently published?
>> >> >> >
>> >> >> > Because of the time constraints imposed by the 3GPP2
>> >> schedule, I'm
>> >> >> > going to cut off discussion on this topic next Thursday,
>> >> >10/28, and
>> >> >> > determine WG consensus at that time.
>> >> >> >
>> >> >> > Here are some considerations for discussion:
>> >> >> >
>> >> >> > 3GPP2 has defined some vendor-specific sub-options, for
>> >> >example, to
>> >> >> > identify a MIP home agent for the DHCP client.
>> >> >> >
>> >> >> > A 3GPP2 client needs to specify to the DHCP server which
>> >> >parameters
>> >> >> > it needs - specifically, whether it needs to receive 
>the BCMCS 
>> >> >> > servers. If the current drafts are adopted, the client
>> >> can simply
>> >> >> > use the parameter request list option (option code 
>55) for the 
>> >> >> > request.  If a VIVSO sub-option is used, 3GPP2 would
>> >> also define a
>> >> >> > parameter request list sub-option.
>> >> >> >
>> >> >> > There is a deployment issue, as some service providers
>> >> >already have
>> >> >> > DHCP servers in place that must be updated for any new
>> >> >options.  Is
>> >> >> > it the case that the options defined in the current
>> >drafts can be
>> >> >> > supported without code changes to existing servers?  Use
>> >> >of a VIVSO
>> >> >> > sub-option would require code changes to existing servers.
>> >> > How long
>> >> >> > would it take to deploy DHCP server that can support VIVSO.
>> >> >> >
>> >> >> > BCMCS may be adopted across multiple technologies, so the
>> >> >options in
>> >> >> > the current drafts would not be specific to 3GPP2.
>> >However, the
>> >> >> > BCMCS specification has not adopted by other standards,
>> >> yet, so we
>> >> >> > may need to define additional options for related
>> >> services in the
>> >> >> > future if those services are not interoperable with the
>> >> >3GPP2 BCMCS
>> >> >> > service.
>> >> >> >
>> >> >> > CableLabs has one option with sub-options (RFC 3495)
>> >rather than
>> >> >> > multiple options because:
>> >> >> > * wanted to avoid exhaustion of DHCP option code space;
>> >> >perhaps less
>> >> >> >    of an issue with option code reclassification
>> >> >> > * would have used VIVSO if available
>> >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom
>> >> >to define new
>> >> >> >    sub-options on demand
>> >> >> > Do these considerations have an impact on our decision
>> >> >about how to
>> >> >> > proceed with the 3GPP2 options?
>> >> >> >
>> >> >> > - Ralph
>> >> >> >
>> >> >> >
>> >> >> > _______________________________________________
>> >> >> > dhcwg mailing list
>> >> >> > [e-mail] https://www1.ietf.org/mailman/listinfo/dhcwg
>> >> >> >
>> >> >
>> >> >
>> >> >_______________________________________________
>> >> >dhcwg mailing list
>> >> >[e-mail] https://www1.ietf.org/mailman/listinfo/dhcwg
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> dhcwg mailing list
>> >> [e-mail] https://www1.ietf.org/mailman/listinfo/dhcwg
>> >>
>> >
>> >
>> >
>>
>>_______________________________________________
>>dhcwg mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/dhcwg
>
>
>

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg