Subject: Re: [Adslmib] Profile indexing-a suggestion

From: Randy Presuhn <[email-masked]>
Date: Tue, 26 Nov 2002 09:15:12 -0800 (PST)

Hi -

> From: "Michael Sneed" <[email-masked]>
> To: [email-masked]
> Cc: [email-masked]
> Date: Tue, 26 Nov 2002 10:37:01 -0500
> Message-ID: <[email-masked]>
> Subject: [Adslmib] Profile indexing-a suggestion
...
> I agree that in one sense this is just part of the bigger problem of keeping 
> profiles synchronized. But the name issue is different, 1) because it is 
> easy to fix (ie. either use the name as an
> index, or get rid of it), and 2) because the name, being the user key for 
> the data, is more damaging if it gets out of synch.
...

This, along with Faye's points and the consideration of how
*multiple* management systems could figure out how to refer
to integer-indexed entries at the user interface, leads me
to prefer strings for indexing the profiles.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  SJC-1.3141
 [email-masked]  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------
_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Faye Ly" <[email-masked]>
Date: Fri, 29 Nov 2002 16:49:04 -0800

Mike,

You lost me!  The agent implements profile name in two places using adsl 
line profile as an example:

1. The index of the adsl line profile table.  Any SNMP agent out there can 
handle this and I have never heard about any issue of supporting this using 
SNMPv3.  I think we all agree on this one.  There is no translation needed 
here.  Agent treats 'GoldAdsl' as the key of an entry in the adsl line 
profile table.

2. The reference in the adsl line table to the adsl line profile entry. (aka 
adslLineConfProfile).  Are you saying that certain translation has to occur 
here to support the reference?  Again I don't understand this, are you 
talking about dynamically changing the content of 'GoldAdsl' while there are 
still multiple adsl lines actively using the 'GoldAdsl'??  There is no 
difference between using integer as the index or string here.  The agent 
still needs to maintain a usage map or counter to make sure all the affected 
lines are updated.  Some implementation doesn't allow dynamic update if the 
profile is still being used.  This makes implementation easy.

Note that the tricky part is referencing from the profile to all the lines 
that are using this profile.  The reverse direction is a no brainer.  Most 
of the NE doesn't support more than 20 profiles and even if the agent does a 
sequential search, it shoudln't take that long.

-faye

>CC: [email-masked]
>The profile name is not just a profile parameter, it is going to be used as 
>an alternate key.
>
>Maybe you are looking at the name as a non-key attribute, but that is going 
>to be what a "user" sees as the key. So it is actually an alternate key.
>
>That is the crux of the problem.
>
>Because the relationship between the "real key" and the "alternate key" 
>exists in the agent (since both items exist in the agent), but must also, 
>by assumption, exist in the application (since it is assumed that is where 
>the translation occurs).  There is, therefore, an opportunity for the two 
>to get out of synch.  And for a user who set a line to "Gold" 
>(application's copy of profileName) to then see it as "Paper" (agent's copy 
>of profileName).  So if the "name" changes, that is really a key change.  
>And you haven't gained anything by not making it the index in the MIB, you 
>have only complicated your software (which now has to provide for the 
>possibility of the names being out of synch).
>
>Why don't we just eliminate the "name" from the profile, and instead insert 
>a "Description" and document it as such ? Then  no one would be tempted to 
>use it as the user (application) level identifier for the profile, and 
>there would be no problem, because applications would not use it as a name. 
>And we would get the benefits of using integer indices, which is important 
>in the VDSL MIB.
>
>I agree that in one sense this is just part of the bigger problem of 
>keeping profiles synchronized. But the name issue is different, 1) because 
>it is easy to fix (ie. either use the name as an
>>Hi,
>>Maybe I miss something here but the real problem, as I understand it, is
>>not the memory resources required for saving strings compared to numeric
>>indexes.
>>
>>The real issue is enforcing an upgrade to SNMP version 3. It's clear that
>>the management of profiles using strings would add a task of upgrading the
>>agent to SNMPv3. That certainly would be "an impediment towards product
>>development."
>>
>>BTW, There's no reason to expect that if the EMS uses numeric indexes then
>>it can go out of sync with the NEs.  In case the EMS dictates the profile
>>index (i.e., the unique numeric or textual value) it cannot be changed by
>>the NE and the type of index doesn't matter. If the NE has also the right
>>to add/delete or modify the profiles then this may happen regardless of 
>>the
>>profile index type. Why can the EMS/NE change a profile with an index
>>number 0x4441564500 and it can't perform the same thing if the you
>>interpret the same value as an index name "DAVE"?
>>
>>Best regards,
>>Moti Morgenstern
>>
>>Senior System Engineer
>>Inovia Telecoms Ltd.
>>Member of the ECI Telecom group
>>30 Hasivim St.
>>Petach Tikva, Israel 49133
>>Tel.: +972-3-9266258 Fax: +972-3-9268182
>>e-mail: [email-masked]
>>
>>
>>
>>
>>                       Greg.Bathrick@
>>                       nokia.com                To:      
>><[email-masked]>, <[email-masked]>, <[email-masked]>
>>                       Sent by:                 cc:
>>                       adslmib-admin@           Subject: RE: [Adslmib] 
>>Profile indexing
>>                       ietf.org
>>
>>
>>                       25/11/02 22:09
>>
>>
>>
>>
>>
>>Hi all,
>>Resending... for clarification.
>>
>>One vote for using strings:
>>
>>I appreciate the importance of Bob's comments on the cost of network
>>element resources (size of image, database, memory, flash), however, it is
>>very unusual to have more than a half dozen service profiles.    Even with
>>advance services (video, voice) around the corner, most access providers
>>follow the "keep it simple" rule, and provide a limited number of choices.
>>Therefore, I feel that the management of profiles using strings would NOT
>>be an impediment towards product development.
>>
>>-----Original Message-----
>>From: ext [email-masked] [mailto:[email-masked]]
>>Sent: Monday, November 25, 2002 12:03 PM
>>To: [email-masked]; [email-masked]
>>Subject: RE: [Adslmib] Profile indexing
>>
>>
>>One vote for using strings:
>>
>>I appreciate the importance of Bob's comments on the cost of network
>>element resources (size of image, databased, memory, flash), however, it 
>>is
>>very unusual to have more than a half dozen service profiles.    Even with
>>advance services (video, voice) around the corner, most access providers
>>follow the "keep it simple" rule, and provide a limited number of choices.
>>Therefore, I feel that the management of profiles using strings would be 
>>an
>>impediment towards product development.
>>
>>
>>
>>-----Original Message-----
>>From: ext Michael Sneed [mailto:[email-masked]]
>>Sent: Monday, November 25, 2002 9:05 AM
>>To: [email-masked]
>>Subject: RE: [Adslmib] Profile indexing
>>
>>
>>
>>I am probably beating a dead horse, but what I see is Bob presenting a 
>>good
>>
>>case for using an integer index on the basis of agent storage 
>>requirements.
>>
>>I see people agreeing with him.  What I do not see is anyone addressing 
>>the
>>
>>issue I have raised.
>>
>>There is another way out of the problems.  Eliminate the profile names 
>>from
>>
>>the MIB.  Since the consensus is apparently to have the management
>>applications translate the name to the integer, why do you need to 
>>maintain
>>
>>the name at the agent?  It is strictly a user presentation issue, right?
>>So
>>it is just occupying space on the agent, and providing yet another data
>>item
>>that can get out of sync.
>>
>>
>> >From: [email-masked]
>> >To: "Bob Ray" <[email-masked]>
>> >CC: [email-masked], [email-masked], [email-masked]
>> >Subject: RE: [Adslmib] Profile indexing
>> >Date: Mon, 25 Nov 2002 18:14:01 +0200
>> >
>> >
>> >Bob,
>> >
>> >From our p.o.v.: Keep it as is.
>> >
>> >Best regards,
>> >Moti Morgenstern
>> >
>> >Senior System Engineer
>> >Inovia Telecoms Ltd.
>> >Member of the ECI Telecom group
>> >30 Hasivim St.
>> >Petach Tikva, Israel 49133
>> >Tel.: +972-3-9266258 Fax: +972-3-9268182
>> >e-mail: [email-masked]
>> >
>> >
>> >
>> >
>> >
>> >                       "Bob Ray" <rray@
>> >                       pesa.com>                To:      "Michael Sneed"
>> ><[email-masked]>
>> >                       Sent by:                 cc:      <adslmib@
>>ietf.org>
>> >                       adslmib-admin@           Subject: RE: [Adslmib]
>> >Profile indexing
>> >                       ietf.org
>> >
>> >
>> >                       25/11/02 18:04
>> >
>> >
>> >
>> >
>> >
>> >Are there any opinions from the group on this indexing issue?
>> >
>> >Currently, there are three voices/votes:
>> >
>> >a) Umberto Bonollo - keep it as is (numeric indices)
>> >b) Mike Sneed - revert to strings
>> >c) Bob Ray - keep it as is
>> >
>> >At the IETF meeting, Faye Ly voted to use strings, so
>> >there is a sorta deadlock (2/2).
>> >
>> >Randy?  Bert?  Opinions?
>> >
>> >Bob Ray
>> >
>>_________________________________________________________________
>>The new MSN 8: advanced junk mail protection and 2 months FREE*
>>http://join.msn.com/?page=features/junkmail
>>
>_________________________________________________________________
>MSN 8 with e-mail virus protection service: 2 months FREE* 
>http://join.msn.com/?page=features/virus
>

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

