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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf