Support multi instance endorsement #434
Conversation
andrew-draper
requested review from
henkbirkholz,
thomas-fossati and
yogeshbdeshpande
as code owners
draft-ietf-rats-corim.md
Outdated
| These values behave in a similar way when used in the `group` field. | ||
|
|
||
| In a condition, the `tagged-variable` is used to indicate that two or more `environment-map`s must have the same `instance` value. | ||
| In an addition, the `tagged-variable` value is used to indicate that the `environment-map`.`instance` field must be copied from the ACS-ECT which matched a condition within the same triple. |
There was a problem hiding this comment.
| In an addition, the `tagged-variable` value is used to indicate that the `environment-map`.`instance` field must be copied from the ACS-ECT which matched a condition within the same triple. | |
| In an addition, the `tagged-variable` value is used to indicate that the `environment-map`.`instance` field must be copied from the ACS-ECT which matched a condition, to the newly added `addition` within the same triple. |
Co-authored-by: Andrew Draper <[email protected]>
Co-authored-by: Yogesh Deshpande <[email protected]>
There was a problem hiding this comment.
I understand the problem that this is trying to solve, and I believe that the technical proposal will achieve the desired outcome.
However, from a design perspective, I don't think extending the environment map is the right approach.
The idea behind environment-map extensibility is to allow new concrete identifiers to be added to cover use cases and technologies that we didn't anticipate.
Instead, this PR adds new semantics to the identifier space, opening up a whole new world in a relatively stable corner of the spec.
This is likely to have consequences that we haven't fully grasped.
For this reason, even though I am clearly in the minority, I'd advise against merging this and instead exploring solutions that either do not require touching core/stable parts or use different constructs altogether.
If we decide to merge it nevertheless, I would like it to be marked as an “experimental" solution to the problem rather than one that we present as "the solution”.
And this should also be clearly reflected in the presentation to the wider group in Madrid.
|
Thomas' comment is tracked in issue #459 If there is a better approach then I see no problem with using that approach instead of this one. |
AES to ACS
|
@andrew-draper : Given that we need sufficient work to explain the clear steps of Conditions and Exit for the Algorithm as in the issue #458 This gives us better time to work on an Alternative proposal and discuss face to face with other CoRIM Design team members. Given your familiarity with the subject, in the background please work on a Clear Algorithm and then what is the best type |
There was a problem hiding this comment.
Rechecking after Thomas' well laid out "stability" argument #434 (review)
|
The English text seems to be too vague about the problem statement. Additionally, I am having a hard time grasping "algorithm issues". This seems to be too hot of a potato to merge. |
|
If there were issues with this then I think it would have been good to raise them before the last minute, and it would be good to see the alternative proposal. If there was an alternative proposal then it might make sense to delay putting in this change until we can decide between the alternatives. Since there isn't an alternative proposal I would prefer to do what Thomas suggested earlier, which is to check this in and be prepared to change to a better version if that is available. If we don't accept this change then my take is that we don't have a complete solution to this issue, and we are not ready for last call. |
Thanks, we have much more better understanding of your problem, we would like to help you make correct design choice. Current design could cause potential instability in an area which is bed rock of CoRIM. Let us discuss about the WGLC aspects on Wednesday! |
Fixes issue #415