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

[Gonzalo Camarillo <[e-mail]>]

Hi Roland,

do not update the draft until the AD tells you so.

Cheers,

Gonzalo

On 10/04/2014 11:07 AM, [e-mail] wrote:
> Hi Marry,
> 
> I’m really sorry, this mail slipped through my hands. And I didn’t see
> anything in the data tracker history. Since I’m the main Editor, it is
> my fault that this was not answered.
> 
> It is true we cannot claim any speed if we do nothing. Again I’m Sorry.
> 
>  
> 
> So here are my answers. For the Gen-review.
> 
> So I have created a Version -14 which I can upload now. Please indicate
> if I should do this or if I should wait for further comments?
> 
>  
> 
> 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.
> 
>  
> 
> [RJ] Yes it is informal as RFC3455 is I’ll change that.
> 
>  
> 
> 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.
> 
>  
> 
> [RJ] Below that section we have the text:
> 
> The access-info MAY contain additional information relating to the
> access network. The values for "cgi-3gpp", "utran-cell-id-3gpp",
> 
>        "i-wlan-node-id", "dsl-location" and "ci-3gpp2", "ci-3gpp2-femto"
> and  "gstn-location" are defined in 3GPP TS 24.229
> 
>  
> 
> Do we need more?
> 
>  
> 
> 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.)
> 
>  
> 
> [RJ] Replaced
> 
> [RJ] Due to your comment I have removed the whole text as follows:
> 
> Additionally the P-Called-Party-ID
> 
>        header field has been defined within 3GPP systems since release
> 
>        5, and therefore it is realistic to expect implementations to be
> 
>        already released to the field.  It is therefore considered that
> 
>        replacement of the P-Called-Party-ID header field within 3GPP
> 
>        systems causes more issues that it solves, and therefore the
> 
>        update of RFC3455 <xref
> 
>          target="RFC3455"></xref>to remove the P-Called-Party-ID header
> field
> 
>        will not be addressed.  However it is recommended that any new
> 
>        usage of this type of functionality should use the History-Info
> 
>        header field defined in RFC 7044
> <xreftarget="RFC7044"></xref>rather than the P-Called-Party-ID header field
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> [RJ] Yes I can agree this. so this seems a action for future.
> 
>  
> 
> 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.
> 
>  
> 
> [RJ] sorry cannot do
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> [RJ] I have addedthe following:
> 
> And where a trustrelationship equivalent with that defined in RFC 3325
> <xreftarget="RFC3325">between entities exist
> 
>  
> 
>  
> 
> 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.
> 
>  
> 
> [RJ] Since we have the P-Access-Network-Info as header that is also set
> up by the IMS entity P-CSCF with adding the network provided element
> there is a difference in interpreting the header by Applications. Of
> course the network provided information is trustful and can be used for
> sensitive services since the user provided information should only be
> used by services which are not sensitive.
> 
>  
> 
> [RJ] Is this sufficient?
> 
>  
> 
>  
> 
> Nits/editorial comments:
> 
>  
> 
> S1 Having the disclaimer as the first section is a little strange.  I
> don't know what it is disclaiming yet.
> 
>  
> 
> [RJ] That is a copy from RFC3455. RFC3455 fullfills the requirements
> documented in RFC4083. Would this be sufficient to write as a one
> sentence statement?
> 
>  
> 
>  
> 
> S1, S3 It looks like a few characters are missing from these sections:
> 
> "trust.These", "environment The", "[RFC3455]   This"
> 
>  
> 
> [RJ] Done
> 
>  
> 
> 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)
> 
>  
> 
> [RJ] tried to solve this. deleted normative text and made some
> corrections to your points.
> 
>  
> 
> 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?
> 
> [RJ] As far as I know is that 3GPP does not want to use it anymore. Is
> it not sufficent to not the deletion?
> 
>  
> 
>  
> 
> Best Regards
> 
>  
> 
> Roland
> 
>  
> 
> *Von:*Mary Barnes [mailto:[e-mail]]
> *Gesendet:* Donnerstag, 10. April 2014 01:08
> *An:* [e-mail]
> *Cc:* Atle Monrad; Gonzalo Camarillo; Richard Barnes
> *Betreff:* Fwd: [Gen-art] Gen-ART review of
> draft-drage-sipping-rfc3455bis-13
> 
>  
> 
> Can you guys please respond to Martin's review?  This document is on the
> IESG telechat agenda for tomorrow.  Honestly, you guys cannot complain
> that IETF is not doing work in a timely manner if authors cannot respond
> to reviews like this, especially at this stage of the game. 
> 
>  
> 
> I will note that I haven't seen all the messages around these reviews
> because people don't usually add the shepherd and I don't seem to be
> being picked up by any aliases. 
> 
>  
> 
> Regards,
> 
> Mary. 
> 
> ---------- Forwarded message ----------
> From: *Martin Thomson* <[e-mail]
> <mailto:[e-mail]>>
> Date: Wed, Apr 9, 2014 at 11:39 AM
> Subject: Re: [Gen-art] Gen-ART review of draft-drage-sipping-rfc3455bis-13
> To: Jari Arkko <[e-mail] <mailto:[e-mail]>>
> Cc: "[e-mail] <mailto:[e-mail]> Review Team"
> <[e-mail] <mailto:[e-mail]>>, IESG IESG <[e-mail]
> <mailto:[e-mail]>>,
> [e-mail]
> <mailto:[e-mail]>
> 
> On 9 April 2014 05:41, Jari Arkko <[e-mail]
> <mailto:[e-mail]>> wrote:
>> Have there been any responses or changes based on your comments? I do
> not see the document version having changed...
> 
> I have seen no response or revision.
> 
>  
>