I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document contains xml data model description for conference information. As this is data model and does not list any actual protocols to transmit those xml files its security considerations section is quite generic. It does say that database access must be authorized (access control rules) and that integrity of the database MUST be protected against unauthorized modifications. How this is done is left to the actual protocol documents. It does NOT require confidentiality of the database, but instead says: The confidentiality of the database SHOULD be protected from unauthorized users, given that the data model contains a set of sensitive elements (e.g., passwords). I do not agree on that comment. If the data model contains sensitive elements like passwords I think the confidentiality MUST be protected from unauthorized users. If it is possible that the data model does not contain any sensitive elements then I think the SHOULD could be enough. Also it does not specify what data in the data model is sensitive. Also the security considerations section completely fails to address the fact that the database most likely also contain data that has privacy issues. For example the list of users participating the specific conference could be quite big privacy issue (for example some group of human rights people discussing issues about their own goverment). Note, that this also might require some discussion about the lifetime of the data in the database. I.e. when is the list of participants removed from the database and how long it is stored there. In most countries there are specific laws protecting such information, so those might require preventing unauthorized access to the database. Also as there is fields like provide-anonymity in the database which tells which user is mapped to which "anonymous" name for users to see, but if someone gets read access to the database that person can directly map those anonoymous users to their real identities. I think the security consideation sections should include text about the privacy issues, and most likely mandate support for confidentiality of the database, and preventing unauthorized read access to it. -- kivinen at iki.fi