MTA MIB draft06 - AD comment #14 (RE: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt)

Thomas,

   Thank you for your input. 
   I am splitting the threads to separate emails. This one is in response to comment #14.

Jean-François

Thomas Anders wrote:
> > # Comment 14
> >
> >> - For
> >
> >>     pktcMtaDevTypeIdentifier     OBJECT-TYPE
> >>        SYNTAX      SnmpAdminString
> >
> >>   I see that it is an identifier as per DHCP option 60 (RFC2132.
> >>   There it is specified as a "string of octets". How are we sure
> that
> >>   such a "string of octets" is a valid SnmpAdminString?
> >
> > Proposed resolution: no action
> > We traced this assurance to a requirement in the PacketCable MTA
> > Device Provisioning spec (see normative ref in the draft):
> >
> > Section 8.2 says:
> >
> >  8.2 DHCP Option 60: Vendor Client Identifier
> >
> > "Option code 60 contains a string identifying Capabilities of the
> MTA.
> > The MTA- MUST send the following ASCII Coded String in DHCP Option
> > ----->                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> > code 60: "pktc1.5:xxxxxx". Where xxxxxx MUST be an ASCII
> > representation of the hexadecimal encoding of the MTA TLV Encoded
> > Capabilities, as defined in Section 10."
> 
> Please note that you obviously quoted the PacketCable *1.5*
> Provisioning
> spec which doesn't apply here. However, this is not a problem as
> [PKT-SP-PROV] (but see #4!) has a similar requirement.

Yes, good catch, my bad. 
As you point out though, the PacketCable 1.0 provisioning specification referenced in the MIB has the exact same text, section 8.2, page 48 of PKT-SP-PROV-I11-050812.

To integrate your feedback, the text should have said:
Section 8.2 says:
 8.2 DHCP Option 60: Vendor Client Identifier
"Option code 60 contains a string identifying Capabilities of the MTA.
The MTA- MUST send the following ASCII Coded String in DHCP Option
----->                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
code 60: "pktc1.0:xxxxxx". Where xxxxxx MUST be an ASCII
representation of the hexadecimal encoding of the MTA TLV Encoded
Capabilities, as defined in Section 10.

i.e. s/pktc1.0/pktc1.5

Corrected in our issue tracking list. Thanks,
Jean-François