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

["Peterson, Jon" <[e-mail]>]

Okay, great! IETF Last call will be forthcoming shortly.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[e-mail]]
> Sent: Tuesday, August 26, 2003 3:07 AM
> To: Wijnen, Bert (Bert); David Zinman; list iptel
> Cc: David Zinman; Jon Peterson (E-mail)
> Subject: RE: [Iptel] RE: Comments on draft-ietf-iptel-trip-mib-08.txt
> 
> 
> 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
> 

_______________________________________________
Iptel mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/iptel