Re: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt

Jean-Francois Mule wrote:
>   We would appreciate receiving quick input from you and the wg on the
> proposed changes for draft 07

Here are my initial comments on #4, #14, #15 and #38:

> # Comment 4
>>     !! Missing citation for Normative reference:
>>     P047 L040:    [RFC2863] McCloghrie, K., Kastenholz, F., "The
>> Interfaces Group
> 
> ok, the reference is mostly because of the IMPORT of the IF-MIB.
> Proposed resolution: reference to [RFC2863] is introduced. We propose
> to add the following text in section 3:
> 
>    EMTA devices implementing this MIB Module MUST be compliant with
>    RFC 2863 [RFC2863] and the Packetcable MTA Device Provisioning
>    Specification [PKT-SP-PROV].
> 
> (we're also proposing to also add the existing normative reference to
> the MTA device provisioning spec here).

Isn't this a formal problem? [PKT-SP-PROV] (PKT-SP-PROV-I10-040730) 
itself has normative references to PKT-SP-MIB-MTA-I09-040402 (which our 
IPCDN MTA MIB is going to supersede) all over the place! Can we still
- say "MUST be compliant with ... [PKT-SP-PROV]"
- list [PKT-SP-PROV] as a normative reference at all
then? If we can't, this may affect the IPCDN MTA MIB at several places.

Will the PacketCable 1.0 specs be updated to include a normative 
reference to the IPCDN MTA MIB (instead of [PKT-SP-MIB-MTA-I09]) after 
it has become RFC?

> # 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.


> # Comment 15
[...]
> pktcMtaDevSnmpEntity
> 
>   object value == DHCP option 122 sub-option 3 value [RFC 3495]
> 
>                   in the form of an FQDN
> 
>   SnmpAdminString is therefore ok.

Is it? DHCP 122.3 is *not* encoded as a string, but rather MUST be 
encoded per RFC 1035 (see RFC 3495, section 5). If the device is 
supposed to convert this object to a string, it should probably be 
stated explicitely.

> pktcMtaDevProvKerbRealmName
> 
>   object value == DHCP option 122 sub-option 6 value [RFC 3495]
> 
>                   ==> GeneralStrings encoded per RFC1510

RFC 3495, section 5.5, also requires RFC 1035 encoding here. See above.


> # Comment 38
> 
>> - At various places in your MIB module you have FQDNs present.
>>   I wonder if it would not be wise (for interoperability) to 
>>   specify WHEN such FQDNs are supposed to be resolved to IP addresses.
> 
> Agree.
> 
> Proposed new text:
[...]
> pktcMtaDevSnmpEntity
>           The MTA must resolve
>           the FQDN value before its very first network interaction
>           with the SNMP entity during the provisioning phase.

Beware that pktcMtaDevSnmpEntity can in fact resolve to multiple IP 
addresses and the expected behaviour is complex. I'd prefer to reference
the corresponding PacketCable Specifications instead.


Best regards,
Thomas

-- 
Thomas Anders (thomas.anders at blue-cable.de)
ewt breitbandnetze gmbh, berlin, germany