RE: [ipcdn] RE: MIB doctor review of: draft-ietf-ipcdn-pktc-mtamib-01.txt (Part 1)

Mike,

Below are the second part of our response to your MIB doctor review. 
It is in response to your comment #11.

Thank you,
Eugene and Jean-Francois.

> 11.) Technical content -- here are the comments on the 
> content of Section 4, "Definitions," which contains the 
> PKTC-IETF-MTA-MIB.
> 
> (a) In the MODULE-IDENTITY DESCRIPTION clause:
> s/set if requirements/requirements/
ok, done in draft-02.
> 
> (b) The ASN.1 comment preceding 
> DocsX509ASN1DEREncodedCertificate promises to do something 
> that is not allowed:
> 
>    --
>    -- The following textual convention will be imported from BPI+ RFC
>    -- when introduced there.
>    --
> 
> It is ILLEGAL to move a TC from one module to another or to 
> remove a definition from a published MIB module.  If the TC 
> is to be imported from the BPI-plus MIB, then do so before 
> this module is published;  otherwise, plan on leaving it in 
> in perpetuity (in which case there is no point in IMPORTING 
> it).  In the latter case, you may want to change the name to 
> PktcMtaX509ASN1DEREncodedCertificate.  In any case, that 
> comment has to go.
Now that draft-ietf-ipcdn-bpiplus-mib-11.txt contains the TC
convention DocsX509ASN1DEREncodedCertificate, in draft02 of the MTA
MIB, we did the following:
 1. remove the TC definition and imported the object def from
DOCS-IETF-BPI2-MIB.
 2. added normative reference to BPI+ mib RFC and added RFC editor
note.

> (c) The REFERENCE clauses do not have a consistent style 
> throughout. Sometimes a document is referred to by title 
> alone;  sometimes a document is referred to by number alone;  
> and in some cases both styles are used in the same REFERENCE 
> clause, e.g.,
> 
>  REFERENCE
>      "PacketCable Provisioning Specification. RFC 3495."
> 
> I find this a little confusing:  it's not clear at a glance 
> whether RFC 3495 is the number of the PacketCable 
> Provisioning Specification or is a separate document.  For 
> this reason I ask that all REFERENCE clauses be updated to 
> use a consistent style when referring to documents.  My 
> suggestion would be to see something line this, which has 
> both document number and
> (abbreviated) title, and which has distinct document 
> references separated by a semicolon:
> 
>  REFERENCE
>      "PKT-SP-PROV-I07-030728, PacketCable MTA Device Provisioning
>       Specification;  RFC 3495, DHCP Option for CableLabs Client
>       Configuration."
> 
Comment received and partially addressed. We did follow the
recommendation for the published RFCs. 
However, for PacketCable specifications, since we update them 3 times
a year, we did not include the PKT-SP-xxx-I0n numbering in the
REFERENCE clause. For e.g., in draft02, we have:
    REFERENCE
        " RFC 2132, DHCP Options and BOOTP Vendor Extensions"
    REFERENCE
        " PacketCable MTA Device Provisioning Specification;
          RFC 3495, DHCP Option for CableLabs Client Configuration."

> (d) In the DESCRIPTION clause of pktcMtaDevSwCurrentVers: 
> s/'sysDecr'/'sysDescr'/
> 
ok, done in draft-02.

> (e) Should the DESCRIPTION clause of pktcMtaDevFQDN say what
> is returned if the device is queried before a domain name
> has been assigned to it?
No action taken. 
Explanation: the MTA cannot be queried via SNMP before the boot
process is complete and an MTA gets its FQDN before it starts its SNMP
agent process.

> (f) In the DESCRIPTION clause of pktcMtaDevEndPntCount:
> s/The physical end points/The number of physical end points/
> 
ok, done.
Also we cleaned the wording of endpoint throughout the document (we
now have a consistent use of endpoint in lieu of end point or
end-point).

> (g) In the definition of pktcMtaDevTypeIdentifier:  please
> add a REFERENCE clause pointing to RFC 2132, where option #60 
> is defined.  NOTE:  there are several other objects that need 
> to have a REFERENCE to RFC 2132.  Among them are 
> pktcMtaDevServerDns1 (option #6), pktcMtaDevServerDns2 
> (option #6), and pktcMtaDevTimeServer (option #4).
> 
ok, done in draft02.

> (h) In the DESCRIPTION clause of pktcMtaDevErrorOidsTable:
> it might be a good idea to specify when in the provisioning 
> process this table is cleared (presumably you do want the 
> table cleared if provisioning is restarted).
>
ok, done in draft-02.
Added clarification in the last sentence, now says: 
"The table MUST be cleared each time the MTA reboots."

> (i) The DESCRIPTION clause of pktcMtaDevErrorOid says:
> 
>    "If the error was due to a reason which cannot be associated
>     with 'recognizable' OID of the parameter, then this MIB
>     object must contain an empty value."
> 
> It is not clear what the words "an empty value" mean.  If you 
> mean "{ 0 0 }" please say so.
> 
> (also, s/Parameter, which caused/Parameter that caused/)
> 
ok, done in draft-02. The DESCRIPTION and SYNTAX have been modified as
follows:
 pktcMtaDevErrorOidsTable  OBJECT-TYPE  
    SYNTAX SEQUENCE OF PktcMtaDevErrorOidsEntry 
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION 
        " This table contains the list of configuration errors or 
          warnings the  MTA encountered when parsing the
          configuration file it received from the provisioning 
          server. 
          For each error, an entry is created in this table
          containing the configuration parameters the MTA rejected
          and the associated reason (e.g. wrong or unknown OID, 
          inappropriate object values, etc.). If the MTA 
          did not report a provisioning state of 'pass(1)' in
          the pktcMtaDevProvisioningState object, this table MUST be
          populated for each error or warning instance. Even if
          different parameters share the same error type (e.g., all
          realm name configuration parameters are invalid), all
          observed errors or warnings must be reported as 
          different instances. Errors are placed into the table in 
          no particular order. The table MUST be cleared each time 
          the MTA reboots." 
    REFERENCE
        " PacketCable MTA Device Provisioning Specification."
    ::= {pktcMtaDevBase 11 }

> (j) The DESCRIPTION clause of pktcMtaDevErrorValue says:
> 
>    "If the error was due to unrecognizable OID of the
>     parameter in the Configuration File, then this MIB
>     Object contains the value of the OID as interpreted
>     MTA. Otherwise (the error happens due to a wrong value
>     of the parameter) - the MIB Object contains the value
>     from the Configuration File converted to SnmpAdminString."
> 
> Putting on my implementor's hat I have a number of problems 
> with this DESCRIPTION clause.  First, it's not clear what is 
> meant by the first sentence.  I'm guessing that it means that 
> if I see an OID in a configuration file that I don't 
> recognize then I must populate this object (rather than 
> pktcMtaDevErrorOid) with that OID.  I shouldn't have to 
> guess.  Second, there is no guidance on how I am suppose to 
> turn OIDs or other values into an SnmpAdminString.  If this 
> is left unspecified then it's quite likely that different 
> implementations will do different things. So, I must ask that 
> you clarify this DESCRIPTION clause.
> 
ok, attempt to improve the description was done in draft02. The
DESCRIPTION has been modified as follows:
pktcMtaDevErrorValue  OBJECT-TYPE
    SYNTAX      SnmpAdminString
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        " This object contains the value of the OID corresponding to
          the configuration file parameter that caused the error.
          If the MTA cannot recognize the OID of the
          configuration parameter causing the error, then this
          object instance contains the OID itself as interpreted
          by the MTA in human readable representation.
          If the MTA can recognize the OID but generate an error due
          to a wrong value of the parameter, then the object
          instance contains the erroneous value of the parameter as
          read from the configuration file.
          In both cases, the value of this object must be
          represented in human readable form as a character string.
          For example, if the value of the pktcMtaDevEnabled object
          in the  configuration file was 3 (invalid value), then the
          pktcMtaDevErrorValue object instance will contain the
          human readable (string) representation of value '3'.
          Similarly, if the OID in the configuration file has been
          interpreted by the MTA as being .1.2.3.4.5, and the MTA
          cannot recognize this OID as a valid one, then this
          pktcMtaDevErrorValue object instance will contain human
          readable (string) representation of value '.1.2.3.4.5'"
    ::= {pktcMtaDevErrorOidsEntry 3}

> (k) This comment deals with some problems related to the 
> usage of the InetAddressType/InetAddress TCs that affect 
> objects of those types in the pktcMtaDevServer group.
> 
> First: the DESCRIPTION clause of pktcMtaDevServerAddressType says:
> 
>  This object defines the address type for the following 
> servers:  pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2, 
> pktcMtaDevServerDns1,  pktcMtaDevServerDns2, pktcMtaDevTimeServer.
> 
> However, the DESCRIPTION clauses of pktcMtaDevServerDhcp1, 
> pktcMtaDevServerDhcp2, pktcMtaDevServerDns1, 
> pktcMtaDevServerDns2, and pktcMtaDevTimeServer do not have 
> this information, as required by the DESCRIPTION clause of 
> the InetAddress TC:
> 
> | An InetAddress value is always interpreted within the context of an 
> | InetAddressType value. Every usage of the InetAddress textual 
> | convention is required to specify the InetAddressType object which 
> | provides the context.
> 
> I strongly recommend, for reasons of ease of maintenance, 
> that the InetAddress/InetAddressType association be specified 
> in the DESCRIPTION clauses of the InetAddress objects _only_. 
ok done.

>  The reason is that it is possible to add new InetAddress 
> objects -- possibly in a different MIB module -- that use a 
> pktcMtaDevServerAddressType as the type discriminator, and if 
> the associations are listed in the 
> pktcMtaDevServerAddressType DESCRIPTION clause the it would 
> need to be updated whenever this happens.  It's clearly 
> undesirable (and not always feasible) to do that.
ok, makes sense.

> Second: although InetAddressType object 
> pktcMtaDevServerAddressType is formally allowed to assume 
> values other than ipv4 -- which may indeed be desirable for 
> future extensibility -- the DESCRIPTION and REFERENCE clauses 
> for the corresponding InetAddress objects 
> pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2, 
> pktcMtaDevServerDns1, pktcMtaDevServerDns2, and 
> pktcMtaDevTimeServer do not currently provide any meaning for 
> any address types other than ipv4(1).  The main reference 
> PacketCable MTA Device Provisioning Specification, 
> PKT-SP-PROV-I07-030728, only discusses provisioning with 
> DHCPv4 and not DHCPv6, and only discusses the use of IPv4 for 
> communication with the DHCP server.  So it's not clear what a 
> client would do with anything other than IPv4 addresses for 
> pktcMtaDevServerDhcp1 and pktcMtaDevServerDhcp2.  Also, the 
> DHCP options that correspond to the pktcMtaDevServerDns1, 
> pktcMtaDevServerDns2, and pktcMtaDevTimeServer objects (cf. 
> #11(g) above) are values of DHCPv4 options, which can only 
> contain IPv4 addresses.
Understand our current limitations, however, this MTA MIB is derived
from specifications that only defined IPv4 behavior.

> If future extensibility to IPv6 is desirable and possible, 
> then the suggested fixes for the problems are to revise the 
> DESCRIPTION clauses for pktcMtaDevServerDhcp1, 
> pktcMtaDevServerDhcp2, pktcMtaDevServerDns1, 
> pktcMtaDevServerDns2, and pktcMtaDevTimeServer along the 
> following lines:
> 
>             "The type of this address is determined by the value of
>              the pktcMtaDevServerAddressType object.  When the latter
>              has the value ipv4(1), this object is [ ... ].
> 
>              The behavior of this object when the value of
>              pktcMtaDevServerAddressType is other than ipv4(1)
>              is not presently specified, but may be specified
>              in future versions of this MIB module."
ok, done in draft02.

> where [ ... ] contains the existing description text 
> (modified as needed for grammatical correctness and to remedy 
> the deficiencies noted in #11(g) above and #11(l) through 
> #11(n) below) and to remove the second sentence of the 
> pktcMtaDevServerAddressType DESCRIPTION clause.
ok, done in draft02.

> If, on the other hand, there is no realistic possibility of 
> re-using this MIB module with a future IPv6-capable version 
> of the PacketCable MTA specs, then it would probably be 
> better to eliminate pktcMtaDevServerAddressType and change 
> the SYNTAX value of pktcMtaDevServerDhcp1, 
> pktcMtaDevServerDhcp2, pktcMtaDevServerDns1, 
> pktcMtaDevServerDns2, pktcMtaDevTimeServer to 
> InetAddressIPv4. Note that this is permitted (although not 
> encouraged) by RFC 3291 (and its successor 
> draft-ietf-ops-rfc3291bis-01.txt).
> In subsequent comments I'll assume that the first solution is 
> adopted;  if it isn't please modify suggested text as appropriate.
we opted to keep InetAddressType and add your proposed statement.

> (l) The DESCRIPTION clauses of pktcMtaDevServerDhcp1 and 
> pktcMtaDevServerDhcp2 should explicitly state that these 
> parameters are normally provided by the Cable Modem (CM) 
> entity associated with the MTA, and that the CM gets them as 
> the values of suboptions 1 and 2 (respectively) of the DHCP 
> CableLabs Client Configuration Option (option #122) defined 
> in RFC 3495.  Note that RFC 3495 (and the provisioning spec) 
> explicitly say that these suboptions apply only to the CM.

> 
> For example, the DESCRIPTION clause for pktcMtaDevServerDhcp1 
> might become:
> 
>             "The type of this address is determined by the value of
>              the pktcMtaDevServerAddressType object.  When the latter
>              has the value ipv4(1), this object is the IP address of
>              the primary DHCPv4 server which will cater to the MTA
>              during its provisioning.  It is provided by the CM to
>              the MTA from suboption 1 of the DHCP Option for
>              CableLabs Client Configuration (option #122) defined
>              in RFC 3495.  It contains the value 255.255.255.255 if
>              there was no preference given with respect to the DHCP
>              servers for MTA provisioning.
> 
>              The behavior of this object when the value of
>              pktcMtaDevServerAddressType is other than ipv4(1)
>              is not presently specified, but may be specified
>              in future versions of this MIB module."
Updated to the following - in draft02:
pktcMtaDevServerDhcp1   OBJECT-TYPE 
    SYNTAX      InetAddress 
    MAX-ACCESS  read-only 
    STATUS      current 
    DESCRIPTION 
        " This object contains the Internet Address of the primary
          DHCP server the MTA uses during provisioning.
          The type of this address is determined by the value of
          the pktcMtaDevServerAddressType object.  
          When the latter has the value 'ipv4(1)', this object 
          contains the IP address of the primary DHCPv4 server the 
          MTA uses during provisioning. It is provided by the CM to 
          the MTA via the DHCP option code 122 sub-option 1 as  
          defined in RFC 3495.  
          This object must be of value '255.255.255.255' if
          the address type was 'ipv4(1)' and if there was no 
          preference given for the primary DHCP server.
          The behavior of this object when the value of
          pktcMtaDevServerAddressType is other than 'ipv4(1)'
          is not presently specified, but may be specified
          in future versions of this MIB module."
    REFERENCE
        " PacketCable MTA Device Provisioning Specification;
          RFC 3495, DHCP Option for CableLabs Client Configuration."
    ::= { pktcMtaDevServer 2 } 

> 
> Similarly, the DESCRIPTION clause for pktcMtaDevServerDhcp2 
> might become:
> 
>             "The type of this address is determined by the value of
>              the pktcMtaDevServerAddressType object.  When the latter
>              has the value ipv4(1), this object is the IP address of
>              the primary DHCPv4 server which will cater to the MTA
>              during its provisioning.  It is provided by the CM to
>              the MTA from suboption 2 of the DHCP Option for
>              CableLabs Client Configuration (option #122) defined
>              in RFC 3495.  It contains the value 0.0.0.0 if there
>              is no specific secondary DHCP server to be considered
>              during MTA provisioning.
> 
>              The behavior of this object when the value of
>              pktcMtaDevServerAddressType is other than ipv4(1)
>              is not presently specified, but may be specified
>              in future versions of this MIB module."
same as above.

> Question:  do these objects apply only to E-MTA or do they 
> apply to S-MTA also?  If they don't apply to S-MTA (i.e., 
> have the value 255.255.255.255/0.0.0.0) then say so;  if they 
> apply to both, I am curious to know how the CM communicates 
> the values to the MTA in that case.
> 
ok, done. The modifications apply to both - E- and S-MTA. In S-MTA
case, it is the DHCP Server that provides the S-MTA with the values of
sub-options-1 & 2. Details are in S-MTA Prov Spec, current in Draft.

> (m) The DESCRIPTION clauses for pktcMtaDevServerDns1 and 
> pktcMtaDevServerDns2 claim that these objects get their 
> values from DHCP option 6 "as defined in RFC-3495".  That is 
> incorrect:  DHCP option 6 is defined in RFC 2132.  The 
> REFERENCE clause also contains this error.  These clauses 
> also read awkwardly.  See #11(l) above for a model 
> DESCRIPTION clause and #11(c) for a model REFERENCE clause.
> 
ok, done.
pktcMtaDevServerDns1  OBJECT-TYPE 
    SYNTAX      InetAddress 
    MAX-ACCESS  read-write 
    STATUS      current 
    DESCRIPTION 
        " This object contains the IP Address of the primary
          DNS server to be used by the MTA to resolve FQDNs. The
          type of this address is determined by the value of the
          pktcMtaDevServerAddressType object.  
          When the latter has the value 'ipv4(1)', this object 
          contains the IP address of the primary DNS server. As
          defined in RFC 2132, PacketCable compliant MTAs receive
          the IP address of the primary DNS Server in the DHCP 
          option 6.
          The behavior of this object when the value of
          pktcMtaDevServerAddressType is other than 'ipv4(1)'
          is not presently specified, but may be specified
          in future versions of this MIB module."
    REFERENCE
        " PacketCable MTA Device Provisioning Specification;
          RFC 2132, DHCP Options and BOOTP Vendor Extensions."
    ::= { pktcMtaDevServer 4 } 

> (n) The DESCRIPTION clause for pktcMtaDevTimeServer does not 
> mention that the value MAY appear as option #4 in a DHCP 
> Offer/DHCP Ack.  In fairness, neither does the provisioning 
> spec PKT-SP-PROV-I07-030728, but it references the DOCSIS 
> spec, which clearly spells this out. Here is an excerpt I 
> picked up from DOCSIS 1.0:
> 
>  The protocol by which the time of day MUST be retrieved is 
> defined  in [RFC-868].  Refer to Figure 7-10.  The request 
> and response MUST  be transferred using UDP. The time 
> retrieved from the server (UTC)  MUST be combined with the 
> time offset received from the DHCP  response to create the 
> current local time.
> 
>  The DHCP server may offer a CM multiple Time of Day server 
> IP  addresses to attempt.  The CM MUST attempt all Time of 
> Day servers  included in the DHCP offer until local time is 
> established.
> 
> I presume that something like this applies to an S-MTA.  I 
> also presume that populating this object is optional for an 
> E-MTA since the latter could get the time-of-day from the CM.
> 
> If these presumptions are correct, please revise the 
> DESCRIPTION clause to say so, and add a reference clause 
> pointing to RFC 2132.
> 
> It these presumptions are not correct, you will probably 
> still want to note that this is the address of an RFC 868 
> timer server and maybe add a REFERENCE clause pointing to RFC 868.
> 
> In any case, please fix this spelling error:  s/SMTA/S-MTA/
> It caused me some confusion in trying to decipher what the 
> DESCRIPTION clause means.  And please also make this change 
> too: s/populated/populated with a value other than 0.0.0.0/
> 
ok, done.

> (o) In the DESCRIPTION clause of pktcMtaDevConfigFile I see:
> 
>  The object returns NULL if the server address is unknown.
> 
> It's not clear what NULL means in this context:  the SYNTAX 
> value is SnmpAdminString, and the TC definition in RFC 3411 
> does not define a NULL value.  If you mean a zero-length 
> string then you must say so explicitly.
> 
> In addition, the English needs to be re-worked a little to 
> get definite and indefinite articles in the right places.
> 
ok, done.

> (p) In the DESCRIPTION clause of pktcMtaDevSnmpEntity:
> s/the DHCP Option CCC/DHCP Option 122/ to be consistent with 
> other DESCRIPTION clauses (and fix the English).
>
ok, done.

> (q) Objects pktcMtaDevProvConfigHash and 
> pktcMtaDevProvConfigKey have SIZE constraints in the 
> definitions that are appropriate to the currently supported 
> algorithms -- MD5 and SHA-1 for authentication, null or DES 
> for privacy -- but may be overly constraining if new 
> algorithms are added in a future version of the PacketCable 
> security spec.  The designers need to be aware that removing 
> or changing SIZE constraints after a MIB module has been 
> published constitutes an illegal revision (see RFC 2578 
> Section 10).  If there is a possibility of adding new 
> algorithms, then the SIZE constraints should be removed 
> before initial publication as an RFC.
> 
Not done at this time. This requires further consideration by the
PacketCable implementers, the provisioning and security teams.

> ... skipping down to the read-create tables ...
> 
> (r) The conceptual rows pktcMtaDevRealmEntry and 
> pktcMtaDevCmsEntry support dynamic creation of rows, but do 
> not have a StorageType column, nor do their DESCRIPTION 
> clauses state what happens to dynamically created rows after 
> a reboot.
> You must have one or the other;  see 
> <draft-ietf-ops-mib-review-guidelines-01.txt> Section 4.6.3.  
added "The conceptual rows MUST NOT persist across MTA reboots."

> If the fate of a row depends on some conditions such as the 
> value of some other object, then putting a statement to that 
> effect in the conceptual row DESCRIPTION clause is the best 
> way to satisfy this requirement.
> 
ok, done.

> (s) The DESCRIPTION clause of pktcMtaDevRealmStatus needs 
> many improvements.  In particular, in view of #11(z) below, 
> the following is not correct:
> 
>              There is no restriction on setting columns in this table
>              when the value of pktcMtaDevRealmStatus is active(1).
> 
> Furthermore, the following stuff just adds unneeded words 
> that have no value at all to the implementor:
> 
>              The  RowStatus TC [RFC2579] requires that this 
> DESCRIPTION
>              clause states under which circumstances other objects in
>              this row can be modified:
> 
> Please eliminate the above paragraph here and wherever else 
done
> it appears. Also eliminate the following, which (in context) 
> appears to be a duplicate of the first (erroneous) statement:
> 
>              The value of this object has no effect on whether other
>              objects in this conceptual row can be modified."
done
> 
> Here is the suggested replacement for all of the above text:
> 
>              The columnar objects pktcMtaDevRealmName and
>              pktcMtaDevRealmOrgName may not be modified when
>              the value of this object is active(1).  The value
>              of this object has no effect on whether other
>              columns in this conceptual row can be modified."
> 
> pktcMtaDevCmsStatus has similar problems (pktcMtaDevCmsFqdn 
> and pktcMtaDevCmsKerbRealmName can't be modified while it is 
> active(1)) and its DESCRIPTION clause needs similar modifications.
> 
> ... skipping down to the notifications section ...
> 
ok, done.

> (t) Regarding the following:
> 
>    --
>    -- notification group is for future extension.
>    --
> 
>    pktcMtaNotificationPrefix OBJECT IDENTIFIER ::= { pktcMtaMib 2 }
>    pktcMtaNotification OBJECT IDENTIFIER ::= {
>    pktcMtaNotificationPrefix 0 }
>    pktcMtaConformance  OBJECT IDENTIFIER ::= { pktcMtaMib 3 }
>    pktcMtaCompliances  OBJECT IDENTIFIER ::= { pktcMtaConformance 1 }
>    pktcMtaGroups       OBJECT IDENTIFIER ::= { pktcMtaConformance 2 }
> 
> Please remove the ASN.1 comment, as it is now incorrect.
done

> 
> For the remainder, consider instead using the following 
> definitions, placed right at the front of the MIB module, 
> just below the TEXTUAL-CONVENTION section (currently page 9):
> 
>    pktcMtaNotification OBJECT IDENTIFIER ::= { pktcMtaMib 0 }
>    pktcMtaMibObjects   OBJECT IDENTIFIER ::= { pktcMtaMib 1 }
>    pktcMtaConformance  OBJECT IDENTIFIER ::= { pktcMtaMib 2 }
Not done at this time. This requires further consideration by the
PacketCable implementers, the provisioning and security teams.
> 
> and consider relocating the following
> 
>    pktcMtaCompliances  OBJECT IDENTIFIER ::= { pktcMtaConformance 1 }
>    pktcMtaGroups       OBJECT IDENTIFIER ::= { pktcMtaConformance 2 }
done
> 
> down to the conformance section (p. 32).  These changes are 
> not mandatory, but they cost nothing and will save one 
> sub-identifier in each OID that identifies a notification.
> 

> (u) In the definitions of the 
> pktcMtaDevProvisioningEnrollment and 
> pktcMtaDevProvisioningStatus notifications, the following 
> REFERENCE clause is bogus:
> 
>        REFERENCE
>            " Inform as defined in RFC 1902"
removed.
> 
> An "inform" or "trap" is a protocol construct that transports 
> a notification, and has nothing directly to do with the SMI.  
> You won't find them defined in RFC 1902;  the definitions of 
> the SNMPv2-Trap-PDU and the InformRequest-PDU are in RFC 3416 
> (formerly RFC 1905).  You seem to be trying to define a 
> notification that can be transported in an inform, but that's 
> not possible with the SMI. If you want to require use of 
> informs instead of traps, the place to do so is in a 
> PacketCable protocol spec (where I believe such a restriction 
> indeed exists), not in a MIB module.  In any case, RFC 1902 
> is obsolete;  it has been replaced by 2578.
> 
ok.

> ... skipping down to the conformance section ...
> 
> (v) The DESCRIPTION clause for the compliance statement 
> pktcMtaBasicCompliance says:
> 
>            " The compliance statement for devices that implement
>              PacketCable/IPCablecom MTA. It is left to 
> manufacturers to
>              determine whether to support both PacketCable and
>              IPCablecom objects in the same MTA."
> 
> This is somewhat incomprehensible in the context of a MIB 
> module that contains neither PacketCable nor IPCablecom 
> objects but rather IETF objects.  May I suggest instead 
> borrowing the text from the PKTC-MTA-MIB in PKT-SP-MIB-MTA-I07-030728:
> 
>            " The compliance statement for devices that implement
>              MTA feature."
point taken. Here is our new proposed text:
pktcMtaBasicRFCyyyyCompliance MODULE-COMPLIANCE 
    STATUS      current 
    DESCRIPTION 
        " The compliance statement for MTA devices that implement
          PacketCable or IPCablecom requirements. 

          This compliance statement applies to MTA implementations
          that support PacketCable 1.x or IPCablecom requirements, 
          which are not IPv6-capable at the time of this 
          RFC publication."

> 
> If you decide to retain pktcMtaDevServerAddressType for 
> future extensibility to IPv6 (cf. #11(k) above), you might 
> want to add to this an additional sentence like this:
> 
>              This compliance statement applies to implementations that
>              support DOCSIS 1.0/1.1/2.0, which are not IPv6-capable.
ok, see above.

> 
> modified as appropriate for MTAs.  See this e-mail message:
> 
> http://ops.ietf.org/lists/mreview/mreview.2003/msg00503.html
> 
> for a discussion of the issues (and other recommended modifications).
> 
ok, done.

> (w) pktcMtaNotificationGroup either needs to be added to the 
> list of MANDATORY-GROUPS of pktcMtaBasicCompliance, if it is 
> indeed mandatory to implement, or else there should be a 
> GROUP clause explaining that it is optional, as explained in 
> comment #9 above. In this case it appears that the correct 
> course would be to add the group to the MANDATORY-GROUPS 
> clause;  that is what was done in the PKTC-MTA-MIB in 
> PKT-SP-MIB-MTA-I07-030728.
> 
ok, done (added to the list of MANDATORY-GROUPS).

> (x) If you decide to retain the object 
> pktcMtaDevServerAddressType then it would be proper to add 
> the following OBJECT clause:
> 
>            OBJECT  pktcMtaDevServerAddressType
>                SYNTAX      { ipv4(1) }
>                DESCRIPTION
>                    " Support for address types other than ipv4(1)
>                      is not required."
> 
ok, done.
        OBJECT  pktcMtaDevServerAddressType
            SYNTAX      { ipv4(1) }
            DESCRIPTION
                " Support for address types other than 'ipv4(1)' 
                  is not presently specified and therefore, is not 
                  required. It may be defined in future versions of 
                  this MIB module."

> (y) The following OBJECT clause looks suspect to me:
> 
>            OBJECT  pktcMtaDevSnmpEntity
>                MIN-ACCESS  read-only
>                DESCRIPTION
>                    " The behavior of the SNMP Agent when the object is
>                      set is currently undefined. Object should be
>                      implemented as read-only."
> 
> Unless there is some clear way that the behavior could in the 
> future be well-defined if this object is changed, then the 
> correct thing to do is to eliminate this OBJECT clause and 
> change the MAX-ACCESS value in the object definition to read-only.
Understood. Removed and changed SYNTAX to read-only which makes sense.

> (z) The following OBJECT clauses are all bogus and need to be
> removed:
> 
>          OBJECT  pktcMtaDevRealmName
>              MIN-ACCESS  read-only
>              DESCRIPTION
>                  " The behavior of the SNMP Agent when the object is
>                    set is currently undefined. Object should be
>                    implemented as read-only after the conceptual
>                    row is created."
> 
>          OBJECT  pktcMtaDevRealmOrgName
>              MIN-ACCESS  read-only
>              DESCRIPTION
>                  " The behavior of the SNMP Agent when the object is
>                    set is currently undefined. Object should be
>                    implemented as read-only after the conceptual
>                    row is created."
> 
>          OBJECT  pktcMtaDevCmsFqdn
>              MIN-ACCESS  read-only
>              DESCRIPTION
>                  " The behavior of the SNMP Agent when the object is
>                    set is currently undefined. Object should be
>                    implemented as read-only after the conceptual
>                    row is created."
> 
>          OBJECT  pktcMtaDevCmsKerbRealmName
>              MIN-ACCESS  read-only
>              DESCRIPTION
>                  " The behavior of the SNMP Agent when the object is
>                    set is currently undefined. Object should be
>                    implemented as read-only after the conceptual
>                    row is created."
> Each of the objects in question has a MAX-ACCESS of 
> read-create. Using a MIN-ACCESS clause in this way means that 
> an agent may (but need not) allow full read-create access.  
> That is clearly not what you want, if the DESCRIPTION clause 
> means what it says.
agreed, removed.
> 
> The correct way to do what you want is to say, in the 
> DESCRIPTION clause of the status column, that the object in 
> question may not be modified when the status is active(1).  
> See #11(s) above, where specific changes are recommended.
> 
ok, done.

> This concludes the review of draft-ietf-ipcdn-pktc-mtamib-01.txt,
> Part 1.  Much of the MIB module still need be reviewed, but 
> that is deferred until the -02 draft and/or another reviewer 
> is available.
> 
> Regards,
> 
> Mike Heard

_______________________________________________
IPCDN mailing list
IPCDN@ietf.org
https://www1.ietf.org/mailman/listinfo/ipcdn