Re: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

[Mark Stapp <[e-mail]>]

Stuart,
I have identified three technical objections in your messages. First, you 
object to the presence of the RCODE fields, which you do not find useful. 
Second, you wish there were a single domain-name encoding in the fqdn 
option. Third, there is some lack of clarity about what servers' default 
behavior should be when presented with client fqdns that are in zones 
outside the servers' administration. I've tried to respond to the third 
issue in the other email threads.

As you observed in your reply to a question about the csr option, there are 
many millions of deployed clients with dependencies on parts of some 
existing options. In some cases, the presence of running implementations is 
worth considering when developing a new protocol feature. In my opinion, 
that is the case with both of your other objections. If we retain some 
backwards compatibility, new functionality is introduced with a minimum of 
disruption. The name encoding cost is born largely by the server 
implementations, who must be prepared for clients who only understand the 
deprecated ascii encoding. Everyone bears the burden of the additional two 
bytes per option for the RCODEs. But that seems to me to be a smaller 
burden than having to support both the existing option as deployed in many 
millions of clients, as well as the time and cost to define, approve, 
implement, and deploy a brand-new option that saves the two bytes.

It has been some time since those issues were last addressed by the working 
group. I think that the compromise has been a very practical and reasonable 
one. I don't think it's worth the time to reopen such a fundamental issue 
as the value of fqdn option compatibility with every shipping MS client 
since win98. I'd prefer that we make the best engineering tradeoff that's 
available, account for the deployed clients, and add additional 
capabilities that can be supported by future clients. If others feel that 
this tradeoff is not worth making, we need to hear from them.

I feel that the purpose of the wg is to identify problems, reach consensus 
on solutions, implement, and then refine based on operational experience. 
We have some operational experience integrating DHCP and DNS, and that 
motivates these specifications.

I'm not quite certain what you're getting at when you refer to our server 
implementation. We update the server quite frequently, like many vendors. 
If you have specific issues or integration problems with the cisco server, 
feel free to contact me or Kim directly.

-- Mark

At 02:07 PM 8/27/2001 -0700, Stuart Cheshire wrote:
> >the [FQDN] option has already been widely deployed
>
>This I think is the real issue.
>
>The purpose of WG discussion is to discuss protocol design, not to
>rubber-stamp an existing implementation, warts and all.
>
>An Informational RFC is the right place to document an existing
>implementation, warts and all.
>
>Mark, don't misunderstand this. I don't have any objection to you
>shipping products. I do object to a Standards-Track RFC published
>after-the-fact to give the impression that the design of the previously
>mentioned shipping products was the result of IETF Working Group
>Consensus.
>
>If you want this to be a Working Group publication, you have to be able
>to update your deployed products to comply with the eventual Working
>Group Consensus. If you can't update your deployed products to comply,
>then this whole process is a waste of time. Just publish it as
>Informational.
>
>Stuart Cheshire <[e-mail]>
>  * Wizard Without Portfolio, Apple Computer
>  * Chairman, IETF ZEROCONF
>  * www.stuartcheshire.org
>
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>http://www1.ietf.org/mailman/listinfo/dhcwg


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