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