RE: [ipcdn] RE: (ipcdn) review of subscriber management mib?

Thanks Bert, For the comments, 

Maybe the topic is out of the ipcdn group so move back to ipcdn topics.

Just see more comments inline '<Edo></Edo>' if interested

Thanks

Eduardo

> Q: If indeed this is done for all drafts, Would still IETF prefer to 
> define InetAddress TEXTUAL-CONVENTION for all this objects instead of 
> InetAddressIPv4 ? And avoid all those COMPLIANCE statements that are 
> replicating in a verbose way the InetAddressIPv4 SYNTAX . (ipv6, dns 
> types are not required in all DOCSIS modules )
> 
The idea of the approach you currently have is that the OBJECT
definitions in the MIB Module itself are all ready for IPv6 (and other
protocols as well). By the time you (or whoever) decides they want to
use this with IPv6 (or whatever other protocol), they can use the MIB
Module unchanged. All that is needed is a possible extra
MODULE-COMPLIANCE (which could be in a separate document) to show that
from then on (or better, in order to claim compliance with the new
compliance
 statement) one must also support IPv6.

<Edo>
I may abandon my desires on that, due to the fact that I guess RFC2578
Section 9. "Refined Syntax" for OCTET STRING note(3) does not allow  an
upgrade of TC octet string to augment the size choise (just to reduce
it) ? 
The bottom line is that the TC is OCTET string, so moving from (SIZE(4))
to InetAddress (SIZE(0..255) may not valid. Am I correct?

I will say I had no intention to be out of the IPv6 upgrading path. Just
getting the minimum COMPLIANCE statements
 << objectable ) :-) >>

But let me explain what weres my thoughs.... Or jump over the next
<Edo></Edo>

I see this as an analogy:
RFC2011 is being proposed to be deprecated by
draft-ietf-ipv6-rfc2011-update-01.txt 
Until someone decided to support Ipv6, there is no need to have support
for the 'RFC2011-update'.
All instrumentation around mib-2 RFC2011 is no longer valid for IPv6
including (i.e) ipNetToMediaTable, now inetNetToMediaTable ( Time to
change the NMS) in the mean time everyone will continue using the
traditional RFC2011 ipNetToMediaTable.

In DOCSIS, mib drafts there are provisions for IPv6 like InetAddressType
and InetAddress* TC rather than IpAddress type.
I do no see a hurry of fully implementing 'InetAddress' TC and being
IPv6 'ready' when IPv4 is overloaded with a big set of COMPLIANT
statements which add few value in the chain (IPv4 is what we care now).

(**) The upgrade to Support IPv6 or any other protocol would be ( if
IETF allows that) moving from InetAddressIPv4 to InetAddress which
technically is no more than moving from SIZE(4) to size(0..255) OCTET
STRING -I'd prefer SIZE(4|8|16|20) under a new TC with no dns(16) type -
and no compliance statements at all. 
Or deprecate the mibs just to change the TC as RFC2011 moving from
IpAddress to InetAddress ? Because of RFC2578 requirements?

Closing the topic :
- InetAddress TC is so general, MIB is ready for further IP protocols
but the backward IPv4 SMIv2 compatibility problem could be costly at
expenses of not still implementing Ipv6 or any other protocol.
 ( see comment about NMS)

</Edo>

> In such way a NMS will have the DISPLAY-HINT 1d.1d.1d.1d ready that is

> the current pain.

I would think that any decent NMS these days should be able to 
handle the techniques as presented in RFC3291, no?
So why would it be so difficult for this specific MIB module.

<Edo>
I guess It is not a problem with this particular mib, it is for all mibs
involved with IP objects migrating to Ipv6. 

The RFC3291 procedure to assign the DISPLAY-HIT based on the object type
is not backward compatible with current(before inetAddress)/legacy NMS
entities and SMIv2 requirements. Now you need an extra object
(inetAddressType) to discriminate the DISPLAY-HINT, so no arbitrary
get/getnext request to an Address object will be able to hint the object
syntax.

 IPv4 case: 
So far 4 browsers/applications I know, handle 'inetAddress' as just
plain OCTET STRING SIZE(0..255) -since no DISPLAY-HINT-, then, a user
gets a Hex format for ipv4 values.

If an "1d." DISPLAY-HINT is set, some of them will present (SNMP GET
operations) in friendly ip format d.d.d.d 
few less will still recognize the hint format and encode properly when
doing SNMP SET operations.
Those cases are worst in graphical interfaces applications.

</Edo>

> I can still illegally have a friend IPv4 representation  by adding in 
> the Browser MIB a DISPLAY-HINT to InetAddress TEXTUAL-CONVENTION in 
> RFC3291, but is not the desired solution.
> 
People can always do illegal things. We are not law (or protocol or
stds) enforcement body... so what can I say.
Cablelabs should not certify implementations that do illegal things
(they have more power than IETF have in this regard).

<Edo>
In this case there is not certainly an ilegal thing that comes with a
wrong implementations, It just a work around in the browser side (not
the Agent implementation) because is knew that ipv4 is the expected
value. What I am saying is I would prefer not having to modified the
InetAddress Tcin RFC3291, or advice someone to do that as I've been
forced to do in some cases, including CableLabs for testing purposes.

We are in an intermedia position: Writing IPv4 implementations
requirements with Ipv6 requirements and not even satisfying the IPv4
needs as they were under SMI/SMIv2 IpAddress scheme ( and I will argue
RFC3291 is broken, not SMIv2 backward compatible in the management
entity side).

</Edo>

Hope this helps.
Bert
> Thanks
> 
> Eduardo
_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn