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

Does this mean that David's address info needs to be updated
as well??!!

Thanks,
Bert 

-----Original Message-----
From: dzinman@somanetworks.com [mailto:dzinman@somanetworks.com]
Sent: maandag 11 augustus 2003 15:20
To: bwijnen@lucent.com
Subject: Re: RE: Comments on draft-ietf-iptel-trip-mib-07.txt

Please be advised that David Zinman is no longer employed at SOMA
Networks, Inc.

For SOMA business matters requiring assistance, please contact
Glenn McAllister at glenn@somanetworks.com.

-------- Original Message --------

> 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