Subject: RE: draft-ietf-ipfc-mib-framework-03.txt (Fwd)

From: "Murali Rajagopal" <[email-masked]>
Date: Thu, 1 Feb 2001 18:44:26 -0800

Mark:

Please provide your plan of action regarding this.

-Murali

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Erik Nordmark
Sent: Tuesday, December 12, 2000 4:00 PM
To: [email-masked]
Cc: Mark A. Carlson; [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: RE: draft-ietf-ipfc-mib-framework-03.txt (Fwd)

The framework document was discussed in the IESG.

The overarching comment was that for the document to serve the WG
it should be more exact and specific when it comes to the set
of requirements that the WG are imposing on the fibre channel mibs.

See the detailed comments.

  Erik

- Section 3. text like:
     The Fibre Channel MIBs may consist of an arbitrary collection 
     of groups,and may contain objects of type: READ-ONLY,
      READ-WRITE, or WRITE-ONLY.

The WRITE-ONLY was a SMIv1 concept which no longer exists.

      The following principles should be observed in developing MIBs.
  
This then goes on to list a set of motherhood and apple pie items
that are common to all MIBs... so not ipfc specific.
Then follow a few ipfc specific items.
I can live with it, but the motherhood and apple pie might be omited.
The one statement for that is that they should be SMIv2 compliant.

- section 4.
  4.1 General
  These MIBs should provide for proxy SNMP management. 
  In other words, at a relatively high level of the MIB, table(s)
  should exist that allowmultiple entities to be referenced.
  The indexing of the table shouldallow multiple entities to be
  referenced through a single SNMP agent,at a single IP
  address.In general, an agent will proxy for a group of 
  devices from a singlevendor. 
  The method which an NMS uses to determine a set of 
  addressableagents is beyond the scope of this document.

This was needed for SNMPv1 and SNMPv2c. With SNMPv3
and the new SNMP Architecture (RFC2571), this is best
handled by using contextNames. If you do that, then there
are no more special considerations for proxy w.r.t. the MIB.
That then all becomes an SNMP agent configuration issue,
for which we have the SNMP PROXY MIB (RFC2573).
That then at the same time specifies a std for an NMS
to learn about the various contexts (logical MIBs if you like).

Another possibility is that maybe they want to use the
entity MIB (RFC2737) for this purpose too. Did they
evaluate that one?

I guess what I would like to see here is that maybe they
evaluate some of these alternatives and then justyify why
they choose a particular approach.

In addition, RFC 2837 doesn't have any proxy indexing (which is good)
so the framework document doesn't seem to capture what is currently done
in the ipfc MIBs.

- Section 4.2 Security

I don't think that the MIB needs to have anything
specific to allow for only read access. That is an implementation
issue. For an SNMP agent with only SNMPv1, it would be
something like specifying only community names with READ
access. In any event, it is not something that needs/should be
specified in a MIB itself (or maybe they mean that just english
text in the security section of such a mib should explain it...
that is fine... but not clear from what they write here.
Also... I am not sure that we would encourage read-only
access via SNMP and write access via HTTP??? If you
do that, I would rather encourage to use SNMPv3.

Section 5.1

Not sure I am happy with the terms "Proxy Management Domain"
and "Proxy Master". We do not have such terms in SNMP, and
also our use of the term "proxy" is not inline with what they 
describe (See RFC2571 and RFC2573). Their wording seems
to be more the description of a master agent and subagent,
somthing that we do know about as in RFC2741

Other nits:
- the reference [1] is not referenced anywhere and seems
  not needed to me.

- reference [2] should be to RFC2578 instead of 1902 which they
  already have as [7]

- but worse, references [2] through [7] are not referenced anywhere.
  So they just seem gratuitous references.

- I see no security section for this document itself. Sect 4.2 talks
  about what nbeeds to be done in MIBs in the ipfc environment
  I believe.

- no standard copy-right section.

---