Subject: [Mipshop] FW: Status of draft-ietf-mos-dhcp-options

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Jan 2009 22:33:52 +0200

FYI. This draft is being discussed on the DHC WG list.

Jari Arkko wrote:
> The new version of this draft addressed the issues that I found in my 
> AD review. However, I'd like to have positive confirmation from the 
> DHC WG that they are fine with the syntax. I can see that the bit 
> pattern mechanism was simplified, but "enc" still remains, and I think 
> David complained about that in particular. If existing DHCP server 
> software cannot deal with a conditional encoding of attributes, I'd 
> recommend simplifying further. You do NOT want to upgrade client and 
> server code just to transport one additional piece of config data.
>
> Jari

_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: Subir Das <[email-masked]>
Date: Wed, 14 Jan 2009 09:13:40 -0500

Jari,
Thanks. We will wait for the confirmation from DHC WG. However, there 
are several existing RFCs use similar 'enc' style, for example, RFC 
3361, RFC 3495.

-Subir

Jari Arkko wrote:
>> pattern mechanism was simplified, but "enc" still remains, and I 
>> think David complained about that in particular. If existing DHCP 
>> server software cannot deal with a conditional encoding of 
>> attributes, I'd recommend simplifying further. You do NOT want to 
>> upgrade client and server code just to transport one additional piece 
>> of config data.
>>
>> Jari
>

---

From: Subir Das <[email-masked]>
Date: Sat, 17 Jan 2009 11:15:42 -0500

Bud Millwood wrote:
> On Friday 16 January 2009, David W. Hankins wrote:
>   
>> On Tue, Jan 13, 2009 at 10:32:21PM +0200, Jari Arkko wrote:
>>     
>>> review. However, I'd like to have positive confirmation from the DHC WG
>>> that they are fine with the syntax. I can see that the bit pattern
>>> mechanism was simplified, but "enc" still remains, and I think David
>>> complained about that in particular. If existing DHCP server software
>>> cannot deal with a conditional encoding of attributes, I'd recommend
>>> simplifying further. You do NOT want to upgrade client and server code
>>> just to transport one additional piece of config data.
>>>       
>> I've reviewed the changes in this draft.
>>
>> This protocol as currently written is not adoptable by existing DHCPv4
>> software on the Internet.  To use this protocol, the administrator of
>> a DHCP server must become intimately familiar with the wire format,
>> and author the wire format directly in contrived and complicated
>> configuration syntax (often, hexadecimal).  Comfortable use of the
>> protocol, converting presentation input to wire format, will require
>> source code changes.
>>     
>
> David: I think the cat's out of the bag on this one. (We just bit the bullet 
> and decided to support an 'encoding' field generically.)
>
> Subir: There's probably no technical argument against this format, but David's 
> point about the number of existing DHCPv4 servers that can natively handle 
> the format is a good point. There are many existing installations that will 
> have to resort to hex presentation.
>   
  Thanks and I  understand David and Ted's concerns. Hopefully we will 
be able to resolve this
  soon.
 
> My own feeling is that the 'encoding' field is a de-facto standard, and we 
> should fully support it.
>   
    I would wait for David or Ted to comment on this.
> - Bud

---

From: Subir Das <[email-masked]>
Date: Sun, 18 Jan 2009 23:55:47 -0500

Bernie Volz (volz) wrote:
> Just for the record, there are DHCP server implementations that do
> support this encoding-byte + data (depending on encoding-byte) format.
>
> And, the RFC 3495 (CableLabs Client Configuration Option) is used by
> lots of devices.
>   
   That was my understanding too. Also RFC 3361 is accepted by 3GPP IMS.
> As it is used in several places, I do think the cat is out of the bag
> and I think it should be usable by new options.
>
> - Bernie 
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Ted Lemon
> Sent: Friday, January 16, 2009 1:25 PM
> To: David W.Hankins
> Cc: Dhcwg; Chairs; [email-masked];
> [email-masked]
> Subject: Re: [dhcwg] Status of draft-ietf-mos-dhcp-options
>
> On Jan 16, 2009, at 9:38 AM, David W. Hankins wrote:
>   
>> I'm unconvinced the demand for these options is sufficient for good
>> deployment, and I haven't heard of existing implementations, so I am
>> not changing my guidance.  I think MIPSHOP should pick one encoding
>> and stick with it.
>>     
>
> I have to side with David here.   I was very much against the encoding  
> options in the other two RFCs as well, for two reasons:
>
> 1. As David says, it's extra code, which nobody is going to implement  
> if they don't have to.
> 2. It's an additional knob to turn, and chances are that it will  
> always be turned the same way.   And so the other way won't get tested  
> (I wish it were not so, but client testing has historically been very,  
> very spotty).   And then when someone does use it, it will break.   If  
> there were some value being added, it would be one thing, but there's  
> no value added here - it's just a decision the protocol designer is  
> deciding not to make.
>
> My advice is to make the decision, and make it the way everyone else  
> does: send an IP address.   If you don't agree with this decision,  
> please state a use case for the FQDN encoding.   Not "someone might  
> want to do FQDN encoding for some reason" but rather "in this case  
> (provide a case here) it will be necessary to do FQDN encoding because  
> IP-address encoding won't work or has the following severe  
> disadvantage (explain disadvantage)."   If you can't come up with one,  
> then the conditional flag here is not only unnecessary, but harmful.
>
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 17 Jan 2009 22:35:51 -0500

- Bernie