Subject: (NAT) RSIP issues

From: Matt Holdrege <[email-masked]>
Date: Thu, 03 Aug 2000 07:41:34 -0700

In today's NAT Working Group meeting, we discussed the idea of creating a 
new working group focused entirely on RSIP. We also discussed the 
possibility of moving RSIP from Standards Track to Experimental Track.

The key people involved in RSIP have agreed that the documents could best 
move forward as RFC's if they are on the Experimental Track. This by no 
means prevents RSIP from moving back to Standards Track at a later date if 
there is consensus to do so. If anyone objects or has comments, please let 
us know.

Forming new working groups and managing existing working groups is the 
responsibility of the IESG. But if you have any feelings one way or the 
other regarding the formation of a new RSIP working group, please let us 
and/or the IESG know.

-
To unsubscribe, email [email-masked]' with
'unsubscribe nat' in the body of the message.

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Aug 2000 11:36:38 -0400

At 07:41 AM 08/03/2000 -0700, Matt Holdrege wrote:
>In today's NAT Working Group meeting, we discussed the idea of creating 
>a new working group focused entirely on RSIP. We also discussed the 

I see an overlap between RSIP and the proposed CAVITI WG.  Below are a 
couple excerpts about CAVITI.

...Scott

At 08:01 AM 08/02/2000 -0700, Matt Holdrege wrote:
>CAVITI assumes that the modern Internet topology is varied in many ways. 
>We have IPv4 nets and IPv6 nets. We also have NAT's and Firewalls to 
>deal with. We have people trying to communicate across such networks, 
>sometimes using private addresses at the edge and even sometimes in the 
>middle. Communicating across these mixed topologies is problematic for 
>many protocols and applications (see 
>draft-ietf-nat-protocol-complications-04.txt).
>
>Notable difficulties occur with realtime multimedia protocols and their 
>related signalling protocols. Especially, urgent solutions are needed 
>for IP Telephony. Therefore CAVITI will work on documenting their 
>requirements for such communications, aiming ultimately at a solution 
>set which may involve control protocols and actions to aid 
>mixed-topology communications.

At 11:23 AM 08/02/2000 -0400, Melinda Shore wrote:
>2) while there is overlap with existing working groups, there
>     is no appropriate home in any of them for this work

>4) in scoping the work, we need to focus on control of
>     packet filters, and location/topology problems are out
>     of scope

>The ADs would like to see us broaden our scope just a bit to
>include more generalized control of packet filters.  Two
>examples that were raised are buffer control (allocation,
>not shaping), and v4<->v6 address translation.

-

---

From: Michael Richardson <[email-masked]>
Date: Thu, 03 Aug 2000 19:08:04 -0400

-----BEGIN PGP SIGNED MESSAGE-----

  {please double check the ipsp address before you blindly reply. I'm
offline, and I keep forgetting to record it}

>>>>> "Scott" == Scott Brim <[email-masked]> writes:
    >> possibility of moving RSIP from Standards Track to Experimental Track.

    Scott> I see an overlap between RSIP and the proposed CAVITI WG.  Below are a 
    Scott> couple excerpts about CAVITI.

  There is some serious overlap with IPSP's SPP protocol as well.  

  RSIP, SPP, RSVP and I think MEGACO, involve sending out messages to
determine and/or provision services prior to actually making a "call"

  In the case of RSIP and SPP, one actually has to modify the parameters
of one's call slightly (changing source addresses, SPIs, port numbers, 
or adding AH/ESP) based upon the response. RSVP does not typically 
involve modifying any parameters, but one might decide not to make the "call"
if one can't get the bandwidth.
  
  This is an entirely different paradigm than we are used to. While
attempting not to reinvent the ISDN control protocol, I think that some
consideration should be given to how one might be able to unify some of these 
setup protocols. 
  Perhaps this should go like it does in Cosmology/Particle Physics: attempt
unification of two, and then three, etc...   

  Did CAVITI meet?  

Melinda> The ADs would like to see us broaden our scope just a bit to
Melinda> include more generalized control of packet filters.  Two
Melinda> examples that were raised are buffer control (allocation,
Melinda> not shaping), and v4<->v6 address translation.

  Interesting. 

] Train travel features AC outlets with no take-off restrictions|gigabit is no[
]   Michael Richardson, Solidum Systems,   in transit from PIT  |problem  with[
]     [email-masked]   www.solidum.com           to PHL        |PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

-