Subject: [Isms] Re: ssh transport domain and transport address definitions

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 12 Mar 2006 11:40:46 +0100

On Mon, Feb 27, 2006 at 09:15:30PM +0100, Juergen Schoenwaelder wrote:
 
> a) [the opaque solution]
> 
> b) [the "SMI lacks unions" solution, but we reuse TRANSPORT-ADDRESS-MIB]
> 
> c) [the "SMI lacks unions" solution, we prefer to be independent]

The current ID specifies the opaque solution, which in principle I
agree with. Here is the relevant text plus some comments/questions.

   TransportAddressSSH ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "1a"
       STATUS      current
       DESCRIPTION
           "[discuss] Represents either a hostname encoded in ASCII
           using the IDNA protocol [RFC3490] followed by
           a colon ':' (ASCII character 0x3A) and a decimal port number
           in ASCII, or an IP address followed by a colon ':'
           (ASCII character 0x3A) and a decimal port number in ASCII.
            The name SHOULD be fully qualified whenever possible.

This text leaves it open how IP addresses are represented. Note that
we have IPv4/IPv6 addresses with and without zone indices. I have
clear opinion on the IDNA issue, except that I like to see a
consistent strategy to deal with IDNs in future MIB modules.

            Values of this textual convention are not directly useable
            as transport-layer addressing information, and require
            runtime resolution. As such, applications that write them
            must be prepared for handling errors if such values are
            not supported, or cannot be resolved (if resolution occurs
            at the time of the management operation).

            The DESCRIPTION clause of TransportAddress objects that may
            have TransportAddressSSH values must fully describe how (and
            when) such names are to be resolved to IP addresses and vice
            versa.

I am not sure whether this TC is now intented to belong to the family
of TransportAddress TCs or not. I think it should not and it belongs
to the family of TAddress TCs (and consequently the above paragraph
does not make much sense and the TC should be named TAddressSSH rather
than TransportAddressSSH).

            This textual convention SHOULD NOT be used directly in
            object definitions since it restricts addresses to a
            specific format. However, if it is used, it MAY be used
            either on its own or in conjunction with
            TransportAddressType or TransportDomain as a pair.

See comment above. Since I do not consider this an extension of the
TransportAddress TCs, this paragraph may not be needed.

            When this textual convention is used as a syntax of an
            index object, there may be issues with the limit of 128
            sub-identifiers specified in SMIv2, STD 58. In this case,
            the OBJECT-TYPE declaration MUST include a 'SIZE' clause
            to limit the number of potential instance sub-identifiers."
       SYNTAX      OCTET STRING (SIZE (1..255))

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms