Subject: Re: [nmrg] meetings
From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 19 May 1999 14:18:00 +0200

On Wed, 19 May 1999 13:35:47 +0200, Juergen Schoenwaelder wrote:
> 
> I will meet Aiko on Sunday morning at 10:00 am at the Boston Park
> Plaza Hotel. Its fine with me if you want to join us.

OK
Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Wed, 19 May 1999 13:35:47 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] meetings
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

J> It appears that we will be the only NMRG members present at
J> IM'99. When and where shall we meet? I will take the plane tomorrow
J> morning, so we need to decide fast. If you read this message after
J> 7pm today, please leave a message for me at the reception of the
J> Boston Park Plaza Hotel.  What about having lunch together on
J> Sunday 23?

I will meet Aiko on Sunday morning at 10:00 am at the Boston Park
Plaza Hotel. Its fine with me if you want to join us.

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] meetings 
Date: Wed, 19 May 1999 13:33:07 +0200
Sender: [email-masked]

On Sat, 01 May 1999 13:09:43 +0200, Aiko Pras wrote:
> 
> I'll be at the IM'99. Although I have not yet arranged my flight,
> most meeting times will be possible for me. Who else is going to
> IM'99? And in what hotels are you staying? I would like to stay
> in the same hotel, so it would be easier to meet.

Juergen and Aiko,

It appears that we will be the only NMRG members present at IM'99. When
and where shall we meet? I will take the plane tomorrow morning, so we
need to decide fast. If you read this message after 7pm today, please
leave a message for me at the reception of the Boston Park Plaza Hotel.
What about having lunch together on Sunday 23?

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Tue, 18 May 1999 17:27:17 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
Subject: [nmrg] [[email-masked]: New IRTF Chair in September]
Sender: [email-masked]

For your information.
							Juergen

------- Start of forwarded message -------
Date: Tue, 18 May 1999 15:46:16 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM Internet Division
To: Karen Sollins <[email-masked]>, Bob Braden <[email-masked]>,
        Susan Hares <[email-masked]>, Allison Mankin <[email-masked]>,
        Cecilia Preston <[email-masked]>,
        Clifford Lynch <[email-masked]>,
        Ran Canetti <[email-masked]>, Dan Harkins <[email-masked]>,
        Mark Handley <[email-masked]>, Sid Nag <[email-masked]>,
        Juergen Schoenwaelder <[email-masked]>,
        Harald Tveit Alvestrand <[email-masked]>,
        IAB <[email-masked]>, Rob Austein <[email-masked]>,
        Geoff Huston <[email-masked]>, Ran Atkinson <[email-masked]>
CC: IESG <[email-masked]>, IAB <[email-masked]>
Subject: New IRTF Chair in September

To: all IRTF members, and other interested parties

[Research Group chairs, please forward to your groups.
Steve Coya, please forward to ietf-announce.]

During March, the IAB called for nominations for the position
of Chair of the Internet Research Task Force (IRTF), since 
Abel Weinrib expressed his desire to step down. We received 
twenty excellent nominations by the closing date of April 15, 
and had considerable diffculty choosing among those nominees 
willing to serve. After careful discussion, the IAB is pleased 
to announce the appointment of 

            Erik Huizer 

as Chair of the IRTF for two years starting in September 1999.
A short biography is attached below.

I would like to take this opportunity to thank Abel Weinrib for
his years of service, to thank the unsuccessful candidates
for their willingness to serve, and to wish Erik every success.

   Brian Carpenter
   IAB Chair

==========

Erik Huizer is the Managing Director of the SURFnet ExpertiseCentrum 
bv, a company based in the Netherlands that does network development, 
design, planning, support, training and consultancy for an 
international customer base.
 
>From 1988 till 1994 he worked as a Technical Manager at SURFnet bv, the 
company that operates the Academic and Research network in The 
Netherlands. 
 
Huizer has extensive experience with Internet technology. He has
been a member of the RARE (now Terena) Technical Committee from 
1991-1994. He was an Area Director for the Applications area of the 
Internet Engineering Task Force from 1990-1995. He was a member of the 
Internet Architecture Board from 1995-1999. Huizer is currently 
involved with the GigaPort project (http://www.gigaport.nl/), the Dutch 
national project for the Next Generation Internet.
 
Huizer received his Ph. D. degree in Science and Technology from Delft
University of Technology, The Netherlands, in 1987.

============
------- End of forwarded message -------

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] SMIng - another work item for the NMRG? 
Date: Fri, 14 May 1999 17:36:44 +0200
Sender: [email-masked]

On Wed, 12 May 1999 18:47:20 +0200, Juergen Schoenwaelder wrote:
> 
> Here is a proposal to add another work item to the NMRG. This is a
> poll for opinions from the NMRG members.
> 
> [...]
> 
> The proposal is to continue the development of SMIng under the
> umbrella of the NMRG. This means that the specification of SMIng will
> be published as an internet draft of the NMRG rather than an
> individual submission and that we will use some of the bandwidth of
> the NMRG mailing list for further discussions on SMIng.

I agree with your proposal. I think it's a good idea. Your student
did an excellent work, especially in laying out the outcome of his
M.S. thesis at:

  http://www.ibr.cs.tu-bs.de/~strauss/sming/

Note that the link behind IRTF-NMRG-SMING-TYPE is currently dangling.

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Wed, 12 May 1999 18:47:20 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: Network Management Research Group <[email-masked]>
CC: [email-masked]
Subject: [nmrg] SMIng - another work item for the NMRG?
Sender: [email-masked]

Here is a proposal to add another work item to the NMRG. This is a
poll for opinions from the NMRG members. Below is the description
of the proposal. Please share your comments.
							Juergen

Background:

As you all know, SMIv2 just recently got published as Internet
Standard 58 and I guess that the IETF is highly interested to keep
this standard stable for a while. Nevertheless, there are known
problems and shortcomings with SMIv2 which could not be fixed in the
revision process. Hence, we started to ask ourself how the next
generation of the SMI could look like. This was the birth of the SMIng
project. The goal was to stay compatible to the SMIv2 and to fix at
the same time as many of the known problems without turning SMIng into
a kitchen sink. This means that we have made many trade-off decisions
during the design of SMIng. SMIng is meant to be an evolutionary
rather than a revolutionary next step.

Status:

