Subject: Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard

From: Mitchell Erblich <[email-masked]>
Date: Tue, 2 Jun 2009 16:28:59 -0700

Begin forwarded message:

> From: Mitchell Erblich <[email-masked]>
> Date: June 2, 2009 4:06:53 PM PDT
> To: [email-masked]
> Subject: Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname  
> (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard
>
> Group,
>
> 	Here are a few stupid/nit questions,
>
> 		1) What do you do with host naming collisions?
>
> 		2) Is a blank "string" blank equal to a "string"?
>
> 		3) Is the hostname case sensitive?
>
> 		4) Since the hostnames are "human readable", would
> 		    a backspace within the name make logical sense?
> 		
> 		5) Don't some system implement x chars per tab,
> 		    then how do we show a consistent hostname?
>
> 		6) If bell is included, does the system need to create
> 		    a sound each time the name is displayed?
>
> 		7) If the router is localized to a different country, wouldn't
> 		    a logical hostname representation be able to support
> 		    multi-character and multi-byte foreign languages?
>
> 		8) Underline support?
>
> 		Thus, IMO, someone needs to re-write part of this to equal
> 		http(s) URL type representation? or only alphanumeric chars
>
> 		And specify some sort of left/right printing justification and
> 		a way to deal with non printable chars..
>
> 		Mitchell Erblich
> 		===================
>
> 	
> On Jun 2, 2009, at 2:37 PM, The IESG wrote:
>
>> The IESG has received a request from the Open Shortest Path First  
>> IGP WG
>> (ospf) to consider the following document:
>>
>> - 'Dynamic Hostname Exchange Mechanism for OSPF '
>>  <draft-ietf-ospf-dynamic-hostname-03.txt> as a Proposed Standard
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action.  Please send substantive comments to  
>> the
>> [email-masked] mailing lists by 2009-06-16. Exceptionally,
>> comments may be sent to [email-masked] instead. In either case, please
>> retain the beginning of the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-ietf-ospf-dynamic-hostname-03.txt
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17203&rfc_flag=0
>>
>> _______________________________________________
>> OSPF mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/ospf
>

---

From: Subbaiah Venkata <[email-masked]>
Date: Thu, 4 Jun 2009 12:59:05 -0700

Hi Mitchell,

Good questions. Comments inline. Some of which we already covered in the
draft.

On Tue, Jun 2, 2009 at 4:28 PM, Mitchell Erblich <[email-masked]>wrote:

>
>
> Begin forwarded message:
>
> *From: *Mitchell Erblich <[email-masked]>
> *Date: *June 2, 2009 4:06:53 PM PDT
> *To: [email-masked]
> *Subject: **Re: [OSPF] Last Call: draft-ietf-ospf-dynamic-hostname
> (Dynamic Hostname Exchange Mechanism for OSPF) to Proposed Standard*
>
> Group,
>
> Protocols as such doesn't find hostname collisions for the advertising
routers.
It is beyond the scope of the draft. I suggest user or  configuration
manager should take care of the collisions.

> Yes.

> Yes because the encoding is in ASCII.

> Anything that is in 7-bit ASCII is supported.  Meaning and interpretation
of the string is left to user.
In the next revision we are adding the following statement to clear
ambiguity:

   This symbolic name can be the FQDN for the   router, it can be a subset
of the FQDN, or it can be any string
   operators want to use for the router.  The use of FQDN or a subset of
   it is strongly recommended.  The content of this value is a domain
   name, see [RFC2181].

>     then how do we show a consistent hostname?
Interpretation of the tab depends on the display setting. So you are right,
you may not get consistent hostname
if tabs are used where sender and receiver display settings are different. I
would suggest not use tabs.
Simple human readable characters like an FQDN are good enough.

> Same as above.

>      multi-character and multi-byte foreign languages?
This is covered in the draft in section 3.1

   The Value field is encoded in 7-bit ASCII.  If a user-interface for
   configuring or displaying this field permits Unicode characters, that
   user-interface is responsible for applying the ToASCII and/or
   ToUnicode algorithm as described in [RFC3490] to achieve the correct
   format for transmission or display.

>  8) Underline support?
Anything that is in 7-bit ASCII is supported.

> Meaning and interpretation of the value string is beyond the scope of this
draft.
It is left to configuration management for flexibility. Anything that is in
7-bit ASCII is supported.
Including human readable and unreadable. But we recommend FQDN or subset.

Hope this helps,
Venkata

> The IESG has received a request from the Open Shortest Path First IGP WG
>
> final comments on this action.  Please send substantive comments to the
>