Thanks for the review, Martin. Have there been any responses or changes based on your comments? I do not see the document version having changed...
Jari On Feb 28, 2014, at 1:43 AM, Martin Thomson <[email protected]> wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-drage-sipping-rfc3455bis-13 > Reviewer: Martin Thomson > Review Date: 2014-02-27 > IETF LC End Date: 2014-03-14 > IESG Telechat date: (if known) > > Summary: I find it strange that this 3GPP document is being published > on the standards track. But since it's a -bis there is clearly > precedent, and it is otherwise sound. > > Major issues: > > This document doesn't include enough information for me to some of the > headers. For example, there isn't enough information in the document > to allow me to interpret the contents of cgi-3gpp: > cgi-3gpp = "cgi-3gpp" EQUAL (token / quoted-string) > (I pick on P-Access-Network-Info, because I'm somewhat familiar with it.) > > This can probably be addressed by the inclusion of appropriate > normative references. I seem to recall there being a 3GPP TS that > covered at least some of these. > > Minor issues: > > RFC 4244 is now obsolete, see 7044. (related nit: Change log entry #2 > seems quite defensive, unnecessarily so. This document only needs to > define P-Called-Party-ID, and reference History-Info as an alternative > mechanism.) > > Change log entry #5, mentions a shortcoming of 3455 (no registry for > access network types), but the draft does nothing about it. It seems > to be propagating the mistake it notes. > > A lot has happened since RFC 3455 was published. The privacy > considerations around the use of P-Access-Network-Info are unchanged > from their pre-Geopriv form. In particular, I find the UA knowledge > part to be problematic; Geopriv definitions can probably help here. > > S6.1 P-Associated-URI is a powerful linkability vector, which could be > a far more serious privacy leak than the text implies. The following > seems like good advice, but is not sufficient: > > An eavesdropper could possibly collect the list of identities a user > is registered. This can have privacy implications. To mitigate this > problem, this extension SHOULD only be used in a secured environment, > where encryption of SIP messages is provided either end-to-end or > hop-by-hop. > > You also have to trust the other end of the hop with the information. > I think that's implicit, but probably needs to be stated. > > S6.4 This claim sounds false to me: > > However, there > are no security problems resulting from a UA inserting incorrect > information. Networks providing services based on the information > carried in the P-Access-Network-Info header field will therefore need > to trust the UA sending the information. A rogue UA sending false > access network information will do no more harm than to restrict the > user from using certain services. > > Any parameter whereby changing it can cause loss of service is likely > to be true in the inverse. The draft makes no claims that would make > me believe otherwise. > > Nits/editorial comments: > > S1 Having the disclaimer as the first section is a little strange. I > don't know what it is disclaiming yet. > > S1, S3 It looks like a few characters are missing from these sections: > "trust.These", "environment The", "[RFC3455] This" > > The change log contains a lot of normative language. I expected to > see pointers to changes, and maybe some justification, but items > include normative-sounding text and no pointers(7), other contain > pointers and duplicate text (3&4) > > Change log #6 notes the removal of a field; given that this is > extensible, why not just mark the CDMA 2000 item deprecated instead of > removing it? > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
