[Gen-art] review of draft-ietf-rtgwg-rfc3682bis-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-rtgwg-rfc3682bis-09.txt Reviewer: Francis Dupont Review Date: 2007/06/10 IETF LC End Date: 2007/06/15 IESG Telechat date: not known Summary: Almost Ready Comments: I have only one major comment: the document does not explain it is a revision of RFC 3682, I propose to add a sentence at the beginning of the introduction stating that with a reference. Other points (minor/editorial/for the RFC editor): - 2 page 4 in: "The possibility of denial-of-service (DoS) attack prevention, however, is based on the assumption that packet classification and separation of their paths is done before they go through a scarce resource in the system." two proposals: "is" -> "are" and "packet classification" -> "classification of (the?) packets" - 2.2 page 5: (i.e., trusted) -> (i.e., are trusted) - 5.1 page 7: hasn't -> has not - 5.5 page 12: multi-hop -> multi-hop case - 6.1 page 12: add a reference for RFC 3682 here (in fact, everywhere at the exception of the abstract). - A page 14: I can't parse "within "TrustRadius" (e.g., 1) of 255 instead of 255" Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: review of draft-ietf-rtgwg-rfc3682bis-09.txt
Hi Francis, Thanks for your review. The draft does say 'obsoletes' in the Abstract and includes Appendix B on Changes since RFC 3682, but I guess we can say this explicitly. Wrt. your TrustRadius comment, the intent was to say that you would accept any value within TrustRadius from 255. I.e., with trustradius 1, 255-1 = 254 would be OK. The simplest possible fix would be replacing "of 255" with "from 255", but I'm not sure whether that would be much clearer; in fact the whole "TrustRadius" concept could be reworded out of the text given that it isn't mentioned anywhere else (anymore) The text was: The main applicability of GTSM is for directly connected peers. GTSM could be used for non-directly connected sessions as well, where the recipient would check that the TTL is within "TrustRadius" (e.g., 1) of 255 instead of 255. [...] On Mon, 11 Jun 2007, Francis Dupont wrote: 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-rtgwg-rfc3682bis-09.txt Reviewer: Francis Dupont Review Date: 2007/06/10 IETF LC End Date: 2007/06/15 IESG Telechat date: not known Summary: Almost Ready Comments: I have only one major comment: the document does not explain it is a revision of RFC 3682, I propose to add a sentence at the beginning of the introduction stating that with a reference. Other points (minor/editorial/for the RFC editor): - 2 page 4 in: "The possibility of denial-of-service (DoS) attack prevention, however, is based on the assumption that packet classification and separation of their paths is done before they go through a scarce resource in the system." two proposals: "is" -> "are" and "packet classification" -> "classification of (the?) packets" - 2.2 page 5: (i.e., trusted) -> (i.e., are trusted) - 5.1 page 7: hasn't -> has not - 5.5 page 12: multi-hop -> multi-hop case - 6.1 page 12: add a reference for RFC 3682 here (in fact, everywhere at the exception of the abstract). - A page 14: I can't parse "within "TrustRadius" (e.g., 1) of 255 instead of 255" Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] draft-ejzak-sipping-p-em-auth-04 addressing all LC comments
Please note the attached draft 04 of draft-ejzak-sipping-p-em-auth. This document reflects all changes requested during last call by Jon Peterson, the responsible AD. The latest comments were from Jon, David and Alfred. There are some additional minor corrections included by me. Thank you for your assistance. Richard Ejzak Alcatel-Lucent SIPPING Working GroupRichard Ejzak INTERNET-DRAFT Alcatel-Lucent Intended status: Informational June 11, 2007 Expires: December 12, 2007 Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media Status of this memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document describes a private Session Initiation Protocol (SIP) header field (P-header) to be used by the European Telecommunications Standards Institute (ETSI) Telecommunications and Internet converged Services and Protocols for Advanced Networks (TISPAN) for the purpose of authorizing early media flows in Third Generation Partnership Project (3GPP) IP Multimedia Subsystems (IMS). This header field is useful in any SIP network that is interconnected with other SIP networks and needs to control the flow of media in the early dialog state. Ejzak [Page 1] INTERNET-DRAFTP-Early-Media Header June 11, 2007 Table of Contents 1. Introduction . 2 2. Applicability Statement... 3 3. Conventions and Acronyms.. 3 4. Background on early media authorization... 4 4.1. Backward early media . 5 4.2. Forward early media... 6 5. Applicability of RFC 3959 and RFC 3960 6 6. Overview of Operation. 7 7. Limitations of the P-Early-Media header field. 8 8. The P-Early-Media header field 8 8.1. Procedures at the User Agent Client...10 8.2. Procedures at the User Agent Server...11 8.3. Procedures at the proxy...11 9. Formal syntax.11 10. Security Considerations..12 11. IANA Considerations..12 11.1. Registration of the "P-Early-Media" SIP header field.12 12. Acknowledgements.13 13. References...13 13.1. Normative References.13 13.2. Informative References...14 14. Authors' Addresses ..14 15. IPR Notice...14 16. Copyright Notice.15 1. Introduction This document defines the use of the P-Early-Media header field for use within SIP [1] messages in certain SIP networks to authorize the cut-through of backward and/or forward early media when permitted by the early media policies of the networks involved. The P-Early-Media header field is intended for use in a SIP network, such as a 3GPP IMS [13][14], that has the following characteristics: its early media policy prohibits the exchange of early media between end users; it is interconnected with other SIP networks that have unknown, untrusted or different policies regarding early media; and it has the