---

From: "Michael Sneed" <[email-masked]>
Date: Sat, 30 Nov 2002 00:00:08 -0500

See comments inline.

>From: "Faye Ly" <[email-masked]>
>To: [email-masked], [email-masked]
>CC: [email-masked]
>Subject: Re: [Adslmib] Profile indexing-a suggestion
>Date: Fri, 29 Nov 2002 16:49:04 -0800
>
>Mike,
>

I don't think SNMPv3 is required or precluded by the string index.

>2. The reference in the adsl line table to the adsl line profile entry. 
>(aka adslLineConfProfile).  Are you saying that certain translation has to 
>occur here to support the reference?  Again I don't understand this, are 
>you talking about dynamically changing the content of 'GoldAdsl' while 
>there are still multiple adsl lines actively using the 'GoldAdsl'??  There 
>is no difference between using integer as the index or string here.  The 
>agent still needs to maintain a usage map or counter to make sure all the 
>affected lines are updated.  Some implementation doesn't allow dynamic 
>update if the profile is still being used.  This makes implementation easy.
>

I was talking about a MIB that uses integer indices, not the curent ADSL 
MIB.  If the table in the MIB uses an integer index, but a user wants to use 
a name for the profile, then *SOMEONE* is doing the translation.  If the 
name also occurs in the MIB table, then there is a potential for 
mistranslation.  As long as the reference in the line table is an index of 
the profile table, whether integer or string, no translation is required in 
the agent, and no updating to the lines would be required by a profile name 
change if integer indices were used.

>of the NE doesn't support more than 20 profiles and even if the agent does 
>a sequential search, it shoudln't take that long.
>

That is certainly one of the tricky parts, and may get trickier with an 
integer index, because if an implementation allows dynamic update (which I 
think is OK if you don't mind having the lines that reference it 
reinitialize) the NAME might change on you (if the name was part of the 
profile that was indexed by the integer).  The reverse direction is 
apparently not a no-brainer, though. Searching a table of 20 across the 
network for every name reference in an application seems like a lot of work, 
and would certainly diminish the utility of integer indices.  However, I 
think the main argument FOR integer indices relates to storage requirements, 
not speed.

My point was really only that if we want to use integer indices, we should 
get rid of the names (in the MIB).

>>The profile name is not just a profile parameter, it is going to be used 
>>as an alternate key.
>>
>>Maybe you are looking at the name as a non-key attribute, but that is 
>>going to be what a "user" sees as the key. So it is actually an alternate 
>>key.
>>
>>(application's copy of profileName) to then see it as "Paper" (agent's 
>>copy of profileName).  So if the "name" changes, that is really a key 
>>change.  And you haven't gained anything by not making it the index in the 
>>MIB, you have only complicated your software (which now has to provide for 
>>the possibility of the names being out of synch).
>>
>>Why don't we just eliminate the "name" from the profile, and instead 
>>insert a "Description" and document it as such ? Then  no one would be 
>>tempted to use it as the user (application) level identifier for the 
>>profile, and there would be no problem, because applications would not use 
>>it as a name. And we would get the benefits of using integer indices, 
>>which is important in the VDSL MIB.
>>

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail