(Including the geopriv list on this reply). Martin - there's one change you made that I think you need to adjust. In response to Elwyn's suggestion about Appendix A, Req 9 below, you've added some 2119 text to that appendix which isn't right. Is there a place you can say what you want to say in the body of the document?
RjS On Oct 30, 2011, at 8:33 PM, Thomson, Martin wrote: > Hi Elwyn, > > Thanks for going through this in detail. > > I see that you've found a few holes in the appendix. I've attempted to > correct those. More detail on that below. > > I've posted -04 with the changes. > <http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-04> > > On 2011-10-24 at 01:11:50, Elwyn Davies wrote: >> Appendix A: Compliance statement for Req 4: The Compliance statement >> states that use of HTTPS from Location Recipient to LS is mandated. I >> cannot find any MUST statement to this effect in the main body of the >> document. > [...] >> Appendix A: Compliance statement for Req 4: Use of the HTTP over TLS >> PKI infrastructure, would I suppose be implicit if the previous >> comment were fixed. However, it might be good to make this explicit. > > The MUST doesn't exist. There was discussion about mandatory TLS that ended > with the text in the body, but the appendix was missed in the edit. The > conclusion was that we wouldn't prevent use of http:, but the risks needed to > made clear. I hope that this was achieved. > > I've added a little note that should make this clearer: > Though discouraged, using unsecured http: URIs is permitted. > Using unsecured HTTP is likely to result in non-compliance > with this requirement. > >> Appendix A: Compliance statement for Req 9: Again, the body of the >> specification is silent on what a Location Reciepient may or may not >> do with a Location URL. Clearly any constraints are not enforceable >> within the context of the HELD protocol but it is probably desirable >> to note the policy of non-propagation implied by Req 9. > > That's a good idea. > >> Appendix B: Compliance statement for Req C3: Compliance for Auth by >> Possession seems somewhat dubious. Derogation due to the requirement >> for expiry is discussed in the body of the document. > > The idea that there are two distinct models for authorization is a little bit > misleading. A URI that is authorized by possession can still be cancelled > using the mechanism described in the policy-uri draft. > > An implementation that doesn't support cancellation is not going to be > compliant, but that's not a fault in the specification. > >> Appendix B: Compliance statement for Req C8: The explicit requirement >> for a minimum of 128 bits of randomness does not appear in the body of >> the document. Since the requirements doc is informational, this needs >> to be made explicit in the main body of the doc. > > ADDED: > The amount of randomness is not specifically identified since it depends on a > number of factors that change over time, such as the number of valid location > URIs, the validity period of those URIs and the rate that guesses can be made. > >> Appendix C: Compliance statement for Req D5: See comments above on >> App A, Req 4. May be a contradiction here: App A appears to require a >> MUST; this compliance implies a RECOMMENDS and possibility of http. >> Needs sorting out. > > Sorted out as described above. > >> Abstract: Acronym HELD needs to be expanded here (currently expanded >> in s1). > > Fixed. > >> s1, Figure 1: (PIcky nit): The infomation carried by the two >> xxxRequest messages is technically a request for xxx rather than the >> actual object. > > Good point; added "for " to each parenthetical. > >> s3.2, para 2: s/before before/before/ >> >> s5, Figure 5: (Picky nit): The indentation is slightly inconsistent >> <geopriv> element only indented one space. > > You are too observant. Unfortunately, indenting more causes the longer lines > to be too wide. > >> Appendix A, Req 12 bullet (b): s/about the identity about the >> Target/about the identity of the Target/ > > Done. > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
