CURRENT_MEETING_REPORT_ Reported by Caralyn Brown/Wellfleet Communications Minutes of the IP Over Large Public Data Networks Working Group (IPLPDN) The purpose of re-opening the IP over Large Public Data Networks Working Group (IPLPDN) was to clean up some unresolved items, and attend to those items which have come up after the group became inactive. Encapsulation Determination Keith Sklower presented a summary of the Internet-Draft he has written entitled ``Determination of Encapsulation of Multi-protocol Datagrams in Circuit-switched Environments.'' The objective of this work is to define a way in which a receiving station might determine which type of encapsulation (X.25, Frame Relay or PPP) is used on a ISDN call. This is an issue because ISO prefers X.25, PPP is out there, and the ITU has recently included access to a Frame Relay switch as an access feature. The document is not specific to ISDN, but to circuit switched networks where prior configuration is not easily done. Keith Sklower agreed to update the document to remove part of section 8, ``Out of Band Signaling,'' change bit inversion parameters (``callee's algorithm'') and remove section 10. Keith also agreed to clean up the sections referring to Internet-Drafts. It was agreed that this document should be published as an Informational RFC as a statement of applicability for various standards. This will be done after Keith has updated the document and circulated it to the working group (via the mailing list) for further comments. Parameter Negotiation Keith Sklower presented a summary of the Internet-Draft entitled ``Parameter Negotiation over Frame Relay.'' The fundamental issue is to enable the negotiation of a few options in the context of the existing RFC 1490 encapsulation and philosophy. There is a similar document being worked in the Point-to-Point Protocol Extensions Working Group (PPPEXT) called ``PPP over Frame Relay.'' This document preposes that once an NCP is negotiated, the encapsulation changes to the PPP encapsulation with the CF NLPID identifier. Each document presupposes different goals. Parameter negotiation defines how to add certain negotiations to a 1490 environment, while PPP on frame relay attempts to define how to run the entire PPP suite over frame relay. The forwarding both documents is the fact that two implementations, one using the parameter negotiations document, and one using PPP over frame relay, might successfully complete negotiation and then be unable to pass data due to differing data encapsulations. The decision was reached within the group that the parameter negotiations document would be modified to clarify that the final data encapsulation would be as specified in RFC 1490 even after negotiations. It would also be clarified to specify that, should an implementation decide to negotiate a protocol for which a PPP encapsulation is defined, but none is defined within RFC 1490 (VJ compression for example), the PPP encoding would be allowed. Protocols which can be defined within the context of RFC 1490 will continue to be encapsulated in that manner. Status of Updates to RFC 1315 The draft for the updates to RFC 1315 has expired. Caralyn Brown has agreed to repost it and set the wheels in motion to get it forwarded. Routing Over Frame Relay Since the disbanding of the original IPLPDN group, there has been much discussion about how to run various protocols over a frame relay network; in particular DECnet over frame relay. The group decided that there are many ways in which to run a protocol over the frame relay network depending upon what the configuration is. Joel Halpern and Fred Baker volunteered to write an Informational document covering experience in partial mesh networks. The document will be posted on the mailing list and discussed there. Inverse ARP for IPX The group decided that the definition of InARP for IPX might better be handled by Novell. There were several companies which already have an implementation of InARP for IPX, but the attendees could not remember details. It was decided that the discussion would take place off-line among those who had already implemented InARP for IPX. Caralyn Brown agreed to be editor for a document describing a common method for IPX InARP. Inverse ARP Extensions During the IP over ATM discussions, it was felt that InARP was not robust enough. Specifically, a requesting station could not determine whether an InARP request was lost, or the responding station did not have an appropriate answer. It was suggested that InARP be expanded to contain a NAK. The group did not disagree with the suggestion, but decided that, because this problem was related to ATM's ARP server, the IP over Asynchronous Transfer Mode Working Group (ATM) should pursue this work. IEEE 802.5 Source Routing Over Frame Relay Those who were most interested in this topic were not present at the meeting. It was decided that this should be taken to the mailing list for further discussion. Attendees Anthony Alles aalles@cisco.com Fred Baker fbaker@acc.com Caralyn Brown cbrown@wellfleet.com Steve Buchko stevebu@newbridge.com David Carr dcarr@gandalf.ca Cheng Chen chen@accessworks.com Frank Ciotti frankc@telxon.com George Clapp clapp@ameris.ameritech.com Thomas Coradetti tomc@digibd.com Robert Downs bdowns@combinet.com Craig Fox craig@ftp.com Vincent Gebes vgebes@sys.attjens.co.jp Daniel Grossman dan@merlin.dev.cdx.mot.com Chris Gunner gunner@dsmail.lkg.dec.com Joel Halpern jmh@network.com B.V. Jagadeesh bvj@novell.com Jan-Olof Jemnemo jan-olof.jemnemo@farsta.trab.se David Kaufman dek@magna.telco.com Stev Knowles stev@ftp.com Sundar Kuttalingam sundark@wiltel.com William Kwan kwan@rabbit.com Thang Lu tlu@mcimail.com Andrew Malis malis@maelstrom.timeplex.com William Miskovetz misko@cisco.com Orly Nicklass orly@radmail.rad.co.il Drew Perkins ddp@fore.com David Rand dave_rand@novell.com Allen Rochkind Allen_Rochkind@3com.com Robert Roden roden@roden.enet.dec.com Benny Rodrig brodrig@rnd-gate.rad.co.il Chi Shue chi@casc.com Keith Sklower sklower@cs.berkeley.edu Douglas Williams dougw@vnet.ibm.com