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-nsis-nslp-natfw-24 Reviewer: Ben Campbell Review Date: 16 April 2010 IESG Telechat date: 22 April 2010 Summary: Ready for publication as an experimental RFC. I have a couple of very minor editorial comments remaining from my last call review that you may consider, but probably shouldn't block anything. Major issues: None Minor issues: None Nits/editorial comments: -- a couple of editorial comments/questions copied from the email conversation on the subject: >>> >>> >>> -- section 3.4, paragraphs about signalling session lifetime being too >>> big or small >>> >>> Does the RESPONSE carry hints about the largest or smallest allowed >>> value? >> >> No it does not. However, there is no indication what the appropriate range is. >> How about adding the NATFW lifetime object to that error response message, in >> which the maximum session lifetime is indicated? >> > > Works for me. Are you proposing a change to the text? ( I don't see this in version 24) [...] >>> >>> -- section 3.7.1, "Firewall:" sub-bullet: >>> >>> When is "later on"? >>> >>> If the FW gets a success RESPONSE from downstream, generates an error >>> RESPONSE due to a local failure, how do downstream devices learn of >>> this? Does it need to send a NOTIFY towards the NR? >> >> This is a mistake in the text - I guess this text got missed while >> editing. >> >> Changed to text to address the fact that error must be generated at the >> time when the CREATE is received, as the policy rule is already reserved >> and all checks whether it is compliant with local policies has to be >> done at that time. >> >> OLD: >> When the initial CREATE message is received at >> the private side, the NAT binding is allocated, but not >> activated (see also Appendix D.3). An error RESPONSE message >> is generated, if the requested policy rule cannot be installed >> later on, of class 'Signaling session failure' (0x6) with >> response code 'Requested policy rule denied due to policy >> conflict' (0x4). The MRI information is updated to reflect the >> >> NEW: >> When the initial CREATE message is received at >> the private side, the NAT binding is allocated, but not >> activated (see also Appendix D.3). An error RESPONSE message >> is generated, if the requested policy rule cannot be reserved >> right away, of class 'Signaling session failure' (0x6) with >> response code 'Requested policy rule denied due to policy >> conflict' (0x4). The MRI information is updated to reflect the >> > > I think the change is good, but I notice you applied it to the NAT bullet, and my comment was on the Firewall bullet. I suspect the same issue applies to both? > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf