RE: Bang-path routing

["Bernard Aboba" <Bernard_Aboba@hotmail.com>]

Alan DeKok said:

"  The problem is that this isn't common practice.  The existing roaming
providers don't do this.  Many AAA servers don't do this.

  Where did this text come from?  Why is it there?"

[BA] The push came from 3GPP.  A discussion of some of the scenarios that
were
envisaged can be found in RFC 5113.  However, at this point there seems
to be more interest in this in Diameter than in RADIUS:
http://www.ietf.org/internet-drafts/draft-korhonen-dime-nai-routing-01.txt

Alan DeKok also said:

"I've discussed this && the i18n issues with roaming providers && AAA
implementors.  They all agree that the existing text in 4282 relating to
i18n and bang-path routing is wrong.  They are starting to see other
standards rely on the "RFC4282" behavior, and it's causing them
problems.  There's a big push to come up with fixes."

I agree that there is an urgent need to fix the i18n issues in RFC 4282. 
One way to address this would be to write an "NAI Internationalization"
document that would update RFC 4282, stating that the NAI should be sent
in UTF-8 and that translation to punycode should only occur when looking
up a realm in the DNS. 

With respect to bang-path routing, is there a concern that goes beyond the
usefulness of it?  For example, is there a concern that two implementers who
thought it useful would be unable to interoperate based on RFC 4282 for 
reasons other than those relating to i18n? 

My recollection is that support for bang-path routing is optional, so that
an implementer believing that it is unnecessary/useless/silly should not
feel compelled to implement it.   


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>