Hi Ben, > -----Original Message----- > From: Ben Campbell [mailto:ben@xxxxxxxxxxx] > Sent: Friday, April 16, 2010 10:12 PM > To: Martin Stiemerling; Hannes (NSN - FI/Espoo) Tschofenig; > cedric@xxxxxxxxx; elwynd@xxxxxxxxxxxxxx; General Area Review Team > Cc: magnus.westerlund@xxxxxxxxxxxx; IETF-Discussion list; > jukka.manner@xxxxxx > Subject: Gen-ART Telechat Review of draft-ietf-nsis-nslp-natfw-24 > > 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) > > [...] Yes, but there was no text. The -25 has the text, saying that a NATFW lifetime object must be included in the error response. The NF includes now a Signaling Session Lifetime object to the error response send to the NI with the maximum or minimum lifetime. > > >>> > >>> -- 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? Yes, good catch, it applies for both. Fixed in -25. Thanks, Martin martin.stiemerling@xxxxxxxxx NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf