[PA Utility Classes] the relative paths are not correctly validated/converted

[bjhargrave]

Original bug ID: BZ#1933 From: Evgeni Grigorov <e.grigorov@prosyst.com> Reported version: R4 V4.3

Duplicates: BZ#1954

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

1. TR069URI.isValidTR069Path(".DeviceInfo") returns false, but must be true
2. TR069URI.getDmtUri(".DeviceInfo") returns .//DeviceInfo, but must be ./Device/DeviceInfo

[bjhargrave]

Comment author: william.lupton@pace.com

1. TR069URI.isValidTR069Path(".DeviceInfo") returns false, but must be true
2. TR069URI.getDmtUri(".DeviceInfo") returns .//DeviceInfo, but must be ./Device/DeviceInfo

The TR-069 path ".DeviceInfo" is not valid as a parameter path in TR-069 RPCs. Such paths are ALWAYS full paths, i.e. begin with the Root Object name ("InternetGatewayDevice" or "Device").

As far as I know, the only place where the leading dot notation can be used is in the value of a "reference parameter", i.e. a parameter whose value is the name of another parameter or object. This is described in TR-106 section 3.2.4. This says:

<<Path names in parameter values MUST always be full path names, with the single exception that a path that begins with a dot is relative to the Root or Service Object. For example, in the Device Root Object, a parameter value of “.DeviceInfo” always means “Device.DeviceInfo”>>

Note that reference parameters are special, because the parameter always provides a context, e.g. if the parameter path is Device.X, if the parameter value is ".X" the Root Object is known to be "Device", so the full path is unambiguously "Device.X".

The leading dot notation is also used in XML data model definitions but this is not relevant here.

So I think that the behaviour in (1) above, and that (2) should fail.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

1. TR069URI.isValidTR069Path(".DeviceInfo") returns false, but must be true
2. TR069URI.getDmtUri(".DeviceInfo") returns .//DeviceInfo, but must be ./Device/DeviceInfo

The TR-069 path ".DeviceInfo" is not valid as a parameter path in TR-069 RPCs. Such paths are ALWAYS full paths, i.e. begin with the Root Object name ("InternetGatewayDevice" or "Device").

As far as I know, the only place where the leading dot notation can be used is in the value of a "reference parameter", i.e. a parameter whose value is the name of another parameter or object. This is described in TR-106 section 3.2.4. This says:

<<Path names in parameter values MUST always be full path names, with the single exception that a path that begins with a dot is relative to the Root or Service Object. For example, in the Device Root Object, a parameter value of “.DeviceInfo” always means “Device.DeviceInfo”>>

Note that reference parameters are special, because the parameter always provides a context, e.g. if the parameter path is Device.X, if the parameter value is ".X" the Root Object is known to be "Device", so the full path is unambiguously "Device.X".

The leading dot notation is also used in XML data model definitions but this is not relevant here.

So I think that the behaviour in (1) above, and that (2) should fail. Thanks for the reference! I checked that before the report. Issue 1: ".DeviceInfo" is valid TR-069 path in the context of reference parameters. IMO, that means that it must be valid in the utility classes. Issue 2: We have residentialmanagement.osgi.root system property, which points to RMT root. The utility classes should work in this context i.e. that method should not fail.

[bjhargrave]

Comment author: william.lupton@pace.com

So I think that the behaviour in (1) above, and that (2) should fail. Thanks for the reference! I checked that before the report. Issue 1: ".DeviceInfo" is valid TR-069 path in the context of reference parameters. IMO, that means that it must be valid in the utility classes. Issue 2: We have residentialmanagement.osgi.root system property, which points to RMT root. The utility classes should work in this context i.e. that method should not fail.

That depends on what the utility classes are intended to be used for. If they are to be used for checking path names in CWMP requests then I believe that they cannot accept ".DeviceInfo". If they are to be used for checking the values of reference parameters then they could accept ".DeviceInfo", but would need to be supplied an absolute path to give the context.

