IF THE DEVICE ATTACHED TO THE PORT IS NOT VLAN-AWARE
a) the switch port must be set as UNTAGGED so that the VLAN info of traffic exiting the switch is removed.
--> correct
b) In case we want the device to participate in more than one VLAN, further VLANs will be set as TAGGED. In this way, traffic for these VLANs will be accepted as well (because of the TAGGED setting), but VLAN info will still be removed (because of the UNTAGGED setting) so that the device can handle it.
---> No, this is wrong. If a device isn't VLAN-aware, it can't participate in more than one VLAN! Those devices can only be attached to ports that are untagged members of exactly one VID, where the port's PVID should also be set to that VID. While it isn't forbidden to define additional tagged VLAN memberships for that port, it is useless, because it will never receive tagged frames from the device and tagged frames sent by the switch will be discarded by the device.
c) the PVID defines which VID must be set for traffic originating from the device.
----> yes, within the switch an ingress untagged frame is tagged according to the ingress port's PVID. The frame then can leave the switch via ports that are either untagged or tagged members of the ingress port's PVID, where it is sent untagged in the first case and tagged in the second case.
Tipically, this is the VLAN matching the IP of the device.
----> ? A VLAN and a device's IP address have nothing to do with each other. But in general, any defined VLAN corresponds to an IP network and the device has an IP address belonging to that IP network. VLAN-unaware devices send and receive untagged frames, hence the VLAN corresponding to the device's IP network is the port's PVID (ingress) and the VID (egress) the port is an untagged member of, where usually VID = PVID.
IF THE DEVICE ATTACHED TO THE PORT IS VLAN-AWARE
d) the port should not be set as UNTAGGED (at least, I cannot think of a case where it could be).
---> not in general. If a device is VLAN-aware, it can handle one ore more VLANs sent and received with a corresponding tag. In addition (or even instead of) it should be able to handle untagged frames (which the switch internally assigns the PVID (ingress) and the VID the port is an untagged member of (egress); usually VID=PVID and it is called the "native" VLAN). In practice the device will assign the untagged frames and the tagged frames to different IP subnetworks. For example you can operate a router with a single physical ethernet interface, by assigning the first IP network to the main interface (valid for frames sent and received untagged) and then defining subinterfaces (one per different VLAN, traffic sent and received tagged), where each subinterface belongs to another IP network. With Linux you can configure a network interface this way. With Windows you would need a VLAN configurable network driver from the NIC's vendor (e.g. Broadcom or Intel)
e) the port should be set to TAGGED for any VLAN the device participates in.
---> yes, eventually except for the native VLAN, see d). From the device's point of view frames sent and received untagged can be regarded like belonging to an "unnumbered" VLAN. The concept of the native VLAN (which is a concrete VLAN ID) is unknown to the device. It is the switch that is responsible to add (ingress: PVID) and remove (egress: VID (=PVID) the port is an untagged member of) the defined native VLAN VID internally.
f) I'm not so sure what the PVID rules in this case, since traffic originating from the device already is VLAN-tagged and PVID shoul only rule untagged traffic. However, as I understand it usually is set to the native VLAN of the device (the VLAN matching the IP of the device), or any other VID of a VLAN the device participates in.
---> Yes, if a VLAN-aware device only sends tagged traffic, the PVID of the port, the device is attached to, is useless. In those cases you should assign the port's PVID a dummy value, that isn't used elsewhere. Hence, if ever an untagged frame enters such a port it is sent to nowhere ...
g) the PVID can also be set to a "dummy" VLAN (in case of the DGS 1210 this means a VLAN defined but with no port set to it) in order for the port to act as a "trunk" (a pass-through port).
---> correct