Subject: Re: Character set for Line ID

From: Glen Turner <[email-masked]>
Date: Fri, 2 Dec 2011 17:09:22 +1030

On 01/12/2011, at 9:09 AM, Suresh Krishnan wrote:
> The only requirement for
> this field is that it should be able to support text strings (e.g. a
> circuit descriptor) and numbers (e.g. 32 bit ids).

Is there not also a requirement that the string be able to be expressed in a typical router's configuration?

-- 
 Glen Turner <http://www.gdt.id.au/~gdt/>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 2 Dec 2011 08:47:38 -0800

Thomas,

No hats on.

I assume that if the Line ID is going to be opaque we don't need to define how to encode strings in it.  Suresh's email wasn't clear on that, if I understood it correctly.

I still would like it to be an opaque field as that keeps it aligned with the DHCP option.  

Bob

On Nov 30, 2011, at 5:33 PM, Thomas Narten wrote:

> Well, if you want the line ID field to hold a string, to do the right
> thing, one probably needs to:
> 
> 1) make the field be a UTF-8 string
> 
> 2) have the string contain normalized unicode, so that the "string"
> entered on one device correctly matches the "string" entered on the
> server (which won't always happen if unnormalized unicode strings are
> allowed).
> 
> I.e., the kind of stuff that the precis WG does. :)
> 
> Thomas
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Fri, 02 Dec 2011 11:53:03 -0500

> I assume that if the Line ID is going to be opaque we don't need to
> define how to encode strings in it.  Suresh's email wasn't clear on
> that, if I understood it correctly.

The problem with this is if the field actually holds a string, you
have to define a canonical representation for the  string. It's just
not sufficient to say it is a "string" or a "UTF-8 string", etc. You
won't get interoperability with that.

This is something *ALL* IETF protocols are starting to grapple with,
if they allow protocol fields to hold strings, and one has to compare
those strings for equality.

> I still would like it to be an opaque field as that keeps it aligned

The DHCP format was specified many years ago... the world is more
complex today...

If we say specifically the opague field is not a "string", this issue
probably goes away. But I think we need to ask the users of this
option whether that is OK.

Thomas

---

From: Bob Hinden <[email-masked]>
Date: Fri, 2 Dec 2011 11:50:47 -0800

Thomas,

> those strings for equality.

Still seems to me that if it's opaque, then it's opaque and we don't need to specify rules for it's contents.  If it's not opaque, then we should specify rules.

> The DHCP format was specified many years ago... the world is more

Is anyone asking to change that?  If it's working, then it's not.....

> option whether that is OK.

Hopefully they will respond to this thread.

Thanks,
Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 4 Dec 2011 02:47:39 -0500

Hi Thomas,

> won't get interoperability with that.

I will try to describe the provisioning procedure a bit. When a
subscriber line is provisioned, the operator will perform the following
steps

a) Configure the Access Node to insert a sequence of bytes into the
line-id field.
b) Configure the AAA server to hand out a given prefix when this exact
sequence of bytes is received in an Access Request.

The edge router will pass on, without inspecting, the line-id received
from the RS and send it off to the AAA server to get the prefix to send
out in the RA.

> those strings for equality.

Right. I was proposing considering this field as an "Absolute
Identifier" as defined in the IAB Identifier comparison draft and the
match policy would be exact match. i.e. The match would fail if any of
the bytes fail to match.

> The DHCP format was specified many years ago... the world is more

But the AAA systems that are used, will use the same kind of line-id
(per operator) for both DHCP(v4/v6) and the RS.

Thanks
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Sun, 4 Dec 2011 02:50:57 -0500

Hi Glen,

> Is there not also a requirement that the string be able to be expressed in a typical router's configuration?

In the deployments that I know of, the line-id is not configured on the
router at all. The router just passes through the line-id it received
from the Access Node onto the AAA server.

Thanks
Suresh