Hi Roland, do not update the draft until the AD tells you so.
Cheers, Gonzalo On 10/04/2014 11:07 AM, [email protected] 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:[email protected]] > *Gesendet:* Donnerstag, 10. April 2014 01:08 > *An:* [email protected] > *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* <[email protected] > <mailto:[email protected]>> > 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 <[email protected] <mailto:[email protected]>> > Cc: "[email protected] <mailto:[email protected]> Review Team" > <[email protected] <mailto:[email protected]>>, IESG IESG <[email protected] > <mailto:[email protected]>>, > [email protected] > <mailto:[email protected]> > > On 9 April 2014 05:41, Jari Arkko <[email protected] > <mailto:[email protected]>> 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. > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
