RE: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt

Fine by me

Bert

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email protected]]
> Sent: Friday, January 21, 2005 00:31
> To: [email protected]
> Cc: Wijnen, Bert (Bert); [email protected]
> Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
> 
> 
> Just a minor editorial change in our informative text to 
> explain why the pktcMtaDevErrorOid is of type SnmpAdminString.
> 
> :
> On Tuesday, January 11, 2005 at 4:47 PM, I had proposed:
> >          "Note that the syntax of this object is SnmpAdminString
> >           rather OBJECT IDENTIFIER because the object value is
> >           provided by an operator in the MTA configuration file
> >           in the form of a character string."
> 
> Based on Eugene's comment, the newly proposed text is:
>           Note that the syntax of this object is SnmpAdminString
>           rather OBJECT IDENTIFIER because the object value may
>           not be a valid OID due to human or configuration tool
>           encoding errors.
> 
> Let us know if this new proposed text is an issue.
> Jean-François 
> 
> > -----Original Message-----
> > From: Jean-Francois Mule 
> > Sent: Tuesday, January 11, 2005 4:47 PM
> > To: Dave Thaler; [email protected]
> > Cc: [email protected]; Wijnen, Bert (Bert); 
> > [email protected]; C. M. Heard
> > Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
> > 
> > 
> > To close on one additional comment:
> > Dave wrote:
> > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc:
> > >     why are OIDs of type SnmpAdminString rather than an
> > > OBJECT IDENTIFIER
> > >     type/subtype?  As is, the management station cannot do 
> > > simple things
> > >     like expanding the OID into the defined string tokens 
> > in the MIB.
> > 
> > We discussed this point during the IETF IPCDN meeting #61, 
> > see proceedings at:  
> > <http://www1.ietf.org/proceedings_new/04nov/ipcdn.html#cmr>
> > 
> > The meeting minutes recorded:
> >     In the WG meeting, we had consensus that since the OID and its
> >     value is provided in the MTA config file by an operator in the
> >     form of a character string, it is better to leave the syntax
> >     as SnmpAdminString rather than OBJECT IDENTIFIER. It was also
> >     requested that the above explanation be mentioned in the doc.
> > 
> > So, the resolution is:
> >     - no object syntax change
> >     - change the description of the pktcMtaDevErrorOid to 
> > indicate the following:
> >          "Note that the syntax of this object is SnmpAdminString
> >           rather OBJECT IDENTIFIER because the object value is
> >           provided by an operator in the MTA configuration file
> >           in the form of a character string."
> >     - after more review of the pktcMtaDevErrorValue object, 
> > we do not believe the above text should be added to its 
> > description as this pktcMtaDevErrorValue object may contain 
> > all kinds of object values in the case where the MTA can 
> > recognize the OID but cannot interpret the given value.
> > 
> > Proposed text changes:
> > pktcMtaDevErrorOid  OBJECT-TYPE  
> >     SYNTAX      SnmpAdminString
> >     MAX-ACCESS  read-only
> >     STATUS      current
> >     DESCRIPTION 
> >         " This object contains a human readable representation
> >           (character string) of the OID corresponding to the
> >           configuration file parameter that caused the particular
> >           error.
> >           For example, if the value of the pktcMtaDevEnabled object
> >           in the configuration file caused an error, then this
> >           object instance will contain the human readable string of
> >           '.1.3.6.1.2.1.XXX.1.1.6.0'.
> >     ************************************************************
> >     * NOTES TO RFC Editor (to be removed prior to publication) *
> >     * Please replace XXX with the IANA-assigned number under   *
> >     * mib-2.                                                   *
> >     ************************************************************
> > 
> >           If the MTA generated an error because it was not able 
> >           to recognize a particular OID, then this object 
> >           instance would contain an empty value (zero-length
> >           string).
> >           For example, if the value of an OID in the configuration 
> >           file was interpreted by the MTA as being .1.2.3.4.5, and 
> >           the MTA was not able to recognize this OID as a valid one,
> >           this object instance will contain a zero-length string.
> >           Note that the syntax of this object is SnmpAdminString
> >           rather OBJECT IDENTIFIER because the object value is
> >           provided by an operator in the MTA configuration file
> >           in the form of a character string."
> >     ::= {pktcMtaDevErrorOidsEntry 2}
> > 
> > Let us know if this change is acceptable or else, feel free 
> > to propose text improvements or suggestions.
> > 
> > Thanks,
> > 
> > Jean-François 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Dave Thaler [mailto:[email protected]]
> > > Sent: Thursday, August 05, 2004 12:33 AM
> > > To: [email protected]; Jean-Francois Mule
> > > Cc: [email protected]; Wijnen, Bert (Bert); 
> > > [email protected]; C. M. Heard
> > > Subject: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
> > > 
> > > 
> > > Here's my MIB Doctor review of this document and what I
> > > believe MUST/SHOULD/MAY be fixed.
> > > 
> > > MUST fix
> > > --------
> > > 1) There is no IANA Considerations section, and this is now
> > > required in the
> > >    new guidelines.  The draft needs something like (based on 
> > > the template 
> > >    in the guidelines):
> > > 
> > >        9. IANA Considerations
> > > 
> > >        The MIB module in this document uses the following
> > > IANA-assigned
> > >        OBJECT IDENTIFIER values recorded in the SMI Numbers 
> > registry:
> > > 
> > >        Descriptor        OBJECT IDENTIFIER value
> > >        ----------        -----------------------
> > >        pktcMtaMib        { mib-2 XXX }
> > > 
> > >        Editor's Note (to be removed prior to publication):
> > > the IANA is
> > >        requested to assign a value for "XXX" under the 'mib-2'
> > >        subtree and to record the assignment in the SMI 
> > > Numbers registry.
> > >        When the assignment has been made, the RFC Editor 
> is asked to
> > >        replace "XXX" (here and in the MIB module) with 
> the assigned
> > >        value and to remove this note.
> > > 
> > > 2) The page header on pages 2-51 says July 2002
> > > 
> > > 3) MIB Guidelines say
> > >     If the module was developed by an IETF working group, then the
> > >     ORGANIZATION clause MUST provide the full name of the
> > > working group
> > >                                          ^^^^^^^^^
> > > 
> > >    The draft just uses the WG acronym:
> > >        ORGANIZATION "IETF IPCDN Working Group "
> > > 
> > > 4) The LAST-UPDATED date predates the REVISION date:
> > >        LAST-UPDATED "200406160000Z" -- June 16, 2004
> > >        REVISION     "200407160000Z"
> > >                           ^
> > > 
> > > 5) pktcMtaBasicSmtaCompliance contains
> > >        MODULE DOCS-CABLE-DEVICE-MIB
> > >            MANDATORY-GROUPS {
> > >                docsDevSoftwareGroupV2
> > >            }
> > >    but RFC2669 is not referenced as a normative reference
> > >    and docsDevSoftwareGroupV2 isn't in there anyway, only
> > >    docsDevSoftwareGroup.  Is this blocked on the progression
> > > of another
> > >    document containing this?  Looks like this used to be in
> > >    draft-ietf-ipcdn-device-mibv2-*.txt which has now expired.
> > > 
> > > 6) SEQUENCE element #4 `pktcMtaDevCmsSolicitedKeyTimeout'
> > > does not match
> > > 
> > >    order of columnar objects under `pktcMtaDevCmsEntry'.
> > >    Should swap the following two lines:
> > >        pktcMtaDevCmsSolicitedKeyTimeout          Unsigned32,
> > >        pktcMtaDevCmsMaxClockSkew                 Unsigned32,
> > > 
> > > 7) pktcMtaDevProvisioningState has 'passWithWarning' 
> > (singular) in the
> > >    enum, but 'passWithWarnings' (plural) twice in the DESCRIPTION.
> > >    Also has 'failOtherReason' in the enum but 
> 'failureOtherReason' 
> > >    in the DESCRIPTION.
> > > 
> > > 8) The comment on page 29 refers to
> > > draft-ietf-ipcdn-pktc-signaling-02.txt
> > >    This should be added to the references section of the doc.
> > >    Also grammar error "Upper case must be use to"
> > >                                           ^^^
> > > 
> > > 9) Typo in DESCRIPTION of pktcMtaDevCmsKerbRealmName:
> > >    realm table (pktcMtaDevRealmtable)."
> > >                                ^ capitalize
> > > 
> > > 10) The DESCRIPTION of pktcMtaDevRealmTgsGracePeriod has
> > > weird indentation,
> > >     and includes weird characters (as do several other objects).
> > > 
> > > SHOULD fix
> > > ----------
> > > 11) pktcMtaDevErrorOidIndex: say what happens after the 
> > value 1024 is 
> > >     reached
> > > 
> > > 12) pktcMtaDevErrorOid, pktcMtaDevErrorValue, etc:
> > >     why are OIDs of type SnmpAdminString rather than an
> > > OBJECT IDENTIFIER
> > >     type/subtype?  As is, the management station cannot do 
> > > simple things
> > >     like expanding the OID into the defined string tokens 
> > in the MIB.
> > > 
> > > 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the
> > > DESCRIPTION of
> > > 
> > >     these objects is worded as if the type is a string 
> > rather than an
> > >     InetAddress (the "dotted" IP address, etc).  Technically,
> > > there's no
> > >     dots in the value, only in the displayed version of it.
> > > 
> > > 14) pktcMtaDevServerAddressType: what does it mean for this
> > > to be read-write
> > >     but the dependent InetAddress fields to be read-only?  
> > I.e., what 
> > >     happens to the latter immediately after the former is set?
> > > 
> > > MAY fix
> > > -------
> > > 15) Consider defining a TC for kerberos realm names, since
> > > this is used by 
> > >     multiple objects (pktcMtaDevProvKerbRealmName, 
> > > pktcMtaDevRealmName,
> > >     and pktcMtaDevCmsKerbRealmName) and has special syntax 
> > > restrictions 
> > >     (1..255 upper case ASCII chars) 
> > > 
> > > 16) The current conformance statements require read-write in
> > > implementations
> > >     to be compliant.  Is this intended?  Since it currently 
> > > only supports
> > >     ipv4, it doesn't seem useful to require read-write 
> access to the
> > >     InetAddressType objects.
> > > 
> > > 17) pktcMtaDevSwCurrentVers is redundant with sysDescr, so
> > > why is this 
> > >     needed?  The draft says:
> > >         The data presented in this object MUST be
> > >         identical to the software version information contained
> > >         in the 'sysDescr' MIB object of the MTA.
> > > 
> > > 18) The MIB guidelines suggest using { pktcMtaMib 0 } for the 
> > >     notification prefix.  The draft currently requires two
> > > definitions:
> > > 
> > >     pktcMtaNotificationPrefix OBJECT IDENTIFIER ::= { 
> pktcMtaMib 2 }
> > >     pktcMtaNotification OBJECT IDENTIFIER ::= {
> > >          pktcMtaNotificationPrefix 0 }
> > > 
> > >     Is there a good reason for this? (e.g. already deployed
> > > implementations?)
> > > 
> > > 19) What is the expected behavior when reading
> > > pktcMtaDevRealmName and 
> > >     pktcMtaDevRealmOrgName when the row is first created 
> > and they are 
> > >     not set?  (There's no DEFVAL, and the MIB doesn't say 
> > > they have to 
> > >     be set in the initial createAndWait set.)
> > > 
> > > 20) draft-ietf-ipcdn-bpiplus-mib-12.txt is referenced, and is now
> > >     draft-ietf-ipcdn-bpiplus-mib-13.txt
> > > 
> > > 21) The wording in section 8 varies marginally from the template.
> > > 
> > >     Template:
> > >     > Some of the readable objects in this MIB module (i.e.,
> > > objects with a
> > >     > MAX-ACCESS other than not-accessible) may be considered 
> > > sensitive or
> > >     
> > >     Actual:
> > >     > Some of the readable objects in this MIB module may be
> > > considered
> > >     > sensitive or [...]
> > > 
> > > 
> > > 
> > 
> > _______________________________________________
> > IPCDN mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/ipcdn
> > 
> > 
>