The implication is that "Owner" of the RCB is to be filled from "ClientLN" when configuring reservations from the SCL file.
However, NOTE 2 says: "The Owner attribute is for diagnosis only, and should not be use to refuse a reservation request to a
This implies that there is not an enforceable mechanism within 61850 to allow an RCB to be reserved for a particular client from SCL.
There has been concern that NAT may cause the IP address of the client to be ambiguous. While that possibility exists, we should not eliminate an interoperable solution for the general case.
As any issues with NAT should be known during the system engineering process, the SCL can be written as needed.
As TISSUE 951 has standardized the information to be stored in the Owner field, NOTE 2 should be removed, or changed to something like "In the case where NAT is involved, the RCB should not be reserved in the SCL file."
05 Dec 13
In Force (green)
30 Oct 13
I agree with Thierry that there is no method that can be enforced by a server without the use of Authentication. However, Authentication does not use an IP Address (62351-4/-6). Therefore, the statement that the IP Address should not be used to refuse (currently what is in the standard) is correct.
18 Oct 13
The current note specifies that only a real identification of the client can lead to a refusal of the reservation.
IP addresses is not a way to identify properly a client application.
Several client application can run on the same machine having the same ip address, but using different authentication parameters.
There should not be several ways to provide an authentication that could lead to a refusal of the reservation of the BRCB. I am not in favour of removing the note.