You cannot unconditionally infer that ".DeviceInfo" means "Device.DeviceInfo. It could equally well mean "InternetGatewayDevice.DeviceInfo"!

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

So I think that the behaviour in (1) above, and that (2) should fail. Thanks for the reference! I checked that before the report. Issue 1: ".DeviceInfo" is valid TR-069 path in the context of reference parameters. IMO, that means that it must be valid in the utility classes. Issue 2: We have residentialmanagement.osgi.root system property, which points to RMT root. The utility classes should work in this context i.e. that method should not fail.

That depends on what the utility classes are intended to be used for. If they are to be used for checking path names in CWMP requests then I believe that they cannot accept ".DeviceInfo". If they are to be used for checking the values of reference parameters then they could accept ".DeviceInfo", but would need to be supplied an absolute path to give the context. I believe that PA should be free to operate over all possible paths.

You cannot unconditionally infer that ".DeviceInfo" means "Device.DeviceInfo. It could equally well mean "InternetGatewayDevice.DeviceInfo"! Actually, I can. If "residentialmanagement.osgi.root" environment property points to ./Device/Services, then utility classes operate over Device root. See RMT spec draft, Overall Residential Management Tree.

[bjhargrave]

Comment author: william.lupton@pace.com

Actually, I can. If "residentialmanagement.osgi.root" environment property points to ./Device/Services, then utility classes operate over Device root. See RMT spec draft, Overall Residential Management Tree.

So this provides the context. OK.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Even more, residentialmanagement.osgi.root must be used in all convert operations according to the specification. For example: Device.Services.OSGi.1.Framework -> ./Device/Services/CustomNode/CustomNode2/OSGi/1/Framework when residentialmanagement.osgi.root=./Device/Services/CustomNode/CustomNode2

[bjhargrave]

Comment author: william.lupton@pace.com

Even more, residentialmanagement.osgi.root must be used in all convert operations according to the specification. For example: Device.Services.OSGi.1.Framework -> ./Device/Services/CustomNode/CustomNode2/OSGi/1/Framework when residentialmanagement.osgi.root=./Device/Services/CustomNode/CustomNode2

Now you've confused me. Here is the definition of residentialmanagement.osgi.root:

---

The OSGi Residential Management Tree is a relative tree. Devices can place the root of this tree anywhere in the Device Management Tree. This relative location in the Device Management Tree is indicated with the “./$”. The root of the OSGi tree is set in the system property that must not change during runtime:

residentialmanagement.osgi.root

When residentialmanagement.osgi.root placed in ./Device/Services/CustomNode/CustomNode2. The TR-069 path Device.Services.OSGi.1.Framework is mapped to ./Device/Services/CustomNode/CustomNode2/OSGi/1/Framework.

The above example implies that this property is NOT the root of the TR-069 management tree, but is the node in the DMT tree that corresponds to the TR-069 "Services" object. Is that right?

Perhaps you could give some examples that show the mapping of the following TR-069 paths for a given value of this property?

2. Device.
3. Device.ManagementServer.
4. .ManagementServer.
5. Device.Services.STBService.
6. .STBService.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Even more, residentialmanagement.osgi.root must be used in all convert operations according to the specification. For example: Device.Services.OSGi.1.Framework -> ./Device/Services/CustomNode/CustomNode2/OSGi/1/Framework when residentialmanagement.osgi.root=./Device/Services/CustomNode/CustomNode2

Now you've confused me. Sorry for that. See my comments below... Here is the definition of residentialmanagement.osgi.root:

---

The OSGi Residential Management Tree is a relative tree. Devices can place the root of this tree anywhere in the Device Management Tree. This relative location in the Device Management Tree is indicated with the “./$”. The root of the OSGi tree is set in the system property that must not change during runtime:

residentialmanagement.osgi.root

When residentialmanagement.osgi.root placed in ./Device/Services/CustomNode/CustomNode2. The TR-069 path Device.Services.OSGi.1.Framework is mapped to ./Device/Services/CustomNode/CustomNode2/OSGi/1/Framework.