The SMIng project reached a state where we have a first complete
specification for SMIng as well as an implementation of MIB parsers
and converters between SMIv2 and SMIng. Frank Strauss, one of our
masters student, did most of the work as part of his final project
assignement. The implementation itself comes as an embeddable C
library for accessing MIB definitions and it will be freely
available. The implementation also supports SMIv1/SMIv2 for which
Frank developed a lex/yacc definition from scratch. (Frank did this
work during the SMIv2 revision process and he reported several
problems back to the SMI design team.) You can find more background
material as well as the current SMIng specification on Frank's Web
page at <URL:http://www.ibr.cs.tu-bs.de/~strauss/sming/>.

Proposal:

The proposal is to continue the development of SMIng under the
umbrella of the NMRG. This means that the specification of SMIng will
be published as an internet draft of the NMRG rather than an
individual submission and that we will use some of the bandwidth of
the NMRG mailing list for further discussions on SMIng.

-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] draft-irtf-nmrg-snmp-tcp-00.txt 
Date: Fri, 07 May 1999 18:25:26 +0200
Sender: [email-masked]

This is a multipart MIME message.

--==_Exmh_-21417432320
Content-Type: text/plain; charset=us-ascii

On Tue, 20 Apr 1999 11:44:16 +0200, Juergen Schoenwaelder wrote:
> 
> (I did not add definitions for IPv6 since we do not have a resolution
> for SNMP over UDP/IPv6 yet and I do not consider this important for
> our current goal.)

Agreed

> Below is the revised document for review.

Sorry I took so long to review it. You will find in attachment:

 1) the new draft that I propose
 2) a Unix diff between the old and the new draft

The main changes are:

1) I disagree with section 3.3: we should not restrict the use of TCP
here, we should only recommend some possible uses. Tomorrow, a good
reason might crop up to use it for something else, thereby rendering
our RFC obsolete.

2) I added a new paragraph to section 3.3 describing what I believe to
be another valid use of TCP instead of UDP. Comments are welcome.

The other changes are minor. I tried to be more systematic in the use
of MUST, SHOULD, CAN, etc. I also tried to be consistent in the number
of white spaces after a period, hence my changes in the IETF sections.

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

--==_Exmh_-21417432320
Content-Type: text/plain ; name="draft-tcp.new"; charset=us-ascii
Content-Description: draft-tcp.new
Content-Disposition: attachment; filename="draft-tcp.new"

Network Working Group                           J. Schoenwaelder, Editor
Internet-Draft                                           TU Braunschweig
Expires November 1999                                         7 May 1999

                    SNMP over TCP Transport Mapping

                   <draft-irtf-nmrg-snmp-tcp-01.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. Internet-Drafts are
   working documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups. Note that other groups MAY also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and MAY be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this document is unlimited. Please send comments to
   the Network Management Research Group <[email-masked]>.

Copyright Notice

   Copyright (C) The Internet Society (1999). All Rights Reserved.

Abstract

   This memo defines a transport mapping for using the Simple Network
   Management Protocol (SNMP) over TCP. The transport mapping defined in
   this memo can be used with any version of SNMP.

J. Schoenwaelder                                                [Page 1]

Internet-Draft      SNMP over TCP Transport Mapping           April 1999

   Table of Contents

   1 Introduction .................................................    3
   2 Definitions ..................................................    3
   3 SNMP over TCP ................................................    4
   3.1 Serialization ..............................................    4
   3.2 Well-Known Values ..........................................    4
   3.3 Connection Management ......................................    5
   4 Acknowledgments ..............................................    5
   5 References ...................................................    6
   6 Editor's Address .............................................    6
   7 Full Copyright Statement .....................................    7

J. Schoenwaelder                                                [Page 2]

Internet-Draft      SNMP over TCP Transport Mapping           April 1999

1.  Introduction

   This memo defines a transport mapping for using the Simple Network
   Management Protocol (SNMP) over TCP. The transport mapping defined in
   this memo can be used with any version of SNMP. This document extends
   the transport mappings defined in RFC 1906 [1].

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [2].

2.  Definitions

   IRTF-NMRG-SNMP-TM DEFINITIONS ::= BEGIN

   IMPORTS
       MODULE-IDENTITY, OBJECT-IDENTITY, experimental
           FROM SNMPv2-SMI
       TEXTUAL-CONVENTION
           FROM SNMPv2-TC;

   nmrgSnmpDomains MODULE-IDENTITY
       LAST-UPDATED "9904201100Z"
       ORGANIZATION "IRTF Network Management Research Group"
       CONTACT-INFO
           "Juergen Schoenwaelder
            TU Braunschweig
            Bueltenweg 74/75
            38106 Braunschweig
            Germany
            Tel: +49 531 391-3283
            E-mail: [email-masked]"
       DESCRIPTION
           "This MIB module defines the SNMP over TCP transport mapping."
       ::= { experimental nmrg(91) 1 }

   -- SNMP over TCP over IPv4

   snmpTCPDomain   OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION
           "The SNMP over TCP/IPv4 transport domain. The corresponding
            transport address is of type SnmpTCPAddress."
       ::= { nmrgSnmpDomains 6 }   -- matches first unused value
                                   -- below snmpDomains

   snmpTCPAddress ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1d.1d.1d.1d/2d"
       STATUS       current

J. Schoenwaelder                                                [Page 3]

Internet-Draft      SNMP over TCP Transport Mapping           April 1999

       DESCRIPTION
               "Represents a TCP/IPv4 address:

                  octets   contents        encoding
                   1-4     IP-address      network-byte order
                   5-6     TCP-port        network-byte order
               "
       SYNTAX      OCTET STRING (SIZE (6))

   END

3.  SNMP over TCP

   SNMP over TCP is an optional transport mapping. Implementors are
   encouraged to support SNMP over TCP whenever possible because this
   enables applications to make more efficient bulk transfers of MIB
   data [3].

   The originator of a request/response transaction chooses the
   transport protocol for the entire transaction. The transport protocol
   MUST NOT change during a transaction.

   In general, originators of request/response transactions are free to
   use the transport they assume is the best in a given situation.
   However, as TCP has a larger footprint on resource usage than UDP,
   applications using SNMP over TCP MAY choose to switch back to UDP by
   refusing new TCP connections whenever necessary (e.g. too many open
   TCP connections).

3.1.  Serialization

   Each instance of a message is serialized into a single BER-encoded
   message, using the algorithm specified in Section 8 of RFC 1906 [1].
   The BER-encoded message is then sent over a TCP connection.

   It is possible to exchange multiple SNMP request/response pairs over
   a single TCP connection (persistent connection). The length field in
   the BER-encoded SNMP message is used to separate multiple requests
   sent over a single TCP connection.

3.2.  Well-Known Values

   It is RECOMMENDED that administrators configure their SNMP entities
   acting in an agent role to listen on TCP port 161 for incoming
   connections, in addition to already listening on UDP port 161. It is
   also RECOMMENDED that notification sinks be configured to listen on
   TCP port 162, in addition to already listening on UDP port 162.

J. Schoenwaelder                                                [Page 4]

Internet-Draft      SNMP over TCP Transport Mapping           April 1999

   When an SNMP entity uses the TCP transport mapping, it MUST be
   capable of accepting messages that are at least 65495 octets in size.
   Implementation of larger values is encouraged whenever possible.

3.3.  Connection Management

   The use of TCP connections introduces costs. Connection establishment
   and teardown cause additional network traffic. Furthermore,
   maintaining open connections binds resources in the network layer of
   the underlying operating system.

   TCP connections SHOULD primarily be used when the large size of the
   data transferred would cause a large latency if UDP connections were
   used instead, due to the small size of UDP packets and the increased
   number of interactions.

   TCP connections MAY also replace UDP connections when the SNMP entity
   acting in a manager role does not support retransmissions over UDP
   at the application level. In this case, the automatic retries of TCP
   give a better chance to management data to be successfully
   transferred.

   All SNMP entities (whether in an agent role or manager role) CAN
   close the connections at any point in time. This ensures that SNMP
   entities can control their resource usage and shut down TCP
   connections that are not used. SNMP engines SHOULD NOT process any
   outstanding requests if the underlying TCP connection has been
   closed. A ``NoResponse'' error condition SHOULD be signalled for
   outstanding requests for command generator applications if the TCP
   connection is closed.

4.  Acknowledgments

   The definitions in this memo are inspired by definitions found in RFC
   1906 [1]. This document is the result of discussions of the Network
   Management Research Group (NMRG). Special thanks go to the following
   participants for their comments and contributions:

   Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels,
   Bert Wijnen.

J. Schoenwaelder                                                [Page 5]

Internet-Draft      SNMP over TCP Transport Mapping           April 1999

5.  References

[1]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport
     Mappings for Version 2 of the Simple Network Management Protocol
     (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc.,
     Dover Beach Consulting, Inc., International Network Services,
     January 1996.

[2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
     Levels", BCP 14, RFC 2119, Harvard University, March 1997.

[3]  Sprenkels, R., and Martin-Flatin, J.P., "Bulk Transfers of MIB
     Data", The Simple Times, Vol. 7, No. 1, pp. 1-7, March 1999.

6.  Editor's Address

     Juergen Schoenwaelder             Email: [email-masked]
     TU Braunschweig                     Tel: +49 531 391-3283
     Bueltenweg 74/75
     38106 Braunschweig
     Germany

J. Schoenwaelder                                                [Page 6]

Internet-Draft      SNMP over TCP Transport Mapping           April 1999

7.  Full Copyright Statement

   Copyright (C) The Internet Society (1998). All Rights Reserved.

   This document and translations of it MAY be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation MAY be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself MAY not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the  purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process MUST be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

J. Schoenwaelder                                                [Page 7]


--==_Exmh_-21417432320
Content-Type: text/plain ; name="draft-tcp.diff"
Content-Description: draft-tcp.diff
Content-Disposition: attachment; filename="draft-tcp.diff"

*** draft-tcp.old	Fri May  7 13:36:59 1999
--- draft-tcp.new	Fri May  7 17:57:39 1999
***************
*** 1,6 ****
  Network Working Group                           J. Schoenwaelder, Editor
  Internet-Draft                                           TU Braunschweig
! Expires October 1999                                       20 April 1999

                      SNMP over TCP Transport Mapping
--- 1,6 ----
  Network Working Group                           J. Schoenwaelder, Editor
  Internet-Draft                                           TU Braunschweig
! Expires November 1999                                         7 May 1999

                      SNMP over TCP Transport Mapping
***************
*** 10,23 ****
  Status of this Memo
  
     This document is an Internet-Draft and is in full conformance with
!    all provisions of Section 10 of RFC 2026.  Internet-Drafts are
     working documents of the Internet Engineering Task Force (IETF), its
!    areas, and its working groups.  Note that other groups may also
     distribute working documents as Internet-Drafts.
  
     Internet-Drafts are draft documents valid for a maximum of six months
!    and may be updated, replaced, or obsoleted by other documents at any
!    time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."
  
     The list of current Internet-Drafts can be accessed at
--- 10,23 ----
  Status of this Memo
  
     This document is an Internet-Draft and is in full conformance with
!    all provisions of Section 10 of RFC 2026. Internet-Drafts are
     working documents of the Internet Engineering Task Force (IETF), its
!    areas, and its working groups. Note that other groups MAY also
     distribute working documents as Internet-Drafts.
  
     Internet-Drafts are draft documents valid for a maximum of six months
!    and MAY be updated, replaced, or obsoleted by other documents at any
!    time. It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."
  
     The list of current Internet-Drafts can be accessed at
***************
*** 27,37 ****
     http://www.ietf.org/shadow.html
  
     Distribution of this document is unlimited. Please send comments to
!    the Network Management Research Group, <[email-masked]>.
  
  Copyright Notice
  
!    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  
  Abstract
  
--- 27,37 ----
     http://www.ietf.org/shadow.html
  
     Distribution of this document is unlimited. Please send comments to
!    the Network Management Research Group <[email-masked]>.
  
  Copyright Notice
  
!    Copyright (C) The Internet Society (1999). All Rights Reserved.
  
  Abstract
  
***************
*** 49,54 ****
--- 49,57 ----

  
+ 
+ 
+ 
  J. Schoenwaelder                                                [Page 1]
  
  Internet-Draft      SNMP over TCP Transport Mapping           April 1999
***************
*** 60,66 ****
     2 Definitions ..................................................    3
     3 SNMP over TCP ................................................    4
     3.1 Serialization ..............................................    4
!    3.2 Well-known Values ..........................................    4
     3.3 Connection Management ......................................    5
     4 Acknowledgments ..............................................    5
     5 References ...................................................    6
--- 63,69 ----
     2 Definitions ..................................................    3
     3 SNMP over TCP ................................................    4
     3.1 Serialization ..............................................    4
!    3.2 Well-Known Values ..........................................    4
     3.3 Connection Management ......................................    5
     4 Acknowledgments ..............................................    5
     5 References ...................................................    6
***************
*** 157,167 ****
         ::= { nmrgSnmpDomains 6 }   -- matches first unused value
                                     -- below snmpDomains
  
!    SnmpTCPAddress ::= TEXTUAL-CONVENTION
         DISPLAY-HINT "1d.1d.1d.1d/2d"
         STATUS       current
  
- 
  J. Schoenwaelder                                                [Page 3]
  
  Internet-Draft      SNMP over TCP Transport Mapping           April 1999
--- 160,169 ----
         ::= { nmrgSnmpDomains 6 }   -- matches first unused value
                                     -- below snmpDomains
  
!    snmpTCPAddress ::= TEXTUAL-CONVENTION
         DISPLAY-HINT "1d.1d.1d.1d/2d"
         STATUS       current
  
  J. Schoenwaelder                                                [Page 3]
  
  Internet-Draft      SNMP over TCP Transport Mapping           April 1999
***************
*** 175,180 ****
--- 177,183 ----
                     5-6     TCP-port        network-byte order
                 "
         SYNTAX      OCTET STRING (SIZE (6))
+ 
     END

***************
*** 182,222 ****
  
     SNMP over TCP is an optional transport mapping. Implementors are
     encouraged to support SNMP over TCP whenever possible because this
!    enables applications to use more efficient bulk MIB data transfers.
  
!    Note, the originator of a request/response transaction chooses the
!    transport protocol for the whole transaction. The transport protocol
     MUST NOT change during a transaction.
  
     In general, originators of request/response transactions are free to
     use the transport they assume is the best in a given situation.
!    However, since TCP costs in terms of resource usage are higher than
!    UDP costs, applications using SNMP over TCP may choose to switch back
!    to UDP (i.e. by refusing new TCP connections) whenever necessary
!    (i.e. too many open TCP connections).

  3.1.  Serialization
  
!    Each instance of a message is serialized into a single BER encoded
     message, using the algorithm specified in Section 8 of RFC 1906 [1].
!    The BER encoded message is then send over a TCP connection.
  
!    Note, it is possible to exchange multiple SNMP request/response pairs
!    over a single TCP connection. The length field in the BER encoded
!    SNMP message is used to separate multiple requests send over a single
!    TCP connection.

! 3.2.  Well-known Values
  
!    It is suggested that administrators configure their SNMP entities
     acting in an agent role to listen on TCP port 161 for incoming
!    connections.  Further, it is suggested that notification sinks be
!    configured to listen on TCP port 162.
! 
!    When an SNMP entity uses this transport mapping, it must be capable
!    of accepting messages that are at least 484 octets in size.

  J. Schoenwaelder                                                [Page 4]
--- 185,224 ----
  
     SNMP over TCP is an optional transport mapping. Implementors are
     encouraged to support SNMP over TCP whenever possible because this
!    enables applications to make more efficient bulk transfers of MIB
!    data [3].
  
!    The originator of a request/response transaction chooses the
!    transport protocol for the entire transaction. The transport protocol
     MUST NOT change during a transaction.
  
     In general, originators of request/response transactions are free to
     use the transport they assume is the best in a given situation.
!    However, as TCP has a larger footprint on resource usage than UDP,
!    applications using SNMP over TCP MAY choose to switch back to UDP by
!    refusing new TCP connections whenever necessary (e.g. too many open
!    TCP connections).

  3.1.  Serialization
  
!    Each instance of a message is serialized into a single BER-encoded
     message, using the algorithm specified in Section 8 of RFC 1906 [1].
!    The BER-encoded message is then sent over a TCP connection.
  
!    It is possible to exchange multiple SNMP request/response pairs over
!    a single TCP connection (persistent connection). The length field in
!    the BER-encoded SNMP message is used to separate multiple requests
!    sent over a single TCP connection.

! 3.2.  Well-Known Values
  
!    It is RECOMMENDED that administrators configure their SNMP entities
     acting in an agent role to listen on TCP port 161 for incoming
!    connections, in addition to already listening on UDP port 161. It is
!    also RECOMMENDED that notification sinks be configured to listen on
!    TCP port 162, in addition to already listening on UDP port 162.

  J. Schoenwaelder                                                [Page 4]
***************
*** 224,271 ****
  Internet-Draft      SNMP over TCP Transport Mapping           April 1999

     Implementation of larger values is encouraged whenever possible.

  3.3.  Connection Management
  
     The use of TCP connections introduces costs. Connection establishment
!    and shutdown causes additional traffic on the wire. Further,
     maintaining open connections binds resources in the network layer of
     the underlying operating system.
  
!    TCP connections should therefore only be used when the size of the
!    data transferred would otherwise cause large latencies due to small
!    UDP packet sizes and an increased number of interactions.
! 
!    Both, an SNMP entity in the agent role and an SNMP entity in the
!    manager role, are allowed to close the connections at any point in
!    time. This ensures that SNMP entities can control their resource
!    usage and shutdown TCP connections that are not used. Note, SNMP
!    engines are not expected to process any outstanding requests if the
!    underlying TCP connection has been closed. A no response error
!    condition SHOULD be signalled for outstanding requests for command
!    generator applications if the TCP connection is closed.

  4.  Acknowledgments
  
     The definitions in this memo are inspired by definitions found in RFC
!    1906 [1]. This document is the result of the Network Management
!    Research Group (NMRG). Special thanks go to the following
     participants for their comments and contributions:
  
     Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels,
!    Bert Wijnen
! 
! 
! 
! 
! 
! 
! 
! 
! 

  
--- 226,273 ----
  Internet-Draft      SNMP over TCP Transport Mapping           April 1999

+    When an SNMP entity uses the TCP transport mapping, it MUST be
+    capable of accepting messages that are at least 65495 octets in size.
     Implementation of larger values is encouraged whenever possible.

  3.3.  Connection Management
  
     The use of TCP connections introduces costs. Connection establishment
!    and teardown cause additional network traffic. Furthermore,
     maintaining open connections binds resources in the network layer of
     the underlying operating system.
  
!    TCP connections SHOULD primarily be used when the large size of the
!    data transferred would cause a large latency if UDP connections were
!    used instead, due to the small size of UDP packets and the increased
!    number of interactions.
! 
!    TCP connections MAY also replace UDP connections when the SNMP entity
!    acting in a manager role does not support retransmissions over UDP
!    at the application level. In this case, the automatic retries of TCP
!    give a better chance to management data to be successfully
!    transferred.
! 
!    All SNMP entities (whether in an agent role or manager role) CAN
!    close the connections at any point in time. This ensures that SNMP
!    entities can control their resource usage and shut down TCP
!    connections that are not used. SNMP engines SHOULD NOT process any
!    outstanding requests if the underlying TCP connection has been
!    closed. A ``NoResponse'' error condition SHOULD be signalled for
!    outstanding requests for command generator applications if the TCP
!    connection is closed.

  4.  Acknowledgments
  
     The definitions in this memo are inspired by definitions found in RFC
!    1906 [1]. This document is the result of discussions of the Network
!    Management Research Group (NMRG). Special thanks go to the following
     participants for their comments and contributions:
  
     Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels,
!    Bert Wijnen.

  
***************
*** 291,296 ****
--- 293,301 ----
  [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, Harvard University, March 1997.
  
+ [3]  Sprenkels, R., and Martin-Flatin, J.P., "Bulk Transfers of MIB
+      Data", The Simple Times, Vol. 7, No. 1, pp. 1-7, March 1999.
+ 

  6.  Editor's Address
***************
*** 328,336 ****

  
- 
- 
- 
  J. Schoenwaelder                                                [Page 6]
  
  Internet-Draft      SNMP over TCP Transport Mapping           April 1999
--- 333,338 ----
***************
*** 340,356 ****
  
     Copyright (C) The Internet Society (1998). All Rights Reserved.
  
!    This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain it
!    or assist in its implementation may be prepared, copied, published
     and distributed, in whole or in part, without restriction of any
     kind, provided that the above copyright notice and this paragraph are
!    included on all such copies and derivative works.  However, this
!    document itself may not be modified in any way, such as by removing
     the copyright notice or references to the Internet Society or other
     Internet organizations, except as needed for the  purpose of
     developing Internet standards in which case the procedures for
!    copyrights defined in the Internet Standards process must be
     followed, or as required to translate it into languages other than
     English.
  
--- 342,358 ----
  
     Copyright (C) The Internet Society (1998). All Rights Reserved.
  
!    This document and translations of it MAY be copied and furnished to
     others, and derivative works that comment on or otherwise explain it
!    or assist in its implementation MAY be prepared, copied, published
     and distributed, in whole or in part, without restriction of any
     kind, provided that the above copyright notice and this paragraph are
!    included on all such copies and derivative works. However, this
!    document itself MAY not be modified in any way, such as by removing
     the copyright notice or references to the Internet Society or other
     Internet organizations, except as needed for the  purpose of
     developing Internet standards in which case the procedures for
!    copyrights defined in the Internet Standards process MUST be
     followed, or as required to translate it into languages other than
     English.

--==_Exmh_-21417432320
Content-Type: text/plain; charset=us-ascii

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

--==_Exmh_-21417432320--

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] 484 octets 
Date: Fri, 07 May 1999 18:05:01 +0200
Sender: [email-masked]

On Fri, 7 May 1999 17:55:01 +0200, Juergen Schoenwaelder wrote:
> 
> I believe it is stupid to define a *protocol constant* in a MIB.

I don't understand your rationale, but since you're more experienced
in SNMP than I am, I'll follow your advice.

Jean-Philippe

Date: Fri, 7 May 1999 17:55:01 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] 484 octets
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> We're talking about bulk transfers here. If a box is so
JP> constrained that it can't have 64k buffers, then it's not a good
JP> candidate for TCP-based SNMP transfers, right?

Whatever number you pick, it is more or less an arbitrary choice. We
can debate endlessly whether 64k is too much or not. This is one of
the cases where you can ask N people and you will get at least N
different opinions.

JP> I picked this example from MIB-II, the first read-only variable
JP> that I found (sysDescr). I'm not familiar with SMI syntax, and I'm
JP> rushed by something else: could you tell me what I should change?

I believe it is stupid to define a *protocol constant* in a MIB.

JP> In our case, the value of snmpAnyDomainGuaranteedAcceptedSize
JP> (484) is specifiedin RFC 1906, but the other values
JP> (snmpUDPGuaranteedAcceptedSize = 1472,
JP> snmpCLNSGuaranteedAcceptedSize = 1472, etc.) aren't. 

Not true. The *protocol constant* is 484. All the other values are
just the opinion of a book author. And they definately do not belong
into the TCP transport mappings document.

JP> In my view, all well-known values ought to be readily retrievable
JP> via SNMP. The memory overhead is small for agents, the coding
JP> overhead is small for vendors, and it makes it easier for
JP> customers to shout at their suppliers if their box doesn't conform
JP> to what it announces to do. In a publish-subscribe view of
JP> management (which happens to be mine), agents publish what they
JP> support.

There is a difference whether you publish a *protocol constant* or
what is actually implemented in an agent.

JP> I'm finishing a new version of the TCP draft that I'll send
JP> shortly to the group. Should I put these constants definitions in,
JP> or do you think they're a bad idea?

I think *protocol constants* for the minimum maximum message size do
not belong into the MIB.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] 484 octets 
Date: Fri, 07 May 1999 17:28:10 +0200
Sender: [email-masked]

On Fri, 7 May 1999 16:49:31 +0200, Juergen Schoenwaelder wrote:
> 
> JP> I prefer the second value. I therefore suggest that we modify the
> JP> TCP draft and replace 484 octets with 65495 octets in section 3.2.
> 
> You really want to require that every implementation uses 64k buffers?
> I personally have no problem with that but I am sure some people from
> embedded systems will.

We're talking about bulk transfers here. If a box is so constrained
that it can't have 64k buffers, then it's not a good candidate for
TCP-based SNMP transfers, right?

> JP> I also believe that this value should be stored in the MIB and
> JP> suggest to add:
> 
> snmpTCPGuaranteedAcceptedSize  OBJECT-IDENTITY
>     SYNTAX  DisplayString (SIZE (0..255))
>     ACCESS  read-only
>     STATUS  current
>     DESCRIPTION
>             "All receiving TCP protocol entities are required to accept
>             messages of at least 65495 octets in length."
>     ::= { snmpTCPDomain 1 }
> 
> He? This is not legal SMIv2. A managed object which returns a protocol
> *constant* is IMHO useless. And why should it be a DisplayString of
> size (0..255)? I am confused.

I picked this example from MIB-II, the first read-only variable that
I found (sysDescr). I'm not familiar with SMI syntax, and I'm rushed
by something else: could you tell me what I should change?

Regarding the issue of a constant: I don't think it is a good idea to
put numeric constants in RFCs under the heading "Well-Known Values"
when these RFCs defined MIBs. And I think it is stupid to define them
outside these RFCs. In our case, the value of
snmpAnyDomainGuaranteedAcceptedSize (484) is specifiedin RFC 1906, but
the other values (snmpUDPGuaranteedAcceptedSize = 1472,
snmpCLNSGuaranteedAcceptedSize = 1472, etc.) aren't. Grouping all these
constants in a single repository is good engineering practice.

In my view, all well-known values ought to be readily retrievable via
SNMP. The memory overhead is small for agents, the coding overhead is
small for vendors, and it makes it easier for customers to shout at
their suppliers if their box doesn't conform to what it announces to
do. In a publish-subscribe view of management (which happens to be
mine), agents publish what they support.

