Hi, thanks for the response. Comments inline. I removed sections for issues
that I think are closed:
On Apr 9, 2010, at 6:53 AM, Martin Stiemerling wrote:
[...]
-- section 3.2.8, "transitory" bullet: "When a node has received a
NOTIFY message, it
marks the signaling session as 'transitory'."
I assume this is content dependent, right? That is, this is not true
for any arbitrary NOTIFY?
It is transitory for any NOTIFY.
NOTIFY is indicating that something did get wrong along the path and
that the NI should react immediately to this. However, making it
context dependent has the risk that, if the path back to the NI is
broken or if the path from the NI to the NFs is broken, that NFs will
keep state for a too long time (probably until the session expires -
which might be long time), despite the fact that the state is not
needed anymore.
Okay.
[...]
-- section 3.4, 4th bullet:
I'm not sure what "data exchange duration" means. Is this the time over
which the DS expects to send exchange data with the DR, or is it the
time required for one round-trip data exchange? If the first, how is
the DS expected to know this in advance?
It is the time over which DS is sending its data. The formulation is bit
blurry, as neither of us can tell how long this time will actually be.
The time can range from few minutes (ftp download) to days (if used with
GRID stuff). The way how the DS learns this is up to the implementer.
Okay.
-- section 3.4, paragraph before numbered list:
Should there be a normative statement about using this algorithm?
(MAY/MUST/SHOULD)?
I would say it should read RECOMMENDED. Is that fine?
Works for me.
-- section 3.4, first paragraph after numbered list:
Is "refresh timer" the same thing as "message refresh period"? (i.e.
"R", above?)
No, see text in 3.4:
" 1. The refresh message timer to be randomly set to a value in the
range [0.5R, 1.5R]."
" This duration is modeled as R, with R the message refresh period (in
seconds);"
Okay,
-- 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?
[...]
2nd and 3rd sentence do not parse.
OLD
Each network edge that has the NATFW NSLP deployed can use EXTERNAL
request message to allow a secure access to the network. This will
allow to open the firewall/NAT on the receiver's side. However, the
edge-devices should not allow to be opened up completely, but to let
DR's to reserve very specific policies. For instance, a DR can
request to reserve an 'allow' policy rule for an incoming TCP
NEW:
Each network edge that has the NATFW NSLP deployed can use the
EXTERNAL request message to allow a secure access to the network.
Using the EXTERNAL request message does allow the DR to open the
firewall/NAT on the receiver's side. However, the edge-devices
should not allow to be opened up completely (i.e., applying an allow-
all policy), but to let DR's to reserve very specific policies. For
instance, a DR can request to reserve an 'allow' policy rule for an
s/"matching CREATE request"/"matching the CREATE request"
fixed.
2nd to last sentence does not parse.
At what part?
Hmm. It parses now. Sorry, I can't remember my objection so it must not be
important.
[...]
Checked:
- changed intended status to experimental
-There is one complain about using private IP addresses instead of the
example addresses. However, since this document is about NATs, private IP
addresses
are needed anyhow.
Okay.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf