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

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Aug 2004 15:15:05 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

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

---

From: "Bernie Volz" <[email-masked]>
Date: Wed, 11 Aug 2004 17:47:21 -0400

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.

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).

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

Best regards,

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Ralph Droms
> Sent: Wednesday, August 11, 2004 3:15 PM
> To: [email-masked]
> 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 

- Ralph Droms

---

From: Senthil Kumar B <[email-masked]>
Date: Thu, 12 Aug 2004 17:37:15 +0530

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

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

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.

>            p       Len        RDF Metadata for the Proxy    
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.

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 12 Aug 2004 08:31:32 -0400

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:[email-masked]] 
Sent: Thursday, August 12, 2004 8:07 AM
To: Bernie Volz
Cc: 'Ralph Droms'; [email-masked]; [email-masked]; [email-masked];
[email-masked]
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:

The current document is

single byte:

   network byte order.

And then:

       | protocol     |       Number   |

       |   HTTP       |         80     |

       |   FTP        |         21     |

       |   NNTP       |         119    |

       |   Gopher     |         70     |

       |   SSL        |         TBD    |

       |   SOCKS      |         1080   |

Will change it. 

   	 |  RDF  |  N   |             RDF                  |

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.

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

acceptable.

Best regards,

- Bernie

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

On Behalf Of Ralph Droms

To: [email-masked]

be assessed.

- Ralph Droms

dhcwg mailing list

[email-masked]

dhcwg mailing list

[email-masked]

dhcwg mailing list

[email-masked]