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?
> >