Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13

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 <martin.thomson@gmail.com> 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
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art