Re: MPA CRC normative text (was DRAFT San Diego minutes)

On Aug 13, 2004, at 3:42 AM, Jim Pinkerton wrote:

>  
>
> You say potahto, I say potato...
>
>   
>
> In other words, both, neither, and possibly anything in between.
>
>  
>
> In re-reading the spec, it would appear as though the specified 
> behavior is:
>
>  
>
>             An implementation MUST support CRCs
>
>             An implementation MUST default to CRCs enabled (i.e. set 
> the C bit in the MPA Request/Reply)
>
>             An implementation MAY disable CRCs if the system 
> administrator tells it to (but the implementation can ignore the 
> administrator).
>
>             The process of override of the default MUST be invisible 
> to the ULP.
>
>  
>
> Thus we don’t have a specific escape clause if a specific Stream has 
> IPSec enabled – but IPsec is generally enabled administratively, so to 
> get the same effective result with the above statements, the 
> administrator just has to take one additional step (enable IPSec, 
> disable MPA CRC).
>
>   
>
> So what’s missing? iSER has no guarantee that the administrator has 
> not turned off CRC (and not enabled IPsec). And it has no guaranteed 
> way of turning off CRC if IPsec is enabled, unless it calls itself a 
> “system administrator” rather than an application. Again, you say 
> potahto, I say potato.
>
>  
>
> I’m not sure this is broken folks...
>
>

The key point that was somehow missed is this:

	ULP designers MUST NOT be concerned that they might be receiving less 
than CRC-32C
	protection on an end-to-end basis.

I thought that this was clear.

There seems to be some concern that the ULP should even protect itself 
against the
possibility of the system administrators setting the network 
configuration up incorrectly.
Frankly, in an IP network that is impossible.

Should the ULP also explicitly require the system administrator to set 
up routing tables
correctly? And DNS? What about "the system administator MUST allow all 
required
traffic to be passed by intermediate firewalls."


The intent is that the LLP MUST provide a level of end-to-end error 
protection that
is at least as good as CRC-32c.

Jim is absolutely correct that this requirement SHOULD be stated as a 
performance
goals, with a note that CRC-32c and IPsec are known to be safe.  I 
believe a
cross-over Ethernet cable would also qualify.

Another obvious destination that could suppress CRCs would be 127.0.0.1.

In any event, this would hardly be the first time that a requirement 
was stated
in terms of an acceptable solution. Building codes routinely require a 
certain
type of wood be used for floors, and occassionally state 'must support 
X pounds
per square foot"

If it really bothers anyone that much, they should simply submit the 
more formal
statement of the requirement. Just be sure to explicitly state that 
CRC-32C and
IPsec both qualify.

_______________________________________________
rddp mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/rddp