RE: IPS Auth MIB 07 changes

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I will let David Harrington respond to your answers on his
comments. After he responds I'll see what I think the total
status is of MIB Doctor Review.

I have comments on your answers to my earlier comments below.
But first some other comments

- Section 4 end of 1st para
     within the IPv4 [RFC2011] or IPv6 [RFC2465] MIB modules.
  RFC2011 has an 2011bis close to being Published (see RFC-Editor queue)
  and it obsoletes both 2011 and 2465. Maybe better to cite and reference
     draft-ietf-ipv6-rfc2011-update-10.txt


- I would change:

    REVISION "200510180000Z" -- October 18, 2005
    DESCRIPTION
        "Initial version of the IP Storage Authentication MIB module"

  into

    REVISION "200510180000Z" -- October 18, 2005
    DESCRIPTION
        "Initial version of the IP Storage Authentication MIB module,
         published as RFCyyyy"  -- RFC-Editor fill in yyyy

- comments/qeustions about IpsAuthAddress

  In IpsAuthAddress TC I see reference to RFC2851, which has been obsoleted
  by RFC4001. I also wonder if it is clear for people how the address
  represented by the TC is being formatted. Why do you not do a 
  IpsAuthAddressType TC in additoon to a IpsAuthAddress TC.
  The TeHopAddressType and TeHopAddress in RFC3811 are a good example
  how it can be done in a much cleaner manner than what you are doing.

  But maybe you only use AddressFamilyNumbers, because that seems to be 
  the discriminator in the 2 cases where you use the TC. Mmm...

I need to spend more time on this module/document. I don't have untill
after the upcoming IETF.

W.r.t. your answers on my earlier comments:

> Comments from Bert Wijnen 2/1/2005
> 
> >So this is hwta I get:
> >
> >   C:\bwijnen\smicng\work>smicng ipsauth.inc
> >   E: f(ipsauth.mi2), (53,7) Leading sub-Id "mib-2" is not known in
> >      current module
> >   W: f(ipsauth.mi2), (5,5) "experimental" imported but not used
> >   *** 1 error and 1 warning in parsing
> >  
> >
> Fixed.
> 

Yep, thanks  Compiles clean now.

> >When I fix that, then it passes SYNTAX checking with SMIXng
> >It also passes smilint syntax checking then.
> >It also passes idnits checking.
> >

Syntax checking clean now.
idnits checking clean now.

> >I think I would change:
> >
> >     ipsAuthDescriptors OBJECT IDENTIFIER ::= { ipsAuthObjects 1 }
> >
> >     ipsAuthMethodTypes OBJECT IDENTIFIER ::= { ipsAuthDescriptors 1 }
> >
> >   into something like:
> >
> >     ipsAuthDescriptors OBJECT IDENTIFIER ::= { ipsAuthObjects 1 }
> >
> >     ipsAuthMethodTypes OBJECT-IDENTITY
> >         STATUS         current
> >         DESCRIPTION   "Registration point for iSCSI Method Types".
> >         REFERENCE     "iSCSI Protocol Specification."
> >     ::= { ipsAuthDescriptors 1 }
> >
> >   It lets you say some more about what this is.
> >   Not a blocking comment though.
> >  
> >
> Done.
> 
Thanks

> >I see in DESCRIPTION of ipsAuthInstIndex (which is a 
> not-accessible index)
> >that values do not need to be preserved over reboot.
> >Does that also mean that ipsAuthInstDescr values do not need to be
> >preserved over reboot?
> >  
> >
> Fixed *Index to recomment preserving across reboots.  Also added
> a StorageType to this row (same as for the Node in the iSCSI MIB)
> to address the ipsAuthInstDescr values.
> 

thanks

> >A similar (not need to be preserved over reboot) is present for:
> >ipsAuthIdentIndex, and yet there is a StorageType object in that
> >table. So what if the StorageType syas "permanent" ??
> >Or what if it says "nonVolatile"?
> >  
> >
> Fixed.
> 
thanks

> >By the way, for a STorageType object you MUST specify which columns
> >(or none) of the writable columns must be writable for permanent 
> >objects.
> >  
> >
> Fixed for ipsAuthInstDescr; all other objects are read-only 
> or read-create.
> 

A read-create object is also a "writable" object. SO you must say it 
for those too.

> >You also need to describe if any (writable) objects in row can
> >be changed when the row is in "active" state.
> >  
> >
> Fixed for ipsAuthInstDescr; all other objects are read-only 
> or read-create.
> 
A read-create object is also a "writable" object. SO you must say it 
for those too.

> >This is all described in RFC2579 and in the mib-review-guidelines.
> >
> 
> Other Modifications:
> 
> Changed "octet string" to "character string" in 
> SnmpAdminString object 
> descriptions.
> 
> Updated references.
> 
> Updated boilerplate text to match RFC 3978/3979.
> 
> Moved Acknowledgements section to the end to match other RFCs.
> 

Great

Bert
> --
> Mark
> 

_______________________________________________
Ips mailing list
Ips@ietf.org
https://www1.ietf.org/mailman/listinfo/ips