PPP Meeting Minutes for the IETF Meeting, November 1993

[Fred Baker <[e-mail]>]

PPP Meeting Minutes for the IETF Meeting, November 1993

Two documents were referred to the IESG for consideration as Proposed 
Standards without discussion:
        draft-ietf-pppext-isdn-03.txt
        draft-ietf-pppext-sonet-01.txt

PPP over X.25 (draft-ietf-pppext-x25-02.txt) generated discussion: 
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.

Discussion of PPP over Frame Relay:

Issues on the table are:
 -- 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 & 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 provide 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.

draft-ietf-pppext-lcpext-04.txt is the obvious place to put this option, 
but contains other work that has been waiting and needs to move 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.

  An editorial note by the chair: it is not clear that the group reached 
  an effective consensus concerning the default encapsulation, or that 
  this consensus represents the many 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...

Dave Rand presented the PPP/LAPB document, draft-ietf-pppext-reliable-
00.txt. After some discussion, the document was recommended for 
consideration by the IESG as a Proposed Standard.

Dave Rand then presented the Compression Control Protocol, 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 Bridging document, pppext-for-
bridging-01.txt. Minor revisions were suggested. It is anticipated that 
this will go to the IESG by year end.

Thomas Dimitri then presented his NETBEUI/PPP proposal, draft-ietf-
pppext-netbios-fcp-00.txt. This was cut short due to time constraints 
and taken to the list.

Keith Sklower then discussed 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 a draft named 
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 PPP 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.

Respectfully submitted,

Fred Baker
Chair

=============================================================================
Don't blame ACC; they think I'm nuts too!