Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text

From: Esko Dijk <[email-masked]>
Date: Wed, 24 Nov 2021 13:37:36 +0000

Hello,

Based on my earlier review comments: see below Section 9 proposed text.  It adds these elements that I think are missing in the current -05 text. I hope that clarifies it.
Also it refers to an existing IANA policy from RFC 8126.

---
9.  IANA Considerations

9.1 Registry for JPY protocol header fields

   This document defines a new IANA registry for map indices of the CBOR
   Map used in the JPY protocol.  The IANA policy for registration of an entry
   in the registry is "IETF Review" as defined by [RFC 8126]. A new registry entry
   MUST define the fields Map Index, Name, CBOR Type (referring to [RFC 8949] 
   defined types), and Description.

  The initial contents of the registry are as follows:

  Map Index	Name		CBOR Type	Description
  ========= 	==========	===========	========================================
  0		ip		byte string	Pledge IPv4/IPv6 link-local address (4 or 16 bytes)
  1		port		integer  	Pledge's UDP port number
  2		family		integer		IP address family; IPv4 (value 4) or IPv6 (value 6)
  3		index		integer       	Join Proxy network interface index/identifier
  4		payload		byte string	DTLS message payload

---

-----Original Message-----
From: Anima <[email-masked]> On Behalf Of [email-masked]
Sent: Monday, October 18, 2021 14:12
To: [email-masked]
Cc: [email-masked]
Subject: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF.

        Title           : Constrained Join Proxy for Bootstrapping Protocols
        Authors         : Michael Richardson
                          Peter van der Stok
                          Panos Kampanakis
	Filename        : draft-ietf-anima-constrained-join-proxy-05.txt
	Pages           : 19
	Date            : 2021-10-18

Abstract:
   This document defines a protocol to securely assign a Pledge to a
   domain, represented by a Registrar, using an intermediary node
   between Pledge and Registrar.  This intermediary node is known as a
   "constrained Join Proxy".

   This document extends the work of [RFC8995] by replacing the Circuit-
   proxy between Pledge and Registrar by a stateless/stateful
   constrained (CoAP) Join Proxy.  It relays join traffic from the
   Pledge to the Registrar.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-anima-constrained-join-proxy/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-anima-constrained-join-proxy-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-constrained-join-proxy-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
Anima mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/anima

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Nov 2021 13:00:25 -0500

Esko Dijk <[email-masked]> wrote:
    > Based on my earlier review comments: see below Section 9 proposed text.
    > It adds these elements that I think are missing in the current -05
    > text. I hope that clarifies it.  Also it refers to an existing IANA
    > policy from RFC 8126.

At first, I was all... "how did we miss this".
But, back in section 5.3, JPY_Message was defined as an *array* not a map, so
there are no indexes to manage in an IANA registry.
(Or rather, the indexes are implicit, maybe)

Maybe we can text making this more explicit?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Esko Dijk <[email-masked]>
Date: Mon, 29 Nov 2021 09:54:17 +0000

Good point; these are not CBOR map keys because it's not a map but an array. But still, for an array, the indices could be managed in an IANA registry for the JPY protocol. This allows future documents to add new map indices to the registry. An alternative is not to create a registry at all but just allow an RFC to update the array with 1 or more indices. I don't have a preference for one of these solutions.

In case we go for the registry solution still, the name 'Map index' needs to be changed to 'Array index' in the text that I proposed.

For extendibility it would be good to add a sentence in the stateful JPY protocol description that any additional array elements (i.e., not specified by current document) MUST be ignored by a receiver if it doesn't know these elements. This allows evolution of the protocol while maintaining backwards-compatibility. And a version number isn't needed; that number is defined by the length of the array ;-)

Best regards
Esko