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: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