[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bang-path routing

Bernard Aboba wrote:
> [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

  Hmm... OK.

> 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. 

  I've looked at 4282, and I think that the issues are larger than that.
 The ABNF for the NAI defines the NAI *after* the punycode encoding.  It
says *nothing* about the NAI before the punycode encoding.  So an update
to 4282 would involve revving the ABNF, too.

  Once the NAI && i18n text is changed, the text relating to
compatibility with email && DNS needs to be updated.

> 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? 

  The concern is that it's being pushed as a "standard" because it's in
4282.  Nearly every RADIUS vendor / implementor I've talked to doesn't
like it.  The operators who run WiFi networks don't like it.  But
because it's a "standard" in 4282, there is a strong push in some
circles to push it on everyone.

> 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.   

  The "optional" part seems to have been missed by some standards bodies
that are referencing 4282.

  Seeing that the text was there only for 3GPP, and not for traditional
(or currently deployed) RADIUS systems, it would seem useful to delete
it.  If 3GPP wants that format, they can define it themselves.

  Alan DeKok.

--
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/>