Subject: RE: [NAT] RE: Re RE: Regarding NAT MIB <draft-ietf-nat-natmib-02>

From: "Rohit Rohit" <[email-masked]>
Date: Thu, 3 Jan 2002 09:46:19 -0800

Hi Suresh, 

   I get your point.
   I will make the changes and send the updated
   version by the end of this week.

   Just to make sure that natConfAddrMapEntry will still have two indexes.
   The first index will be natConfAddrMapName and the second index will
   be a rule number ( 1..MAX ).

   Thanks
   Rohit

-----Original Message-----
From: Pyda Srisuresh [mailto:[email-masked]]
Sent: Wednesday, January 02, 2002 9:02 PM
To: Rohit Rohit; Rajendra Prasad
Cc: [email-masked]
Subject: RE: [NAT] RE: Re RE: Regarding NAT MIB
<draft-ietf-nat-natmib-02>

Rohit,

Having just two tables to confiure (per-interface table and
address-map table) makes the MIB simple and easy to follow.

I would suggest the above. Thanks.

cheers,
suresh

--- Rohit Rohit <[email-masked]> wrote:
> Hi Suresh, 
> 
> My comments are inline. Please search for [ROHIT].
> 
> <... stuff deleted>
> > --- Rohit Rohit <[email-masked]> wrote:
> > > Hi, 
> > > 
> > >   The main idea behind dividing the config info in the three
> > >   tables is the modularity and clarity.
> > >   
> > >   There are three steps in configuring the NAT :-> 
> > > 
> > >   1. enable\disable on the particular interface.
> > >   2. define the type of nat and other protocol specific parameters.
> > >   3. define the addrMap.
> > > 
> > >   So the three different tables just represent these three steps.
> > > 
> > This is good.
> > 
> > I see that each interface configuration is covered by NatInterfaceEntry.
> > Within NatInterfaceEntry, I see 
> >   1) is covered by natInterfaceStatus, Even though I believe, there should
> >      be 2 fields - One to control the NAT enable/Disable and 
> >      the second field to query teh status from NAT device.
> > 
> > [ROHIT] the same field can is supposed to show the present status.
> 
> Yup, You are right. Sorry about that.
> 
> >   
> > As for item 2), this is "natConfServiceType" field in NatConfEntry as
> below.
> >     NatConfEntry ::= SEQUENCE {
> >         natConfName                 SnmpAdminString,
> >         natConfServiceType          INTEGER,
> >         natConfProtConfigName       SnmpAdminString,
> >         natConfStorageType          StorageType,
> >         natConfStatus               RowStatus
> >     }
> > So, including natConfName as a field within NatInterfcaeEntry will 
> > do the job, as you say.
> > 
> > As for item 3, I am confused as to how an address map table is 
> > associated with the Interface. 
> > I understand, natConfig is constituted of:
> >       natConfTable, natConfAddrMapTable, natInterfaceTable, 
> >       natConfUdpDefIdleTimeout, natConfIcmpDefIdleTimeout, 
> >       natConfOtherDefIdleTimeout, natConfTcpDefIdleTimeout
> > 
> > Now, How do you associate an Addressmap table with a specific 
> > interface? 
> > 
> > How is NatConfEntry (associated with a specific InterfaceTableEntry)
> > associated with an AddrMaptable? Thanks.
> > 
> > [ROHIT] The addrMap Tables have two indexes :-> 
> >         natConfName, natConfAddrMapName.
> > 
> OK. natConfName is currently not an index in AddrMapEntry.
> I assume, you were suggesting to add this.
> 
> [ROHIT] natConfName is already an index to the natAddrMapEntry.
> 
> natConfAddrMapEntry OBJECT-TYPE
>     SYNTAX      NatConfAddrMapEntry
>     MAX-ACCESS  not-accessible
>     STATUS      current
>     DESCRIPTION
>             "A description of a NAT entry. This entry
>              contributes to the dynamic or static NAT table of 
>              the device."
>     INDEX   { natConfName, natConfAddrMapName }
>     ::= { natConfAddrMapTable 1 }
> 
> 
> I have a somewhat radically different thought on the organization
> of natconf. Here it goes. Do let me know what you think.
> 
>  * I believe, we can simplify natConfig to consist of just
>    natInterfaceTable and natConfAddrMapTable. 
> 
>    I.e., get rid of natConfTable, natConfUdpDefIdleTimeout,
>    natConfIcmpDefIdleTimeout, natConfOtherDefIdleTimeout, and
>    natConfTcpDefIdleTimeout from natConfig.
>  
>  * The natInterfaceTable may be expanded to contain 
>    natConfUdpDefIdleTimeout, natConfIcmpDefIdleTimeout, 
>    natConfOtherDefIdleTimeout, natConfTcpDefIdleTimeout, 
>    natConfServiceType, natConfAddrMapName and 
>    natConfProtConfigName fields
> 
>    natConfServiceType will describe the NAT-type for the
>    interface - Traiditional-NAT, Twice-NAT or Bidirectional-NAT.
>    
>    natConfAddrMapName will be the index into the NAT
>    Address map table. 
> 
>    natConfProtConfigName will be the index into protocol
>    specific natProtConfTable (for the future)
> 
>  * The natConfAddrMapEntry may be expanded to include 
>    AddrMapIndex field.
> 
>    So, all entries of an address map will be identified 
>    by natConfAddrMapName, with differing index or rule number.
> 
> 
> [ROHIT] The suggested approach is towards combining the natConfTable
>         and natInterfaceTable and then adding the pointer to the 
>         natConfAddrMapName in the same table.
> 
>         I don't see any problem or issue with the approach. It is just
>         rearranging the config parameters. Whichever approach is more
>         close to the practical implementation, we should go ahead with that.
> 
> 
> Thanks
> Rohit
>     
> <... stuff deleted>
> 
> regards,
> suresh
> 
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com

=====

__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 3 Jan 2002 10:36:20 -0800 (PST)

Sounds good. Thanks.

cheers,
suresh

=====

---

From: Pyda Srisuresh <[email-masked]>
Date: Thu, 3 Jan 2002 10:36:20 -0800 (PST)

Sounds good. Thanks.

cheers,
suresh

=====