The above example implies that this property is NOT the root of the TR-069 management tree, but is the node in the DMT tree that corresponds to the TR-069 "Services" object. Is that right? I double checked that. That property gives the root of OSGi node in DMT, nothing more. Nothing about TR data model structure. There is no way to specify DeviceInfo root.

Perhaps you could give some examples that show the mapping of the following TR-069 paths for a given value of this property?

2. Device.
3. Device.ManagementServer.
4. .ManagementServer.
5. Device.Services.STBService.
6. .STBService. Ok, I see, those values don't depend on that property value.

I think that PA needs some way to get TR-069 tree root location (./Device or ./InternetGatewayDevice), right? Otherwise, there is no way to find the Services.

Shige, can you check that?

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

No new comments, TC was updated according the last comments i.e. relative paths are not valid for the TR-069 Utility classes.

[bjhargrave]

Comment author: william.lupton@pace.com

No new comments, TC was updated according the last comments i.e. relative paths are not valid for the TR-069 Utility classes.

That means that they cannot (in general) be used for the values of reference parameters. Is that OK?

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

No new comments, TC was updated according the last comments i.e. relative paths are not valid for the TR-069 Utility classes.

That means that they cannot (in general) be used for the values of reference parameters. Is that OK? Personally to me, no, but we don't have the context for processing of the relative paths. I'll reopen that issue, we can discuss tomorrow on conference call.

[bjhargrave]

Comment author: william.lupton@pace.com

At the 30-Mar-11 telecon, I mentioned that we could add a new TR069URI method such as:

public static final java.lang.String getTR069AbsPath(java.lang.String tr069BasePath, java.lang.String tr069Path);

where tr069BasePath must be absolute but tr069Path can be relative or absolute. If tr069path is absolute, it is returned unaltered, but if it is relative, an absolute path is formed (using tr069BasePath) and returned.

(or maybe the arguments should be the other way round?)

This will be needed only for "reference parameters", i.e. parameters whose values are TR-069 paths. This is the only place where a relative path can be used. In this case tr069BasePath will be the parameter path and tr069Path will be the parameter value.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

In additionally, TR069URI.isValidTR069Path(String) must be updated to validate relative paths.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Before I update the javadoc in RI, let me clarify: Is my understanding correct that relative TR-069 path cannot start with "." ?

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Before I update the javadoc in RI, let me clarify: Is my understanding correct that relative TR-069 path cannot start with "." ?

In addition, can tr069BasePath ends with "." ?

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Before I update the javadoc in RI, let me clarify: Is my understanding correct that relative TR-069 path cannot start with "." ?

By definition, TR-069 relative path starts with ".". TR-106 Amendment 5, 3.2.4 Parameters that Reference Objects: " Path names in parameter values MUST always be full path names, with the single exception that a path that begins with a dot is relative to the Root or Service Object. For example, in the Device Root Object, a parameter value of “.DeviceInfo” always means “Device.DeviceInfo”. "

Before I update the javadoc in RI, let me clarify: Is my understanding correct that relative TR-069 path cannot start with "." ?

In addition, can tr069BasePath ends with "." ?

I think that tr069BasePath cannot end with ".". The partial path (which ends with ".") can point to an intermediate node, but tr069BasePath should point to parameter with a reference value.

William, is my point of view correct?

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Before I update the javadoc in RI, let me clarify: Is my understanding correct that relative TR-069 path cannot start with "." ?

By definition, TR-069 relative path starts with ".". TR-106 Amendment 5, 3.2.4 Parameters that Reference Objects: " Path names in parameter values MUST always be full path names, with the single exception that a path that begins with a dot is relative to the Root or Service Object. For example, in the Device Root Object, a parameter value of “.DeviceInfo” always means “Device.DeviceInfo”. "

Thanks for pointing out. I will fix the RI.

Before I update the javadoc in RI, let me clarify: Is my understanding correct that relative TR-069 path cannot start with "." ?

