RE: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt
"Jean-Francois Mule" <[email protected]>
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
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
>
>