Subject: RE: [Isms] SnmpSSHAddress

From: "David Harrington" <[email-masked]>
Date: Thu, 8 Nov 2007 17:07:17 -0500

Juergen mentioned RFC3986, which does deal with ports.
I used that RFC.

dbh

> -----Original Message-----
> From: tom.petch [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 12:57 PM
> To: David Harrington; [email-masked]
> Subject: Re: [Isms] SnmpSSHAddress 
> 
> 
> ----- Original Message -----
> From: "David Harrington" <[email-masked]>
> To: <[email-masked]>
> Sent: Thursday, September 27, 2007 6:40 PM
> Subject: [Isms] SnmpSSHAddress
> 
> 
> > Hi,
> >
> > Bert and Jeff raised questions about the format for IPv4/IPv6
> > addresses and hostnames. Is the following acceptable?
> >
> > Is there an RFC that describes the textual representation of an
IPv6
> > address?
> 
> RFC4291 s2.2
> 
> The ABNF for this is somewhere unexpected (which I will stumble
across
> sometime).
> 
> But note that this section does not cover the interface 
> number, which has
> provoked discussion on URI because of the use of  the percent 
> character, nor the
> port number
> 
> Tom Petch
> 
> >
> > Bert pointed out that MIB addresses have been inconsistent 
> - some use
> > '/' to separate the port nunber and others use ':'. Jeff pointed
out
> > that using a colon makes it difficult to determine where an IPv6
> > address ends and the port starts. Maybe we should use the ':'
> > separator for the hostname format, and the '/' separator for the
IP
> > address formats to eliminate the ambiguity. RFC4181 has no 
> guidance on
> > this point; are there other documents that provide guidance on the
> > separator character for hostnames and/or IP adddresses?
> >
> > SnmpSSHAddress ::= TEXTUAL-CONVENTION
> >     DISPLAY-HINT "1a"
> >     STATUS      current
> >     DESCRIPTION
> >         "Represents either a hostname with a port number or an IP
> >          address with a port number.
> >
> >          The hostname must be encoded in ASCII, as specified in
> >          RFC3490 (Internationalizing Domain Names in Applications)
> >          followed by a colon ':' (ASCII character 0x3A) and a
> >          decimal port number in ASCII. The name SHOULD be fully
> >          qualified whenever possible.
> >
> >          An IPv4 address must be a dotted decimal format followed
> >          by a colon ':' (ASCII character 0x3A) and a decimal port
> >          number in ASCII.
> >
> >          An IPv6 address must be a colon separated format,
> >          surrounded by brackets, followed by a colon ':' (ASCII
> >          character 0x3A) and a decimal port number in ASCII.
> >
> >          Values of this textual convention may not be 
> directly useable
> >          as transport-layer addressing information, and may
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 snmpSSHAddress values must fully describe how (and
> >          when) such names are to be resolved to IP 
> addresses and vice
> >          versa.
> >
> >          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.
> >
> >          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))
> >
> > David Harrington
> > [email-masked]
> > [email-masked]
> >
> >
> >
> > _______________________________________________
> > Isms mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/isms
> 
> 

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