Hi Michal, On Wed, 2019-07-24 at 21:12 +0200, michal.lowas-rzechonek@xxxxxxxxxxx wrote: > Hi Inga, > > On 07/24, Stotland, Inga wrote: > > > > So here, prior to removing the temorary node, the element paths > > > > need to be copied into the "req->attach" version of the node. > > > > Same goes for node->agent and node->provisioner. > > > > > > True, thanks! I'll fix this in v3. > > > > Also, could you please add some comment there, like "Deleting the > > temporary node" just to make the point that tit was temporary? I am > > afraid that for an outside person this will not be clear why the > > node > > is being removed. > > Sure thing. > > > > > "Location" property is described as optional in mesh-api.txt. > > > > It's > > > > populated with "Default Location", if the property is not > > > > present. > (...) > > Let's try to keep it as optional then. > > Will do. > > > This will require some *fuzzy* matching of the composition data, > > something like: > > add a boolean flag to generate_node_composition() that indicates > > whether the composition is generated for the verification or as a > > result of an external request, i.e. for the config server model. > > Based > > on the flag, either include location field, or not. > > I don't think I follow. If the application doesn't provide the > "Location" property, everything behaves as if it provided it with > value > "0", no? > > Location descriptor is *not* optional in Composition Data (Table 4.4 > in > section 4.2.1.1). > > Never mind, I was overthinking this. Even if the property is *optional*, the value (or the fact of its presense) is not supposed to change. Let's keep it optional, and, just as it is currently, and it be populated with "Default Location" if it's not found.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
