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

Looks good.
I understand that the warnings do not go away.
But they are "warnings", and so we check if the DESCRIPTION
clause has the proper instructions to implementers, and they now
do. So it looks good to me.

Thanks,
Bert 

> -----Original Message-----
> From: David Zinman [mailto:dzinman@rogers.com]
> Sent: maandag 11 augustus 2003 20:07
> To: Wijnen, Bert (Bert); Romascanu, Dan (Dan); list iptel
> Cc: David Zinman; Bert Wijnen (E-mail)
> Subject: Re: [Iptel] RE: Comments on draft-ietf-iptel-trip-mib-07.txt
> 
> 
> inline:
> 
> ----- Original Message ----- 
> From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>; "list iptel"
> <iptel@ietf.org>
> Cc: "David Zinman" <dzinman@somanetworks.com>; "Bert Wijnen (E-mail)"
> <bwijnen@lucent.com>
> Sent: Monday, August 11, 2003 9:20 AM
> Subject: [Iptel] 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.
> >
> 
> I am leaving section 14 in for now.
> 
> > 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.
> 
> Added both the reference to RFC 2788 and the REVISION clause 
> in TRIP-TC
> 
> > - 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:
> 
> I have removed the restriction on the index sizes, and included the
> description
> of the 128 limit. However this will not get rid of the warnings.
> 
> >       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.
> 
> I have included the IMPORT
> >
> > From a generic review
> > - Missing reference [BCP0014]
> 
> Added reference to this BCP (RFC2119)
> 
> > - Ref [RFC2026] probably goes away when this becomes an RFC
> 
> I'm leaving this in for now.
> 
> >
> > Thanks,
> > Bert
> >
> 
> I have also addressed Dan's concern about the copyright year 
> and the area
> directors in section 14.
> 
> I will submit the new draft (08) if there are no further comments.
> 
> Cheers,
> DZ
> 

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