Subject: [BEHAVE] Comments on draft-ietf-behave-lsn-requirements-04

From: Dave Thaler <[email-masked]>
Date: Thu, 10 Nov 2011 22:58:10 +0000

Summary:

1) REQ-7 has the clause 'UNLESS it is known that "Address- Independent Filtering"
   does not cause the application-layer protocol to break'.  
Not sure this makes sense. How could it reliably know the application-layer protocol? 
Since this is already a "RECOMMENDED" not a MUST, I think this phrase should be deleted.

2) REQ-12 is about DSCP values.  Why is this requirement specific to CGNs
(rather than all NATs)?   It also contains two sentences that seem to contradict each
other:
> When packets pass from one side to the other, the DSCP values MUST be 
> preserved. If the CGN also includes diffserv classifier and marker 
> functionality it MAY change the DSCP values.

Because of the MAY in the second sentence, s/MUST/SHOULD/

If there is a reason this belongs in this document because there's something specific to CGNs, then the Justification should explain it.

3) Any mention of "NAT444" seems irrelevant.   Suggest removing all use of that term.

4) Several items (e.g., sections 4, 4.1, 8) use RFC 2119 language without using the REQ-# format and should be recast into that format.

5) Section 5 seems to have no requirements, so why is it in this document?
If there are requirements (and I suspect there are), then they should be called out.
Same for section 6.

6) A couple places phrase requirements in terms of what an administrator does.
These should be rephrased as CGN implementation requirements (e.g., being capable of being configured to do blah).  Examples of such statements are in section 8 and in the second sentence of REQ-2.

I'll send a marked up PDF to the authors with in-line comments/edits that include various editorial nits.

-Dave

---

From: Simon Perreault <[email-masked]>
Date: Fri, 11 Nov 2011 09:45:33 -0500

> Not sure this makes sense. How could it reliably know the application-layer protocol?

That is intentionally left unspecified. Otherwise it's a rat hole.

> Since this is already a "RECOMMENDED" not a MUST, I think this phrase should be deleted.

Well, that's the point of using the "RECOMMENDED ... UNLESS" idiom: to 
provide guidance as to when it is acceptable to deviate from the 
recommendation.

> (rather than all NATs)?

Right, I don't think it's specific to CGNs. How about we move it to 
draft-penno-behave-rfc4787-5382-5508-bis?

> It also contains two sentences that seem to contradict each
> other:

Agreed. I'll use the "SHOULD ... UNLESS" idiom.

> 3) Any mention of "NAT444" seems irrelevant.   Suggest removing all use of that term.

Agreed.

> 4) Several items (e.g., sections 4, 4.1, 8) use RFC 2119 language without using the REQ-# format and should be recast into that format.

Makes sense.

> If there are requirements (and I suspect there are), then they should be called out.

They are informational. The intent is to provide guidance to CGN 
implementers. I think it makes sense to keep them. We could explicitly 
state that these sections are not normative. What is it that is bugging 
you exactly?

> These should be rephrased as CGN implementation requirements (e.g., being capable of being configured to do blah).  Examples of such statements are in section 8 and in the second sentence of REQ-2.

Makes sense.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Reinaldo Penno <[email-masked]>
Date: Sat, 12 Nov 2011 16:23:36 -0500

I can incorporate into the next version
draft-penno-behave-rfc4787-5382-5508-bis

---

From: Dave Thaler <[email-masked]>
Date: Sun, 13 Nov 2011 02:31:02 +0000

> provide guidance as to when it is acceptable to deviate from the

I agree it's a rat hole to even mention, but since you're mentioning it anyway
you might be more explicit that it's not easy to know.

Also UNLESS isn't a term defined in 2119 and shouldn't be capitalized.
I'm not a fan of the "SHOULD ... unless" wording personally.  Personally
I think it's cleaner to either have "MUST ... if/unless" for things that are
conditionally mandatory, or for conditional recommendations then two
separate sentences like "SHOULD blah.   If blah, an implementation MAY
instead do blah."

> implementers. I think it makes sense to keep them. We could explicitly state
> that these sections are not normative. What is it that is bugging you exactly?

We have an IPR declaration on a requirements document.  That's surprising and
my guess is it's because the requirements document contains section 5 and 6
which aren't about requirements.

-Dave

---

From: Simon Perreault <[email-masked]>
Date: Sun, 13 Nov 2011 16:32:57 +0900

> you might be more explicit that it's not easy to know.

Ok.

> separate sentences like "SHOULD blah.   If blah, an implementation MAY

Thanks, I'll try to come up with clearer text.

Simon