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

From: "Faye Ly" <[email-masked]>
Date: Thu, 05 Dec 2002 17:52:33 -0800

Mike,

Point well taken.  But I think we want to use SnmpAdminString as the index 
of the VDSL profile table following the same convention as ADSL and HDSL 
MIBs.  Is this correct?

Best,

-faye

>From: "Michael Sneed" <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>Subject: Re: [Adslmib] Profile indexing-a suggestion
>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,
>>
>>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.
>
>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.
>
>>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.
>>
>
>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).
>
>
>
>>-faye
>>
>>
>>
>>
>>
>>
>>>From: "Michael Sneed" <[email-masked]>
>>>To: [email-masked]
>>>CC: [email-masked]
>>>Subject: [Adslmib] Profile indexing-a suggestion
>>>Date: Tue, 26 Nov 2002 10:37:01 -0500
>>>
>>>
>>>
>>>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
>>>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.
>>>
>>>
>>>>
>>>>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
>>>> >
>>>> >_______________________________________________
>>>> >Adslmib mailing list
>>>> >[email-masked]
>>>> >https://www1.ietf.org/mailman/listinfo/adslmib
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >_______________________________________________
>>>> >Adslmib mailing list
>>>> >[email-masked]
>>>> >https://www1.ietf.org/mailman/listinfo/adslmib
>>>>
>>>>
>>>>_________________________________________________________________
>>>>The new MSN 8: advanced junk mail protection and 2 months FREE*
>>>>http://join.msn.com/?page=features/junkmail
>>>>
>>>>_______________________________________________
>>>>Adslmib mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/adslmib
>>>>_______________________________________________
>>>>Adslmib mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/adslmib
>>>>_______________________________________________
>>>>Adslmib mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/adslmib
>>>>
>>>>
>>>>
>>>>
>>>>_______________________________________________
>>>>Adslmib mailing list
>>>>[email-masked]
>>>>https://www1.ietf.org/mailman/listinfo/adslmib
>>>
>>>
>>>_________________________________________________________________
>>>MSN 8 with e-mail virus protection service: 2 months FREE* 
>>>http://join.msn.com/?page=features/virus
>>>
>>>_______________________________________________
>>>Adslmib mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/adslmib
>>
>
>
>_________________________________________________________________
>Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
>http://join.msn.com/?page=features/featuredemail
>
>_______________________________________________
>Adslmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/adslmib

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

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