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

["Wijnen, Bert (Bert)" <[e-mail]>]

OK, I think this is a discussion not specific to your IPCDN 
MIB Modules, but a generic discussion about the INET-ADDRESS-MIB
and that is best done on the [e-mail] mailing list
(you must subscribe in order to post).

I believe that a lot of this discussion did take place in the
past already... but it may not be bad to do another rerun if
you so desire. You will find that many/most/all SNMP/SMI/MIB
people will agree with me (approving the RFC3291 basically
means we have IETF consensus on it). If not, then I am 
surprised that not anyone spoke up on the IETF Last Call
for that document (that is what IETF Last Calls are for...
if people just ignore such last calls and then object when
they later get faced with what we believe to be IETF consensus
... well, then our process is broken.... or people/participants
do not understand how the process works).

Thanks,
Bert 

> -----Original Message-----
> From: Eduardo Cardona [mailto:[e-mail]]
> Sent: donderdag 9 januari 2003 3:23
> To: Wijnen, Bert (Bert); [e-mail]
> Cc: [e-mail]; Ipcdn (E-mail)
> Subject: 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ipcdn