[Gen-art] review of draft-ietf-simple-xcap-diff-13.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-simple-xcap-diff-13.txt Reviewer: Francis Dupont Review Date: 2009-07-15 IETF LC End Date: 3009-07-22 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: None Nits/editorial comments: - 3 page 6: i.e. -> i.e., - 3 pages 7 and 8: endoced -> encoded - 4 pages 8-10: I am looking for a tool which can check the schema (something like MIB doctor, I've tried XSV...) - Authors' Addresses page 16: US -> USA Regards francis.dup...@fdupont.fr PS (to gen-art): we need a tool to check XML schemas (it is easy to find one to check a document against a schema, not to check the schema itself). ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-mpls-tp-requirements
All, I propose the following RFC Editor note... Section 1 OLD Although both static and dynamic configuration of MPLS-TP transport paths (including Operations, Administration and Maintenance (OAM) and protection capabilities) is required by this document, it MUST be possible for operators to be able to completely operate (including OAM and protection capabilities) an MPLS-TP network in the absence of any control plane. NEW MPLS-TP transport paths may be established using static or dynamic configuration. It should be noted that the MPLS-TP network and its transport paths can always be operated fully (including OAM and protection capabilities) in the absence of any control plane. - - - - Section 2 OLD This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS transport profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP. The requirements in this document do not describe what functions an MPLS-TP implementation supports. The purpose of this document is to identify the toolkit and any new protocol work that is required. NEW The MPLS-TP requirements set out in this section are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS transport profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP. - - - - Please let me know if this is acceptable. A - Original Message - From: "Christian Vogt" To: Cc: ; ; ; "Gen-ART Mailing List" ; ; Sent: Thursday, July 16, 2009 1:25 AM Subject: Gen-ART review of draft-ietf-mpls-tp-requirements 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-mpls-tp-requirements Reviewer..: Christian Vogt Review date...: July 15, 2009 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This document specifies protocol requirements for MPLS in packet transport networks. The document is of very good quality, with an elaborate introduction explaining the background for this document. Two editorial nits that the authors should consider addressing prior to publication of this document are the following: - The fourth paragraph on page 6, which is part of the introduction, already specifies a requirement. I suggest moving this to section 2, since this is the section that is dedicated to requirements. - The first paragraph of section 2 is a duplicate; it already appears in the introduction. I suggest removing it from section 2. The paragraph is important for the reader to understand the scope of the document, and hence should retain its prominent position in the introduction rather than the position in section 2. Best regards, - Christian On Jul 2, 2009, The IESG wrote: The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Requirements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2009-07-16. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-09.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18021&rfc_flag=0 ___ Ietf mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Ecrit] FW: Gen-ART LC review ofdraft-ietf-ecrit-location-hiding-req-01
Hi, Thanks for the response. Comments imbedded. I removed sections in which I think we are in agreement. On Jul 10, 2009, at 2:29 PM, Hannes Tschofenig wrote: Hi Ben, Thanks for your review. Please find some comments below: [...] -- 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? A lot of the emergency services work relies on assumptions of what various parties provide or do not provide. For this specific requirement the group thought it would be important that the ISP/IAP allows either the end point or the VSP to do some form of emergency call routing. Assuming that we expect to build protocol mechanisms around these requirements (Is that the intent?), how would you determine compliance with a requirement on an ISP? [...] -- 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? I at least did not know what to write into the security consideration section. I'm not sure I understand your meaning--do you mean to say that you think the section is adequate as is, or do you think in needs more text/work? [...] -- 3.3, first bullet: Is it appropriate to have "MUST"s in a section on "desirable properties"? Hmmm. Not sure. I took the section title of "desirable properties" to mean "properties that are (perhaps very) nice to have, but not hard requirements." If that's what it means, then it seems odd to have a MUST here (except perhaps as a sub-requirement of some feature, where the feature itself is "nice to have". Was the intent something different? Thanks! Ben. ___ 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 - 16 July 2009
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-090716-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. 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
Re: [Gen-art] Gen-ART review of draft-ietf-mpls-tp-requirements
Adrian - Your proposed RFC Editor notes are excellent. I consider this Gen-ART review addressed. Thanks. - Christian On Jul 16, 2009, Adrian Farrel wrote: All, I propose the following RFC Editor note... Section 1 OLD Although both static and dynamic configuration of MPLS-TP transport paths (including Operations, Administration and Maintenance (OAM) and protection capabilities) is required by this document, it MUST be possible for operators to be able to completely operate (including OAM and protection capabilities) an MPLS-TP network in the absence of any control plane. NEW MPLS-TP transport paths may be established using static or dynamic configuration. It should be noted that the MPLS-TP network and its transport paths can always be operated fully (including OAM and protection capabilities) in the absence of any control plane. - - - - Section 2 OLD This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). The requirements are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS transport profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP. The requirements in this document do not describe what functions an MPLS-TP implementation supports. The purpose of this document is to identify the toolkit and any new protocol work that is required. NEW The MPLS-TP requirements set out in this section are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS transport profile is constructed. That is, the requirements indicate what features are to be available in the MPLS toolkit for use by MPLS-TP. - - - - Please let me know if this is acceptable. A ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
