[Iptel] RE: Comments on draft-ietf-iptel-trip-mib-07.txt

Bert is correct with respect to the OID size limit errors. I was using a non-edited version of the MIB (with the root OID xxxx-ed) and did not get the errors at compilation. These were rather major issues in my previous review, and I suggest that you fix them before advancing the document. I think that we talked about something similar the DESCRIPTION text suggested by Bert on the corridors in Vienna.

Regards,

Dan

> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: 11 August, 2003 4:20 PM
> To: Romascanu, Dan (Dan); list iptel
> Cc: David Zinman; Bert Wijnen (E-mail)
> Subject: RE: Comments on draft-ietf-iptel-trip-mib-07.txt
> 
> 
> Thanks Dan for your review.
> 
> I think the copyright-year will be addressed by RFC-Editor 
> when it gets there.
> So unless there are othe reasons for a respin, I can live 
> with it for now.
> But it seems anew rev may be wise because of my additional 
> comments below
> 
> I wonder why sect 14 is needed. I leave this up to TSV AD(s) 
> on how to deal
> with it.
> 
> From a MIB review perspective I have a few additional comments):
> -  I think that RFC2788 needs to be added to normative 
> references since
>    this doc IMPORTs from the  NETWORK-SERVICES-MIB in RFC2788
> - TRIP-TC module does not have a REVISION clause, which we actually DO
>   want to have.
> - I get these smilint warnings:
>     .\TRIP-MIB:327: [5] {index-exceeds-too-large} index of 
> row `tripRouteTypeEntry'
>       can exceed OID size limit by 6 subidentifier(s)
>     .\TRIP-MIB:511: [5] {index-exceeds-too-large} index of 
> row `tripPeerEntry' can
>       exceed OID size limit by 6 subidentifier(s)
>   SMICng complains about the same. I see
>           1.3.6.1.2.1.xxxx.1.2.1.6  tripRouteTypePeer 
>   as the first accessible object int tripRouteTypeEntry. So 
> prefix is 11 subids
>   index objects are 5 integer-based objects and a var size 
> octet string.
>   so we have 5 plus 1 (for lenght) plus number of octets as 
> index part.
>   So we have 6 fixed (5 integers plus length value) subids 
> plus one for every
>   octet in the octet string. So max size for OCTET STRING should be
>   111 octets, not 117.
>   Similar calculation for tripPeerEntry seem to tell me max 
> lenght can be 113
>   instead of 119.
>   This makes me thin k that it is kind of strange to ha ve 
> different size for InetAddress,
>   is it not. Another way to solve these concerns is to add 
> something to the DESCRIPTION
>   clause that states the implementation issues w.r.t. 128 
> subids instad of setting
>   arbitray size constrains in the SYNTAX field  (that we may 
> regret if the 128 subid
>   limit ever gets removed). A good example of text for this 
> would be in
>   arcEntry in draft-ietf-disman-conditionmib-09.txt or 
> sctpAssocLocalAddrEntry in
>   draft-ietf-sigtran-sctp-mib-10.txt
> - smicng (strict checking) also complains:
>       E: f(trip.mi2), (1629,33) Item "applRFC2788Group" 
> should be IMPORTed
>   it is not a MUST that you do import it. But as the 
> mib-review-guidelines state,
>   it would be good to do so to not cause confusion.
> 
> From a generic review 
> - Missing reference [BCP0014]
> - Ref [RFC2026] probably goes away when this becomes an RFC
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> > Sent: maandag 11 augustus 2003 14:34
> > To: list iptel
> > Cc: David Zinman; Bert Wijnen (E-mail)
> > Subject: Comments on draft-ietf-iptel-trip-mib-07.txt
> > 
> > 
> > The latest version addresses all major issues in my previous 
> > review, and does not seem to have introduced new ones. 
> > 
> > I am left with two editorial comments, which may be addressed 
> > down the road:
> > 1. The copyright year in the DESCRIPTION clauses of the two 
> >       MIB modules still says 2002.
> > 2. One of the Area Directors was replaced since the previous 
> >       Internet-Draft publication (Section 14). 
> > 
> > Thanks,
> > Dan
> > 
> 

_______________________________________________
Iptel mailing list
Iptel@ietf.org
https://www.ietf.org/mailman/listinfo/iptel