Subject: [Gen-art] Gen-ART (belated) LC Review of draft-ietf-nsis-nslp-natfw-23

From: Ben Campbell <[email-masked]>
Date: Mon, 15 Mar 2010 18:24:02 -0500

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 resolve these comments along with any other Last Call comments
you may receive.

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.