Re: [Gen-art] Gen-ART LC review of draft-ietf-sip-ua-privacy-07.txt
I have sent the copy of this e-mail from my personal e-mail address, so sending it again from the address listed in the draft. I apologize if people are receiving a duplicate copy. Brian; Many thanks for your review. I have pasted relevant text from your comments and replied to them inline.. [Brian] Comments: - Apart from the small point mentioned below, I didn't find any technical issues with this draft, but it left me feeling a little uncomfortable. It isn't a standard, it isn't an experiment, it isn't a description of current practice, so what is it? [Brian] We had a draft which clarified the use of RFC3323 (Currently in the AUTH48 state) along with the recommendation to use tools that were not available at the time of RFC3323. WG decided to take on the portion which described the toolset that were recently defined to obtain user's privacy as a BCP, and we progressed the portion that clarified the use of RFC3323 as a separate draft and submitted as an independent submission. As the toolset recommended in this draft aren't widely deployed and not even an RFCs, the WG agreed to change the status to informational. (We really believed the referenced specifications namely GRUU and TURN were to be an RFCs by the time this draft was to be published.) There are more and more implementations of GRUU observed at interop test events and some in deployments and TURN are seeing tractions as well, so putting this out there will ensure the use of proper toolsets to obtain privacy in SIP without relying on what is defined in RFC3323. [Brian] Minor issues: - Referring to section 5.1.2, note that in RFC5364, sip:anonym...@anonymous.invalid is a MUST rather than a SHOULD. I don't know whether that interacts with the current draft in any way. [Brian] Sniplet from the introduction of RFC5364 -- Additionally, we provide the sender with the capability of indicating in the URI list that one or more resources should be anonymized, so that some recipients' URIs are not disclosed to the other recipients. Instead, these URIs are replaced with anonymous URIs. -- So the anonymization is for not the sender itself but for the recipients of the copied messages (receivers). The UA-privacy is about obtaining the privacy of the sender thus there is no interaction that we have to worry about between this draft and RFC5364. But thanks for bringing this up anyhow. As for the reference I will update the reference and resubmit the version 08 of the draft. Many Thanks Regards Shida On 5-May-09, at 11:45 AM, Brian E Carpenter wrote: draft-ietf-sip-ua-privacy-07-carpenter.txt ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART LC review of draft-ietf-ecrit-location-hiding-req-01
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-ietf-ecrit-location-hiding-req-01 Reviewer: Ben Campbell Review Date: 20090507 IETF LC End Date: 20090511 IESG Telechat date: (if known) Summary: This document is almost ready for publication as an informational RFC. There are some minor clarity issues where the reader is left to infer some things that could be more explicit. Major issues: None Minor issues: -- 1.1, last paragraph: Can you expand on how withholding information information needed for call routing concretely differs from withholding information from emergency personnel? I assume there is more to this than the intent of the ISP. Also, by saying an ISP is not interested, I think the point is to say that they have legal obligations to disclose to emergency personnel, regardless of any interest otherwise, right? -- 1.2, first paragraph: I think this leaves out what I assume to be the actual problem statement, which is we need a way that an ISP/IAP can hide location info from the user agent of the VSP in such a fashion that it is still available for PSAP routing, correct? I can infer that pretty easily, but I don't see where it is explicitly stated in one place. Is there a case where an ISP is simply unable to provide location information? I assume that would be out of scope for this document, but it should be stated as such. -- 1.3, fourth paragraph: This paragraph could be more clear--how does the PSAP having credentials meet a requirement to _hide_ information? I infer the assumption is that the caller does _not_ have the necessary credentials. If so, it would be better to state it explicitly -- Fifth paragraph: is compatibility with LoST a requirement? -- Req-B Is it appropriate for this document to put requirements on the ISP/ IAP? Or do you mean to say they MUST be _able_ to support this, while hiding information location from the VSP and/or UA? -- Req-C I don't really understand what is being said here. Is the point to say that they must be able to validate that the URI identifies a bona fide emergency service contact, and that a call to that URI actually routes to the right place? How does this interact with the later requirement that the entities need not be SIP aware? -- Req-D this is stated as a requirement on the ISP rather than a statement about the solution. I _think_ you are saying there is a requirement to be _able_ to provide location info to the PSAP while withholding it from the caller. Is that correct?. Also how does by value or by reference interact with the previous statement concerning LoST requiring LbyV? -- Req-5 How does the requirement that the ISP/IAP not need to know SIP interact with the statement in Req-D that the ISP must be able to determine if a call is being routed to a bona-fide location service? Also, does Req-5 imply a requirement to work with non-SIP VoIP services? -- Req-6 What does it mean for a PSAP boundary to have holes? -- Req 12: Minimal impact is vague--can you add clarifying text to make this more concrete? -- Req 15: Is that really a requirement, or just an observation of fact? -- Security Considerations: I'm a little skeptical of this statement that this does not raise additional considerations. For example, would you consider that a human might be endangered because an ISP wanted to reserve location information as a for pay service a security consideration, in that it requires the solution to be more fail-safe than other protocols? On the other hand, is the need to keep the UA from inferring location when an ISP wants to hide it a security consideration? Nits/editorial comments: -- Abstract, paragraph 2: It's not clear to me that the document described architectural impacts. It refers to architecture, but I don't see explicit statements about how the architecture breaks if the ISP is not willing to disclose. -- 1.1, list item 3. Please expand VSP on first use. -- Req-A: I don't think the requirement is to be able to withold location from any entity it wishes, since that would include the PSAP, etc. -- Req-2: jurisdiction of the PSAP Geographical jurisdiction? -- Req-10: The solution MUST allow the end host to determine PSAP/ ESRP URLs prior to the call, for all emergency services. Who is the end host? -- 3.3, first bullet: Is it appropriate to have MUSTs in a section on desirable properties? -- Third bullet: That's an implementation detail. I think you mean to say something to the effect of the presence of NATs SHOULD not break the mechanism. -- idnits reports the following (which I include without prejudice): idnits 2.11.11 tmp/draft-ietf-ecrit
[Gen-art] draft-ietf-sipping-update-pai-09.txt
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-ietf-sipping-update-pai-09.txt Reviewer: Francis Dupont Review Date: 2009-05-06 IETF LC End Date: 2009-05-11 IESG Telechat date: unknown Summary: Ready Major issues: none Minor issues: IMHO the Abstract should be reworded a bit before publication (RFC Editor could handle this) Nits/editorial comments: - ToC page 2: Acknowledgements - Acknowledgments - 1 page 3: the right place to introduce common abbrevs: UAC, UAS, URI... - 2 page 3: UAC and URI abbrevs should be introduced - 2 page 4: same for UAS - 3.1 page 4: same for PSTN (I suggest in o PSTN gateways;) - 3.2 page 6: poor wording: with methods that are not provided for in RFC 3325 or any other RFC. - 7 page 10 (title): Acknowledgements - Acknowledgments Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ietf-sipping-update-pai-09.txt (resent)
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-ietf-sipping-update-pai-09.txt Reviewer: Francis Dupont Review Date: 2009-05-06 IETF LC End Date: 2009-05-11 IESG Telechat date: unknown Summary: Ready Major issues: none Minor issues: IMHO the Abstract should be reworded a bit before publication (RFC Editor could handle this) Nits/editorial comments: - Behaviour - Behavior (i.e., American spelling) - ToC page 2: Acknowledgements - Acknowledgments - 1 page 3: the right place to introduce common abbrevs: UAC, UAS, URI... - 2 page 3: UAC and URI abbrevs should be introduced - 2 page 4: same for UAS - 2 page 4: standardised - standardized - 3.1 page 4: same for PSTN (I suggest in o PSTN gateways;) - 3.2 page 6: poor wording: with methods that are not provided for in RFC 3325 or any other RFC. - 6 page 10: standardised - standardized - 7 page 10 (title): Acknowledgements - Acknowledgments Regards francis.dup...@fdupont.fr ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-isms-secshell-16.txt (partial)
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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-isms-secshell-16.txt Reviewer: Francis Dupont Review Date: 2009-05-07 IESG Telechat date: 07 May 2009 Summary: none as draft-ietf-isms-secshell-17.txt was published before I finished the review... Comments are about the not-MIB part (i.e., not the section 7) and of course about the version before the update. Major issues: none in the read part Minor issues: - STD 62 (aka SNMPv3 aka RFC341[1-8]) must be explicitely cited Nits/editorial comments: - ToC page 3: Acknowledgements - Acknowledgements - 1 and 1.1 page 4: move the (SNMP) from 1.1 to 1. - 1.2 page 4: STD62 - STD 62 (but it should be referenced in 1, not here) - 3.1.4 page 12: a SSH - an SSH (based on es es haish pronunciation) - 5.1 page 16 (twice): e.g. - e.g., - 5.1 page 17: move the ASI abbrev intro from 5.3 to here - 9.1 page 30: DH - Diffie-Hellman exchange - 11 page 33: Acknowledgements - Acknowledgements - 12.1 page 34: bad page layout (I-D.ietf-isms-transport-security-model too long for the tool) - Authors' Addresses page 38: US - USA Regards francis.dup...@fdupont.fr PS: note you have some comments about -17 version from IESG. As I've seen a Revised ID Needed I (or another gen-art reviewer) wait for a -18... ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 7 May 2009
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-090507-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Also, I would like to welcome Avshalom Houri to the Gen-ART review team. Thanks, Mary. --- 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: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
