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

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 11 Jan 2005 16:47:06 -0700

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-masked]] 
> Sent: Thursday, August 05, 2004 12:33 AM
> To: [email-masked]; Jean-Francois Mule
> Cc: [email-masked]; Wijnen, Bert (Bert); 
> [email-masked]; 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-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Tue, 11 Jan 2005 17:06:56 -0700

> SHOULD fix
[snip]
>     dots in the value, only in the displayed version of it.

Good point and yes, this may be confusing.
Here's a proposed rewording for all the affected object description clauses (it's a bit of a convoluted rewording but that's the best I could come up with):
Replace:
<         If this object is of value '0.0.0.0', the MTA MUST stop 
<         all provisioning attempts as well as all other activities.
<         If this object is of value '255.255.255.255', it means
          there was no preference given for the primary DHCP 
          server, and, the MTA must follow the logic of RFC2131, and  
          the value of DHCP option 122 sub-option 2 must be 
          ignored."

with:
>         If this object is of an InetAddress value equivalent to 
>         '0.0.0.0', the MTA MUST stop all provisioning attempts 
>         as well as all other activities.
>         If this object is of an InetAddress value equivalent to
>         '255.255.255.255', it means
          there was no preference given for the primary DHCP 
          server, and, the MTA must follow the logic of RFC2131, and  
          the value of DHCP option 122 sub-option 2 must be 
          ignored."

Ok?
Jean-François

---

From: "Eugene Nechamkin" <[email-masked]>
Date: Tue, 11 Jan 2005 16:14:56 -0800

Looks good to me.

Eugene.

-----Original Message-----
From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Tuesday, January 11, 2005 4:07 PM
To: Dave Thaler; Eugene Nechamkin
Cc: [email-masked]; Wijnen, Bert (Bert); [email-masked]; C. M. Heard
Subject: RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt

[snip]
> 13) pktcMtaDevServerDhcp1, pktcMtaDevServerDns1, etc: the DESCRIPTION 
> of
> 
>     InetAddress (the "dotted" IP address, etc).  Technically, there's 
> no

Ok?
Jean-François

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Wed, 12 Jan 2005 12:40:29 +0100

Look fine to me too
Bert

> Sent: Wednesday, January 12, 2005 03:39
> To: Jean-Francois Mule; [email-masked]
> Cc: Wijnen, Bert (Bert); [email-masked]; C. M. Heard;
> [email-masked]
> Jean-Francois Mule writes:
> [...]
> >     - change the description of the pktcMtaDevErrorOid to 
> indicate the
> > following:
> >     - 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.
> [...]
> 
> This resolution looks fine to me.
> 
> -Dave
>

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 11 Jan 2005 18:38:42 -0800

> To: Dave Thaler; [email-masked]
> Here's a proposed rewording for all the affected object description
> clauses (it's a bit of a convoluted rewording but that's the best I could
> come up with):
> Replace:

My original comment was specifically in response to the use of the word "dotted" in the DESCRIPTION clauses, which is no longer present in -05.
For example, -04 had 
	"When the latter has the value 'ipv4(1)', this object  
	contains the dotted IP address of the primary DHCP 
	server."
in the description of pktcMtaDevServerDhcp1, whereas -05 has
	"When the latter has the value 'ipv4(1)', this object  
      contains the IP address of the primary DHCP 
      server."

Hence my original comment has been resolved in -05 and in response to your
proposed text above, I actually prefer the current wording (just
"value '0.0.0.0'" rather than "value equivalent to '0.0.0.0'").

-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Tue, 11 Jan 2005 18:38:49 -0800

[...]
>     - after more review of the pktcMtaDevErrorValue object, we do not
> pktcMtaDevErrorValue object may contain all kinds of object values in
the
given
[...]

-Dave

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Wed, 12 Jan 2005 08:24:45 -0700

Ok, I missed to record the removal of "dotted" in my log. Will keep the text of draft05 then.
Thanks,
Jean-Francois.

	-----Original Message----- 
	From: Dave Thaler [mailto:[email-masked]] 
	Sent: Tue 1/11/2005 7:38 PM 
	To: Jean-Francois Mule; [email-masked] 
	Cc: [email-masked]; Wijnen, Bert (Bert); [email-masked]; C. M. Heard 
	Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt

	
	
	-Dave

---

From: "Dave Thaler" <[email-masked]>
Date: Wed, 12 Jan 2005 11:50:44 -0800

It would also make sense to remove the ' ' from around the address values to 
make it clear they're not strings.  Hence:
> <         If this object is of value 0.0.0.0, the MTA MUST stop
> <         If this object is of value 255.255.255.255, it means

-Dave

From: Jean-Francois Mule [mailto:[email-masked]] 
Sent: Wednesday, January 12, 2005 7:25 AM
To: Dave Thaler; [email-masked]
Cc: [email-masked]; Wijnen, Bert (Bert); [email-masked]; C. M. Heard
Subject: RE: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt

-----Original Message----- 
From: Dave Thaler [mailto:[email-masked]] 
Sent: Tue 1/11/2005 7:38 PM 
To: Jean-Francois Mule; [email-masked] 
Cc: [email-masked]; Wijnen, Bert (Bert); [email-masked]; C. M. Heard 
Subject: [ipcdn] RE: Review of draft-ietf-ipcdn-pktc-mtamib-04.txt

-Dave

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 13 Jan 2005 11:49:56 -0700

Dave wrote:
> make it clear they're not strings.  
Absolutely, otherwise it implies this could be the object value. Done.

> Hence:

Thanks,
Jean-François

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 20 Jan 2005 16:31:17 -0700

Just a minor editorial change in our informative text to explain why the pktcMtaDevErrorOid is of type SnmpAdminString.

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

> From: Jean-Francois Mule 
> Sent: Tuesday, January 11, 2005 4:47 PM
> To: Dave Thaler; [email-masked]
> Cc: [email-masked]; Wijnen, Bert (Bert); 
> [email-masked]; C. M. Heard
> indicate the following:
> 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:
> Let us know if this change is acceptable or else, feel free 
> to propose text improvements or suggestions.
> 
> Thanks,
> 
> Jean-François 
> 
> 
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 21 Jan 2005 14:54:54 +0100

Fine by me

Bert

> Sent: Friday, January 21, 2005 00:31
> To: [email-masked]
> Cc: Wijnen, Bert (Bert); [email-masked]
> Just a minor editorial change in our informative text to 
> explain why the pktcMtaDevErrorOid is of type SnmpAdminString.
> 
> :