You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not clear to me that the architecture should be saying that a Provider which is not going to support either of a standard data model or standard interface is a viable situation. In this case we are basically saying that you can have a Provider to which a standards based Consumer is unable to talk to. I would think that, depending on how a data model could be queried about, a standard interface would be a required component.
The text was updated successfully, but these errors were encountered:
The context of "a Provider which is not going to support either of a standard data model or standard interface" probably only encompasses the data plane and not the SACM control plane?
In general, I am not sure what the current decision - if there is consensus - about supporting "existing standard interfaces" on the data plane (in contrast to standard SACM interfaces) is. There is the notion of different variants of endpoint attribute collection coming from the Endpoint ID team (see Issue sacmwg/draft-ietf-sacm-terminology#11), which implies the use of non-SACM standard interfaces (in "collected via a SACM Component located on an Endpoint different from the Target Endpoint").
Version -03
It is not clear to me that the architecture should be saying that a Provider which is not going to support either of a standard data model or standard interface is a viable situation. In this case we are basically saying that you can have a Provider to which a standards based Consumer is unable to talk to. I would think that, depending on how a data model could be queried about, a standard interface would be a required component.
The text was updated successfully, but these errors were encountered: