RE: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 - NO GO!

["Bernie Volz" <[e-mail]>]

Hi:
 
IMHO, the design of this option is bad - what if you want a new protocol and
want it to have a encoding similar to RDF? You won't be able to do this
because all clients and servers would need to be upgraded at once - which is
clearly not possible.
 
You need to think about a general format that will accommodate future growth
and do it in a backwards compatible manner.
 
Perhaps something like:
    2-bytes protocol number
    1-byte encoding
    variable number of data bytes depending on encoding
 
This is still not that great because you can't add a new encoding type
without upgrading all clients and servers at once. Though, one of the known
encoding types could have the data contain a length in the first 2-bytes to
accommodate the RDF encoding.
 
A better format, though less compact, might be:
    Protocol number (2 bytes)
    Data length (1 or 2 bytes; 2 probably needed if RDF could be > 255
bytes)
    Data of length bytes
 
The data of length bytes for most protocols would be
<encoding><address><port>. <encoding> is likely a bad name for this field in
this case?
 
In this way, you can extend the future "encodings" because those that don't
know the "encoding" for a protocol number know what to do - they simply skip
the data (and they know how long it is).
 
It isn't as compact as the old encoding, but it is much more extensible.
 
- Bernie

-----Original Message-----
From: Senthil Kumar B [mailto:[e-mail]] 
Sent: Thursday, August 12, 2004 8:07 AM
To: Bernie Volz
Cc: 'Ralph Droms'; [e-mail]; [e-mail]; [e-mail];
[e-mail]
Subject: Re: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00 -
NO GO!


Thanks a lot for you reply and please see my reply inline. Replies are in
Blue color.

Bernie Volz wrote:


I do *NOT* agree with the last call on this document!



The current document is

http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-01.txt

and I assume that is really the one being last called and the one I'll

comment on (as there are significant differences between 00 and 01).



First, I'd like to understand how they'll encode values such as 1080 into a

single byte:



   The Proxy Server Configuration entry consists of a sequence of 

   Protocol Type (p), Encoding (e), IP address and port. 

   	  

   	+--+--+--+--+--+--+--+--+

	|p |e |IP address |port |

	+--+--+--+--+--+--+--+--+



   The Protocol(p) and encodig (e) are on octet each; each IP address is

---------------------------------------^^ (I assume this is ONE octet each?)

   four octets, and each port number is a two-octet integer encoded in

   network byte order.



And then:



   The protocol type(p) specifies the type of Protocol and MUST be 

   one of the following assigned numbers.



       +-------------------------------+

       | protocol     |       Number   |

       +-------------------------------+

       |   HTTP       |         80     |

       +-------------------------------+

       |   FTP        |         21     |

       +-------------------------------+

       |   NNTP       |         119    |

       +-------------------------------+

       |   Gopher     |         70     |

       +-------------------------------+

       |   SSL        |         TBD    |

       +-------------------------------+

       |   SOCKS      |         1080   |

  

1080 requires two bytes to encode.


I agree that the protocol should be 2 octets. Initially, I thought of
getting these protocol types assigned by IANA.

As per your earlier suggestion, I had changed it to standard protocol
numbers, but forgot to update the document.

Will change it. 




Later, the document goes on about:



   The format of the Proxy Server Configuration using Metadata type is:





            p       Len        RDF Metadata for the Proxy    

   	 +-------+------+----------------------------------+

   	 |  RDF  |  N   |             RDF                  |

   	 +-------+------+----------------------------------+





What is this and where does this go? Is this a new option? Is this encoded

in the existing option in some manner which I can't understand?





And, the option size would seem to exceed the 255 byte limit: "... giving a

total of 418 characters including the overhead", yet nothing is ever

mentioned about RFC 3396 (encoding long options).

If the protocol type field (first field in the tuple in p/e/IPADDR/port) has
the value for RDF (as specified in the table),  
then it SHOULD be followed by the length (N) of the RDF payload.

I agree that RFC 3396 needs to be referred here. Will do the changes.

Please let me know if there are any further comments, so that i can update
all at once and will submit a new version.




So, I think this draft needs much further revision before I feel it would be

acceptable.



Best regards,



- Bernie



  

-----Original Message-----

From: [e-mail] [mailto:[e-mail]] 

On Behalf Of Ralph Droms

Sent: Wednesday, August 11, 2004 3:15 PM

To: [e-mail]

Subject: [dhcwg] dhc WG last call on draft-ietf-dhc-proxyserver-opt-00





This message announces a second WG last call on "DHCP Option 

for Proxy Server Configuration" 

<draft-ietf-dhc-proxyserver-opt-00>.  There was insufficient 

(that is, none) response to the first WG last call.  This 

document can not be submitted to the IESG without positive 

response during the WG last call.  This last call will 

conclude at 1700 EDT, 2004-08-27.



Please respond to this WG last call.  If you support 

acceptance of the document without change, respond with a 

simple acknowledgment, so that support for the document can 

be assessed.



"DHCP Option for Proxy Server Configuration" defines a 

Dynamic Host Configuration Protocol (DHCP) option that can be 

used to configure the TCP/IP host's Proxy Server 

configuration for standard protocols like HTTP, FTP, NNTP, 

SOCKS, Gopher, SLL and etc. Proxy servers provide controlled 

and efficient access to the Internet through the use of 

access control mechanisms for different types of user 

requests and caching frequently accessed information (Web 

pages and other files that might have been downloaded using 

FTP and other protocols).  This draft is available as 

    

http://www.ietf.org/internet-drafts/draft-ietf-dhc-proxyserver-opt-00.txt



- Ralph Droms





_______________________________________________

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