Entry in ifXTable but not in ifTable. Is that RFC-noncompliant?

[Peter Valdemar Mørch]

We've seen a Nortel Ethernet Routing Switch 5510-48T show rows in
ifXTable, that do not have corresponding rows in ifTable:

$ snmpwalk -v2c -cpublic 1.2.3.4 ifTable | grep 'ifIndex\.10'
IF-MIB::ifIndex.10 = INTEGER: 10

$ snmpwalk -v2c -cpublic 1.2.3.4 ifXTable | grep 'ifName\.10'
IF-MIB::ifName.10 = STRING: ifc10 (Slot: 1 Port: 10)
IF-MIB::ifName.10001 = STRING: ifc10001 VLAN #1
IF-MIB::ifName.10005 = STRING: ifc10005 VLAN #5

Clearly the 10001 and 10005 instances are in ifXTable but not in
ifTable.

ifXEntry is defined with "AUGMENTS { ifEntry }" instead of an INDEX.
Reading the SMIv2 RFC [1] and David T. Perkins' "Inter-Table Indexing
in SNMP MIBs" [2] it seems clear to me that this is not a valid
situation when reading between the lines, but I don't find the RFC
completely clear either.

In section 7.8.1, the RFC says:
> Instances of subordinate columnar objects of a conceptual
> row augmentation are identified according to the INDEX
> clause of the base conceptual row corresponding to the
> object named in the AUGMENTS clause. Further, instances of
> subordinate columnar objects of a conceptual row
> augmentation exist according to the same semantics as
> instances of subordinate columnar objects of the base
> conceptual row being augmented. As such, note that creation
> of a base conceptual row implies the correspondent creation
> of any conceptual row augmentations.

So now I ask: Would you feel confident telling Nortel their switch is
not conforming to the RFC? What do you guys think?

Peter

[1] http://www.rfc-editor.org/rfc/rfc2578.txt
[2] http://www.snmpinfo.com/tables.pdf