MTA MIB draft06 - AD comment #15 (RE: RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt)
"Jean-Francois Mule" <[email protected]> Mon, 5 Sep 2005 10:58:05 -0600
| Newsgroups | gmane.ietf.ipcdn |
|---|---|
| Message-ID | <[email protected]> |
Thomas, Thank you for your input. I am splitting the threads to separate emails. This one is comment #15. Jean-François 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. > > > 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. 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? Jean-François