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

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 01 Mar 2006 14:06:27 -0500

On Tuesday, February 28, 2006 04:22:43 PM -0800 Randy Presuhn 
<[email-masked]> wrote:

> Hi -
>
>> From: "David B Harrington" <[email-masked]>
>> To: "'Randy Presuhn'" <[email-masked]>; <[email-masked]>
>> Sent: Tuesday, February 28, 2006 4:11 PM
>> Subject: RE: [Isms] ssh transport domain and transport address
>> definitions
> ...
>> Please send wordsmithed text.
> ...
>
> When the value is a hostname, it is encoded in ASCII using the
> IDNA protocol [RFC3490].

I think you need to be more specific than that.  You need to refer to 
RFC3490 section 4, and specify in each case whether the domain name is 
being used as a query or storage string.  If you want to treat this as an 
IDN-unaware domain name slot and encode each label using ToASCII, you need 
to say that explicitly.

Incidentally, you should ask the DNS folks about this, but I expect they 
will tell you that new protocols should specify that IDN's be encoded as 
UTF-8, not punycode.  The latter encoding was intended for use in 
situations with severe limitations on the encoded form, such as those found 
in the DNS protocol and some legacy applications.  We don't have those 
limitations here, and using punycode makes about as much sense as using 
UTF-7.

-- Jeff

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

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 1 Mar 2006 17:55:26 -0800

Hi -

I've long been in the "just use UTF-8" camp, and it would
suit me just fine in this case as well.  As I said earlier, as long
as the DESCRIPTION makes it clear what is to be done, I'll
be happy.  The question is how does the WG want it to work?

Randy

----- Original Message ----- 
> From: "Jeffrey Hutzelman" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; <[email-masked]>
> Sent: Wednesday, March 01, 2006 11:06 AM
> Subject: Re: [Isms] ssh transport domain and transport address definitions
>
> 
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 2 Mar 2006 10:15:23 +0100

> be happy.  The question is how does the WG want it to work?

I think this calls for a more general decision since I am not sure we
are well served to handle this differently from WG to WG. The question
is whether it is generally realistic to assume that devices do IDN
processing and conversion or whether this is the job of the management
application.

* The InetAddressDNS TC definition is rather vague since when it was
  created, discussion how to handle IDNs were ongoing and it was not
  clear what the outcome would be. So the TC is just an OCTET STRING
  and the DESCRIPTION is silent about IDN stuff (which means we need
  to clarify this anyway and we might do it in either direction).

* The TransportAddressDns TC is basically what Dave Harrington posted
  here and it says that the colon is ASCII code point 0x3A and the
  following number is encoded in ASCII digits. Again, it is rather
  unclear what the character set of the hostname actually is. We
  might clarify this in either direction.

* The DnsName TC uses the DNS protocol encoding of names so this seems
  to be clearly limited to 7-bit ASCII.

* The sysName object description says: By convention, this is the node's
  fully-qualified domain name and it uses the DisplayString TC.

* wwwServiceName contains a fully qualified domain name and is of type
  DisplayString.

* sctpAssocRemHostName uses the DNS protocol encoding and clearly says
  US-ASCII.

* assocRemoteApplication may contain a domain name and uses an
  SnmpAdminString and it is unclear how to represent IDNs

* OwnerString (IF-MIB) may contain a domain name and it seems to be
  ASCII (but note that this TC is deprecated so we can probably ignore
  it).

* applOpenConnectionNearEndpoint, applOpenConnectionFarEndpoint,
  applPastConNearEndpoint, applPastConFarEndpoint,
  applOpenConnectionNearEndpoint, applOpenConnectionFarEndpoint all
  contains domain names and they use SnmpAdminString. Again, it is
  unclear how to represent IDNs.

I am sure there are more objects that may contain DNS names. If you know
some, please let me know.

Perhaps we should write up a short document which explains the issue
and clarifies for all TCs/object we know of how they are supposed to
deal with IDNs. In addition, such a document should specify that any
updates to the documents in question should clarify the issues and
define the general strategy how SNMP MIB modules should deal with
IDNs. Such an activity, however, does not really fall into the ISMS
charter. Perhaps the OPS NM ADs (the leaving and the coming) can
discuss this and propose whether they want actions to be taken and if
so under what umbrella.

/js

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