CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT) Two documents were referred, without discussion, to the IESG for consideration as Proposed Standards. o ``PPP over ISDN'' (draft-ietf-pppext-isdn-03.txt) o ``PPP over SONETE/SDH'' (draft-ietf-pppext-sonet-01.txt) The following Drafts generated quite a bit of discussion. o ``PPP over X.25'' (draft-ietf-pppext-x25-02.txt) Should the language in the document be changed to say must not instead of should not about the sending of the 0xCF encapsulation if the connection was established with the zero Call User Data? Resolution: the language is acceptable as it stands since it does not propose using the 0xCF encapsulation for times other than when PPP is desired. The document is recommended to the IESG for consideration as a Proposed Standard. o ``PPP in Frame Relay'' (draft-ietf-pppext-frame-relay-02.txt) - The interaction with RFC 1490 systems may be indeterminate. - To make it determinate, data protocols (not control protocols) must use RFC 1490 encapsulation. - This is per PPP/IPLPDN agreements from Columbus and Amsterdam. - Requirement is a direct result of separating Bill and Keith's documents. The question was raised: If a system dies, how can the other system tell if we are using the 0xCC data encapsulation? It was also suggested that we use a SNAP encapsulated negotiation if we want to revert to 1490 and use the 0xCF otherwise. Recommendation: Insert a new sentence in the PPP/Frame Relay document that would clarify the requirement that a system re-negotiate if it sees an encapsulation it was not expecting. The final vote for this results in several options. - Option 1: The result of the negotiation results in the PPP encapsulation and provides an LCP option to change the encapsulation to 1490. - Option 2: If the negotiations are performed on a medium that has a default encapsulation, default to the media's preferred encapsulation type. Provide an LCP option to go back to PPP (0xCF) encapsulation. - Option 3: There should be no LCP option for changing the encapsulation type. Final vote: Option 1: 1, Option 2: 23, Option 3: 5, Abstain: 10. Given this option, it is recommended that the single sentence be added to draft-ietf-pppext-frame-relay-02.txt, and the resulting draft-ietf-pppext-frame-relay-03.txt be considered by the IESG as a Proposed Standard. The obvious place to put this option is ``PPP LCP Extensions'' (draft-ietf-pppext-lcpext-04.txt), but it contains other work that has been waiting and needs to be moved forward. Therefore, the recommendation is that draft-ietf-pppext-lcpext-04.txt be considered by the IESG as a Proposed Standard, and another document will be drawn up describing the LCP option for negotiation of encapsulations. [A note from the PPPEXT Chair: It is not clear that the group reached an effective consensus concerning the default encapsulation, or that this consensus represents the many members of the PPP Working Group who were not in the meeting. It was stated clearly and unanimously conceded in the meeting that the indeterminate interaction with RFC 1490 systems is only of concern if the default data encapsulation is 1490-style; if the negotiation results in the use of the PPP encapsulation, and given the renegotiation on receipt of the other encapsulation, there is no ambiguity. The members of IPLPDN present in the meeting stated that they found the ambiguity acceptable because it enabled them to not change their micro code for their routers, to which the counter-argument was made that to continue using the 1490 encapsulation they need only not negotiate the indicated NCP. The chair observes that there is also a backward compatibility issue; by the time the working group agrees on the LCP option and publishes a document, there will assuredly be compliant PPP/Frame Relay implementations fielded, which will be using the 0xCF data encapsulation it recommends. The chair also notes, without prompting from the members of the working group, that it is as easy for one political camp to negotiate the option as it is for the other, so the argument that the default must be to use 1490 encapsulation after the NCP has been negotiated appears weak. The chair further notes that the PPP encapsulation inside a compressed or multi-link data stream is (by specification) the PPP encapsulation without any address/control field, requiring Frame Relay system to recognize the encapsulation anyway if they use the PPP features that they wish to import. The chair notes that he has sought throughout this debate to mediate a strong disagreement between two working groups, and give each what they wish out of it. The objective facts seem to suggest that the LCP option should negotiate the use of a non-PPP encapsulation after the negotiation of the NCP, as the use of the PPP encapsulation is provably correct and the other---a point freely admitted by the proponents of the other position---is not. This is the most important attribute of all, and should, in his opinion, drive the debate to its conclusion. The chair's recommendation (to be freely and spiritedly debated by all who wish) is that the document describing the option should be drawn up by Bill Simpson, indicating that the default encapsulation is the provably correct PPP encapsulation, but that the other is negotiable. The updated PPP/Frame Relay document and the document describing this LCP option should become Proposed Standards together.] Day 2 - Further Document Review Dave Rand presented the ``PPP Reliable Transmission'' document, (draft-ietf-pppext-reliable-00.txt). After some discussion, the document was recommended for consideration by the IESG as a Proposed Standard. Dave also presented ``The PPP Compression Control Protocol (CCP)'', (draft-ietf-pppext-compression-01.txt). Numerous changes were recommended by the working group, separating the ``Predictor'' algorithm into a separate document, and modifying the structure of the CCP options. These will be edited into a new draft, which will be posted in the Internet-Drafts directory for discussion. It is anticipated that this work can be sent to the IESG before year end. Rich Bowen then presented the updated ``PPP Bridging Control Protocol (BCP)'' document (draft-ietf-pppext-for-bridging-01.txt). Minor revisions were suggested. It is anticipated that this will go to the IESG by year end. Thomas Dimitri presented his NETBEUI/PPP proposal, ``The PPP NetBIOS Frames Control Protocol (NBFCP)'' (draft-ietf-pppext-netbios-fcp-00.txt). This was cut short due to time constraints and will be taken to the list. Keith Sklower discussed ``The PPP Multilink Control Protocol (MCP)'' (draft-ietf-pppext-multilink-02.txt), that he had mailed to the list just before the IETF meeting. This discussion continued with key players during lunch. He will post the draft (draft-ietf-pppext-multilink-03.txt) for discussion; it is anticipated that this work will be ready for IESG consideration by year end. The chair had planned to discuss the plan for the PPPEXT Working Group for the coming two years, but was unable to do so due to lack of time. This matter will be taken to the list. Attendees Andy Adams ala@merit.edu James Allard jallard@microsoft.com Fred Baker fbaker@acc.com Rich Bowen rkb@ralvm11.vnet.ibm.com Caralyn Brown cbrown@wellfleet.com Steve Buchko stevebu@newbridge.com David Carr dcarr@gandalf.ca Cheng Chen chen@accessworks.com Chris Chiotasso chris@lightstream.com George Clapp clapp@ameris.ameritech.com Thomas Coradetti tomc@digibd.com Jonathan Didner jonb@bangate.compaq.com Thomas Dimitri tommyd@microsoft.com Robert Downs bdowns@combinet.com Craig Fox craig@ftp.com Richard Fox rfox@metricom.com John Gawf gawf@compatible.com Shawn Gillam shawn@timonware.com Daniel Grossman dan@merlin.dev.cdx.mot.com Chris Gunner gunner@dsmail.lkg.dec.com Joel Halpern jmh@network.com Ronald Jacoby rj@sgi.com B.V. Jagadeesh bvj@novell.com Jan-Olof Jemnemo jan-olof.jemnemo@farsta.trab.se David Kaufman dek@magna.telco.com Robert Lutz Andrew Malis malis@maelstrom.timeplex.com Glenn McGregor ghm@lloyd.com William Miskovetz misko@cisco.com Dennis Morris morris@altair.disa.mil Andy Nicholson andyni@microsoft.com Todd Palgut todd@nei.com Eric Peterson elpeterson@eng.xyplex.com James Philippou japhilippou@eng.xyplex.com Venkat Prasad vsp@3com.com David Rand dave_rand@novell.com Kenneth Rehbehn kjr@netrix.com Allen Rochkind Allen_Rochkind@3com.com Robert Roden roden@roden.enet.dec.com Benny Rodrig brodrig@rnd-gate.rad.co.il Paul Serice serice@cos.com Satya Sharma ssharma@chang.austin.ibm.com William Simpson Bill.Simpson@um.cc.umich.edu Keith Sklower sklower@cs.berkeley.edu Timon Sloane timon@timonware.com Steve Suzuki steve@fet.com Thomas Walsh tomw@kalpana.com James Watt james@newbridge.com Bradley Wilson wilson@ftp.com Honda Wu honda@nat.com Mauro Zallocco mdz@netlink.com