Subject: [dhcwg] comment to proxyserver drafts

From: Mohacsi Janos <[email-masked]>
Date: Thu, 4 Aug 2005 14:04:45 +0200 (CEST)

Hi,
 	I read the draft-ietf-dhc-proxyserver-opt-04.txt and I have some 
comments:
1. The treatment proxy servers should be more generic.
1.1 Proxy servers can be used for various reasons: not only listed in the 
current draft. I think you should think of VOIP (e.g. SIP) proxy also. So 
I could imagine any kind of application protocol to be proxied...
1.2 You should think of adding protocol type (TCP/UDP/SCTP etc.) to Proxy 
Server Configuration Options. What would happen if somebody want to proxy 
a portnumber/udp instead of portnumber/tcp. Identifying a communication 
end-point requires protocol also (e.g. TCP/UDP...).
1.3 I don't want initiate a religious war, but I think the IP address 
of the proxy server should specified in string format instead of network 
byte order 4 octets. First, the current draft excludes usage of IPv6 
proxies. Second, You would like to have proxy configured after you have 
your DNS servers configured....  This way length field has much more 
sense...

2. As discussed on the WG meeting the RDF and XML seems to be very 
problematical in implementation point of view. Is it allowed to have a 
client that implement non-RDF/XML proxies. This would allow easier 
implementation, however might generate some problems:
- should DHCP server announce proxy information in two format? - maybe two 
options: simple and RDF/XML - client can decide what it wants?

Regards,

Janos Mohacsi
Network Engineer, Research Associate
NIIF/HUNGARNET, HUNGARY
Key 00F9AF98: 8645 1312 D249 471B DBAE  21A2 9F52 0D1F 00F9 AF98

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

---

From: "David W. Hankins" <[email-masked]>
Date: Mon, 8 Aug 2005 10:21:23 -0700

> I could imagine any kind of application protocol to be proxied...

I suggested earlier that one solution might be to make the string format
of a proxy contain a URL.  Is there a URL format for SIP proxies?

> end-point requires protocol also (e.g. TCP/UDP...).

I suppose that's only a problem if we expect there will exist some number
of proxies that are transportable by both tcp and udp.  Presently, the
only ones I know of are transported by one or the other, but never both.

> byte order 4 octets.

Bad idea.

If an IPv4 address is to be delivered, it is best to do so in the binary,
network byte order, format.

> First, the current draft excludes usage of IPv6 
> proxies.

Because it is an option to be encoded in IPv4 DHCP.  Supporting IPv6
delivery in a V4 client is out of scope.

If you want to deliver v6 addressed proxies, do so in DHCPv6, or DNS.

> Second, You would like to have proxy configured after you have 

I'm not sure I understand your reasoning here.

You want a textual string describing an ip address, eg "127.0.0.1", to
be passed to the DHCP client?

The client returns this string to its dynamically-configured recursive
nameserver?

Or you meant as a domain name?

Certainly, the SOCKS proxy for example is probably always going to be
configured as an IPv4 address - you probably have to connect to your
SOCKS proxy before you can reach your recursive nameservers.

So long as I'm on that topic, it may be that combining network/packet
proxies and protocol proxies in the same option(s) is mis-scoped.  They
both have 'proxy' in the name, but they're very different beasts,
consumed by different kinds of client applications.

> options: simple and RDF/XML - client can decide what it wants?

Margaret made an excellent point on this topic at IETF63 that I'm not
sure the room took properly to heart.

Defining multiple different ways of delivering the same information
means clients have to implement every one of them, not a subset.

So, if one solution does everything that is needed, it would simplify
matters substantially for all involved if that that one solution was
selected.

I think that might mean the enhanced XML format the author discussed at
IETF63, being delivered via url (http, tftp, or whatever), which takes
all this "various encodings" in the draft out of the picture entirely.

I look forward to reading -05.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg