[nmrg] Minutes of the 2nd NMRG meeting

["J.P. Martin-Flatin" <[e-mail]>]

The 2nd NMRG meeting took place in Boston, MA, USA on May 23 and 26,
in parallel to IM'99. Duration = 2 * 0.5 day.

Present:

 * Juergen Schoenwaelder (JS)
 * Aiko Pras (AP)
 * Jean-Philippe Martin-Flatin (JPMF)

Agenda:

 * draft-irtf-nmrg-snmp-tcp-00.txt
 * compression
 * SMIng
 * long-term aim of NMRG
 * how should NMRG operate?
 * next NMRG meetings

Minutes:

1) draft-irtf-nmrg-snmp-tcp-00.txt
   ===============================

* We are not far from completing this draft. We went through the
  comments that JPMF sent to the NMRG mailing list (NMRGml) on May 7.

* The new section 3.3 should be rephrased (e.g. "UDP connections" is
  a contradiction). JS typed in a new text we all agreed with. JPMF's
  idea that this RFC should not explicitly limit the use of TCP to
  bulk data transfers was accepted. AP proposed a new wording for the
  retransmissions with which we all agreed.

* Use of MUST, SHOULD, CAN...: JS will decide when to capitalize these
  words.

* What should be the minimum size guaranteed to be accepted by all
  entities? We had a long discussion to find a good trade-off between
  what should be supported by all boxes (don't make this guaranteed
  size too high) and when the use of TCP becomes useless if this
  guaranteed size is too low. JS put 484 octets in his first draft.
  JPMF changed it to 64k. JS advocated 2k instead. AP, Grand Master
  of Consensus, proposed 8k. Agreed by all parties present; to be
  discussed on the NMRGml. In the meantime, JS puts 8k in his new
  draft.

* ACTION: JS modifies the draft posted by JPMF on May 7 and sends it
  to the NMRGml for review.


2) Compression
   ===========

* Do we want compression only in SNMPv3, or in SNMPv1 and SNMPv2c as
  well? AP and JPMF both mentioned the danger of multiple releases
  branching off. JS argued that since SNMPv3 is not getting deployed
  fast, adding compression to SNMPv1 and SNMPv2c might be a good idea.
  To be discussed on the NMRGml.

* JS: it is important to compress before we encrypt, otherwise we would
  lose any pattern in the data --> poor compression ratio (see IPcomp
  in IPv6).

* We discussed the pros and cons of JS's solutions for compression.

* Solution #1: Compression is a special case of encryption. Problem:
  authentication would become mandatory (because encryption mandates
  authentication in SNMPv3). AP and JPMF: This is a big problem.

* Solution #2: In the SNMPv3 header, the 4th bit of the msgFlags
  (RFC 2572) specifies if compression is used. Name: compressFlag.
  (The 1st bit is authFlag for authentication, the 2nd bit is privFlag
  for encryption, the 3rd bit is reportableFlag for Report PDUs). If
  compressFlag is set, compression is then handled like encryption
  today. Advantage: simple. Drawback: this works only with v3.

* Solution #3: In RFC 2572, a scoped PDU is defined as follows:

       ScopedPDU ::= SEQUENCE {
           contextEngineID  OCTET STRING,
           contextName      OCTET STRING,
           data             ANY -- e.g., PDUs as defined in RFC 1905

  Instead of using only PDUs as defined in RFC 1905, we could define a
  new PDU called compressedPDU. The encoding of this PDU would specify
  to compress the data. We need to put in a MIB a table of all the ANYs
  supported by an entity; this enables a sending entity to find out if
  a receiving entity supports compressedPDU. Advantage: works with v1,
  v2c and v3. Drawback: allows the compression of a little less data
  than solution #2 (the context engine and the context name are not
  compressed with #3).

* There's no clear winner yet. For each solution, we need to study in
  detail the reaction of a normal SNMP agent/manager when it receives
  a compressed SNMP message.

* All solutions require that the compression algorithm (e.g. gzip) be
  specified in a MIB. We need to define this in more detail.

* ACTION: Discuss this on the NMRGml and choose a solution at the
  next NMRG Meeting.


3) SMIng
   =====

* JS: Is NMRG the right forum to discuss SMIng? JPMF=yes. AP=not sure.
  We didn't get enough answers to this question on the NMRGml.

* AP: We should develop a vision of an architecture (service mgmt,
  distributed network mgmt...) together with looking at the more
  detailed things such as SMIng.

* AP: What we miss in SMIv2 is the equivalent of C structures. We have
  only tables. JS: We don't need nested tables, equiv. to structures,
  because nested tables are easy to flatten into a single table (see SQL
  which doesn't support nested tables either).

* JS: We miss the notion of method or function calls with well-defined
  signatures. There are currently many different ways to do the same
  thing via side effects of SET operations. This raises implementation
  cost issues and leads to interoperability problems. How these SMI
  methods or function calls map to underlying management protocols or
  APIs remains to be defined.

* ACTION: JS reposts his question of May 12 to the NMRGml.


4) Long-term aim of NMRG & 5) How should NMRG operate?
   ===================================================

* Starting point: JS is a bit disappointed that we don't get things
  done fast enough. We are very slow to progress. Few people in the
  NMRGml answer his questions. There are many "sleeping partners"
  (do nothing, see what the others do) and not enough active members
  in NMRG.

* We had a long discussion showing that we all expect different
  things from NMRG:

* AP wants to work on a new architecture for Internet mgmt:
  - SLA
  - inter-domain mgmt
  - distributed mgmt
  - not simply network elements
  Preference = architecture. Also interested in design & implem.

* JPMF: Main interest in distributed network mgmt. Manager to manager,
  manager to agent. Define high-level semantics, high-level
  information models. Map to XML.
  Preference = design. Also interested in arch. & implementation.

* JS wants to get real things out, especially prototypes and RFCs.
  His primary interest is to get the initial thing which started the
  NMRG completed (SNMP over TCP, Compression, getsubtree PDU).
  Preference = implementation. Also interested in arch. & design.

* The bad news is:
  - we have different expectations, different poles of interest
  - we are all funded separately to do very different tasks
  - we'll probably never agree to work all on the same thing at the
    same time.

* The good news is:
  - we all want to work together
  - we are very complementary in our interests

* Everyone agrees that this working group has great value, and we all
  like to work together. Still, it may be necessary to adjust our
  mode of operation as all of us are busy with many things, which must
  be performed in parallel with the work for NMRG. We must accept that
  it will not be possible to investigate every research topic that we
  would like. We agreed therefore that we will only start a new topic
  if there is at least one person who takes the lead for that topic,
  and who sends documents to the NMRGml for scrutiny, analysis,
  criticism, feedback... Our commitment as members of NMRG is to make
  the effort to read these documents reasonably fast and spend the
  time to provide valuable feedback. For NMRG to be successful, it is
  important that, once in a while, we set a milestone and produce some
  output: RFC, paper, prototype...

* ACTION: Discuss this on the NMRGml and check if others are happy
  with this change.


6) Next NMRG meetings
   ==================

* It is important that we have meetings several times per year.
  Otherwise the group will dissolve quickly. It is OK that all NMRG
  members don't attend all meetings (money, time schedule...).

* The 3rd NMRG Meeting will take place in Oslo, Norway on July 10,
  just before the 45th IETF Meeting. It will last only 1 day because
  IETF Meetings are already very demanding.

* The 4th NMRG Meeting will take place in Zurich, Switzerland in
  October, together with the DSOM'99 workshop. It will last 2 days.

* ACTION: JS contacts the IETF folks and gets a room in Oslo.

* ACTION: JPMF contacts the organizers of DSOM'99, chooses a date with
  them and gets a room at ETH Zurich.

____________________________________________________________________
Jean-Philippe Martin-Flatin, EPFL-DI-ICA, 1015 Lausanne, Switzerland
Email: [e-mail]                   Fax: [phone]
Web: http://icawww.epfl.ch/~jpmf/