I'm finishing a new version of the TCP draft that I'll send shortly
to the group. Should I put these constants definitions in, or do you
think they're a bad idea?

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Fri, 7 May 1999 16:49:31 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] 484 octets
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> For snmpTCPDomain, we can be conservative and take 1472 octets, as
JP> for snmpUDPDomain, or we can be agressive and pick 64k. More
JP> precisely:

[...]

JP> I prefer the second value. I therefore suggest that we modify the
JP> TCP draft and replace 484 octets with 65495 octets in section 3.2.

You really want to require that every implementation uses 64k buffers?
I personally have no problem with that but I am sure some people from
embedded systems will.

JP> I also believe that this value should be stored in the MIB and
JP> suggest to add:

snmpTCPGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving TCP protocol entities are required to accept
            messages of at least 65495 octets in length."
    ::= { snmpTCPDomain 1 }

He? This is not legal SMIv2. A managed object which returns a protocol
*constant* is IMHO useless. And why should it be a DisplayString of
size (0..255)? I am confused.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

From: "J.P. Martin-Flatin" <[email-masked]>
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] 484 octets 
Date: Fri, 07 May 1999 16:38:21 +0200
Sender: [email-masked]

On Fri, 7 May 1999 15:39:46 +0200, Juergen Schoenwaelder wrote:
> 
> Page ...

Thank you

> J> 1) Should we remain compliant with an old version of Appletalk (and
> J> incidentally RFCs 1906 and 1910) and specify 484?
> 
> J> 2) Should we specify the RFC-1122-compliant value for TCP?
> 
> J> 3) Should we specify the RFC-1122-compliant value for the worst
> J> case between TCP and UDP, i.e. UDP?
> 
> We should define what makes sense for TCP. There is IMHO absolutely no
> value in using the same minimum size for all transport mappings. Hence,
> it does not matter what is defined for snmpUDPDomain.
> 
> Sure, there might be old implementations that only support 484 bytes
> in their internal buffers. But I think its reasonable to require
> larger buffers while switching to TCP.

OK. So we have 2 concepts here:

 - snmpTCPDomain
 - snmpAnyDomain

For snmpAnyDomain, it makes sense to keep 484 octets. It's historic
and it's useless, because the real constraints come from snmpUDPDomain,
snmpCLNSDomain, snmpIPXDomain, etc.

For snmpTCPDomain, we can be conservative and take 1472 octets, as for
snmpUDPDomain, or we can be agressive and pick 64k. More precisely:

1500 (max Ethernet) - 20 (min IP header) - 8 (min UDP header) = 1472
65535 (max IP) - 20 (min IP header) - 20 (min TCP header) = 65495

I prefer the second value. I therefore suggest that we modify the TCP
draft and replace 484 octets with 65495 octets in section 3.2.

I also believe that this value should be stored in the MIB and suggest
to add:

snmpTCPGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving TCP protocol entities are required to accept
            messages of at least 65495 octets in length."
    ::= { snmpTCPDomain 1 }

To be consistent, we should also defined similar values for the existing
transport domains. Which calls for the addition of:

snmpUDPGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving UDP protocol entities are required to accept
            messages of at least 1472 octets in length."
    ::= { snmpUDPDomain 1 }

snmpCLNSGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving CLNS protocol entities are required to accept
            messages of at least 1472 octets in length."
    ::= { snmpCLNSDomain 1 }

snmpCONSGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving CONS protocol entities are required to accept
            messages of at least 1472 octets in length."
    ::= { snmpCONSDomain 1 }

snmpDDPGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving DDP protocol entities are required to accept
            messages of at least 484 octets in length."
    ::= { snmpDDPDomain 1 }

snmpIPXGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving IPX protocol entities are required to accept
            messages of at least 546 octets in length."
    ::= { snmpIPXDomain 1 }

Arguably, we could also specify the lower bound for all transport domains
in this MIB, because it is specified in RFC 1906 (although I don't think
it is necessary):

snmpAnyDomainGuaranteedAcceptedSize  OBJECT-IDENTITY
    SYNTAX  DisplayString (SIZE (0..255))
    ACCESS  read-only
    STATUS  current
    DESCRIPTION
            "All receiving protocol entities are required to accept
            messages of at least 484 octets in length, whatever the
            protocol. This value may be overridden by a value specific
            to a transport domain."
    ::= { nmrgSnmpDomains 7 }

Jean-Philippe

Date: Fri, 7 May 99 16:30:25 DST
From: "Bert Wijnen" <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: [nmrg] 484 octets
Sender: [email-masked]

Ref:  Your note of Fri, 07 May 1999 15:22:29 +0200

Subject: Re:   [nmrg] 484 octets

I do not understand what your issue is.
The 484 is the minimum maximum value.
The maximum maximum value is MUCH larger and that is what we
worry about for SNMP over TCP, right? We want to BULK transfer
LARGE amounts of MIB data, right?

SO what do we care what minimal agents do? we cannot have
efficoient communication with them anyway. And they probably
will not have large tables.... so....??

Bert

Date: Fri, 7 May 1999 15:39:46 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] 484 octets
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

>> Note, Rose mentions other limits in the second revised edition of
>> the simple book.

J> Page number, please? I can't find it.

Page 171 says that 1472 bytes are required for snmpUDPDomain.
Page 172 says that 1472 bytes are required for snmpCLNSDomain/snmpCONSDomain.
Page 173 says that  484 bytes are required for snmpDDPDomain.
Page 174 says that  546 bytes are required for snmpIPXDomain.

(BTW, I am also looking forward to see whether the OSI transport
 mappings will be kept in a revised version of RFC 1906 and how the
 implementation and deployment report will look like. ;-)

J> I'll follow the advice of these two wise men and will refrain
J> myself from raising this dangerous issue to the SNMPv3 WG. But what
J> about draft-irtf-nmrg-snmp-tcp-00.txt?

J> 1) Should we remain compliant with an old version of Appletalk (and
J> incidentally RFCs 1906 and 1910) and specify 484?

J> 2) Should we specify the RFC-1122-compliant value for TCP?

J> 3) Should we specify the RFC-1122-compliant value for the worst
J> case between TCP and UDP, i.e. UDP?

We should define what makes sense for TCP. There is IMHO absolutely no
value in using the same minimum size for all transport mappings. Hence,
it does not matter what is defined for snmpUDPDomain.

