Subject: [ANCP] Character set designator for text fields in AN MIB?

From: Tom Taylor <[email-masked]>
Date: Wed, 04 Aug 2010 20:43:02 -0400

I said in a previous note that we were going to specify that text fields are 
encoded as UTF-8, with the default being ASCII, whatever the proper terminology. 
It occurred to me that the character set being used is something that will be 
pre-provisioned on the AN and not subject to change once the AN is operating. 
Thus it seems appropriate that a character set identifier be provided by the AN 
MIB rather than by an ANCP operation.

Comments?

Tom Taylor

---

From: "DE CNODDER, STEFAAN (STEFAAN)" <[email-masked]>
Date: Thu, 5 Aug 2010 10:16:44 +0200

Hi Tom,

Not sure I understand what you mean.  What would be the advantage of having a configurable character set?  It is just the encoding of some fields in the protocol so why would an operator choose for one or the other character set?  Can we not just pick one and keep it fixed? 

If the character set is configurable, then the protocol should also allow to negotiate the selected character set between AN and NAS.  Is my understanding correct?

If the character set can be configured, then obviously, the AN MIB has to be updated.  I guess that this has to be configured per ANCP session, so that's only adding an object in ancpAnSessionConfigTable.  Is it the intention that the AN decides on which set to use, and the NAS has to simply accept it meaning that the NAS also has to support all possible sets, or is there a negotiation between AN and NAS?

Regards,
Stefaan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: donderdag 5 augustus 2010 2:43
To: [email-masked]
Subject: [ANCP] Character set designator for text fields in AN MIB?

Comments?

Tom Taylor
_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Aug 2010 08:38:43 -0400

No, I didn't mean for the character set to be negotiable between the AN and NAS. 
What I meant was that the operator configures, for example, access port 
identifiers on the AN (and in AAA, obviously), in some character set. The reason 
for having a READ-ONLY (something I should have said earlier) character set 
value in the MIB would be for verification that the text data on the AN is in 
the expected character set. Maybe I'm being far-fetched in providing for such 
verification.

DE CNODDER, STEFAAN (STEFAAN) wrote:
> Hi Tom,
> 
> Not sure I understand what you mean.  What would be the advantage of having a
> configurable character set?  It is just the encoding of some fields in the
> protocol so why would an operator choose for one or the other character set?
> Can we not just pick one and keep it fixed?
> 
> If the character set is configurable, then the protocol should also allow to
> negotiate the selected character set between AN and NAS.  Is my understanding
> correct?
> 
> If the character set can be configured, then obviously, the AN MIB has to be
> updated.  I guess that this has to be configured per ANCP session, so that's
> only adding an object in ancpAnSessionConfigTable.  Is it the intention that
> the AN decides on which set to use, and the NAS has to simply accept it
> meaning that the NAS also has to support all possible sets, or is there a
> negotiation between AN and NAS?
> 
> Regards, Stefaan
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Tom Taylor Sent: donderdag 5
> augustus 2010 2:43 To: [email-masked] Subject: [ANCP] Character set designator
> for text fields in AN MIB?
> 
>  encoded as UTF-8, with the default being ASCII, whatever the proper
> terminology. It occurred to me that the character set being used is something
> that will be pre-provisioned on the AN and not subject to change once the AN
> is operating. Thus it seems appropriate that a character set identifier be
> provided by the AN MIB rather than by an ANCP operation.
> 
> Comments?
> 
> Tom Taylor _______________________________________________ ANCP mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/ancp
> 
>

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Aug 2010 10:48:04 -0400

It occurs to me that there is a more direct use for the charset parameter. If a 
manager needs to display any text fields, it needs to know what character set 
they represent.

Tom Taylor wrote:
> No, I didn't mean for the character set to be negotiable between the AN 
> and NAS. What I meant was that the operator configures, for example, 
> access port identifiers on the AN (and in AAA, obviously), in some 
> character set. The reason for having a READ-ONLY (something I should 
> have said earlier) character set value in the MIB would be for 
> verification that the text data on the AN is in the expected character 
> set. Maybe I'm being far-fetched in providing for such verification.
> 
>> Tom Taylor _______________________________________________ ANCP 
>> mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ancp
>>
>>
>

---

From: "DE CNODDER, STEFAAN (STEFAAN)" <[email-masked]>
Date: Thu, 5 Aug 2010 16:55:54 +0200

Ok, I see now.  Can we not just set the encoding to ASCII as the only option?  Then the manager knows the encoding and does not have to go to the AN to check what encoding has been used.

Regards,
Stefaan

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Aug 2010 11:05:56 -0400

I raised the question at the meeting, noting that I had not had any response 
from my Huawei colleagues when I asked about a possible requirement for 
non-ASCII text fields. Woj suggested that we go with UTF anyway. So really, the 
matter is open to confirmation on the list.

DE CNODDER, STEFAAN (STEFAAN) wrote:
> Ok, I see now.  Can we not just set the encoding to ASCII as the only option?
> Then the manager knows the encoding and does not have to go to the AN to
> check what encoding has been used.
> 
> Regards, Stefaan
> 
> 
> -----Original Message----- From: Tom Taylor [mailto:[email-masked]] 
> Sent: donderdag 5 augustus 2010 16:48 To: DE CNODDER, STEFAAN (STEFAAN) Cc:
> [email-masked] Subject: Re: [ANCP] Character set designator for text fields in
> AN MIB?
> 
> It occurs to me that there is a more direct use for the charset parameter. If
> a manager needs to display any text fields, it needs to know what character
> set they represent.
> 
> Tom Taylor wrote:
>> No, I didn't mean for the character set to be negotiable between the AN and
>> NAS. What I meant was that the operator configures, for example, access
>> port identifiers on the AN (and in AAA, obviously), in some character set.
>> The reason for having a READ-ONLY (something I should have said earlier)
>> character set value in the MIB would be for verification that the text data
>> on the AN is in the expected character set. Maybe I'm being far-fetched in
>> providing for such verification.
>> 
...

---

From: Moti Morgenstern <[email-masked]>
Date: Thu, 5 Aug 2010 18:16:06 +0300

Hi Stefaan & Tom,

I'm in favor of Stefaan's suggestion. However, note that the text fields you're talking about are based on GsmpNameType. The GsmpNameType is a little bit misleading, because a MAC address is also a legal 'name'. So, the ASCII encoding can be defined as the only option when the value is not a MAC address, correct? 

Regards,
Moti
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DE CNODDER, STEFAAN (STEFAAN)
Sent: Thursday, August 05, 2010 5:56 PM
To: Tom Taylor
Cc: [email-masked]
Subject: Re: [ANCP] Character set designator for text fields in AN MIB?

Regards,
Stefaan

---

From: Tom Taylor <[email-masked]>
Date: Thu, 05 Aug 2010 16:42:14 -0400

I assume you're talking about the MIB as opposed to the protocol. The protocol 
specification for the Access-Loop-Circuit-ID in particular is very clearly text 
(assuming VLAN identifiers are represented in ASCII text).

---

From: "DE CNODDER, STEFAAN (STEFAAN)" <[email-masked]>
Date: Fri, 6 Aug 2010 13:19:42 +0200

Hi Tom,

Access-Loop-Circuit-ID must contain the exact same information as option 82 in case of DHCP.  I checked the spec of option 82 and they do not specify a certain encoding.  Since Access-Loop-Circuit-ID is a "copy/paste" from option 82, is the encoding for ANCP important for ANCP?  I mean: could it be possible that option 82 is in ASCII while Access-Loop-Circuit-ID in ANCP is another encoding?  I think it is more opaque to ANCP.

Regards,
Stefaan

---

From: Tom Taylor <[email-masked]>
Date: Fri, 06 Aug 2010 08:47:32 -0400

Hmm ... That's an interesting point. From a protocol point of view I certainly 
can't see any reason to specify the format of this field in particular. That 
means I should probably delete the format information that's there now. I mean 
the formats:

Access-Node-Identifier " atm " slot "/" port ":" vpi "." vci

and

Access-Node-Identifier " eth " slot "/" port [":" vlan-id]

DE CNODDER, STEFAAN (STEFAAN) wrote:
> Hi Tom,
> 
> Access-Loop-Circuit-ID must contain the exact same information as option 82
> in case of DHCP.  I checked the spec of option 82 and they do not specify a
> certain encoding.  Since Access-Loop-Circuit-ID is a "copy/paste" from option
> 82, is the encoding for ANCP important for ANCP?  I mean: could it be
> possible that option 82 is in ASCII while Access-Loop-Circuit-ID in ANCP is
> another encoding?  I think it is more opaque to ANCP.
> 
> Regards, Stefaan
> 
...

---

From: "DE CNODDER, STEFAAN (STEFAAN)" <[email-masked]>
Date: Fri, 6 Aug 2010 16:34:41 +0200

If I remember well, long time ago in the beginning, it was said that the format is in the draft but it is only an example and it was never meant that ANCP defines the format of the content.  So it should be made clear in the draft that it is just an example and not a formal definition.

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: vrijdag 6 augustus 2010 14:48
To: DE CNODDER, STEFAAN (STEFAAN)
Cc: [email-masked]
Subject: Re: [ANCP] Character set designator for text fields in AN MIB?

and

...

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 11 Aug 2010 14:01:40 +0200

>From ANCP's perspective, the circuit-id format cannot be opaque (while the
contents of course may be) for one main reason: Unlike in the DHCP case,
ANCP actively uses the circuit-id to reference an object, thus it needs to
at least understand the encoding of that object name. Furthermore, while the
ANCP port naming can be the same as used for dhcp, it doesn't have to be and
there are use-cases (eg referencing the DSALM uplink) for which dhcp does
not relay any info.
Unless my understanding is off, UTF-8 and ASCII are compatible, so the only
issue will come if someone uses UTF-8-only characters when talking to an
ASCII only implementation.

-Woj.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 11 Aug 2010 10:56:34 -0400

Can't the AN or NAS just do an octet by octet comparison in order to locate the 
object?

---

From: Tom Taylor <[email-masked]>
Date: Wed, 11 Aug 2010 15:39:11 -0400

Just to go further on this, RFC 3046 says this for the DHCP server receiving the
same information:

   "The Circuit ID SHOULD be considered an opaque value, with
    policies based on exact string match only; that is, the Circuit ID
    SHOULD NOT be internally parsed by the server."

Tom Taylor wrote:
> Can't the AN or NAS just do an octet by octet comparison in order to locate
> the object?
> 
> Wojciech Dec wrote:
>> at least understand the encoding of that object name. Furthermore, while
>> the ANCP port naming can be the same as used for dhcp, it doesn't have to 
>> be and there are use-cases (eg referencing the DSALM uplink) for which dhcp
>> does not relay any info. Unless my understanding is off, UTF-8 and ASCII
>> are compatible, so the only issue will come if someone uses UTF-8-only
>> characters when talking to an ASCII only implementation.
>> 
>> -Woj.
>> 
>> 

>>> Hmm ... That's an interesting point. From a protocol point of view I 
>>> certainly can't see any reason to specify the format of this field in 
>>> particular. That means I should probably delete the format information 
>>> that's there now. I mean the formats:
>>> 
>>>> Access-Loop-Circuit-ID must contain the exact same information as 
>>>> option 82 in case of DHCP.  I checked the spec of option 82 and they do
>>>>  not specify a certain encoding.  Since Access-Loop-Circuit-ID is a 
>>>> "copy/paste" from option 82, is the encoding for ANCP important for 
>>>> ANCP?  I mean: could it be possible that option 82 is in ASCII while 
>>>> Access-Loop-Circuit-ID in ANCP is another encoding?  I think it is more
>>>>  opaque to ANCP.
>>>> 
>>>> Regards, Stefaan
>>>> 
>>> ... _______________________________________________ ANCP mailing list 
> _______________________________________________ ANCP mailing list

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 12 Aug 2010 09:52:13 +0200

On 11/08/2010 16:56, "Tom Taylor" <[email-masked]> wrote:

> the 

Perhaps, implementers please comment.
What I know is done in some 3.1 implementations is that the char string is
matched to a locally operator configured value (eg in order to apply a
shaping rate on the correct VC). For the 3.2 spec we could go with UTF-8.

-Woj.

>>> certainly