diff --git a/draft-ietf-gnap-core-protocol.md b/draft-ietf-gnap-core-protocol.md
index 6ab7046..a5a89be 100644
--- a/draft-ietf-gnap-core-protocol.md
+++ b/draft-ietf-gnap-core-protocol.md
@@ -82,7 +82,6 @@ normative:
 
 informative:
     RFC4107:
-    RFC5652:
     RFC6202:
     RFC6973:
     RFC7518:
@@ -6147,7 +6146,7 @@ the RS whose focus is to provide an API or the client software whose focus is to
 ## Symmetric and Asymmetric Client Instance Keys {#security-symmetric}
 
 Many of the cryptographic methods used by GNAP for key-proofing can support both asymmetric and symmetric
-cryptography, and can be extended to use a wide variety of mechanisms.
+cryptography, and can be extended to use a wide variety of mechanisms. 
 Implementers will find useful the available guidelines on cryptographic key management provided in {{RFC4107}}. While symmetric
 cryptographic systems have some benefits in speed and simplicity, they have a distinct drawback
 that both parties need access to the same key in order to do both signing and verification of
@@ -6155,7 +6154,7 @@ the message.
 When more than two parties share the same symmetric key,
 data origin authentication is not provided.  Any party that knows the
 symmetric key can compute a valid MAC; therefore, the
-contents could originate from any one of the parties (see {{RFC5652}} for further discussion).
+contents could originate from any one of the parties.
 
 Use of symmetric cryptography means that when the client instance calls the AS to request a token, the
 AS needs to know the exact value of the client instance's key (or be able to derive it) in