Determine if peer id or scoped node id is more appropriate for commissioning callbacks.

[cecille]

Problem

Peer id isn't unique, but it's also deeply related to commissioning and my be all the caller has to work with.
Arguments for using peer id:

• fabric table doesn't exist for most of commissioning, so scoped node id doesn't make sense for status callbacks - completion callback should match this
• caller likely is already working with the peer id since they are commissioning

Arguments for using scoped node id:

• it is unique

Proposed Solution

If we're going to change this, we should change it quickly

[cecille]

Please see #16882 (comment) for discussion

[bzbarsky-apple]

Another option is to pass the pointer to the DeviceCommissioner and the node id, if a given DeviceCommissioner is associated with a specific fabric. Which maybe it's not?

[cecille]

The caller should already know about the device commisioner becuase it registered against it. So it already can get that information.

[cecille]

If you feel strongly about using scoped node id, I am also fine with that. Caller can also get the compressed fabric id from from the scoped node id if there is one present and the scoped node id is happy to take an undefined fabric id

[cecille]

• Unless the caller registered with multiple DeviceCommissioners, I suppose

[bzbarsky-apple]

Right, that's the thing. What is the data that really identifies "that thing we are commissioning" in a way that the consumer can make sense of it?

The input the consumer provides to the PASE/commissioning process is:

1. The "node id" (which is really just a 64-bit number for identification purposes, not the actual node id of anything, and maybe we should make that clearer).
2. The setup code or rendezvous parameters.
3. The commissioning parameters.

So arguably the thing we should provide in the callback is just the "node id", since that's the only identifier for the "commissioning process" we really have around....

[bzbarsky-apple]

I guess the one exception is the CommissioningComplete callback, which happens after CASE and whatnot, and there we do in fact have a fabric on the DeviceCommissioner. Not sure whether that should hand back the same id as was sent into Commission or the actual node id or something else....

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.