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

[Simon Perreault <[e-mail]>]

On 11/10/2011 05:58 PM, Dave Thaler wrote:
> 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?

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.

> 2) REQ-12 is about DSCP values.  Why is this requirement specific to CGNs
> (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:
>> 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/

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.

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

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?

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

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