Subject: [alto] Restrictions on cost-type names?

From: Wendy Roome <[email-masked]>
Date: Fri, 17 Apr 2015 13:58:48 -0400

Does RFC 7285 define any restrictions on cost-type names? Eg, length or
character set?

I am referring to the names in the IRD meta for a combination of cost-metric
& cost-mode. Eg, "num-routing" in

 "meta" : {
     "cost-types": {
         "num-routing": {
             "cost-mode" : "numerical",
             "cost-metric": "routingcost",
             "description": "My default"
       },

As near as I can tell, while we rigorously defined cost metric names,
resource ids, and everything else, we missed cost-type names.

- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 19 Apr 2015 16:40:57 -0400

Wendy,

I see the same. The formal definition is at the beginning of Sec. 9.2.2. It
is JSONString. I assume that an arbitrary long string may break a parser.
What other potential issues do you see?

Thanks,
Richard

On Friday, April 17, 2015, Wendy Roome <[email-masked]> wrote:

> I am referring to the names in the IRD meta for a combination of
> cost-metric & cost-mode. Eg, "num-routing" in
>
>  "meta" : {
>      "cost-types": {
>          "num-routing": {

-- 
Richard

---

From: "Y. Richard Yang" <[email-masked]>
Date: Sun, 19 Apr 2015 21:19:40 -0400

I went over the basically-string types: PID name, resource id, tag,
and cost-type name. The first two are restricted on length and legal
chars while the second two are not. I believe that this is reasonable,
since the first two may benefit from extension (e.g., hierarchy PIDs). Make
sense?

Y

On Sunday, April 19, 2015, Y. Richard Yang <[email-masked]> wrote:

> Wendy,
>
> I see the same. The formal definition is at the beginning of Sec. 9.2.2.
> It is JSONString. I assume that an arbitrary long string may break a
> parser. What other potential issues do you see?
>
> Thanks,
> Richard
>
> On Friday, April 17, 2015, Wendy Roome <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>

-- 
Richard

---

From: Wendy Roome <[email-masked]>
Date: Sun, 19 Apr 2015 21:43:24 -0400

I believe Section 10.3, page 39 (third paragraph) says version tags must be
1-64 non-blank ascii characters.

I think that would be a reasonable restriction for cost-type-names as well.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Sun, April 19, 2015 at 21:19
To:  Wendy Roome <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [alto] Restrictions on cost-type names?

I went over the basically-string types: PID name, resource id, tag, and
cost-type name. The first two are restricted on length and legal chars while
the second two are not. I believe that this is reasonable, since the first
two may benefit from extension (e.g., hierarchy PIDs). Make sense?

---

From: ChenGuohai <[email-masked]>
Date: Tue, 21 Apr 2015 01:28:55 +0000

Sure，  a long length shall break a parser,this happed .

Date: Sun, 19 Apr 2015 16:40:57 -0400
From: [email-masked]
To: [email-masked]
CC: [email-masked]
Subject: Re: [alto] Restrictions on cost-type names?

Wendy,
I see the same. The formal definition is at the beginning of Sec. 9.2.2. It is JSONString. I assume that an arbitrary long string may break a parser. What other potential issues do you see?
Thanks,
Richard

On Friday, April 17, 2015, Wendy Roome <[email-masked]> wrote:
Does RFC 7285 define any restrictions on cost-type names? Eg, length or character set?
I am referring to the names in the IRD meta for a combination of cost-metric & cost-mode. Eg, "num-routing" in
 "meta" : {     "cost-types": {         "num-routing": {             "cost-mode" : "numerical",             "cost-metric": "routingcost",             "description": "My default"       },
As near as I can tell, while we rigorously defined cost metric names, resource ids, and everything else, we missed cost-type names.
	- Wendy Roome

-- 
Richard

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: Wendy Roome <[email-masked]>
Date: Mon, 20 Apr 2015 21:57:51 -0400

Yes, a size limit simplifies C/C++ programs. And char codes over 0x7e can cause confusion, especially when print the name.

    - Wendy Roome

> On Apr 20, 2015, at 21:28, ChenGuohai <[email-masked]> wrote:
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 21 Apr 2015 15:27:57 -0500

On 04/19/2015 08:43 PM, Wendy Roome wrote:
> I believe Section 10.3, page 39 (third paragraph) says version tags must
> be 1-64 non-blank ascii characters.
>

If the both of you think that the above is a reasonable restriction for
cost-type-names, we can file an errata with the RFC Editor.

You can file errata by following FAQ item number 6 in [1].

Just as an FYI, when erratas are filed, they will be sent for vetting to
the Area Directors, WG chairs, and the WG mailing list.  Once it has
been determined that this is a genuine errata, the RFC Editor will
update the RFC masthead with the errata.

[1] http://www.rfc-editor.org/rfcfaq.html

Cheers,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Wendy Roome <[email-masked]>
Date: Tue, 21 Apr 2015 16:57:18 -0400

Do folks think that is worth the effort?  I'm not sure it is.

	- Wendy Roome

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 21 Apr 2015 19:35:03 -0400

I see this as a minor issue. Unless there is strong support from others, I
propose we table it, for now.

On Tuesday, April 21, 2015, Wendy Roome <[email-masked]> wrote:

> On 04/21/2015, 16:27, "Vijay K. Gurbani" <[email-masked] <javascript:;>>
> wrote:
>
> >[1]
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.rfc-2Deditor.org_rfcfaq.html&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=rkZCjk3mc5HsbRgXJdpPXX8nUU-7g8tjgD2Uy5dc43g&s=rrlByKzBAePPX-FfhjflO_pdPI6xRxtYvClNl72ohzQ&e=
> >
> >Cheers,
> >
> >- vijay
> >--
> <javascript:;>
> >Web:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__ect.bell-2Dlabs.com_who_vkg_&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=rkZCjk3mc5HsbRgXJdpPXX8nUU-7g8tjgD2Uy5dc43g&s=GLl8FMHyfknQId6Ncq2dpidyPBRyO-HIAmEIJWz1VSM&e=
>  | Calendar:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__goo.gl_x3Ogq&d=AwICAg&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=rkZCjk3mc5HsbRgXJdpPXX8nUU-7g8tjgD2Uy5dc43g&s=o6FeLI8yw0yd-xBD5CHi2oAKg5Fe3mvDbBiClz6kDEc&e=
>
>
>

-- 
Richard