Dear Mr. David Black, Thank you for the Gen-ART review comments on the sip-privacy-guideline draft.
See inline. > Munakata-san, Schubert-san and Ohba-san, > > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-munakata-sip-privacy-guideline-03.txt > Reviewer: David L. Black > Review Date: 3 August 2008 > IETF LC End Date: 7 August 2008 > > Summary: > > This draft is on the right track, but has open issues, described in > the review. > > Comments: > > The draft is in very good shape - it does a good job of explaining the > requirements for what is and is not to be done and why. Significant > care has been taken to avoid modifying the RFCs that define the SIP > privacy features. > > The first open issue is that this draft is currently intended to be > an Informational RFC - the responsible AD should recheck whether > Standards Track (Proposed Standard RFC) would be more appropriate. > The draft uses RFC 2119 upper-case requirements language (e.g., MUST, > SHOULD), only when restating requirements from other standards track > RFCs, but there appear to be a number of lower-case requirement > statements (e.g., for the SDP header lines in Section 5.2) that appear > to merit RFC 2119 language. If the draft becomes standards track in > order to do this, the Note in Section 2 about use of RFC 2119 > terminology would need to be modified appropriately. Will wait for the AD's reply and modify the Note in Section 2 about use of RFC 2119 terminology as necessary. > > The second open issue is in Section 5.3.3. I think what is being > stated in this section is that privacy requirements will cause the > Replaces header and "replaces" parameter to not work in some situations, > and this loss of functionality is allowed and/or intended (i.e., it > is not the responsibility of a privacy service to ensure that these > features always work). That should be stated explicitly, in a form > that tells implementers that having these not work because of privacy > is acceptable. You are right. Will add the text to explain that explicitly. > > If I did not understand the section correctly, the text needs > clarification. > > Nit: In Section 5.1.4: > > The recommended form of the From header for anonymity is: > > From: "Anonymous" <sip:[EMAIL PROTECTED]>;tag=1928301774 > > Please state that the tag value may be changed, but that the rest > of this header form is recommended as shown. Will add the text to state that the tag value may be changed. Thank you very much! Mayumi Munakata > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > [EMAIL PROTECTED] Mobile: +1 (978) 394-7754 > ---------------------------------------------------- > > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
