Subject: RE: (ngtrans) Working Group last call for BROKER-02, closes 1 Dec 99

From: Guardini Ivano <[email-masked]>
Date: Thu, 18 Nov 1999 10:51:48 +0100

Matt,

draft-ietf-ngtrans-broker-02 is intended to be framework document 
describing the guidelines for the provision of a Tunnel Broker service
within the Internet. For this reason it does not specifies any protocol
or MIME type but details the general architecture of the proposed
approach and outlines a set of available alternatives for implementing it.
Anyway I agree with you when you say that the use of a newly
defined MIME type to deliver the tunnel parameters to the client is a 
very attractive alternative which is certainly worth envisaging. But I think
that such an effort should be the subject of a companion document to
be published on the standards track.
What I can certainly do in broker-02 is to add a few sentences
clarifying that the MIME-based approach you propose is a valuable
alternative for the implementation of the broker-client interaction and that
for this reason the definition of a new MIME type to deliver tunnel 
configuration parameters is strongly recommended. In addition I can 
better clarify in the security considerations that the use of .bat or shell 
scripts to configure the client is frightening insecure and should be 
considered only for early implementations of the Tunnel Broker approach.

Bye
Ivano

> ----------
> From: 	Matt Crawford[SMTP:[email-masked]]
> Reply To: 	Matt Crawford
> Sent: 	Wednesday, November 17, 1999 11:52 PM
> To: 	NGtrans List
> Subject: 	Re: (ngtrans) Working Group last call for BROKER-02, closes
> 1 Dec 99
> 
> Sorry, Bob and authors, but I don't think there's enough material
> there to publish as an RFC unless you define the format of the tunnel
> parameters returned to the client.  I've been saying for a year now
> that there ought to be such a definition and it should be client-
> platform independent.  (To preserve the attractive convenience -- and
> frightening insecurity -- of sending over a .BAT file or shell
> script, the response might be a MIME multipart/alternative.)
> 
> 				Matt
>

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 18 Nov 1999 12:20:01 -0500

Mime is one way of doing this and actually more elegant than scripts.  But, 
it is still no negociation between the client and the server, and no 
mechanism for keepalive. I think the right approach is more towards what I 
presented in ngtrans last week, which is a tunnel setup protocol, in the 
lines of what Peter Tattam  was proposing 6 months ago.

Since the broker draft goes to informational, then it doesn't describe a 
standards track protocol, so do we really need to have MIME in it?

Regards, Marc.

>considered only for early implementations of the Tunnel Broker approach.

-----------------------------------------------------------
Marc Blanchet			| [email-masked]
Viagénie inc.			| http://www.viagenie.qc.ca
2875 boul. Laurier, suite 300	| tél.: 418-656-9254
Ste-Foy, Québec		| fax.: 418-266-5539
Canada, G1V 2M2		| radio: VA2-JAZ
------------------------------------------------------------
Internet Engineering Standards/Normes d'ingénierie Internet
                http://www.normos.org
------------------------------------------------------------

---

From: Guardini Ivano <[email-masked]>
Date: Fri, 19 Nov 1999 11:39:46 +0100

Marc,

> ----------
> From: 	Marc Blanchet[SMTP:[email-masked]]
> Reply To: 	Marc Blanchet
> Sent: 	Thursday, November 18, 1999 6:20 PM
> To: 	Guardini Ivano; 'Matt Crawford'
> Cc: 	Fasano Paolo; [email-masked]
> Subject: 	RE: (ngtrans) Working Group last call for BROKER-02, closes
> 1 Dec	99
> 
I think that neither of the two approaches (MIME and the ad-hoc protocol)
is perfect. Hence it is not clear to me which one is best. 
MIME certainly has some disadvantages, one of  them being that 
it does not allow keepalive and negotiations. Anyway it is secure and 
does not require the deployment of a newly deigned protocol for tunnel 
management, and these are two great advantages which could be
summarized saying that the MIME approach is simpler.
On the contrary the approach you propose is certainly the best with 
respect to tunnel management (the tunnel can be immediately released
after the user disconnects) and this is already clearly (I hope) stated in 
the current version of the draft.
My concern is that I think that the standardization of a tunnel setup
protocol would be a long and difficult task (much more difficult than
the definition of a new MIME type).

> standards track protocol, so do we really need to have MIME in it?
Just to further clarify what I said in my previous e-mail. I think that
broker-02
is not the right place where a new protocol or MIME type for tunnel setup 
should be standardized. Anyway I think that it is important in this draft to

mention also the MIME approach suggested by Matt as one of the possible
(and maybe most promising) alternatives for implementing the client-broker 
interaction. Exactly in the same way as I mentioned rsh, the use of 
automatically created scripts or the deployment of a new ad-hoc 
protocol (your proposal).

Moreover I think that regardless of the approach we decide to pursue (MIME,
new protocol or both) it should be general enough to be usable also for
other applications needing tunnels (e.g. IP Multicast or whatever) and not
only for IPv6 tunnel brokers. This is another reason for not to put MIME
types of protocol definitions in the broker draft.

Bye
Ivano