Sure, there might be old implementations that only support 484 bytes
in their internal buffers. But I think its reasonable to require
larger buffers while switching to TCP. (Even ATM people learned that
53 bytes is a poor match for moving data around. ;-)
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] 484 octets 
Date: Fri, 07 May 1999 15:22:29 +0200
Sender: [email-masked]

On Fri, 7 May 1999 13:49:03 +0200, Juergen Schoenwaelder wrote:
> I am not sure but I think the story was that you can't have messages
> larger than 484 bytes on appletalk and they used this constant for all
> SNMP transports.

Argh...

On Fri, 7 May 1999 13:49:03 +0200, Juergen Schoenwaelder wrote:
> Note, Rose mentions other limits in the second revised edition of
> the simple book.

Page number, please? I can't find it.

On Fri, 7 May 99 13:58:09 DST, Bert Wijnen wrote:
> If it gets changed, then then umpty million SNMPv1 implementations
> will not change anyway.

RFCs 1906 and 1910 have nothing to do with these umpty million SNMPv1
boxes which follow RFCs 1213, 1157, etc. Old SNMPv1 agents don't care
what new RFCs say. It's the job of smart modern managers to comply with
old RFCs iff they talk to old agents, and to comply with the latest
RFCs iff they talk to brand new boxes.

 ------------------------

On Fri, 7 May 1999 13:49:03 +0200, Juergen Schoenwaelder wrote:
> RFC 1910 is not worth fixing. People will consider such a "fix" a
> non-editorial change an debate you to death with regard to RFC 1906.
> But it might be fun to bring this up in the SNMPv3 WG.

On Fri, 7 May 99 13:58:09 DST, Bert Wijnen wrote:
> No... I stroongly recommend to NOT bring it up (but you're free to
> do so... we are an OPEN process).

I'll follow the advice of these two wise men and will refrain myself
from raising this dangerous issue to the SNMPv3 WG. But what about
draft-irtf-nmrg-snmp-tcp-00.txt?

1) Should we remain compliant with an old version of Appletalk (and
   incidentally RFCs 1906 and 1910) and specify 484? This would be
   backward compatible, Fortran I compatible, COBOL 0.1 compatible,
   ENIAC compatible, etc. But if RFCs 1906 and 1910 are fixed one day,
   our document will have to be fixed, too.

2) Should we specify the RFC-1122-compliant value for TCP?

   536 = 576 (RFC 1122) - 20 (IP) - 20 (TCP)

   This would be self-consistent, but would not take into account the
   UDP reality of SNMP-based management.

3) Should we specify the RFC-1122-compliant value for the worst case
   between TCP and UDP, i.e. UDP?

   548 = 576 (RFC 1122) - 20 (IP) - 8 (UDP)

   This would be consistent with what the RFCs should be, assuming
   that the purpose of new documents is to fix older ones. It would
   not cause a problem if RFCs 1906 & 1910 were updated one day.
   It would not be compatible with agents conforming to RFCs 1906 and
   1910, but that's no problem since people need to change their code
   anyway to support TCP.

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Fri, 7 May 99 13:58:09 DST
From: "Bert Wijnen" <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked], [email-masked]
Subject: [nmrg] 484 octets
Sender: [email-masked]

Ref:  Your note of Fri, 7 May 1999 13:49:03 +0200

Subject: Re:   [nmrg] 484 octets

Juergen writes:
> RFC 1910 is not worth fixing. People will consider such a "fix" a
> non-editorial change an debate you to death with regard to RFC 1906
> But it might be fun to bring this up in the SNMPv3 WG.
>
No... I stroongly recommend to NOT bring it up (but you're free to
do so... we are an OPEN process).
But it will be a waste of time.
If it gets changed, then then umpty million SNMPv1 implementations
will not change anyway.
For SNMPv3, there are other methods for entities to tell what size they
support. For the coexistence document we're also proposing a
bigger default and again you can specify it in a MIB.

Bert (personal opinion)

Date: Fri, 7 May 1999 13:49:03 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [nmrg] 484 octets
Sender: [email-masked]

>>>>> J P Martin-Flatin writes:

JP> I have a problem with the minimal value of 484 octets specified
JP> in:

[...]

JP> In other words, all IP hosts *must* accept IP messages that are up
JP> to 576 octets in length, and may accept longer messages. Assuming
JP> no IP options (worst case), a legal SNMP message can therefore be:

JP>   576 - 20 (IP header) - 8 (UDP header) = 548 octets

I am not sure but I think the story was that you can't have messages
larger than 484 bytes on appletalk and they used this constant for all
SNMP transports. Note, Rose mentions other limits in the second
revised edition of the simple book.

JP> Therefore, as far as I can see, RFC 1906, RFC 1910 and the TCP
JP> draft are in contradiction with RFC 1122. Did I overlook
JP> something? If you agree, we should propose to modify RFCs 1906 and
JP> 1910 (+ change the TCP draft) and make them specify that all SNMP
JP> entites must accept messages that are up to 548 octets, not 484
JP> octets.

RFC 1910 is not worth fixing. People will consider such a "fix" a
non-editorial change an debate you to death with regard to RFC 1906.
But it might be fun to bring this up in the SNMPv3 WG.

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
cc: [email-masked]
Reply-To: [email-masked]
Subject: [nmrg] 484 octets
Date: Fri, 07 May 1999 13:37:17 +0200
Sender: [email-masked]

I have a problem with the minimal value of 484 octets specified in:

 - sections 3.2, 4.2 and 5.2 of RFC 1906
 - sections 2.9 and 5 of RFC 1910
 - section 3.2 of draft-irtf-nmrg-snmp-tcp-00.txt

RFC 1122 states (about IP reassembly):

      3.3.2  Reassembly

         The IP layer MUST implement reassembly of IP datagrams.

         We designate the largest datagram size that can be reassembled
         by EMTU_R ("Effective MTU to receive"); this is sometimes
         called the "reassembly buffer size".  EMTU_R MUST be greater
         than or equal to 576, SHOULD be either configurable or
         indefinite, and SHOULD be greater than or equal to the MTU of
         the connected network(s).

In other words, all IP hosts *must* accept IP messages that are up to
576 octets in length, and may accept longer messages. Assuming no IP
options (worst case), a legal SNMP message can therefore be:

  576 - 20 (IP header) - 8 (UDP header) = 548 octets

Therefore, as far as I can see, RFC 1906, RFC 1910 and the TCP draft are
in contradiction with RFC 1122. Did I overlook something? If you agree,
we should propose to modify RFCs 1906 and 1910 (+ change the TCP draft)
and make them specify that all SNMP entites must accept messages that
are up to 548 octets, not 484 octets.

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Thu, 06 May 1999 10:05:33 +0200
From: Ron Sprenkels <[email-masked]>
Organization: University of Twente
To: Juergen Schoenwaelder <[email-masked]>
CC: [email-masked]
Subject: Re: [nmrg] meetings
Sender: [email-masked]

