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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf