robertmclemons
commented
4 years ago I think the FAU_GEN.1 in the module is effectively a refinement of the FAU_GEN.1 in the base, and the f-component should say as much. There can be an AppNote saying that the Audit Events will be merged with those for the base in the ST, but I think the SFR should use the standard language. The audit events still need the attribute specifying whether it is threshold or selection-based or whatever so that the module is rendered properly. For ST generation, the default behavior is to merge the audit events from the module with those for the base PP, so I don;t think we need anything extra in the schema to deal with that. Now for modules with more than one possible base (like VPN Client and WLAN Client) we might need separate audit tables in the module for each base PP.
The WLAN AS EP has a section in it for modifications to FAU_GEN.1 (4.2.2.11). This is not actually correct because it’s modifying an NDcPP SFR rather than creating a new one. As a result, this SFR is better placed in the section. However, the current schema doesn’t permit raw text to exist inside of f-components in this section so it’s not actually possible to include this table in the correct place. Recommend adding optional tag like what was done for subsection intros. In addition to this case, it will be useful in other Modules since some of them may say things like, “There is no change to this SFR from its definition in the Base-PP. However, the Base-PP defines it as an optional SFR while this PP-Module considers it to be mandatory.”