Hi,

> I think its time to talk about face-to-face meetings. I already
> mentioned in a previous email the following events:
> 
>         May 24-28, 1999         IM '99 Boston
>         July 12-16, 1999        45. IETF Oslo
>         October 11-13, 1999     DSOM '99 Z"urich
>         November 8-12, 1999     46. IETF Washington

I won't be at IM99. For the other three options: I don't have a paper at
DSOM99, and at this time I don't have prior plans or reasons to attend any
IETF meetings. This means that I'll have to discuss this with my boss; I'll
let you know asap what comes out of that.

Ron.

--------------------------------------------------------------------------
Ron Sprenkels  [email-masked]   http://www.cs.utwente.nl/~sprenkel
University of Twente, Department of Computer Science, TSS Management group 
P.O. Box 217, 7500 AE Enschede, The Netherlands.    (Tel. +31 53 489 4663)

To: [email-masked]
Subject: Re: [nmrg] meetings
Organization: U.C.Davis, Information Technology - D.C.A.S.
From: Wes Hardaker <[email-masked]>
Date: 04 May 1999 09:44:01 -0700
Lines: 16
Sender: [email-masked]

>>>>> On Tue, 04 May 1999 16:02:23 +0200, "J.P. Martin-Flatin" <[email-masked]> said:

> On Thu, 29 Apr 1999 17:29:32 +0200, Juergen Schoenwaelder wrote:
> 
> May 24-28, 1999         IM '99 Boston
> July 12-16, 1999        45. IETF Oslo
> October 11-13, 1999     DSOM '99 Zurich
> November 8-12, 1999     46. IETF Washington

Unfortunately, the first I can make is probably the November IETF
meeting...

-- 
Wes Hardaker
Distributed Computing Analysis and Support
University of California at Davis

From: "J.P. Martin-Flatin" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [nmrg] meetings 
Date: Tue, 04 May 1999 16:02:23 +0200
Sender: [email-masked]

On Thu, 29 Apr 1999 17:29:32 +0200, Juergen Schoenwaelder wrote:
> 
>         May 24-28, 1999         IM '99 Boston
>         July 12-16, 1999        45. IETF Oslo
>         October 11-13, 1999     DSOM '99 Zurich
>         November 8-12, 1999     46. IETF Washington

I will attend IM'99 and DSOM'99. I will not attend any IETF meeting
this year.

> Regarding IM'99, I will arrive in Boston on Saturday 22 and I will
> leave on Friday 28. We can either meet on Sunday or on Friday since I
> do not plan to attend any of the Friday tutorials.

I will attend two tutorials on Friday, so I'd rather we meet on Sunday.
I'll stay at the Boston Park Plaza Hotel. We might find a meeting room
there, but I don't know if it'll be free of charge. Alternatively, we
could have our meeting in a restaurant.

Jean-Philippe

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [email-masked]                   Fax: +41-21-693-66-10
Web: http://icawww.epfl.ch/~jpmf/

Date: Mon, 3 May 1999 17:32:20 +0200
From: Juergen Schoenwaelder <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [nmrg] meetings
Sender: [email-masked]

>>>>> Luca Deri writes:

Luca> Concerning IM'99 I have a problem. I should present a poster
Luca> session (is about SAMBA+SNMP). Unfortunately when i submitted
Luca> the paper I didn't knwo the date of the marriage. Then some
Luca> colleagues of mine from Finsiel were supposed to go @ IM'99 but
Luca> they recently changed their plans. I'm wondering whether I could
Luca> ask some of you to help me. I was thinking so mail you the
Luca> poster itself and a few copies of the paper, in order not to
Luca> cancel my poster. Does some of you want to gimme this favour?

I can help you out. Just send all the material to the following
address:

	   Juergen Schoenwaelder
	   TU Braunschweig
	   Bueltenweg 74/75
	   38106 Braunschweig
	   Germany

I am flying to Boston on Saturday the 22 of May. Please make sure
that I receive the material in time.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

Date: Mon, 3 May 99 10:54:45 DST
From: "Bert Wijnen" <[email-masked]>
To: [email-masked], [email-masked]
cc: [email-masked]
Subject: [nmrg] meetings
Sender: [email-masked]

Ref:  Your note of Sat, 01 May 1999 13:09:43 +0200

Subject: Re:   [nmrg] meetings

Right now, it seems I will NOT be at IM'99. Sorry, so I can't attend.

Bert

Date: Sat, 01 May 1999 13:09:43 +0200
From: Aiko Pras <[email-masked]>
To: Network Management Research Group <[email-masked]>
Cc: Juergen Schoenwaelder <[email-masked]>
Subject: Re: [nmrg] meetings
Sender: [email-masked]

Hi all

I'll be at the IM'99. Although I have not yet arranged my flight,
most meeting times will be possible for me. Who else is going to
IM'99? And in what hotels are you staying? I would like to stay
in the same hotel, so it would be easier to meet.

Bye

Aiko

Juergen Schoenwaelder wrote:
> 
> I think its time to talk about face-to-face meetings. I already
> mentioned in a previous email the following events:
> 
>         May 24-28, 1999         IM '99 Boston
>         July 12-16, 1999        45. IETF Oslo
>         October 11-13, 1999     DSOM '99 Z"urich
>         November 8-12, 1999     46. IETF Washington
> 
> I got one (!) reply saying that he generally prefers meetings at IETFs
> rather than conferences. Given the silence of the other NMRG members,
> I propose to
> 
>  (a) hold an official NMRG meeting at the IETF in Oslo
> 
>  (b) hold an interim NMRG meeting at IM'99 in Boston (since many of
>      us are going to be at IM'99 anyway)
> 
> I think we should try to get a meeting room in Oslo during the IETF
> week - probably on Friday if everything else if filled up. (But we
> actually only need a small room - so there is a good chance that
> something is available.) We can also try to meet on Sunday before the
> IETF week starts - but this needs to be aligned with our travel plans
> (so please raise you voice).
> 
> Regarding IM'99, I will arrive in Boston on Saturday 22 and I will
> leave on Friday 28. We can either meet on Sunday or on Friday since I
> do not plan to attend any of the Friday tutorials. Again, let me know
> who will be there so that we can agree where and when to meet.
> 
>                                                         Juergen
> --
> Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
> Technical University Braunschweig, Dept. Operating Systems & Computer Networks
> Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)