Subject: [midcom] Re: Fwd: RE: NAT-MIB review

From: [email-masked]
Date: Mon, 15 Sep 2003 01:02:56 -0500

Hi Juergen,

  Thanks a lot for your comments. It looks like that we will have to come
       up
  with a new revision to address most of your comments.

  I agree with most of your comments. I will only list the comments here,
       where i
  have some confusion/explanation to make.

  1.  As Suresh also mentioned that Midcom MIB is not published yet; thats
      why MIDCOM Compliance/Owner Id/Group Id  may not make much sense.
      What should we do in this case ?

 2.  > > >
> > >  7) Section 4.3 says that binds which point to non-existing address
> > >     maps are not allowed. In the MIB definitions, it would be very
> > >     useful to say precisely what happens if one tries to violate the
> > >     rule (that is, which error code is actually generated when I try
> > >     to delete an address map with pending binds or try to create a
> > >     bind which points to a non-existing address map).

   In the last revision, i had mentioned snmp error code as
inconsistentErrorValue but there
   were comments that this error code is only specific to some snmp version
and hence
   we shouldn't mention it. I would like to know your opinion on the same.

3. I will remove storageType objects on the next version as i don't see
much use of them in this MIB.
   Let me know your opinion about the same.

4. It is my undretstaning that in most of the customer scenarios, the binds
   and sessions are generated dynamically while addrmaps are configured.
   Thats why we have separate branches for config and translation.
   Even if the bind and session have the rowStatus, i don't anticipate
   it to be used widely.

5. Related to notification changes, we will simplify it a lot in the next
   version.

Thanks
Rohit

>From: Pyda Srisuresh <[email-masked]>
>To: "Wijnen, Bert \(Bert\)" <[email-masked]>,
>"[email-masked]'" <[email-masked]>,
>[email-masked], [email-masked], [email-masked],
>[email-masked]
>CC: [email-masked]
>Subject: RE: NAT-MIB review
>Date: Sun, 14 Sep 2003 20:01:06 -0700 (PDT)
>
>Bert & Juergen,
>
>Please see my comments below.
>
>regards,
>suresh
>
>--- "Wijnen, Bert (Bert)" <[email-masked]> wrote:
> > Thanks Juergen.
> > So I expect the authors to respond/comment back, and to most
> > probably issue another revision to address the issues.
> >
> > Pls copy me explicitly on any follow up communication, cause
> > I am currently not subscribed to midcom list.
> >
> > Thanks,
> > Bert
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder [mailto:[email-masked]]
> > > Sent: donderdag 11 september 2003 18:05
> > > To: [email-masked]; [email-masked]; [email-masked];
> > > [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: NAT-MIB review
> > >
> > >
> > > Bert asked me to play the MIB doctor for the NAT-MIB and so I have
> > > reviewed <draft-ietf-nat-natmib-06.txt>. The document needs further
> > > editorial work in order to comply with the MIB guidelines as
> > > documented in <draft-ietf-ops-mib-review-guidelines-02.txt> and there
> > > are several technical questions that need to be discussed and
resolved
> > > before the document is ready to go.
> > >
>Thanks, Juergen, for the detailed review. Great job indeed. You have
really
>fine combed the syntax and semantics. Thansk again. I have responded to
>some
>below. For the remaining, I requested Rohit, one of my Co-authors, to
chime
>in.
>However, any one of the co-authors might do so.
>
>A bunch of your questions relate to MIDCOM compliance. Unfortunately, the
>MidcomBase MIB is not published yet. Until the Midcombase MIB is out, the
>MIDCOM extension done in the NAT MIB would not make much sense to the
>readers,
>I am afraid. DO let me know if you have any suggestions on how to go about
>this. Thanks.
>
>
> > >  1) The abstract should not contain references, see also the
> > > guidelines
> > >     document.
> > >
>
>Will do.
>
> > >  2) I suggest to add definitions of key terms into section 3. In
> > >     particular, I would like to see a definition for concepts such
> > >     as sessions, groups and probably owners. Also the relationship
> > >     to other MIDCOM work needs to be explained since the MIB module
> > >     talks about "MIDCOM compliance" and I have no clue what that
> > >     means (see also below).
> > >
>
>OK. The Midcom compliance is pending a new Midcom draft outlining how
>SNMPv3
>would suffice to serve as MIDCOM protocol.
>
> > >  3) In the overview section, you should say that this MIB module
> > >     depends in some parts on the IF-MIB.
> > >
>
>Only in that NAT is configurable on a per-interface. We will mention this
>in
>the Overview section. Thanks.
>
> > >  4) In the overview section, please introduce the names of the tables
> > >     and use these names where appropriate to reduce any risk for
> > >     confusion. Some phrases I think are a bit confusing, e.g.
> > >
> > >    o two scalars used to monitor address thresholds and generate
> > >      notifications when the thresholds are crossed.
> > >
> > >     I do not think you monitor thresholds. In fact, these thresholds
> > >     define when notifications are generated. (And my later reading of
> > >     the MIB makes me wonder whether the second one is ever used.)
>
>Perhaps Rohit will respond to this.

