Re: should guidelines say something about NOT using IMPLIED?

[Andy Bierman <abierman@cisco.com>]

At 12:47 PM 2/7/2003 -0800, C. M. Heard wrote:
>On Thu, 6 Feb 2003, Andy Bierman wrote:
>> The issue with IMPLIED is that it can only be applied to the
>> last component in an INDEX.  This limits future extensions.
>> It prevents the creation of any associated table that would 
>> extend the indexing scheme.  In practice, MIBs have defined
>> such an extension by removing the IMPLIED keyword in the
>> associated table.  This means an implementation cannot
>> reuse the code from the 'primary' table because the sort
>> order is different, and therefore data structures meant
>> to be extended are actually replicated.
>> 
>> In a hierarchical data model (such as SMI-DS) the IMPLIED
>> mechanism would severely limit the reusability and nesting
>> flexibility of the data structures that used it.
>
>Thank you, Andy, for this excellent explanation.  I believe
>that I understand the issue now.  Now the question is what
>we want to say about it.

We can say that it is not recommended because it has
high implementation costs and low user benefit.  As Randy
pointed out, it only provides alphabetical sort order for
US-ASCII strings.

Andy


>Obviously, we at least want to make authors (and ignorant
>reviewers like me :) aware of the cost that IMPLIED imposes
>if there are extension tables.  Going a little further, we
>could say that IMPLIED is NOT RECOMMENDED if extension tables
>currently exist or are likely to exist.  And we could obviously
>ratchet up the disapproval some more.  Before I actually attempt
>to draft any text, I'd like to hear opinions on exactly what the
>guidelines should recommend or require.
>
>As for the logistics of where to put this, in Section 4.6.3,
>under the major bullet "- For conceptual rows:", the second
>indented bullet talks about expansion tables.  The text on
>implications of IMPLIED might go there, or perhaps in a
>paragraph after all the indented bullets.  Other suggestions
>would be welcomed.
>
>Mike