Re: Erratum reported on MPA (RFC 5044)

Having seen no comment other than Pat's approval, and since
the erratum matches how I would expect an implementation to
work (CRC the data as it comes off the "wire", then figure
out what the data is), I'm going to tell our AD to approve
the erratum. 

Thanks,
--David
 

> -----Original Message-----
> From: Pat Thaler [mailto:[email protected]] 
> Sent: Thursday, December 04, 2008 7:33 PM
> To: Black, David; [email protected]; [email protected]; 
> [email protected]; [email protected]; [email protected]; Uri Elzur
> Subject: RE: Erratum reported on MPA (RFC 5044)
> 
> David,
> 
> I've checked with our implementers and we support accepting 
> the erratum.
> 
> Pat 
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of [email protected]
> Sent: Monday, December 01, 2008 2:05 PM
> To: [email protected]; [email protected]; Uri Elzur; 
> [email protected]; [email protected]; [email protected]
> Cc: [email protected]
> Subject: [rddp] Erratum reported on MPA (RFC 5044)
> 
> An erratum has been reported on MPA (RFC 5044):
> 
> http://www.rfc-editor.org/errata_search.php?eid=1427
> 
> The background is that MPA is 4-byte aligned, and hence
> the 2 least significant bits of a marker MUST be zero.
> 
> The current language in MPA requires a receiver to set
> these bits to zero in all markers before calculating
> the CRC.  The erratum suggests calculating the CRC with
> whatever arrives.
> 
> This sounds like a reasonable approach, as any modifications
> to inbound traffic prior to the CRC calculation may be
> problematic, but it raises an issue: What is the "right"
> thing to do if a packet passes a CRC check but has a
> misaligned marker (two least-significant bits aren't
> both zero)?
> 
> The erratum implies that this condition is ignored - the
> least significant bits are treated as if they were zero
> in using the marker (and this is very easy to do in an
> implementation).
> 
> On this basis, I'm inclined to accept the erratum, but
> would like to hear from implementers on what they actually
> do with misaligned markers if they arrive - I think
> "running code" should be paramount in making this decision.
> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> [email protected]        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> _______________________________________________
> rddp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rddp
> 
> 
> 
>