>From the title, I was expecting something a little deeper; I find this I-D strong on current detail, less so on the underlying, perhaps more lasting issues. For example, as has been pointed out on these lists before, identifiers refer to an identity and an object may have multiple identities in different contexts and each identity may have multiple identifiers. (Is an SSN a different identifier to the same identity as a passport number, or to a different identity? DISCUSS). This I-D seems to skate over this issue seeming to assume for the most part that there is one identity and one identifier. I think the I-D should at least mention to this underlying complexity. Equally, in the discussion of tests, the I-D rightly points out the concepts of false negative and false positive but could go further. The gold standard test, one that is always right, is a fine concept that does not exist in our engineered world. Rather, most, if not all, tests can be modified to increase the probability of false positives and decrease the probability of false negatives, or vice versa; and which outcome is better depends on the context. (The example of this last I see quoted is a test for a serious disease, when a false (positive) diagnosis is usually seen as the preferred outcome). Again, this is the sort of background I would expect to see some reference to. The distinction between host names and domain names is also one that surfaces regularly here. Section 3.1 alludes to this but, for me, is not clear enough about the definitions thereof that the IETF has made; this recurs in section 3.4. This last section seems imprecise about e-mail addresses; RFC5321 is specific - "The local-part of a mailbox MUST BE treated as case sensitive" - so I think that that could be brought out more strongly here. There is a more general issue underlying this, that a body such as the IETF produces a precise specification but manufacturers, or other SDOs or even later WGs within the IETF, then make it looser, with local variations, which may in time come to be taken as the standard. In this case, a sharper distinction could be drawn between an e-mail address, as the IETF has specified, and an e-mail-like address, as used in other contexts. Tom Petch ----- Original Message ----- From: "IAB Chair" <iab-chair@xxxxxxx> To: <ietf-announce@xxxxxxxx> Sent: Wednesday, January 09, 2013 8:42 PM This is an announcement of an IETF-wide Call for Comment on 'Issues in Identifier Comparison for Security Purposes'. The document is being considered for publication as an Informational RFC within the IAB stream, and is available for inspection here: http://tools.ietf.org/html/draft-iab-identifier-comparison The Call for Comment will last until February 10, 2013. Please send comments to iab at iab.org or submit them via TRAC (see below). =============================================================== Submitting Comments via TRAC 1. To submit an issue in TRAC, you first need to login to the IAB site on the tools server: http://tools.ietf.org/wg/iab/trac/login 2. If you don't already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can file an issue by navigating to the ticket entry form: http://trac.tools.ietf.org/wg/iab/trac/newticket 4. When opening an issue: a. The Type: field should be set to "defect" for an issue with the current document text, or "enhancement" for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. For example, editorial issues are typically "minor" or "trivial". c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing the issue on. e. The Version: field should be set to "1.0". f. The Severity: field should be set to based on the status of the document (e.g. "In WG Last Call" for a document in IAB last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you. h. The Assign To: field is generally filled in with the email address of the editor. 5. Typically it won't be necessary to enclose a file with the ticket, but if you need to, select "I have files to attach to this ticket". 6. If you want to preview your Issue, click on the "Preview" button. When you're ready to submit the issue, click on the "Create Ticket" button. 7. If you want to update an issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/iab/trac/report/1 Click on the ticket # you want to update, and then modify the ticket fields as required.