[ROHIT] will do this.

>
> > >
> > >  5) typo "... the currently exist ..." -> "... that currently
> > > exist ..."
>Yup.
>
> > >
> > >  6) Section 4.1 says:
> > >
> > >    The association between the various configuration tables can be
> > >    represented as follows:
> > >
> > >
> > >      per interface config   (global config parameters)
> > >         |                            |
> > >         |                            |
> > >         |                            |
> > >         |----------------------------|
> > >         |
> > >         |
> > >      address map
> > >
> > >     My understanding is that the global config parameters are just
> > >     a few scalars and not a table.
>
>The diagram is correct. The configuration consists of a few global scalars
>(natConfig objects 1..7) and a per-interface address
>map(natConfInterfaceTable)
>
>
> > >
> > >  7) Section 4.3 says that binds which point to non-existing address
> > >     maps are not allowed. In the MIB definitions, it would be very
> > >     useful to say precisely what happens if one tries to violate the
> > >     rule (that is, which error code is actually generated when I try
> > >     to delete an address map with pending binds or try to create a
> > >     bind which points to a non-existing address map).
>OK. When you try to delete an address map with pending binds, all
>associated
>BINDs are removed. No error is created. Typically, address maps are not
>edited
>once confgured.When you try to create a BIND pointing to a non-existing
>address
>map (or) an exisitng address map, but has no relevance to the BIND, BIND
>creation fails - error code: UnknownAddressMapEntry (or)
>InvalidAddressMapEntry.
>
>We will add this info.
> > >
> > >  8) You seem to use the RowStatus for two purposes -
> > >     creating/destroying rows as well as enabling/disabling them. The
> > >     compliance allows implementations that do only one-shot row
> > >     creation and deletion, which means that those implementations
> > >     do not have the capability to disable a row. Also note that a
> > >     row in the notInService state has a timer attached so the row
> > >     cannot be in that state for longer periods of time.
> > >
> > >     Perhaps you want to introduce explicit enabled/disabled states
for
> > >     the rows in question in case it makes sense.
>
>Perhaps Rohit will respond to this.
>
> > >
> > >  9) The start of the module needs editorial work so that it conforms
> > >     to section 4.5 in the MIB review guidelines document.
>
>OK. Perhaps Rohit will respond to this.
>
> > >
> > > 10) I suggest to also make the bit set representation of the protocol
> > >     types an explicit TC so that both TCs are close together which
> > >     reduces any maintenance issues.
>
>Agreed. Sounds good.
>
> > >
> > > 11) What does an idle timeout of 0 seconds actually mean? (This
> > >     question affects natConfUdpDefIdleTimeout,
> > >     natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout,
> > >     natConfTcpDefIdleTimeout and natConfTcpDefNegTimeout.
>
>When idle timeout is set to zero, these fields will be assigned their
>respective DEFVAL values.
> > >
> > > 12) I suggest to reword the description of the TCP idle timeout
> > >     objects:
> > >
> > >     natConfTcpDefIdleTimeout:
> > >
> > >     The default time interval a NAT session (or is it a binding or
> > >     both?) for an established TCP connection is allowed to remain
> > >     valid without any activity on the TCP connection.
>
>OK. This refers just to the session, not the binding.
>
> > >
> > >     natConfTcpDefNegTimeout:
> > >
> > >     The default time interval a NAT session (or is it a binding or
> > >     both?) for a TCP connection which is not in the established state
> > >     is allowed to remain valid without any activity on the TCP
> > >     connection.
> > >
> > >     The point here is that the phrase "TCP protocol session" confuses
> > >     me - do you refer to a NAT session for a TCP connection or
> > >     something else?
>
>Yes. NAT session is for a TCP connection. Sorry about the confusing
>phrases.
>We will fix this.
>
> > >
> > > 13) I fail to see how the notification thresholds actually work. It
> > >     seems to me that actually only the natConfAddrRiseThreshold is
> > >     used. If my reading is wrong, the text probably has to be
> > >     improved.
>Perhaps Rohit will respond to this.
>
> > >
> > > 14) typo "... Groupn" -> "... Group"
>OK.
>
> > >
> > > 15) The description of the natConfInterfaceTable should probably say
> > >     that this is per interface configuration (and then you can remove
> > >     the comment above ;-).
>The description in natConfInterfaceEntry does say this. But, could be
>clearer,
>perhaps.
>
> > >
> > > 16) Why do you introduce natConfInterfaceIndex and not just import
and
> > >     use ifIndex?
>
>Makes sense. perhaps Rohit will respond to this.
> > >
> > > 17) What are the semantics of zero-length natConfAddrMapConfigName
> > >     values?
>
>A name with zero-length is invalid and has no impact.
>
> > >             Can I actually have multiple natConfAddrMapConfigName
> > >     objects with the same value?
>No. NatConfAddrMapTable indexed by natConfAddrMapName.
>
> > >                                  If not, what happens if I try to
> > >     create them? And why do you identify address maps by name when
all
> > >     the other entities are identified by numbers?
>
>Address map is essentially a file name with one or more address map
entries
>within it. An interface is associated with a unique address map at the
>configuration time.
>
>As for the other entries identified by numbers - are you referign to
>Bind-Id,
>session-Id etc? These are NAt generated, so it makes sense for them to be
a
>number.
> > >
> > >     Also, I find the description confusing since this does not
> > >     according to my understanding select a set of address maps but
> > >     rather a single address map.
>
>Yes. You have just one address map selected per-interface. The actual
>address
>map entries associated with the name are obtained from
natConfAddrMapTable.
>
> > >
> > > 18) The StorageType TC requires you to specify which objects are
> > >     writable if the storage type is permanent - see also section
4.6.4
> > >     in the MIB review guidelines document. This is missing in all
> > >     places where StorageType is being used.
>
>OK. Rohit wil lprobably address this.
>only natConfig & natConfAddrMapTable are saved between reboots.
>
> > >
> > > 19) I fail to understand the concept of the OwnerId and GoupId. What
> > >     does the value 42 tell a management station? I think this concept
> > >     is important to introduce in the beginning of the document.
>
>OK. The concept of Ownerid & GroupId are introduced principally to extend
>the
>MIB to be Midcom compliant. This will become apparent when the Midcom MIB
>draft
>is out.
>
>Essentially, a Midcombase MIB will maintain a table that associates Midcom
>agent (username) with the agentId assigned to it. Perhpa,s we could add a
>pointer to the midcombase MIB draft when the draft is published. The draft
>is
>currently in review by the design team.
>
> > >
> > > 20) What precisely happens if I write a value != 0 to
> > >     natConfLocalPortFrom, natConfLocalPortTo, natConfGlobalPortFrom,
> > >     natConfGlobalPortTo on a basic NAT?
>
>That would not be considered a BasicNat address map. As a result, this
>woudl
>not generate address BINDs. If the parameters donot fit the requirements
of
>a
>static map or NAPT or one of the other supported maps, the address map
>entry
>will be declared invalid and will not be used.
> > >
> > > 21) I think the number space for address binds (e.g. natAddrBindId,
> > >     natAddrPortBindId) should exclude the value 0. Perhaps it
actually
> > >     makes sense to introduce TCs doe NatAddrBindId and
> > >     NatAddrBindIdOrZero so things will be consistent.
>OK.
>
> > >
> > > 22) The description of natAddrBindDirection says:
> > >
> > >             "This object represents the direction of the BIND.
> > >              A BIND may be either uni-directional or bi-directional,
> > >              same as the orientation of the address map, based on
> > >              which this bind is formed."
> > >
> > >     Where in the address map is the direction specified?
>Good catch. We missed it.
>
> > >
> > > 23) Please say precisely which error is to be generated if you set
> > >     natAddrBindAddrMapName or natAddrPortBindAddrMapName to a non
> > >     existent addrMapName.
>
>For the NAT devices that are not MIDCOM compliant or donot communicate
with
>MIDCOm agents, this is not an issue as the MAP name is generated by the
NAT
>devices alone.
>
>In the case a NAT device is in session with a MIDCOM agent,
>INVALID_MAP_NAME
>error will be issued when the specified MapName is invalid.
>
> > >
> > > 24) Should natAddrBindMaxIdleTime natAddrPortBindMaxIdleTime and
> > >     natSessionMaxIdleTime not use syntax TimeInterval instead of
> > >     TimeTicks?
>
>Perhaps Rohit will respond to this.
>
> > >
> > > 25) You may want to rename all counters ending in *Translate to
> > >     *Translates to follow the old rules that counters are in plural.
>OK.
>
> > >
> > > 26) The natAddrBindTable, natAddrPortBindTable and natSessionTable
> > >     have no StorageType, see the MIB review guidelines document.
> > >
> > >     (In general, one can also ask why these tables are not part of
the
> > >     configuration branch since I can do row creation here. Also there
> > >     are counters in the translation tables which are actually
> > >     statistics. Personally, I would just drop the branches since they
> > >     serve no real value and only increase the length of the OIDs.)
>
>natAddrBindTable, natAddrPortBindTable and natSessionTable are genrated
>dynamically by the NAt device and are not saved between reboots. Unlike
>these,
>natConfig is a configuration object.
>
>Perhaps, Rohit will respond to this in detail.
> > >
> > > 27) What is the "query id" you refer to in the description of
> > >     natAddrPortBindLocalPort and natAddrPortBindGlobalPort? If you
> > >     mean the ICMP type code, then please say ICMP type code.
>
>This is refering to the Identifier field in the header.
>
> > >
> > > 28) In the number space for session, you really want to exclude the
> > >     value 0. Again, it might help to introduce specific TC(s).
>OK.
>
> > >
> > > 29) What is the relationship between binds and sessions? Your MIB
> > >     is modelled as if it is 1:n, that is you can have n sessions
> > >     for one bind. Is that the case?
>Yes.
>
> > >
> > > 30) Is there redundant information? Can a session have a different
> > >     protocol type than the associated binds? Or why are
> > >     natSessionProtocolType and friends needed?
>
>Well, session desribes the full session characteristics - namely the
>original
>5-tuple and the xlated 5-tuple. When a session has a non-zero BindId
>specified,
>the ProtocolType and friends in the session must match that of the BIND.
>However, in case of a symmetric NAPT device, the Session will have  BindId
>specified as Zero. In such a case, the session must include AddressMapName
 >and
>AddressMapEntryIndex specified. Oops... these two fields are missing in
>NatSessionEntry.
>
>
> > >
> > > 31) Looking at this description:
> > >
> > >     natStatsAddrMapAddrUsed OBJECT-TYPE
> > >         SYNTAX     Gauge32
> > >         MAX-ACCESS read-only
> > >         STATUS     current
> > >         DESCRIPTION
> > >                 "The number of addresses, pertaining to this
> > > address map,
> > >                  that are currently being used from the nat pool. The
> > >                  value of this object is irrelevant if the
> > > address map in
> > >                  question is a static address map."
> > >         ::= { natStatsAddrMapEntry 6 }
> > >
> > >     What does it mean that the object is irrelevant? Should it still
> > >     be implemented (if not clarify in the compliance definition). If
> > >     implemented, should it still report the correct value or can it
> > >     contain arbitrary garbage?
>
>Perhaps Rohit will address this in detail.
>But, here is my read on this. In the case of static address map, this
could
>will be the full count of all addresses that are statically mapped. There
>is no
>room for additional addresses for performing a BIND.
>
>
> > >
> > > 32) I propose to rename the following objects for consistency:
> > >
> > >     natStatsInterfacePktsIn  -> natStatsInterfaceInTranslates
> > >     natStatsInterfacePktsOut -> natStatsInterfaceOutTranslates
>Sounds good.
>
> > >
> > > 33) I suggest to change the notification registration as follows:
> > >
> > >     natMIBNotifications OBJECT IDENTIFIER ::= { natMIB 0 }
> > >
> > >     natAddressUseRising NOTIFICATION-TYPE
> > >         -- yada yada
> > >         ::= { natMIBNotifications 1 }
> > >
> > >     natPacketDiscard NOTIFICATION-TYPE
> > >         -- yada yada
> > >         ::= { natMIBNotifications 2 }
> > >
> > >
> > >     This again saves a sub-identifier and makes things more compact.
> > >
> > > 34) The description of natAddressUseRising makes me beliefe that the
> > >     falling threshold is actually never being used
> > >
> > > 35) Why can you not use natConfAddrMapName instead of natAddrMapName
> > >     in the natPacketDiscard notification? And since you only
> > >     distinguish two discard reasons, why do you not simply use two
> > >     different notifications? This would avoid the introduction of
> > >     natPktDiscardReason. (In general, accessible-for-notify is kind
of
> > >     a strange construction and this is why I wonder about these
> > >     objects.)
>
>Perhaps, Rohit will respond to the above three.
>
> > >
> > > 36) In the compliance section, you always talk about "MIDCOM
> > >     compliance" and I have no clue what that means.
>
>How do you suggest we break the umbilical chord? I agree, much of this has
>no
>meaning unless the Midcom-MIB is published.
>
> > >
> > > 37) I think there are dependencies between the natMIBNotif*Groups and
> > >     you probably want to spell them out since it does not make sense
> > >     to implement the natMIBNotificationGroup without the other
> > >     natMIBNotif*Groups.
>
>perhaps Rohit will respond to this.
>
> > >
> > > 38) I think section 9 is not really needed since this OID assignment
> > >     will happen automatically when this document is being processed.
>OK.
>
> > >
> > > 39) In the security considerations, you simply state that "some of
> > >     these objects could contain sensitive information, e.g. bind
> > >     information". For someone deploying this, it might be useful to
> > >     have a more explicit discussion of the security implications.
>
>Perhaps, this will make more sense when the Midcom MIB is reviewed and
>published. The objective of the Midcom MIB is to ensure that only the
>authorized agents are allowed to modify the NAT resources; And, SNMPv3
>ishall
>be the management protocol.
>
> > >
> > > 40) Remove the leading quote character in teh Full Copyright
Statement
> > >     section.
>OK.
>
> > >
> > > That's it.
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder             International University Bremen
> > > <http://www.eecs.iu-bremen.de/>         P.O. Box 750 561,
> > > 28725 Bremen, Germany
> > >
>
>
>=====
>

