[Gen-art] Gen-ART review of draft-ietf-sieve-managesieve-05.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-sieve-managesieve-05.txt Reviewer: Miguel Garcia miguel.a.gar...@ericsson.com Review Date: 29 December 2008 IESG Telechat date: 18 December 2008 IETF LC End Date: 30 December 2008 Summary: The document is ready for publication as a proposed standard RFC. Major issues: none Minor issues: - Section 1.2 could be slightly improved to guide the reader over the rest of the document by describing, at the very beginning, that this is a command-response protocol based on a client/server architecture. The client emits a command; the server processes the command and replies with a response (or something like that). I am also missing a sentence indicating that the protocol runs over any connection-oriented transport protocol, although at the moment, TCP (and TCP over TLS) are the only defined transport protocols. - Section 2.1 (towards the end) has a discussion about the STARTTLS command and the mechanism to protect against a MITM bid-down attack. The text says: Once a SASL security layer is established, the server MUST re-issue the capability results, followed by an OK response. This is necessary to protect against man-in-the-middle attacks which alter the capabilities list prior to SASL negotiation. The capability results MUST include all SASL mechanisms the server was capable of negotiating with that client. This is done in order to allow the client to detect active down-negotiation attack. What I am missing here is some normative text that instructs clients to do an action (which one would that be?) if such MITM bid-down attack is detected by the client. Nothing is written so far, and I suspect that client will not implement any action if it isn't clearly indicated. Nits/editorial comments: - idnits reveals that references [DIGEST-MD5] and [IANA-GUIDELINES] are declared in Section 9.2, but never used. There should be an anchor in the text or the reference should be deleted. - idnits reveals that references to RFC 4366 and RFC 3280 are obsolete. The updated references are RFC 5246 and RFC 5280, respectively. - there are a couple of anchors in the text. Just make sure these are deleted before publication, in particular anchor8, which describes Chris Newman's thoughts. /Miguel -- Miguel A. Garcia +34-91-339-3608 Ericsson Spain ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-andreasen-sipping-rfc3603bis-07.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-andreasen-sipping-rfc3603bis-07.txt Reviewer: Francis Dupont Review Date: 2008-12-24 IETF LC End Date: 2009-01-10 IESG Telechat date: unknown Summary: Ready Comments: some minor editorial concerns (i.e, to be fixed bt the RFC Editor): - Abstract page 2: please remove (SIP) [RFC3261] (the Abstract is an autonomous text, the abbrev is not used so is useless, etc) - ToC page 3: Acknowledgements - Acknowledgments - 1 page 5: this is the right place to introduce the SIP abbrev, i.e., SIP - Session Initiation Protocol (SIP) [RFC3261] - 2 page 6: the DCS abbrev is never introduced - 5 page 10: the UAC abbrev is not introduced, IMHO you should find a way to introduce UAC and UAS abbrevs in 3 (Trust Boundary). - 5.1 page 11: .The trace-param - . The trace-param - 8 page 25: ccc-id - cccid (for uniformity) - 8.3 page 28: The UAC may also include a P-DCS-Redirect header. - The UAC MAY also include a P-DCS-Redirect header. (IMHO according to the context this should be the uppercase keyword) - 8.5 page 28: .Otherwise, - . Otherwise, - 12 page 37: Acknowledgements - Acknowledgments - 12 page 37: Tung- Hai - Tung-Hai ? - 13.2 page 38: please use the long names for months (first 4 entries) Don't forget you have expert review and IANA comments in the ID tracker. Regards francis.dup...@fdupont.fr PS: I don't comment about the lawful interception stuff. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt
Hi, Richard, These changes address all my comments - best wishes with your draft. Happy New Year, Spencer - Original Message - From: Richard Ogier rich.og...@earthlink.net To: Spencer Dawkins spen...@wonderhamster.org Cc: phillipspagn...@gmail.com; General Area Review Team gen-art@ietf.org; Acee Lindem a...@redback.com; Abhay Roy a...@cisco.com Sent: Sunday, December 28, 2008 4:59 PM Subject: Re: Gen-ART Last Call review of draft-ietf-ospf-manet-mdr-03.txt Hi Spencer, I have updated the draft to address all of your comments. http://www.ietf.org/internet-drafts/draft-ietf-ospf-manet-mdr-04.txt Answers to your questions are given below. Thanks, Richard Spencer Dawkins 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-manet-mdr-03.txt Reviewer: Spencer Dawkins Review Date: 2008-12-12 IETF LC End Date: 2008-12-24 IESG Telechat date: (not known) Summary: This draft is on the right track for publication as Experimental. I have a small number of questions, listed below. Comments: 2.6. Hello Protocol Differential Hellos are sent every HelloInterval seconds, except when full Hellos are sent, which happens once every 2HopRefresh Hellos. Spencer (clarity): Is 2HopRefresh a counter? As I continue reading, it seems to be treated as a counter, but that wasn't clear to me at this point in the document (I think I caught up in Section 4.1, but that's later than I'd hoped) . Richard: To clarify the meaning of the parameter 2HopRefresh, I modified the text in Section 2.6 (overview) to be similar to the corresponding text in Section 4.1. The default value of 2HopRefresh is 1, i.e., the default is to send only full Hellos. The default value for HelloInterval is 2 seconds. Differential Hellos are used to reduce overhead and to allow Hellos to be sent more frequently, for faster reaction to topology changes. 3.2. New Configurable Interface Parameters All possible configurations of the new interface parameters are functional, except that if AdjConnectivity is 0 (full-topology adjacencies), then LSAFullness must be 1, 2, or 4 (see Section 9.3). Differential Hellos should be used to reduce the size of Hello packets when the average number of neighbors is large. Differential Spencer (clarity): does large have any relationship with 160 or 200 nodes mentioned in the next paragraph? Richard: No. To give an idea of what large means here, I added (e.g., greater than 50) after the word large. Hellos are obtained by setting the parameter 2HopRefresh to an integer greater than 1, with the recommended value being 3. Good performance in simulated mobile networks with up to 160 nodes has been obtained using the default configuration with differential Hellos. Good performance in simulated mobile networks with up to 200 nodes has been obtained using the same configuration except with minimal LSAs (LSAFullness = 0). Simulation results are presented in Appendix E. MDRConstraint A parameter of the MDR selection algorithm, which affects the number of MDRs selected. The default value of 3 results in nearly the minimum number of MDRs. The optional value 2 results in a larger number of MDRs. Spencer(clarity): are 3 and 2 the only possible values for this parameter? If so, that's fine, but the chosen values made me wonder about other possible values... Richard: I added text specifying that MDRConstraint can be any integer greater than or equal to 2. 12. IANA Considerations This document defines three new LLS TLV types to be allocated by IANA: MDR-Hello TLV, MDR-Metric TLV, and MDR-DD TLV. Spencer (clarity): it would be good to point to the definitions in this section. Richard: Done. D. Non-Ackable LSAs for Periodic Flooding In a highly mobile network, it is possible that a router almost always originates a new router-LSA every MinLSInterval seconds. In this case, it should not be necessary to send Acks for such an LSA, or to retransmit such an LSA as a unicast, or to describe such an LSA in a DD packet. In this case, the originator of an LSA MAY indicate that the router-LSA is non-ackable by setting a bit (to be specified) in the options field of the LSA. For example, a router Spencer: to be specified? Is this the L bit described in A.1? Richard: Yes. I modified the text to indicate this. can originate non-ackable LSAs if it determines (e.g., based on an exponential moving average) that a new LSA is originated every MinLSInterval seconds at least 90 percent of the time. (Simulations can be used to determine the best threshold.) ___ Gen-art mailing list Gen-art@ietf.org
Re: [Gen-art] Gen-ART Last Call review of draft-korhonen-mip4-service-06
Hi, Jouni, Thanks for your quick response - I'm OK with most of your proposed changes. I should emphasize that my comments here are Last Call comments that you (and the document shepherd, and the AD) can decide to ignore - I'm just telling you what I'm seeing when I read the text. Just to finish up: Some of the potential use-cases were listed earlier in this section. The general aim is better manageability of services and service provisioning from both operators and service providers point of view. However, it should be understood that there are potential deployment possibilities where selecting a certain service may restrict simultaneous access to other services from an user point of view. For example, services may be located in different administrative domains or external customer networks that practice excessive filtering of inbound and outbound traffic. Spencer: I wasn't clear on who this understanding is directed to - it almost reads like you're warning users that bad things might happen if you use a specific service, but surely the user specifies the service because an operator requires this? We had this discussion earlier on RFC5149.. and concerns were raised whether the Service Selection is a potential tool for enabling walled gardens etc. Thus this note here was added to emphasize that point. I understand your point from your explanation, but can't get that understanding from the draft text. If you said s/from a user point of view/from a user point of view (for example, a walled garden)/ that would be as clear as your explanation. 3. Service Selection Extension At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. It SHOULD be included at least in Spencer: seems to be missing a qualifier: When a non-default service is selected, the Service Selection extension SHOULD be included ...? Spencer: If this is qualified, could the SHOULD be a MUST? Hmm.. right. New text would be: At most one Service Selection extension MAY be included in any Mobile IPv4 Registration Request message. When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. The Service Selection extension MUST be placed in the Registration Request message as follows: Spencer: If it remains as SHOULD, what happens if the Service Selection extension is not included in the initial binding registration, but is included in subsequent binding registrations? The first RRQ would be treated as the selection of the default service. The subsequent RRQs with the service selection would cause reauthorization evaluation of the requested service. If the newly requested service conflicts with the default service from the HA point of view, then an appropriate error is returned and the binding is dropped. I'm still confused by When a non-default service is selected, the Service Selection extension SHOULD be included at least in the Registration Request message that is sent for the initial binding registration when the mobile node and the home agent do not have an existing binding. My understanding from your explanation is that, by definition, if you don't include the Service Selection extension, you aren't selecting a non-default service until you DO send an RRQ that includes the Service Selection extension - right? If I'm tracking you, you're talking about two cases at the same time - what happens if you DO include the extension in the first RRQ, and what happens if you DON'T include the extension in the first RRQ, then switch to a non-default service by including the Service Selection extension in a subsequent RRQ - that would be why I was confused. I think your explanation is way clearer than the draft text - perhaps you could insert it into the draft text? Thanks, and Happy New Year, Spencer ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
