home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / pppext / pppext-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  6KB  |  184 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. IETF PPP Extensions Working Group
  4. San Jose, 12/10/96
  5. Minutes taken by Matt Holdrege <mholdrege@ascend.com>
  6.  
  7. L2TP - Andy Valencia, Gurdeep Singh Pall (absent)
  8.  
  9. Consensus on all pending issues
  10.     Transport independence - Not dependent on TCP/IP
  11.     Security
  12.     Attribute numbering
  13.     Control message delivery via small LAPD-like reliable protocol
  14.  
  15. Organization of attribute-value pair number required several iterations
  16. Consensus on 
  17.     number globally
  18.     document locally
  19.     Where possible, share a common description
  20.  
  21. For IP tunnel media, L2TP recommends IPsec
  22.  
  23. Next: 
  24. Edit and insert markups submitted
  25. Andy will publish draft hopefully in 4 weeks
  26. Implement!
  27. Initial interoperability testing at CIUG in May 1997
  28.  
  29. John Shriver (Shiva) wants authentication to occur earlier before the
  30. tunnel begins to accommodate users with older protocols. This issue
  31. will move to the list.
  32.  
  33.  
  34.  
  35. L2TP  Security - Baiju Patel
  36.  
  37. Basically it was recommended to use IPSEC.
  38.  
  39.  
  40.  
  41. PPP over Sonet/SDH - RFC 1619 - Bill Simpson
  42.  
  43. pppsdh@greendragon.com is the new list for this protocol.
  44. [New information: listserv@watervalley.net is the address to subscribe
  45. to pppsdh. In the body of the message, say subscribe pppsdh YOUR NAME]
  46.  
  47.  
  48.  
  49. PPP Vendors Extensions - Bill Simpson - draft-ietf-pppext-vendor-00.txt
  50.  
  51. Recommended to move to an Informational RFC. All implementors should
  52. review before requesting numbers from IANA.
  53.  
  54.  
  55.  
  56. Protocol Spoofing - Randy Sales of Novell - draft-ietf-pppext-spoof-00.txt
  57.  
  58. Novell has a current implementation in their lab. Randy said that the
  59. draft author (Ian - Not Present) has not been able to further refine
  60. the draft. Novell would like the PPPEXT WG to help further refine this
  61. protocol. It was brought up that this draft has a scalability issue in
  62. reference to callback numbers. Novell said that they hope to use
  63. tunneling protocols to aid this scaling issue. Further work on timer
  64. negotiation needs to be done.
  65.  
  66. John Shriver from Shiva requested that Novell publish a paper
  67. detailing just how to spoof NCP. Novell agreed.
  68.  
  69. Bill Simpson noted that IPXCP already covers IPX spoofing. Bill also
  70. noted that we have too many protocols that use callback. Bill hopes
  71. that we can make whatever changes are necessary to IPXCP to satisfy
  72. needs.
  73.  
  74.  
  75.  
  76. LCP extensions & callback. Bill sent two drafts out after the deadline.
  77.  
  78.  
  79.  
  80. BACP - Craig Richards (absent), Kevin Smith (absent) -
  81. draft-ietf-pppext-bacp-05.txt
  82.  
  83. Change the number for BAP so that it doesn't compress. Recommend to
  84. create a new version of this draft. Karl will request new numbers from
  85. IANA. Ascend is the only vendor in the room shipping BACP.
  86.  
  87.  
  88.  
  89. ISSLOW - Carsten Bormann
  90.  
  91. They want to provide fragmentation and suspend/resume mechanisms,
  92. header compression, and obtain compressability hints from the
  93. application.
  94.  
  95. Big packets can be fragmented by MP, small packets would be sent
  96. outside of MP.
  97.  
  98. As for suspending, they need something like H.324 or DSVD. The V.80
  99. modem standard has much lower latency than V.34 and was recommended
  100. for RTP applications.
  101.  
  102. They want to make use of the reserved bits in MP header to define
  103. classes of priority.
  104.  
  105. They want to define a scheme where the fragmenters and suspenders can
  106. happily interoperate. Refer to isslow-fragment-ext-00.txt and
  107. draft-ietf-issll-isslow-mcml-00.txt
  108.  
  109.  
  110. Anita Freeman noted that the next Pac Bell PPP interoperability
  111. testing would take place from May 12-16th.
  112.  
  113. -----------------------------------------------------------------------------
  114.  
  115. IETF PPP Extensions Working Group
  116. San Jose, 12/11/96
  117. Minutes taken by Scott Wasson <sgw@sgw.xyplex.com>
  118.  
  119. Steve Casner, IP/UDP/RTP Compression
  120.  
  121. - Steve gives a presentation of RTP compression, which is similar to
  122.   VJ TCP/IP Header Compression.
  123.  
  124. - Need PPP packet types assigned, to differentiate between the IPv4
  125.   compression, and several new flavors to support compressed RTP and
  126.   UDP.
  127.  
  128. - Desire is to combine IPv4 and IPv6 compression into one document.
  129.  
  130. - Discussion about whether both compressions should/would run
  131.   concurrently.  Both NCPs could be Open, allowing independence.
  132.   Decision was to not allow concurrence so that the existing VJ
  133.   Protocol ID's could be recycled.
  134.  
  135. John Vollbrecht, Larry Blunk, EAP
  136.  
  137. - No changes needed to the current draft; any new additions to go into
  138.   a new add-on draft.
  139.  
  140. IP Address option negotiation
  141.  
  142. - None of the original protagonists were present, so the group
  143.   discussed the issue in their absence.  Anything "decided" obviously
  144.   has to be taken to the mailing list to reach full consensus.
  145.  
  146. - If unit sends:
  147.  
  148.     Req(0) ->
  149.  
  150.   and peer sends back:
  151.  
  152.     <- Nak(addr) ;That's OK.
  153.     <- Nak(0)     ;Prohibited!  Never do!
  154.     <- Rej()     ;take default value, "Not Configured".
  155.     <- Ack(0)     ;Prohibited!  Never do!
  156.  
  157.   Question is: What is the default value of this option? Unnumbered?
  158.   Manually configured?  Not configured?  Decided "Not configured"
  159.   should be the default.  This is no change from before.
  160.  
  161. - Discussion about adding a 2-byte "Numbered/Unnumbered" option.
  162.  
  163. - We found that some vendors send cr-0, expecting the peer to supply
  164.   an IP address.  They hoped that the peer would send ca-0, meaning,
  165.   "I don't have an address to give you, so if you really do have an
  166.   address but were just trying to be polite and let me pick it, and
  167.   since I don't have one to give you, now send me yours."
  168.  
  169. - Consensus was that the originator shouldn't have attempted to be so
  170.   polite.  Just send its address.
  171.  
  172. - Frank K. stepped up and pointed out that we were going in circles on
  173.   the numbered/unnumbered issue, and that we should write up our
  174.   discussion and bring it to the mailing list.
  175.  
  176. - Brief mention of the next L2TP draft - hope to have it by the end of
  177.   January.
  178.  
  179. -----------------------------------------------------------------------------
  180. -- 
  181. Karl Fox, servant of God, employee of Ascend Communications
  182. 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221   +1 614 326 6841
  183.  
  184.