_________________________________________________________________
MSN Hotmail now on your Mobile phone.
http://server1.msn.co.in/sp03/mobilesms/ Click here.

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Sep 2003 20:54:10 +0200

>       What should we do in this case ?

As I wrote in another email: Either wait until the MIDCOM MIB is ready
to go as well or put these objects in place at a later point in time by
using AUGMENTS or whatever is a good choice to handle things.
 
>    inconsistentErrorValue but there were comments that this error code 
>    is only specific to some snmp version and hence

The formal argument would be that inconsistentValue is part of the
official SNMP standard and everything else is historic. The more useful
response is that there is a well-defined mapping of SNMPv3 error codes
to SNMPv1 error codes, see RFC 3584 section 4.4.
 
>    Let me know your opinion about the same.

The MIB review guidelines say that you should have StorageType columns
on tables that have RowStatus columns. Why do you think a storage type
is not of much use? Do you assume that all the rows created by a manager
are volatile on all implementations?
 
>    Even if the bind and session have the rowStatus, i don't anticipate

I am not sure whether it helps anyone to have different branches for
things that are configured and things that are not (or unlikely to be
configured). But despite this debatable view of the world, I am 
wondering why some tables have RowStatus columns which you do not 
consider to be used for configuration...
 
> 5. Related to notification changes, we will simplify it a lot in the next

OK. But it would be good to get the WG involved in the changes and to
have the WG agree to the changes.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany