Document: draft-ietf-nsis-nslp-natfw-23
Reviewer: Ben Campbell
Review Date: 2010-03-15
IETF LC End Date: 2010-03-12
IESG Telechat date: (if known)

[Apologies for the tardiness of this review. I somehow missed the assignment 
until after the LC completed.]

Summary:

This draft is almost ready for publication as an experimental RFC. There are 
a few minor issues and nits that should be addressed first.

Major issues:

Minor issues:

-- section 1.4, figure 1:

I'm not sure I understand the intent of the "application server" element 
in the figure.

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

-- 3.3, paragraph 1:

You offer guidance to reject a message for any syntax error. Are there 
cases where you can have trivial syntax errors that could be processed 
anyway? It's been my experience that coders often become protocol police, 
and reject things that could have worked. Postel's law may apply here.

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

-- section 3.4, paragraph before numbered list:

Should there be a normative statement about using this algorithm? (MAY/MUST/
SHOULD)?

-- section 3.4, first paragraph after numbered list:

Is "refresh timer" the same thing as "message refresh period"? (i.e. 
"R", above?)

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

-- section 3.4, 2nd to last paragraph, starting with : "Each NSLP forwarder 
processes the RESPONSE message..."

I'm a little confused here. Is the "received" lt value the one received in 
the CREATE/EXTERNAL or the RESPONSE? What happens if the value in 
a RESPONSE is not acceptable to an NF (i.e. two low) ? It can't respond to 
a RESPONSE. Does this require a NOTIFY in the downstream direction?

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

Nits/editorial comments:

-- section 3.4, 3rd bullet:

unbalanced parenthesis

-- section 5.3: paragraph 1:

s/typcial/typical

... paragraph 2:

Please expand AA on first use.

... paragraph 3:

s/"can use EXTERNAL"/"can use the EXTERNAL"

2nd and 3rd sentence do not parse.

s/"matching CREATE request"/"matching the CREATE request"

2nd to last sentence does not parse.

s/indepdently/independently

... paragraph 4:

s/deploy/deployment

s/completetly/completely 

-- idnits returned some warnings--please check it.