In addition, can tr069BasePath ends with "." ?

I think that tr069BasePath cannot end with ".". The partial path (which ends with ".") can point to an intermediate node, but tr069BasePath should point to parameter with a reference value.

OK.

William, is my point of view correct?

I will wait for William's comment.

[bjhargrave]

Comment author: william.lupton@pace.com

In addition, can tr069BasePath ends with "." ?

I think that tr069BasePath cannot end with ".". The partial path (which ends with ".") can point to an intermediate node, but tr069BasePath should point to parameter with a reference value.

OK.

William, is my point of view correct?

I will wait for William's comment.

It's true that a parameter path will never end with a period (".") but I don't think that we should require the base path to be a parameter path, because any absolute path will do. As noted in bug BZ#1934, the rules about whether paths do or do not end with periods are rather complicated, and I have recommended that the conversion methods should permit but not require them in object paths.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Thanks for the comment, William.

Summary: I will fix the RI so that:

• relative TR-069 path MUST start with "." This rule is used in isAbsoluteTR069Path().

• tr069BasePath can end with "." in getTR069AbsPath(tr069BasePath, tr069Path). getTR069AbsPath("Device.Services.", ".A.B") = "Device.Service.A.B"; getTR069AbsPath("Device.Services", ".A.B") = "Device.Service.A.B";

[bjhargrave]

Comment author: william.lupton@pace.com

Thanks for the comment, William.

Summary: I will fix the RI so that:

• relative TR-069 path MUST start with "." This rule is used in isAbsoluteTR069Path().

• tr069BasePath can end with "." in getTR069AbsPath(tr069BasePath, tr069Path). getTR069AbsPath("Device.Services.", ".A.B") = "Device.Service.A.B"; getTR069AbsPath("Device.Services", ".A.B") = "Device.Service.A.B";

Ah, I see the confusion. "relative to the Root or Service Object" never means "relative to Device.Services". The Root Object is always "Device." (TR-181) or "InternetGatewayDevice." (TR-098). The Service Object is an instance of any of the tables that can live BELOW "Device.Services.".

For example:

getTR069AbsPath("Device.DeviceInfo.X", ".A.B") = "Device.A.B"; getTR069AbsPath("Device.Services.STBService.1.X", ".A.B") = "Device.Services.STBService.1.A.B";

but:

getTR069AbsPath("Device.Services.", ".A.B") = "Device.A.B";

because there is no Service Object here, just the "Services" node, which is the parent of all tables of Service Objects.

(I wish this wasn't in TR-106 ... but it is)

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Ah, I see the confusion. "relative to the Root or Service Object" never means "relative to Device.Services". The Root Object is always "Device." (TR-181) or "InternetGatewayDevice." (TR-098). The Service Object is an instance of any of the tables that can live BELOW "Device.Services.".

For example:

getTR069AbsPath("Device.DeviceInfo.X", ".A.B") = "Device.A.B"; getTR069AbsPath("Device.Services.STBService.1.X", ".A.B") = "Device.Services.STBService.1.A.B";

but:

getTR069AbsPath("Device.Services.", ".A.B") = "Device.A.B";

because there is no Service Object here, just the "Services" node, which is the parent of all tables of Service Objects.

(I wish this wasn't in TR-106 ... but it is)

I understand. But, what to do in the following cases ?

getTR069AbsPath("Device.Services.STBService.1.X.Y.X.2", ".A.B") = ??? isValidTR069Path("Device.Services.STBService.1.X.Y.X.2") = ??? isAbsoluteTR069Path("Device.Services.STBService.1.X.Y.X.2") = ???

[bjhargrave]

Comment author: william.lupton@pace.com

I understand. But, what to do in the following cases ?

getTR069AbsPath("Device.Services.STBService.1.X.Y.X.2", ".A.B") = ??? Device.Services.STBService.1.A.B

isValidTR069Path("Device.Services.STBService.1.X.Y.X.2") = ??? Yes, assuming that this is only a syntax check

isAbsoluteTR069Path("Device.Services.STBService.1.X.Y.X.2") = ??? Yes, because it doesn't begin with a "."

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

I understand. But, what to do in the following cases ?

getTR069AbsPath("Device.Services.STBService.1.X.Y.X.2", ".A.B") = ??? Device.Services.STBService.1.A.B

Now, I understand. "Service object" must be "Device(orIGD).Services.Hoge.".

isValidTR069Path("Device.Services.STBService.1.X.Y.X.2") = ??? Yes, assuming that this is only a syntax check

I got it.

isAbsoluteTR069Path("Device.Services.STBService.1.X.Y.X.2") = ??? Yes, because it doesn't begin with a "."

I got it.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

I'm now implementing...Detail must be clarified :

getTR069AbsPath("Device.Services", ".A.B") = Device.A.B getTR069AbsPath("Device.Services.", ".A.B") = Device.A.B getTR069AbsPath("Device.Services.Hoge", ".A.B") = Device.A.B
getTR069AbsPath("Device.Services.Hoge.", ".A.B") = Device.A.B
getTR069AbsPath("Device.Services.Hoge.1", ".A.B") = Device.Services.Hoge.1.A.B or Device.A.B
getTR069AbsPath("Device.Services.Hoge.1.", ".A.B") = Device.Services.Hoge.1.A.B or Device.A.B
getTR069AbsPath("Device.Services.Hoge.abc", ".A.B") = IllegalArgumentException or Device.Services.Hoge.abc.A.B
getTR069AbsPath("Device.Services.Hoge.abc.", ".A.B") = IllegalArgumentException or Device.Services.Hoge.abc.A.B

William, could you give your opinion ?

[bjhargrave]

Comment author: william.lupton@pace.com

I'm now implementing...Detail must be clarified :

Ah, good questions! TR-106 does require that all Service Objects are modelled as tables, i.e.:

<<Each Service Object instance MUST be appended with an Instance Number (assigned by the CPE) to allow for the possibility of multiple instances of each. For example, if the device supports the Service Object ABCService, the first instance of this Service Object might be “ABCService.1”>>

So I would say that you are correct on all these, and that the "or..." cases do NOT apply.

getTR069AbsPath("Device.Services", ".A.B") = Device.A.B getTR069AbsPath("Device.Services.", ".A.B") = Device.A.B getTR069AbsPath("Device.Services.Hoge", ".A.B") = Device.A.B
getTR069AbsPath("Device.Services.Hoge.", ".A.B") = Device.A.B
getTR069AbsPath("Device.Services.Hoge.1", ".A.B") = Device.Services.Hoge.1.A.B or Device.A.B
getTR069AbsPath("Device.Services.Hoge.1.", ".A.B") = Device.Services.Hoge.1.A.B or Device.A.B
getTR069AbsPath("Device.Services.Hoge.abc", ".A.B") = IllegalArgumentException or Device.Services.Hoge.abc.A.B
getTR069AbsPath("Device.Services.Hoge.abc.", ".A.B") = IllegalArgumentException or Device.Services.Hoge.abc.A.B

One other thought that occurred to me is that while "" (empty string) is a valid absolute path, it cannot be a valid tr069BasePath because the Root Object isn't known. Possibly, though, the implementation could permit an empty string if the tr069Path is in fact already absolute?

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

So I would say that you are correct on all these, and that the "or..." cases do NOT apply.

getTR069AbsPath("Device.Services", ".A.B") = Device.A.B getTR069AbsPath("Device.Services.", ".A.B") = Device.A.B getTR069AbsPath("Device.Services.Hoge", ".A.B") = Device.A.B
getTR069AbsPath("Device.Services.Hoge.", ".A.B") = Device.A.B
getTR069AbsPath("Device.Services.Hoge.1", ".A.B") = Device.Services.Hoge.1.A.B or Device.A.B
getTR069AbsPath("Device.Services.Hoge.1.", ".A.B") = Device.Services.Hoge.1.A.B or Device.A.B
getTR069AbsPath("Device.Services.Hoge.abc", ".A.B") = IllegalArgumentException or Device.Services.Hoge.abc.A.B
getTR069AbsPath("Device.Services.Hoge.abc.", ".A.B") = IllegalArgumentException or Device.Services.Hoge.abc.A.B

I got it.

One other thought that occurred to me is that while "" (empty string) is a valid absolute path, it cannot be a valid tr069BasePath because the Root Object isn't known.

I got it.

Possibly, though, the implementation could permit an empty string if the tr069Path is in fact already absolute?

I will re-write the javadoc: Check whether the tr069Path is absolute and if yes return it before other checks is done.

[bjhargrave]

Comment author: william.lupton@pace.com

I would be interested to know what "Hoge" means! Is it the Japanese "Foo"?

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

I would be interested to know what "Hoge" means! Is it the Japanese "Foo"?

Sorry about it :-). That is what I meant (opaque). But please don't assume all Japanese use "Hoge" !

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

Although I answered "I got it" in comment#26, I have another issue.

To realize it, this method impl needs to check in detail.

getTR069AbsPath("Device.Services.Hoge.abc", ".A.B") = IllegalArgumentException getTR069AbsPath("Device.Services.Hoge.abc.", ".A.B") = IllegalArgumentException

Generally speaking in TR-069 context, "Device.Services.Hoge.abc" is not valid TR-069 path. So I would propose:

• those check should be done not by getTR069AbsPath() but isValidTR069Path().
• getTR069AbsPath() will not check it, while it checks the specified path is absolute or not, if needed.

What do you think ?

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Although I answered "I got it" in comment#26, I have another issue.

To realize it, this method impl needs to check in detail.

getTR069AbsPath("Device.Services.Hoge.abc", ".A.B") = IllegalArgumentException getTR069AbsPath("Device.Services.Hoge.abc.", ".A.B") = IllegalArgumentException

Generally speaking in TR-069 context, "Device.Services.Hoge.abc" is not valid TR-069 path. So I would propose:

• those check should be done not by getTR069AbsPath() but isValidTR069Path().
• getTR069AbsPath() will not check it, while it checks the specified path is absolute or not, if needed.

What do you think ? Javadoc can require that the first argument must be absolute path and the second must be valid. PA can always check that.

[bjhargrave]

Comment author: Evgeni Grigorov <e.grigorov@prosyst.com>

Thanks for the comment, William.

Summary: I will fix the RI so that:

• relative TR-069 path MUST start with "." This rule is used in isAbsoluteTR069Path().

• tr069BasePath can end with "." in getTR069AbsPath(tr069BasePath, tr069Path). getTR069AbsPath("Device.Services.", ".A.B") = "Device.Service.A.B"; getTR069AbsPath("Device.Services", ".A.B") = "Device.Service.A.B";

Ah, I see the confusion. "relative to the Root or Service Object" never means "relative to Device.Services". The Root Object is always "Device." (TR-181) or "InternetGatewayDevice." (TR-098). The Service Object is an instance of any of the tables that can live BELOW "Device.Services.".

For example:

getTR069AbsPath("Device.DeviceInfo.X", ".A.B") = "Device.A.B"; getTR069AbsPath("Device.Services.STBService.1.X", ".A.B") = "Device.Services.STBService.1.A.B";

but:

getTR069AbsPath("Device.Services.", ".A.B") = "Device.A.B";

because there is no Service Object here, just the "Services" node, which is the parent of all tables of Service Objects.

(I wish this wasn't in TR-106 ... but it is) William, those examples look very useful for TR-106 spec.

[bjhargrave]

Comment author: william.lupton@pace.com

William, those examples look very useful for TR-106 spec. prosyst is a BBF member :)

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

The discussion will be continued in Bug#1954.

[bjhargrave]

Comment author: Ikuo Yamasaki <yamasaki.ikuo@lab.ntt.co.jp>

This bug has been marked as a duplicate of bug BZ#1954