RE: index object restrictions for ipv4/v6 in raqmon-pdu

Bert,

As I said, I have no problems describing the limiting of the read-only object that is also used in an index via a normal OBJECTS clause in the MODULE-COMPLIANCE. My point was that even without this clause there seems to be no real problem, because of the fact that according to the RAQMON framework only IPv4 and IPv6 addresses are being send by RAQMON Data Sources to collectors.  

I'll go with your proposal unless I hear any other contrary opinion.

Regards,

Dan



> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[email protected]]
> Sent: 11 March, 2005 5:15 PM
> To: Romascanu, Dan (Dan)
> Cc: RMON WG (E-mail)
> Subject: RE: index object restrictions for ipv4/v6 in raqmon-pdu
> 
> 
> Wel... I see
>        raqmonParticipantAddrType OBJECT-TYPE
>            SYNTAX InetAddressType
>            MAX-ACCESS read-only
>            STATUS current
>            DESCRIPTION
>                "The type of the Internet address of the 
> participant for
>                 this session."
>            ::= { raqmonParticipantEntry 4 }
> 
>       raqmonParticipantAddr OBJECT-TYPE
>            SYNTAX InetAddress
>            MAX-ACCESS read-only
>            STATUS current
>            DESCRIPTION
>                "The Internet Address of the participant for 
> this session."
>            ::= { raqmonParticipantEntry 5 }
> 
> 
> First, RFC4001 (and so does 3291) states that in the 
> InetAddress, you MUST indicate
> which objct controls the format. So that is the earlier 
> InetAddressType object.
> For example:
> 
>       raqmonParticipantAddr OBJECT-TYPE
>            SYNTAX InetAddress
>            MAX-ACCESS read-only
>            STATUS current
>            DESCRIPTION
>                "The Internet Address of the participant for 
> this session.
> 
>                 The type of this address is determined by the 
> value of the
>                 raqmonParticipantAddrType object.
>                "
>            ::= { raqmonParticipantEntry 5 }
> 
> 
> RFC4001 also states that IF a type of dns is valid (and 
> without any restrictions that
> seems to be valid), then you MUST state when the dns name 
> gets resolved. Maybe that is
> most impartant (or only relevant to) writable objects... but.
> 
> The one read-only object that is also used in an index can 
> nicely be limited
> via a normal OBJECTS clause in the MODULE-COMPLIANCE.
> 
> Hope this helps.
> 
> Bert
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email protected]]
> > Sent: Friday, March 11, 2005 15:18
> > To: Wijnen, Bert (Bert)
> > Cc: RMON WG (E-mail)
> > Subject: RE: index object restrictions for ipv4/v6 in raqmon-pdu
> > 
> > 
> > We can do it, but the read-only non-index objects are not an 
> > issue. All the discussion is about the warning that smilint 
> > returns on potentially exceeding the max OID size in the 
> > table indexed by raqmonParticipantAddr. 
> > 
> > Regards,
> > 
> > Dan
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Wijnen, Bert (Bert) [mailto:[email protected]]
> > > Sent: 11 March, 2005 2:16 PM
> > > To: Romascanu, Dan (Dan)
> > > Cc: RMON WG (E-mail)
> > > Subject: RE: index object restrictions for ipv4/v6 in raqmon-pdu
> > > 
> > > 
> > > Possibly also for index objects (in pdu document):
> > > 
> > >   raqmonPeerAddrType
> > >   raqmonPeerAddr
> > > 
> > > you ought to do something like below indeed.
> > > For the raqmonParticipantAddr occurence in the 
> > > raqmonParticipantAddrTable
> > > you are re-using an object defined in another table, so I 
> would not
> > > think that defining restriction here in this table makes 
> > > sense, does it?
> > > You define the restrictions in the original object (which 
> is defined
> > > read-only if I see it correctly). So see next para.
> > > 
> > > For raqmonParticipantAddrType and raqmonParticipantAddr
> > > and for raqmonParticipantPeerAddrType and 
> raqmonParticipantPeerAddr
> > > (in raqmon-mib document), you can do normal OBJECT clauses, 
> > > they are read-only objects, no?
> > > 
> > > 
> > > Or am I mistaken here?
> > > 
> > > Bert
> > > > -----Original Message-----
> > > > From: Romascanu, Dan (Dan) [mailto:[email protected]]
> > > > Sent: Friday, March 11, 2005 00:58
> > > > To: Wijnen, Bert (Bert)
> > > > Cc: RMON WG (E-mail)
> > > > Subject: RE: index object restrictions for ipv4/v6 in raqmon-pdu
> > > > 
> > > > 
> > > > So, if I am to take the model that you are providing, we 
> > > > should include in the DESCRIPTION clause of the compliance 
> > > > the following:
> > > > 
> > > >                 There is one INDEX object that cannot be 
> > > >                 represented in the form of OBJECT clause 
> > in SMIv2, 
> > > >                 but for which there are compliance 
> requirements, 
> > > >                 expressed in OBJECT clause form in this 
> > > description: 
> > > >      
> > > >                            
> > > >                 -- OBJECT      raqmonParticipantAddr 
> > > >                 -- SYNTAX      InetAddress (SIZE (4 | 8 | 
> > 16 | 20)) 
> > > >                 -- DESCRIPTION 
> > > >                 --     This MIB requires support for global and 
> > > >                 --     non-global IPv4 and IPv6 addresses. 
> > > > 
> > > > Good time for anyone who has an objection to express it.
> > > > 
> > > > Thanks and Regards,
> > > > 
> > > > 
> > > > Dan
> > > > 
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: Wijnen, Bert (Bert) [mailto:[email protected]]
> > > > > Sent: 10 March, 2005 9:38 PM
> > > > > To: Romascanu, Dan (Dan)
> > > > > Cc: RMON WG (E-mail)
> > > > > Subject: index object restrictions for ipv4/v6 in raqmon-pdu
> > > > > 
> > > > > 
> > > > > draft-ietf-ipv6-rfc2096-update-07.txt is a doc that shows
> > > > > how we did it for InetAddressType and InetAddress in that
> > > > > document. I think it would make sense to do a simialr thing.
> > > > > 
> > > > > As discussed at IETF62
> > > > > 
> > > > > Bert
> > > > > 
> > > > 
> > > 
> > 
>