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

Jean-Francois Mule wrote:
> Thomas Anders wrote:
>>># 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.
[...]
> I'm not sure I get your point and/or the issue. 
> 
> Let me elaborate:
>  - the encoding of the DHCP 122.3 value in a DHCP message follows RFC 3495 which transitively refers to the RFC1035 format for FQDN (RFC 1035 defines the *format* as in BNF grammar for domain names among other things);
>  - the encoding of the MIB object value pktcMtaDevSnmpEntity corresponding to such DHCP value (formatted per RFC1305) can be achieved by using an object syntax of SnmpAdminString.
> At least, this is how we're doing it today.
> 
> Is this clarification clearing your comment or, else, can you be more precise in your comment?

I've been commenting on the simplification "object value == DHCP option 
122 sub-option 3 value [...]". Re-reading the pktcMtaDevSnmpEntity 
DESCRIPTION clause, there doesn't seem to be an ambiguity there.

The use of RFC4001 for pktcMtaDevSnmpEntity and friends (limited to 
AddressType dns(16) here) has been considered (and discarded), hasn't 
it? If that's the case, then "no action" seems appropriate.


+Thomas

-- 
Thomas Anders (thomas.anders at blue-cable.de)