home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / iesg / iesg.93-12-16 < prev    next >
Text File  |  1993-12-31  |  4KB  |  98 lines
  1.    DRAFT * DRAFT * DRAFT * DRAFT *  DRAFT * DRAFT * DRAFT * DRAFT *    
  2.       
  3.             INTERNET ENGINEERING STEERING GROUP (IESG)
  4.                        December 16, 1993
  5.  
  6.          Reported by:  Steve Coya, Acting IESG Secretary
  7.  
  8. This report contains IESG meeting notes, positions and action items.
  9.  
  10. These minutes were compiled by the IETF Secretariat which is supported
  11. by the National Science Foundation under Grant No. NCR 8820945.
  12.  
  13. For more information please contact the IESG Secretary.
  14. iesg-secretary@cnri.reston.va.us.
  15.  
  16.  
  17.  
  18. ATTENDEES
  19. ---------
  20.  
  21.     Bradner, Scott / Harvard
  22.     Chapin, Lyman / BBN
  23.     Coya, Steve / CNRI
  24.     Crocker, Dave / SGI
  25.     Gross, Philip / ANS
  26.     Huitema, Christian  / INRIA (IAB Liaison)
  27.     Huizer, Erik / SURFnet
  28.     Klensin, John / UNU
  29.     Knowles, Stev / FTP Software
  30.     Mankin, Allison / NRL
  31.     Reynolds, Joyce / ISI
  32.     Piscitello, Dave/ Bellcore
  33.     Rekhter, Yakov / IBM (IAB Liaison)
  34.     Rose, Marshall / DBC
  35.  
  36. Regrets
  37.     Hinden, Robert / SUN
  38.     Crocker, Steve / TIS
  39.  
  40. 1. The minutes of the December 2, 1993 meeting were approved. Coya will
  41.    place copy in the public directories
  42.  
  43. 2. The IESG approved the publication of the following three
  44.    Internet-Drafts as Proposed Standard:
  45.  
  46.      Network Services Monitoring MIB
  47.     Mail Monitoring MIB
  48.     X.500 Directory Monitoring MIB
  49.  
  50.    Coya to send notification to the IETF and the RFC Editors
  51.  
  52.  
  53. 3. The IESG discussed the status of the Classical IP and ARP over ATM
  54.    document that has been submitted for Proposed Status. The WG needs
  55.    to clarify the meaning of "Classical" as used in the document. If it
  56.    refers to IPv4, the use of the word MUST in requiring a router
  57.    between virtual lans must be changed. If it refers to the classical
  58.    paradigm, then it would be acceptable. A revision of the document
  59.    clarifying the definition of Classical is required.
  60.  
  61.    Scott will send message to the WG conveying the concerns of the IESG
  62.    and requesting that a revision be submitted as an Internet-Draft
  63.    which clarifies the definition of the word Classical.
  64.  
  65.  
  66. 4. The IESG approved the publication of Questions and Answers to
  67.    Commonly Asked "Primary and Secondary School Internet User" Questions"
  68.    <draft-ietf-isn-faq-02.txt> as an Informational FYI RFC.
  69.  
  70. 5. The IESG approved the publication of Essential Tools for the OSI
  71.    Internet <draft-ietf-noop-tools-03.txt> as an Informational FYI RFC.
  72.  
  73. 6. The status of the Router Requirements document was discussed. The
  74.    current document will be submitted as an Internet-Draft, and a
  75.    new Router Requirements Working Group will be established. Stev and
  76.    Dave P. will work together on identifying and choosing the WG Chair.
  77.  
  78. 7. The IESG approved RSVP as a Working Group in the Transport Services
  79.    Area. Coya to enter charter and milestone information and send an
  80.    announcement to the IETF community.
  81.  
  82. 8. Scott Bradner requested that if any Area Director knows of a
  83.    proposal that might have some operational impact, they should give
  84.    the OPS Area Director an explicit referral.
  85.  
  86. 9. The IESG discussed the Simple Network Paging Protocol document which
  87.    is an individual submission. Discussion moved to the more general
  88.    topic of whether the IESG can insist or request that text reflecting
  89.    the IESG's opinion on the subject be included as part of the
  90.    document. While this has been done in the past for experimental
  91.    protocols, there was a difference of opinion as to whether this
  92.    ability could or should be expanded to include Informational RFCs.
  93.    It was noted that the RFC Editor had implied that additional text
  94.    would be considered. No consensus was reached. 
  95.  
  96.  
  97.  
  98.