UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36

Steps to reproduce the problem:
1. Load a URL for a page where the HTTP response includes a "set-cookie" header of value "a=b; path=/ ; SameSite" 
2. Reload the same URL and inspect the HTTP Request "cookie" header

What is the expected behavior?
I should see that the "a=b" key value pair was used in subsequent requests to the URL.

What went wrong?
The cookie a=b is not used.

If the initial Set-Cookie response contains "... ; SameSite=Strict" then the cookie a=b is used.

Did this work before? No 

Chrome version: 51.0.2704.79  Channel: stable
OS Version: OS X 10.11.4
Flash Version: Shockwave Flash 21.0 r0

The IETF spec for SameSite/First-Party-Cookies (https://tools.ietf.org/html/draft-west-first-party-cookies-07) is a bit ambiguous.

Section 3.1 specifies that both "SameSite" and "SameSite=Strict" should both be accepted.

Section 3.2 specifies if the value is "Strict" or if the value is invalid then 
behave as if the enforcement policy is strict.

But Section 4.1 says if the attribute value is not "Strict" or "Lax" then ignore the cookie-av (does this mean ignore it entirely or just the attribute-value) ?

Given this ambiguity in the spec I think there needs to be clear documentation about what Chromium will and will not accept. I was not able to find any documentation on what Chromium accepted.