[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.

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