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

["Romascanu, Dan (Dan)" <[e-mail]>]

The 'MIB Doctor' agrees. 

Dan


> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:[e-mail]]
> Sent: 26 August, 2003 12:19 AM
> To: 'David Zinman'; Romascanu, Dan (Dan); 'list iptel'
> Cc: 'David Zinman'; 'Bert Wijnen (E-mail)'; Jon Peterson (E-mail)
> Subject: RE: [Iptel] RE: Comments on draft-ietf-iptel-trip-mib-08.txt
> 
> 
> Seems all fine to me now.
> 
> One remaining NIT, can be addressed during RFC-Editing phase 
> as far as I am
> concerned:
> 
>   RFC2119 needs to be referenced NORMATIVELY.
> 
> Jon, as far as I am concerned this one is ready for IETF Last 
> Call and then
> IESG Agenda. I assume that the MIB Doctor (Dan Romascanu) agrees.
> 
> Thanks,
> Bert 
> 
> > -----Original Message-----
> > From: Wijnen, Bert (Bert) 
> > Sent: maandag 11 augustus 2003 20:59
> > To: David Zinman; 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
> > 
> > 
> > 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:[e-mail]]
> > > 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)" <[e-mail]>
> > > To: "Romascanu, Dan (Dan)" <[e-mail]>; "list iptel"
> > > <[e-mail]>
> > > Cc: "David Zinman" <[e-mail]>; "Bert Wijnen 
> > (E-mail)"
> > > <[e-mail]>
> > > 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
[e-mail]
https://www.ietf.org/mailman/listinfo/iptel