[Gen-art] Gen-ART review of draft-ietf-ipfix-mediators-problem-statement-09
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-ipfix-mediators-problem-statement-09 Reviewer..: Christian Vogt Review date...: May 7, 2010 IESG Telechat date: May 6, 2010 Summary: This draft is ready for publication as a Informational RFC. This document identifies scalability problems with modern flow-based measurement, which are due to increasing traffic volume as well as increasing measurement requirements complexity. The document motivates IPFIX mediation as a solution, and it gives a set of examples where this solution applies. The document also analyzes the disadvantages of IPFIX mediation, which constitute the cost for better scalability. I believe the document is ready for publication. The document is easy to read, concise, and well-structured. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ospf-af-alt-09
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-ospf-af-alt-09 Reviewer..: Christian Vogt Review date...: December 2, 2009 IESG Telechat date: December 3, 2009 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The document describes small modifications to the OSPFv3 protocol that enable the use of OSPFv3 for multiple address families simultaneously. The document is well-written and concise, and is ready for publication. However, one nit that should be fixed is the following editorial one: The document uses the acronym AF both to denote the term address family, as well as to refer to the OSPF extensions being specified in the document (e.g., in the definition of the AF bit in section 2.2). This is confusing, in particular because AF is explicitly defined only to mean the former, not the latter. I suggest using a different name, e.g., AF support, to denote the OSPF extensions being specified, and adding a definition for this to the introduction of the document. In section 3, Backwards Compatibility, it may furthermore be worth mentioning that all modifications to OSPFv3, as specified in this document, exclusively affect the use of OSPFv3 for new address families. Since this is a prerequisite for backwards compatibility, it will further support the backwards compatibility claim of this section. - Christian ___ 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-sipcore-presence-scaling-requirements-02
On Sep 23, 2009, Avshalom Houri wrote: - It would be worth mentioning in the introduction of the document what the expected result of this document should be. Obviously, we are expecting (or hoping for) an improvement in the scalability of SIP/SIMPLE, but this should be made explicit. Also, do we have estimates of how much SIP/SIMPLE will improve? These are defined by the requirements themselves specifically in 3.3. Right. But it would be useful if this was explained even earlier in the document. How about changing the first paragraph of the introduction as follows: OLD The document lists requirements for optimizations of the SIP/SIMPLE protocol. See [I-D.ietf-simple-simple] for the list of RFCs and drafts that are considered as part of the SIP/SIMPLE protocol. These optimizations should reduce the load on the network and the presence servers in interdomain presence subscriptions. The need for the requirements is based on a separate scaling analysis document [I-D.ietf-simple-interdomain-scaling-analysis]. NEW This document identifies requirements for optimizations of the SIP/SIMPLE protocol, which aim at increasing the scalability of the SIP/SIMPLE protocol, and at reducing the load on the network and the presence servers in interdomain presence subscriptions. The need for such requirements is based on the scaling analysis in [I-D.ietf-simple-interdomain-scaling-analysis]. See [I-D.ietf-simple-simple] for a list of RFCs and Internet drafts that are part of the SIP/SIMPLE protocol. This might already be sufficient. - The document only talks about optimizations to which the defined requirement should apply. How about other types of protocol enhancements, such as functional extensions? Wouldn't the defined requirements apply to those just as well? No. Functional requirements are not in the scope of this document. Ok. - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-sipcore-presence-scaling-requirements-02
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-sipcore-presence-scaling-requirements-02 Reviewer..: Christian Vogt Review date...: September 22, 2009 IESG Telechat date: September 24, 2009 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This document describes requirements for SIP/SIMPLE optimizations, primarily to address scalability issues that have been observed for SIP/SIMPLE deployments. The document is well-written and concise, and it is basically ready for publication. Two comments, though, which the authors may want to consider: - It would be worth mentioning in the introduction of the document what the expected result of this document should be. Obviously, we are expecting (or hoping for) an improvement in the scalability of SIP/SIMPLE, but this should be made explicit. Also, do we have estimates of how much SIP/SIMPLE will improve? - The document only talks about optimizations to which the defined requirement should apply. How about other types of protocol enhancements, such as functional extensions? Wouldn't the defined requirements apply to those just as well? Good luck with the publication! - Christian ___ 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
[Gen-art] Gen-ART Review of draft-ietf-softwire-security-requirements-07
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-softwire-security-requirements-07 Reviewer..: Christian Vogt Review date...: 2009-04-01 (no, not a joke) IESG Telechat date: 2009-04-02 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The document analyzes potential security issues and resulting security requirements for scenarios where softwire methods are used for IPv4/IPv6 co-existence. I think this type of analysis is important given the expected widespread existence of these scenarios. Below are a few recommended modifications that should be applied to the document prior to publication: - The document is partly about the security for data packets, and it concludes by requiring authentication, integrity, and reply protection for data packets. Why should this be a requirement given that the purpose of softwires is simply to provide interworking between IPv4 and IPv6? Certainly, there will be /some/ scenarios where one would want data packet protection, but generally such protection would be independent of the use of IPv4/IPv6 co-existence methods. Consequently, I would suggest to reduce the security requirements for data packets, perhaps from MUST to MAY/SHOULD. - The document talks about hosts being mobile or nomadic in several places. This might lead a reader into falsely concluding that the described scenarios or vulnerabilities do not apply to stationary hosts. I would therefore suggest to either remove the attributes mobile and nomadic, or to make clear that mobility and nomadicness is only used in the document for exemplification. - On page 9, the document refers to related security analyses, which relate to softwires as well, such as those for PANA, NSIS, and routing protocols. You could add to this list the security analysis for Mobile IP [RFC 4225], which considers similar issues. The similarity becomes obvious if you replace the softwire initiator with the mobile host and the softwire concentrator with the home agent. - On page 10, the document claims that address spoofing causes a DoS attack. I would soften this statement a bit. It is true that address spoofing can be used as a tool in a DoS attack, yet address spoofing does not consistute a DoS attack by itself. - To prevent address spoofing, the document recommends the use of authentication. This should be elaborated on. Authentication alone does not prevent the authenticated entity from spoofing its address. What is needed in addition is a binding between the legitimate address and the authenticated identity. Hope this helps. Wish everyone involved a smooth publication process! - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-ippm-delay-var-as-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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document..: draft-ietf-ippm-delay-var-as-01 Reviewer..: Christian Vogt Review date...: Jan. 7, 2009 IESG Telechat date: Jan. 8, 2009 Summary: This draft is ready for publication as Informational RFC. This document compares two widely used metrics for measuring packet delay variations, and it provides guidance with respect to when to use which of the metrics. I found the document clearly ready for publication. It is very informative and easy to read. The comparison and guidelines provided by the document are relevant given the resemblance of the observed metrics and the variety of use cases to which the metrics potentially apply. Furthermore, the document includes an excellent motivation and survey of related work; this renders it useful for readers of different levels of expertise in the field of performance measuring. Also, the document is perfectly embedded into existing work through a large number of well-placed references. Two nits, which should be fixed prior to publication, are the following: - Section 1.1, 3rd paragraph: Lost and delayed packets are separated by a waiting time threshold. -- Since the waiting time threshold does not only apply to those packets that are lost or delayed, this sentence should be rephrased to: Packets for which one-way loss or delay is measured are - Section 3.2, 4th-to-last paragraph: The error in the alignment process can be accounted for by a factor, A. -- A is an offset (addend) here, not a factor. Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review on draft-ietf-mmusic-sdp-capability-negotiation-09
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-mmusic-sdp-capability-negotiation-09 Reviewer..: Christian Vogt Review date...: October 24, 2008 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. The document on SDP Capability Negotiation is very well written and should be published soon. I have one suggestion regarding the differentiation between actual and potential configurations, which is used in the document as part of the negotiation model: One of the main purposes for differentiating between actual and potential configurations is to express preferences of the offerer: Potential configuration are of higher preference for the offerer than actual configurations. This property does not become sufficiently clear in the introduction and model description at the beginning of the document. On the contrary, a reader may assume the opposite preference order, namely, that actual configuration are preferred because the offerer would have to re-configure in order to use any of the potential configurations. Suggest to clarify the correct prioritization early on in the document. - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-sanchez-webdav-current-principal-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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document..: draft-sanchez-webdav-current-principal-01 Reviewer..: Christian Vogt Review date...: September 24, 2008 IESG Telechat date: September 25, 2008 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. This document explains the need for a new WebDAV property containing the principal of an online resource, and it specifies such a property. The document is in good shape overall, and I think it can be published very soon. However, I have one technical comment, which may either require some rethinking and rewriting, or some additional explanation in the document. I have also identified a few editorial nits, which are easy to fix. TECHNICAL Section 3, 2nd paragraph of description field: This paragraph specifies the return value for the principal resource in case there are multiple possible values. The return value is in this a case to be freely chosen by the server. Why not return all possible values? The disadvantage of returning only a single principal resource value is that it may lead to consistency problems. The paragraph attempts to prevent this by urging servers to /try/ to be consistent. But since consistency cannot be guaranteed, consistency problems may still come up. Always returning all possible values would fix this. The authors should consider changing the protocol behavior to always returning all available principal resource values. If there are reasons to restrict the number of values returned to a single one, then these reasons should be explained in section 3 of the document. EDITORIAL Section 1, 1st paragraph: The acronym ACL appears here for the first time and should therefore be spelled out. Section 1, 1st paragraph: principal resource which -- principal resource, which Section 1, 2nd paragraph: recommended way to do identify -- recommended way to identify Section 3, purpose field: current authenticated -- currently authenticated Section 3, value field: The value is currently specified to always be a DAV:href element. But according to the description that follows, it could also be a DAV:unauthenticated element. This inconsistency should be fixed. Section 4: issues beyond those defined in HTTP -- issues beyond those identified for HTTP ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-pwe3-cep-mib-12
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-pwe3-cep-mib-12 Reviewer..: Christian Vogt Review date...: August 6, 2007 Summary: This draft is ready for publication as a Proposed Standard RFC I have no objections against publishing this document, yet would suggest considering the following three comments: - Introductory sections 1 through 4: References to related documents are currently scattered across these sections. It would in my opinion make sense to group all these references in a single section, perhaps section 1. This would make it easier for the reader to go back and look them up as it becomes necessary while reading the document. - Security Considerations section: The vulnerabilities discussed in this section do not directly fit into the scope of a Security Considerations sections, because they already exist and are not introduced by the document at hand: (i) consequences of misconfiguration; (ii) security considerations for MIBs in general, such as SET operations in insecure environments, or GET operations on confidential data; (iii) security issues in SNMP versions older than version 3. Notwithstanding this, all of these vulnerabilities are certainly important for network administrators to be aware of. I therefore suggest adding a paragraph at the beginning of the Security Considerations section that explains that the document itself does not introduce new vulnerabilities, but that the following vulnerabilities of related mechanisms should be considered. - Some nits: Abstract: Packet Switch Network - Packet Switched Network Introduction: Acronym PSN is defined twice. Introduction: Acronym VT is not defined. ___ 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-l2vpn-vpls-mcast-reqts-05
Hi Yuji, thanks for addressing my comments on your document. I like the changes you are suggesting. These settle the questions/concerns I had. Regarding your clarifications on fate sharing: Do you think you could add these thoughts to the document, perhaps as an introductory paragraph to the fate sharing section? - Christian On Jul 22, 2008, Yuji KAMITE wrote: Hi Christian, I'm planning changes based on your Gen-ART Reviews (attached email). See my response in [YK] part written below and please tell me if it is OK. Regarding your 3rd comment (about section 5.10), please see my clarification about it (see below). And then I'd like to hear your thoughts more. Best regards, Yuji ___ 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-l2vpn-vpls-mcast-reqts-05
Yuji - To address your comment, I propose to add a new parragraph below in this section (after 4st paragraph). I think your question was if this requirement has benefit or not, so I'm trying to clarify that. This policy will benefit customers. Some customers would like to detect failure soon at CE side and restore full connectivity by switching over to their backup line, rather than to keep poor half connectivity (i.e., either unicast or multicast being in fail). Even if either unicast or multicast is kept alive, it is just disadvantageous to the customer's application protocols which need both traffic. Fate-sharing policy contributes to preventing such a complicated situation. Yes, this is great. If you add this text to the document, it will be more clear to the reader why you enforce fate sharing. Thanks! - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-isis-te-bis-00
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-isis-te-bis-00 Reviewer..: Christian Vogt Review date...: 2008/07/25 Summary: This draft is ready for publication as a Proposed Standard RFC. The document is clearly ready for publication. Just two nits: In section 3, you write: Further, there is no defined mechanism for extending the sub-TLV space for a particular neighbor. Thus, wasting sub-TLV space is discouraged. This seems to be a general issue that may be good to move to a more dominant position. It refers to the sub-TLV concept in general, but here it is mentioned only in the specific context of the Extended IS Reachability TLV. Consider moving this to a place that talks generally about the sub-TLV concept, e.g., to section 2. In section 4, you write: This data structure can be replicated within the TLV, without exceeding the maximum length of the TLV. Suggest rewording to ...as long as the maximum length of the TLV is not exceeded. Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Christian's Gen-ART review of draft-ietf-sipping-consent-format-06.txt
Gonzalo, the modifications you are proposing definitely address the comments I had. Thanks! - Christian ___ 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-ospf-ospfv3-update-18
Acee, thanks for clarifying this in the OSPFv3 document. The changes you applied make it clear what the purpose and scope of the document is. This addresses my comments from the Gen-ART review. Best, - Christian On Apr 15, 2008, at 21:59, Acee Lindem wrote: Hi Christian, Actually, I misstated the intent of the document below. OSPFv3 requires IPv6 and is specifically designed to over it. It can be extended to advertise reachability information for other address families (e.g., IPv4) as well and there is more than one draft stating how this should be done. However, this is not fully specified in this document. I've attempted to clarify this by including the version numbers in the first reference in the abstract and introduction. http://www.ietf.org/internet-drafts/draft-ietf-ospf-ospfv3-update-21.txt Thanks, Acee ___ 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-ospf-ospfv3-update-18
Hi Acee, thanks for addressing these comments. Your explanation regarding virtual links is convincing, so the corresponding text should be left as is in the document. Take care, - Christian On Apr 14, 2008, at 19:38, Acee Lindem wrote: Hi Christian, Thanks taking the time to review this large document. See inline. On Apr 10, 2008, at 6:05 AM, Christian Vogt 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-ospf-ospfv3-update-18.txt Reviewer: Christian Vogt Review Date: April 10, 2008 Summary: This draft is ready for publication as a Proposed Standard RFC. Comments: This document specifies OSPF for IPv6 networks. It is very well written, clear overall, structured, and easily understandable. I suggest this document to move forward in the publication process. Few comments that should be addressed on this way: (1) The document, in particular abstract and introduction, is ambiguous on whether (a) it describes extensions/modifications to OSPF for IPv6 support, which would result in an OSPF version for both IPv4 and IPv6, or whether (b) it is a separate OSPF version specifically for IPv6. The first sentence of the abstract implies (a). But later the abstract implies (b), because it says that authentication mechanisms have been replaced by IPv6-specific ones, leaving no authentications means for IPv4. Then again, the increment of the OSPF version number specified in section 2.7 indicates that (a) is the case. Please clarify the purpose and content of the document early in the abstract and introduction. As you surmised, it is (a). I'll make sure this is clear. (2) The document is very consistent WRT to introducing all acronyms (by spelling them out) when they appear first. Do this for LSA also. See 2nd paragraph of abstract. I added a bunch of these. I'll make sure I get this one and I'll check for other acronyms that require expansion. (3) In section 2.5, a special source address selection rule is defined for virtual links. Is this rule needed specifically for OSPF, or is it specific to virtual links? If the latter was the case, would it make sense to define this rule more generally in an IPv6 document? I'd have to say this rule is specific to OSPFv3 virtual links. I think the meaning of virtual link varies depending on the context so I wouldn't try and define behavior beyond OSPFv3. For example, in one context a virtual link might imply a tunnel while it the OSPFv3 sense it is a multi-hop adjacency implying any OSPF path through the transit area can be used for backbone routing. Thanks, Acee Good luck with the publication, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-sipping-consent-format-06
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-consent-format-06 Reviewer: Christian Vogt Review Date: March 10, 2008 IETF LC End Date: March 6, 2008 IESG Telechat date: -- Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: (1) It would be nice if section 3.1 would briefly explain what a condition is -- like sections 3.2 and 3.2.1 explain what an action or translation handling is, respectively. That would make it easier for the reader to put the rest of the section into context. (2) It seems that section 3.2.1. (Translation Handling) should get the number 3.3. The introduction of section 3 talks about three parts in a permission document -- conditions, actions, and transformations. There is section 3.1 for conditions, section 3.2 for actions, but a section 3.3 for transformations is missing. I think current section 3.2.1 is actually meant to be section 3.3. - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-manet-jitter-04
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). Document: draft-ietf-manet-jitter-04 Reviewer: Christian Vogt Review Date: 12/23, 2007 IETF LC End Date: 11/29, 2007 Summary: Ready for publication Comments: This document is well written, understandable, and has a convincing problem statement. I hence believe that it was the right decision to put it into the RFC Editor queue. Below are a few comments that the authors may want to address, to the extent possible, during AUTH48: (1) Section 3, Applicability Statement: These mechanisms are intended for application where the underlying medium access control and lower layers do not provide effective mechanisms to avoid such collisions. It would be useful to state what could happen if jittering was (accidentally) performed at lower and upper layers simultaneously. Such double jittering would clearly result in different jitter intervals, and an additional sentence should state this IMO. But it seems unlikely that double jittering could ever break a protocol, and this should be state, too. (2) Section 5.3., Message Forwarding, first considers jitter on a message basis and then specifies what should happen if multiple messages are sent in a single packet. I believe that jittering is relevant only at the packet level. The section would hence be more straightforward if it discussed jittering on the packet level from the very beginning. (3) Introduction of section 4, Protocol Overview and Functioning: Using such protocols simultaneous transmissions from two (or more) adjacent nodes may cause delays, packet losses and other problems. Better add a comma after protocols, for the sentence is otherwise very hard to parse. Hope this helps, and happy holidays! - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-simple-prescaps-ext-08
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-prescaps-ext-08.txt Reviewer: Christian Vogt Review Date: October 26, 2007 Summary: Ready. Comments: This document is ready for publication from my perspective. Just two nits, which the authors may want to correct: Section 3.2.8. (message element): The message element indicates that the service supports message as a streaming media type as defined in [12]. s/supports message/supports messaging/ Section 3.2.10. (automata element): The automata element indicates whether the service represents an automata [...] s/an automata/an automaton/ Hope this helps, regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Mip6] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
Francis, I think we disagree on this issue. IMO the I-D is missing a clear statement that a binding between the home address and IPsec SA is required. If you don't want to add this statement, let's agree to disagree. Regards, - Christian Francis Dupont wrote: In your previous mail you wrote: unless you bind the IPsec security association to the home address, an attacker could send a Binding Update message with a spoofed home address using its own IPsec SA. The correspondent node's IPsec instance would accept that message and hand it on to the Mobile IPv6 instance. The Mobile IPv6 instance would rely on the message being authenticated and update the binding cache entry for the spoofed home address. = I agree but I can't see an issue with this: if I remove the word home and all allusions to mobility your statement still applies so as I've already explained the home address is not special and this kind of spoofing is not specific to mobility. You can eliminate this issue with one or two additional, clarifying sentences in your draft. = IMHO it is not reasonable to forbid dynamic addressing in IPsec so it is not reasonable to forbid dynamic or pseudo-anonymous home addresses (pseudo-anonymous: which has no particular property attached to it). And please note the initial IPsec establishment has to be done before IPsec can protect the mobility signaling so without asking anything to IPsec for this IPsec is already at least as good as a return routability check. To finish I've also already stated I am not against a SHOULD for a protection in the case of statically assigned home addresses: - it is easy to do in this case - it improves the security - as this protection is required in the MN-HA context and in this case the simplest way is to encode it in the certificate it should be got for free. To summary if a spoofed home address is accepted it is because the IPsec configuration was setup to accept it. The only thing we have to do is to enforce it was not by accident. Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Mip6] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
Francis, unless you bind the IPsec security association to the home address, an attacker could send a Binding Update message with a spoofed home address using its own IPsec SA. The correspondent node's IPsec instance would accept that message and hand it on to the Mobile IPv6 instance. The Mobile IPv6 instance would rely on the message being authenticated and update the binding cache entry for the spoofed home address. You can eliminate this issue with one or two additional, clarifying sentences in your draft. - Christian Francis Dupont wrote: In your previous mail you wrote: an attacker can not do significantly more damage with a fake home address than with just a fake address. With IPsec alone, an attacker wouldn't be reachable if it used a fake IP address. This is different when you add Mobile IPv6 because the attacker may then be reachable at the care-of address even if the home address is fake. = as this is the point we disagree about, just explain how this can happen! Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Mip6] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
Francis, the purpose of Mobile IPv6 is to redirect packets for a home address to a care-of address. To authorize such redirection, one needs to ensure that the node requesting it is the home address owner. This is why it is necessary to have a strong binding between an IPsec SA and the home address. an attacker can not do significantly more damage with a fake home address than with just a fake address. With IPsec alone, an attacker wouldn't be reachable if it used a fake IP address. This is different when you add Mobile IPv6 because the attacker may then be reachable at the care-of address even if the home address is fake. - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-mip6-cn-ipsec-05
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-mip6-cn-ipsec-05 Reviewer: Christian Vogt Review Date: September 10, 2007 IETF LC End Date: September 9, 2007 IESG Telechat date: -- Summary: Ready with nits. Comments: An important requirement for IPsec-based protection of Mobile IPv6 route optimization is that the IPsec security associations are bound to the mobile node's home address. A malicious mobile node could otherwise misuse its own security association for impersonating the home address of a different mobile node. The draft ensures this requirement in section 3 by saying that... - the Traffic Selectors MUST match exclusively the Home Address of the Mobile Node and an address of the Correspondent Node (the address used for communication between peers). Yet the importance of this requirement, as well as its reason and effect, is unlikely to become clear to the non-expert reader. I would recommend adding a section in the Security Considerations sections elaborating on this. Three nits in addition: - Abstract: This document defines how IPsec can be used between the Mobile Node and Correspondent Nodes for Home Address Option validation (aka. triangular routing) and protection of mobility signaling for Route Optimization. The phrase aka. triangular routing is out of context here. Just drop it. - Section 1: This document defines an alternative mechanism -- ...an alternative mechanism for Mobile IPv6 route optimization - Section 3: anti-replay services MUST be selected -- ...MUST be enabled Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ecrit-security-threats-04.txt
Hannes: I hope that the new draft version addresses your comments. http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-05.txt It does, addressing my main comment right in the introduction. Thanks for the revision, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: [Ecrit] WG: Review of draft-ietf-ecrit-security-threats-04.txt
Henning and Hannes, one brief comment: Maybe this should be clarified either in this document, or in the Requirements document -- in particular because the Requirements document currently only talks about verifying the caller's location, rather than verifying whether there actually exists an emergency case at that location. The future emergency services infrastructure might be able to handle more media types and accept additional data. However, it is quite likely that the PSAP operator will not be able to use these things for a long time since the capabilities are just not supported by end systems and in some cases it might actually be difficult to expect the emergency caller to take pictures (given the level of stress they are likely to experience during an emergency situation). Right, and this is in line with what I was saying: Verification of the truthfulness of (the extent of) a reported incident cannot be solved by the ECRIT protocol. I was suggesting to clarify this in the requirements section. Best, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-crispin-collation-unicasemap-06
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-crispin-collation-unicasemap-06 Reviewer: Christian Vogt Review Date: August 21, 2007 IESG Telechat date: August 23, 2007 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. Comments: The document describes the collation algorithm for the Unicode casemap in section 1. This section ends with an applicability statement for the algorithm. It says that, while the algorithm is well-suited for technical languages, it does not work correctly in certain cases when applied to natural language. My suggestion is to move the applicability statement to a more prominent place, perhaps into a new section preceding current section 1. Moreover, I had previously reviewed version 04 of the document, and those comments have been addressed appropriately in the meantime. This earlier review is available here: http://www1.ietf.org/mail-archive/web/gen-art/current/msg02027.html Finally, 3rd paragraph of section 1: s/using using/using/ Kind regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART Review of draft-ietf-mmusic-ice-17
Jonathan, two small comments. (1) Section 2.6, 1st paragraph: However, it is possible that packet losses will cause a higher priority check to take longer to complete. In that case, allowing ICE to run a little longer might produce better results. Just to avoid confusion: I would say a packet loss rather than packet losses. A reader might otherwise wonder why running a little longer might produce better results if it would mean that a high-packet-loss path gets eventually chosen. OK. Of course there could be more than one packet loss, and it might still be a better choice... Sure. I was thinking that the text in the draft sounds a bit like /persistent/ packet loss. That was my impression. Maybe you just reformulate it to this: [...] However, it is possible that a higher- priority check takes longer to complete due to packet loss. [...] Section 18.5.2, STUN Amplification Attack, explains that ICE candidate probes could be used for amplified flooding: It is impossible to eliminate the amplification, but the volume can be reduced through a variety of heuristics. [...] A reader might at first glance wonder why the amplification could not be avoided by requiring the initiator to send a separate request per response. E.g., this is done in Mobile IPv6 route optimization where a mobile host sends out two initialization messages that each prompt the peer to send a single response message. The problem is, that receipt of a response would assume connectivity. The whole problem ICE is trying to resolve is that I don't know if I have connectivity. It could be, the reason I got no response, is that this candidate isn't reachable from here. So you cannot pace the checks based on responses. What I was thinking of was not that the initiator should wait for request n+1 until it has received response n. Rather, the initiator could be required to send N separate requests if it has N candidates, i.e., one request per candidate. That would preclude amplification if and only if we have (at most) one response per candidate. But in the case of ICE, we typically have more than one response per candidate given that there is one response per local/remote-candidate pair. So sending a separate request for each candidate does not mitigate the amplification threat. - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-mmusic-ice-17
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-mmusic-ice-17.txt Reviewer: Christian Vogt Review Date: August 16, 2007 IETF LC End Date: August 13, 2007 Summary: This document is of very good quality. It also has a very plausible problem statement and an excellent summary of the ICE operation. I support this document going forward in the publication process. Comments: A few comments still, but they are easy to fix: (1) Section 2.6, 1st paragraph: However, it is possible that packet losses will cause a higher priority check to take longer to complete. In that case, allowing ICE to run a little longer might produce better results. Just to avoid confusion: I would say a packet loss rather than packet losses. A reader might otherwise wonder why running a little longer might produce better results if it would mean that a high-packet-loss path gets eventually chosen. (2) Regarding the Security Considerations section: Section 18.5.2, STUN Amplification Attack, explains that ICE candidate probes could be used for amplified flooding: It is impossible to eliminate the amplification, but the volume can be reduced through a variety of heuristics. [...] A reader might at first glance wonder why the amplification could not be avoided by requiring the initiator to send a separate request per response. E.g., this is done in Mobile IPv6 route optimization where a mobile host sends out two initialization messages that each prompt the peer to send a single response message. It might hence be valuable to note in section 18.5.2 that a balancing of the number of request and response messages is not possible in the case of ICE because the initiator does not know the number of responses at the time it sends the request. In ICE, the number of responses depends on both the initiator's and the responder's set of IP addresses. (3) Finally some editorial notes: Section 2.1, 1st paragraph: In all cases, such a network interface appears to the agent as a local interface from which ports (and thus a candidate) can be allocated. s/ports (and thus a candidate)/a port (and thus a candidate)/ ...or plural in both cases. Section 2.1, 2nd paragraph on page 11: I assume local interface Y should be local IP address Y because only the IP address is relevant for connectivity, not the interface. And an interface may have multiple IP addresses, of course. Kind regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-Art Review of draft-ietf-sip-gruu-14
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-sip-gruu-14 Reviewer: Christian Vogt Review Date: August 10, 2007 IESG Telechat date: August 9, 2007 Summary: This draft is ready for publication as a Proposed Standard RFC. Just 2 really small editorial nits. Comments: Section 1, 5th paragraph: s/the the/the/ The initialism UA is used for user agent in the beginning of the document, but at the end of the document, user agent is spelled out. I personally prefer the spelled-out variant and would recommend to use that consistently throughout the document. Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-Art Review of draft-ietf-bmwg-igp-dataplane-conv-app-13
Scott: I appreciate your comment and question. Measurement of each component requires white-box knowledge of the DUT. The BMWG by charter focuses on black-box measurements, which is the externally-observable sum of the components. Yeah, I was assuming that. Maybe you just add a sentence in section 3 clarifying that A black-box convergence test measures the sum of these convergence time components; there is no need to obtain a separate measurement for each of the components. Do you think this makes sense? - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-ecrit-security-threats-04.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-ecrit-security-threats-04.txt Reviewer: Christian Vogt Review Date: July 12, 2007 IETF LC End Date: -- IESG Telechat date: (if known) Summary: This document identifies and describes threats that affect emergency call mechanisms. As the Requirements document, this document is already in good shape. However, as explained below, there is one attack objective that I think is very important, and that should be attended to a bit closer. Comments: The following attack objective described in the document is important enough to be attended to a bit closer IMO: o to divert emergency responders to non-emergency sites. This memo has not identified any attacks within its intended scope that achieve this objective, so it will not be mentioned further. Diverting emergency responders to non-emergency sites is actually not an objective that an attacker might have, but rather a technique of reaching the objective described in the first bullet (to deny system services to all users in a given area). So the draft actually does address this objective. Still, I think the /possibility/ for an attacker to divert emergency responders to non-emergency sites -- as a means of reaching the DoS objective -- is important enough to get a bit further elaborated on, in particular with respect to its relationship to the mechanism to be developed by the Ecrit WG. I think that some clarification would be useful along these lines: Preventing diversion of emergency calls would likely require some evidence about the existence of a reported emergency case, such as a photograph, a video clip, or N previous calls reporting the same emergency case. The decision of which proof would be acceptable, and whether requiring such proof is something desirable in the first place, is likely something that cannot be decided in the Ecrit WG. Preventing diversion of emergency calls is hence something that is likely not to be in scope of the Ecrit WG. Maybe this should be clarified either in this document, or in the Requirements document -- in particular because the Requirements document currently only talks about verifying the caller's location, rather than verifying whether there actually exists an emergency case at that location. Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART Review of draft-ietf-ipfix-biflow-04.txt
Great, this looks good. - Christian Brian Trammell wrote: Christian, We have addressed your comments in the present working copy, slated to be submitted as -05 after coordination with the document shepherd. Please see inline for specific comments... Regards, Brian [...] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-crispin-collation-unicasemap-04.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-crispin-collation-unicasemap-04.txt Reviewer: Christian Vogt Review Date: 07 June 2007 IESG Telechat date: 07 June 2007 Summary: This document describes an extension to existing work on collation, and it should go ahead for publication. One improvement suggestion below, though. Comments: I found that it would probably be helpful for a reader unfamiliar with the details of collation if the introduction of the document was extended to begin with - a description of what we are actually trying to accomplish, i.e., text string comparisons/collations, - which standards we already have in this realm, referring to i;ascii-casemap, and - why this falls short of today's need, and why we are introducing i;unicode-casemap now. Kind regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART Review of draft-ietf-ipfix-biflow-04.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-ipfix-biflow-04.txt Reviewer: Christian Vogt Review Date: 07 June 2007 IESG Telechat date: -- Summary: Ready with comments. Comments: The document is in a good shape overall. One thing I liked in particular is the Rationale and History section, which describes possible design alternatives and the reasons for not choosing those. For a reader not so familiar with traffic measuring, it would be good if the key technical terms were defined in the introduction, where they are used the first time. E.g., one can quickly assume what the metering and collection processes do, and why these ought to be separate processes. But it would be great if the document itself would clarify this, possibly including citations to existing documents. Another thing that I think could be improved is that the figures on pages 9 and on are neither referenced nor described in the text. The text would be nicer to read if it would directly refer to the figures and explain matters based on the figures. Also, the abbreviations used in the figures should be explained. It is currently left to the reader to guess that MP is a metering process, and that an Nx is a node whoose traffic is being measured. Otherwise, go ahead with the publication. Kind regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Review of draft-crispin-collation-unicasemap-04.txt
Christian Vogt wrote: Document: draft-crispin-collation-unicasemap-04.txt Reviewer: Christian Vogt Review Date: 07 June 2007 IESG Telechat date: 07 June 2007 There is actually no IESG telechat scheduled AFAIK. This was my copy-and-paste mistake; it should be: Document: draft-crispin-collation-unicasemap-04.txt Reviewer: Christian Vogt Review Date: 07 June 2007 IESG Telechat date: -- Thanks, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Review of raft-mrose-apex-historic-01.txt
Marshall, the new version is fine with me. I think this document should go forward now. Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Review of draft-ietf-tcpm-syn-flood-04
Wesley, I read your draft on TCP SYN Flooding Attacks and Common Mitigations as part of my work as a Gen-ART reviewer. Below some feedback. (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-tcpm-syn-flood-04.txt Reviewer: Christian Vogt Review Date: May 23, 2007 IESG Telechat date: -- Summary: The draft is certainly ready for publication. I found it very well-structured and easy to read. The introduction gives the unexperienced reader an excellent overview on the topic. I also think that the draft is a valuable contribution, finally providing a concise and well-citeable summary on SYN flooding prevention mechanisms. Comments: (1) Section 3.3 (Reducing SYN-RECEIVED Timer): Maybe you could state here /why/ this technique might prevent legitimate connections from becoming established. The reason obviously is that the RTT to a legitimate peer might be longer than a shortened connection establishment timeout, but this should be written down explicitly. Also, it might be good to add that RTTs can be quite long in some wireless access technologies, e.g., due to long buffering delays. (2) Section 3.4 (Recycling the Oldest Half-Open TCB): Again, this technique could again prevent legitimate connection establishments especially when the RTT is long. (3) Section 3.6 (SYN Cookies), 3rd paragraph: Referring to the example that SYN cookies might not interoperate with MSS encodings in initial sequence numbers: I am not an expert in this area, but I could imagine that the problem is due to the TCP responder not being able to store the 2 MSS bits in the sequence number from the SYN, nor being able to reconstruct these bits in the sequence number from the ACK following the SYN-ACK. Reconstruction of the MSS bits from the ACK are not feasible because the SYN might have options, which, at the time the ACK is received, have been forgotten by the TCP responder. If this is what causes the problem, then it might be good to spend one or two more sentences explaining it. Editorial nits: (1) Section 1, 1st paragraph: s/denial of service method/denial-of-service method/ (2) Section 3.6, 2nd paragraph: s/implementation dependent/implementation-dependent/ (3) Section 3.6, 6th paragraph: s/never is/is never/ That's it. Excellent work, go ahead and publish! - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART review of draft-ietf-inch-iodef-12.txt
Hello Roman: I found that it might be useful to allow a telephone number to be accompanied by a time range during which it should be used. E.g., it might be ok to call an office number between 8 am and 5 pm, but a cell-phone number should be used outside this time range. Possibly, the free-form meaning attribute in the Telephone class could be used for this purpose. If so, it might be useful to state this explicitly in the document. The use case you are describing is exactly why [EMAIL PROTECTED] and [EMAIL PROTECTED] attributes were originally added. As multiple parties are thinking it, but it is not document, perhaps it should be. I propose adding the following additional text to description of these attributes: ... A free-form description of the element content (e.g., hours of coverage for a given number). Yes, that's a good suggestion IMO. Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Gen-ART review of draft-ietf-inch-iodef-12.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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-inch-iodef-12.txt Reviewer: Christian Vogt Review Date: 9 May 2007 IESG Telechat date: 10 May 2007 Summary: This draft is in a good condition. Especially the introduction provides a reasonable understanding of the purpose and background of the standard for an unexperienced reader. Few comments below, though. Comments: I found that it might be useful to allow a telephone number to be accompanied by a time range during which it should be used. E.g., it might be ok to call an office number between 8 am and 5 pm, but a cell-phone number should be used outside this time range. Possibly, the free-form meaning attribute in the Telephone class could be used for this purpose. If so, it might be useful to state this explicitly in the document. In addition, some editorial nits: - Section 2.4, page 8: s/encoding of the document are/encoding of the document is/ [I'm not 100% sure if data goes with singular or plural in the English language, since I'm not a native speaker. But from the information I found, it should be singular in this context.] - Section 2.13, page 10: s/A telephone number/A telephone or fax number/ - Section 3.7.1, page 22: s/Regional Latin-American/Latin-American/ - Section 7.1, page 62: s/A example/An example/ Best regards, - Christian ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: Gen-ART Last Call Review of draft-ietf-mipshop-cga-cba-02.txt
Eric - For some reason, in your response, my bulletization of the list of the new status codes somehow got re-paragraphed - hopefully my version below does not suffer the same fate. Oh, no, this was probably one of my Thunderbird extensions for nicer quotations. It's now deinstalled. Anyway, your suggested bulletization is fine in your emails and I got your point. Typographical resets should be absolutely disallowed in E-Mail. :-) To the casual reader, it may otherwise be unclear exactly what change I was suggesting... Yes. Will incorporate your suggestions into the draft ASAP. Thanks! - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
[Gen-art] Re: review of draft-ietf-netlmm-threats-04.txt
Hi Francis, thanks for your review! - a variety of ... which make mouting - makes? mounting ^ ^ (if someone finds the answer for the grammar point in the web, can (s)he give a pointer? I've based my comment on French, perhaps English is different. BTW a large number of is plural without question). FWIW: I had to look this up on the Web myself and it seems that the English grammar is in this case exactly the opposite as the German: While Germans would use the German version of a variety of attack barriers /makes/..., Americans seem to use a plural verb in this context: a variety of attack barriers make I found this information at: http://www.askoxford.com/asktheexperts/faq/aboutgrammar/numberofpeople?view=uk Native speakers, please correct me if this is incorrect. Kind regards, - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ 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 wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-netlmm-threats-04.txt Reviewer: Francis Dupont Review Date: 15 November 2006 IESG Telechat date: 16 November 2006 Summary: Ready Comments: I have some grammar questions which should be handled by the RFC Editor in 3.1 page 8: - can to trick - can trick - a variety of ... which make mouting - makes? mounting ^ ^ (if someone finds the answer for the grammar point in the web, can (s)he give a pointer? I've based my comment on French, perhaps English is different. BTW a large number of is plural without question). - both on-link and off-link - either on-link or off-link? Regards [EMAIL PROTECTED] ___ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
