diff --git a/README.md b/README.md
index 3fa06aa..3ef77dc 100644
--- a/README.md
+++ b/README.md
@@ -22,8 +22,8 @@ The JS API will be a convenience for analytics reporting and may be used to make
 ASIDE: the JS API for CPU Cores is already available via hardwareConcurrency API
 
 ### The Header
-Proposed Client Hints Header for memory: `Device-Memory`\
-`Device-Memory : <value>`\
+Proposed Client Hints Header for memory: `Sec-CH-Device-Memory`\
+`Sec-CH-Device-Memory : <value>`\
 where `<value>` is an approximation of the amount of RAM in GiB (floating point number).\
 The `<value>` is calculated by using the actual device memory in MiB then rounding it to the nearest number where only the most significant bit can be set and the rest are zeros (nearest power of two). Then dividing that number by 1024.0 to get the value in GiB.
 
@@ -48,7 +48,7 @@ HTTP caching doesn't deal well with mixed value headers, therefore separate head
 
 #### When is the header sent?
 Client Hints cannot be used to enable providing network performance data on the first request, however this is being actively addressed with [this proposal](https://github.com/httpwg/http-extensions/issues/306#issuecomment-283549512).
-The header is sent after an explicit per-origin opt-in via Client Hints mechanism. The following new hint will be added: `Accept-CH: Device-Memory`
+The header is sent after an explicit per-origin opt-in via Client Hints mechanism. The following new hint will be added: `Accept-CH: Sec-CH-Device-Memory`
 
 For background, [Client Hints](http://httpwg.org/http-extensions/client-hints.html) provides a set of HTTP request header fields, known as Client Hints, to deliver content that is optimized for the device. In that sense using Client Hints is a great fit for this proposal.
 Client Hints recently addressed a [significant limitation in spec](https://github.com/httpwg/http-extensions/issues/306#issuecomment-283549512): opt-in can now be persisted across browser restarts using `max-age` in header.
@@ -56,13 +56,13 @@ Client Hints recently addressed a [significant limitation in spec](https://githu
 #### Usage Guidance
 Servers can advertise support for Client Hints using the Accept-CH header field or an equivalent HTML meta element with http-equiv attribute
 ```
-  Accept-CH = Device-Memory
+  Accept-CH = Sec-CH-Device-Memory
 ```
 
 The Memory request header field is a number for the client’s device memory i.e. approximate amount of ram in GiB.
 eg. 512 MiB will be reported as:
 ```
-  Device-Memory: 0.5
+  Sec-CH-Device-Memory: 0.5
 ```
 
 Servers can use this header to customize content for low memory device eg. serve light version of the app or a component such as a video player.
diff --git a/index.bs b/index.bs
index 2b0cbee..42d06d7 100644
--- a/index.bs
+++ b/index.bs
@@ -59,15 +59,15 @@ Device memory is an especially useful signal for determining “device-class”.
 
 Usage Example {#example}
 ------------------------
-A server opts-in to receive a `Device-Memory` client hint [[!CLIENT-HINTS]] using the `Accept-CH` header field, or an equivalent HTML meta element with http-equiv attribute:
+A server opts-in to receive a `Sec-CH-Device-Memory` client hint [[!CLIENT-HINTS]] using the `Accept-CH` header field, or an equivalent HTML meta element with http-equiv attribute:
 <pre class="highlight">
-    Accept-CH: Device-Memory
+    Accept-CH: Sec-CH-Device-Memory
 </pre>
 
-In turn, on receiving the above preferences from the server, a compatible user agent would then advertise the device capability for memory, via the `Device-Memory` request header field:
+In turn, on receiving the above preferences from the server, a compatible user agent would then advertise the device capability for memory, via the `Sec-CH-Device-Memory` request header field:
 <pre class="highlight">
     GET /example HTTP/1.1
-    Device-Memory: 0.5
+    Sec-CH-Device-Memory: 0.5
     ...
 </pre>
 
@@ -76,10 +76,10 @@ Device Memory (Client Hint) Header Field {#sec-device-memory-client-hint-header}
 
 The Device Memory header field is a [[CLIENT-HINTS]] header.
 It is a [=structured header value=] containing an [=item=] which value is a [=decimal=] that indicates the client’s device memory, i.e. the approximate amount of RAM in GiB.
-The ABNF (Augmented Backus-Naur Form) syntax for the `Device-Memory` header field is as follows:
+The ABNF (Augmented Backus-Naur Form) syntax for the `Sec-CH-Device-Memory` header field is as follows:
 
 ~~~ abnf
-  Device-Memory = sf-decimal
+  Sec-CH-Device-Memory = sf-decimal
 ~~~
 
 <h3 dfn>Computing Device Memory Value</h3>
@@ -89,19 +89,19 @@ An upper bound and a lower bound should be set on the list of values.
 
     NOTE: While implementations may choose different values, the recommended upper bound is 8GiB and the recommended lower bound is 0.25GiB (or 256MiB).
 
-If Device-Memory header field occurs in a message more than once, the last value overrides all previous occurrences.
+If `Sec-CH-Device-Memory` header field occurs in a message more than once, the last value overrides all previous occurrences.
 
 
 <h3 dfn>Examples</h3>
 
 512 MiB will be reported as:
 <pre class="highlight">
-    Device-Memory: 0.5
+    Sec-CH-Device-Memory: 0.5
 </pre>
 
 1000 MiB will be reported as:
 <pre class="highlight">
-    Device-Memory: 1
+    Sec-CH-Device-Memory: 1
 </pre>
 
 A full list of possible values should be as follows: 0.25, 0.5, 1, 2, 4, 8
@@ -126,7 +126,7 @@ WorkerNavigator includes NavigatorDeviceMemory;
 
 Security Considerations {#sec-security-considerations}
 =======================================
-Device-Memory Client Hint header and JS API will only be available to HTTPS secure contexts.  
+`Sec-CH-Device-Memory` Client Hint header and JS API will only be available to HTTPS secure contexts.  
 
 Device identification and classification (e.g. device type and class) based on advertised User-Agent, and other characteristics of the client, are commonly used to select and provide optimized content. Such solutions frequently rely on commercial device databases, which are costly, hard to integrate, and hard to maintain. This specification defines a mechanism to obtain device memory capability that addresses these technical challenges.
 
@@ -134,13 +134,13 @@ To reduce fingerprinting risk, reported value is rounded to single most signific
 
 IANA considerations {#iana}
 ===================
-This document defines the `Device-Memory` HTTP request header field, and registers them in the permanent message header field registery ([[RFC3864]]).
+This document defines the `Sec-CH-Device-Memory` HTTP request header field, and registers them in the permanent message header field registery ([[RFC3864]]).
 
-Device-Memory Header field {#iana-device-memory}
+Sec-CH-Device-Memory Header field {#iana-device-memory}
 ---------------------------------
 
 : Header field name
-:: Device-Memory
+:: Sec-CH-Device-Memory
 
 : Applicable protocol
 :: http