Subject: Minutes from CIUG bakeoff town meeting

From: Don Grosser <[email-masked]>
Date: Thu, 26 Feb 1998 11:57:15 -0500

Here are the minutes from the town meeting at the CIUG interoperability
workshop in San Francisco.  Please report any issues or mistakes to the
mailing list.

Wednesday, February 25, 1998

o Tested at the bakeoff:
   - MLPPP - no issues
   - BACP/BAP - no issues
   - CCP - no specification issues
   - MPPE - no issues
   - ECP - no issues
   - EAP - no issues, tested with MD5 only
   - AO/DI - no issues
   - L2TP - see comments below...

o Not tested at the bakeoff (but were listed):
   - IPSEC w/L2TP

o Next bakeoff:

   - functions that will be tested:
      + CCP
      + L2TP
      + ECP (with stateless option)
      + EAP
      + MPPE
      + AO/DI

   - Bob Larribeau will post which protocols will be tested before 
     the next bakeoff.  Please send any additional reqests to 
     [email-masked].

o L2TP

   1.) typographical problems:
      + Everyone is strongly encouraged to send typos in draft 09 
        to the L2TP mailing list.

   2.) Clarifications:
      + It was noted that ACKs should not be delayed on lossy networks
         > Mark Townsley said that the recommended ACK strategy is 
           modeled after TCP & PPTP. Further, an implementation is 
           free to choose an alternative RTT calculation.
      + It was noted that bearer and framing types should be clarified
         > Bill Palter said that framing type is a hint for incoming
           calls and what is desired for outgoing calls. It is also 
           used for logging purposes.
         > Clarification will be added.
      + Clarification for the dialed-number and sub-address semantics
        will be added. 
      + Most of section 8.1 will be moved to a new lossy-network 
        appendix.
      + It was noted that examples of partial authentication between 
        the client and LAC should be included.
         > Mark Townsley said that partial authentication should not 
           violate PPP from the client's perspective.
         > Examples for common situations will be added.
      + It was noted that hostname semantics should be clarified.  No
        NULL characters should be included in the hostname AVP.  A
        byte-by-byte check should be sufficient. Presence of the 
        lenth field in the AVP is enough of an inditcation that
        the string should not be NULL-terminiated.
         > No clarifying text will be added.
      + It was noted that one vendor only ACks MRU of 1500 
         > This is a TCP/MSS/host requirements problem or 
           specific implementation issue rather than a 
           problem with PPP or L2TP.
      + CHAP re-challenge was a problem for one vendor when the LNS 
        challenged the client with a different name than the name 
        sent in the original challenge from the LAC.  The client 
        recognized it was challenged by 2 different peers and hung up.
         > Karl Fox suggested a knob for the client to turn off this
           check.
      + The draft will be updated to state that it is HDLC "slanted".
         > It was noted that tunneling PPP over X25 could be 
           problematic.
      + The draft will be updated to say that you can't hide the 
        hostname AVP in any packet or assigned-tunnel-id AVP in the 
        StopCCN.
      + It was noted that the draft needs to be consistent with its
        use of the Mandatory-Bit among the table, text and graphics.
         > Everyone is encouraged to post inconsistencies to the list.
      + It was noted that there should be more guidance for LCP 
        options on the LNS.
         > The draft will be changed to point to existing encapsulation
           specifications for initial parameter suggestions.
 
   3.) Changes to bits over the network
      + It was noted that we should consider not sending 'FF 03' over
        the tunnel.
         > Karl Fox said that it is too late for such a large change
           to the draft.  
        
-- 
Donald B. Grosser                            [email-masked]
IBM Corporation                                  Phone (919)254-2160
Remote Access Software                             Fax (919)543-7378

---

From: Don Grosser <[email-masked]>
Date: Thu, 26 Feb 1998 17:46:08 -0500

>            free to choose an alternative RTT calculation.

expanding on this item...

The recommendation was to not change the wording on congestion 
control.  The text ALLOWS sending ACKs on a per packet basis, but 
suggests other techniques that should be used (eg DELAYED ACKS).
-- 
Donald B. Grosser                            [email-masked]
IBM Corporation                                  Phone (919)254-2160
Remote Access Software                             Fax (919)543-7378