Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
This email just to summarize conclusions to the list. Esko Dijk wrote: >> I don't think that we should make this extensible via IANA registry. >> Any update will mostly have to Amend this document, probably it will have to >> obsolete it. > I don't have a strong preference here. Relying on a future follow-up > document to Amend it, or Obsolete it in a responsible way, seems > fine. So we have to decide whether to keep the registry or remove it - > topic for the call today! We have concluded this morning that we would use: mcr> 3) receiver can process first five items as they are, and new items mcr> can be placed after the payload, which older receivers are told mcr> to ignore. > For using the current single-array structure, my preference is > (3). Doing (2) seems risky from an implementation perspective. In > today's Agile SW world, people don't consider tomorrow's change so much > in today's code. Because they're supposed to only consider that in > tomorrow's code. But as we know today's code isn't always maintained > anymore when tomorrow comes ;)Identifying the particular risk here > is left as an exercise to the reader. We need to write text that says that receivers should: 1) check for >= 5 items. 2) always copy all items into the reply (but update the content/payload) We discussed using instead of IP + family. (it will shortly be RFC 9164 , not in AUTH48). It would cost 1 byte more. if we don't, we concluded, for family to use: https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xhtml -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
> I don't think that we should make this extensible via IANA registry.
> Any update will mostly have to Amend this document, probably it will have to
> obsolete it.
I don't have a strong preference here. Relying on a future follow-up document
to Amend it, or Obsolete it in a responsible way, seems fine. So we have to
decide whether to keep the registry or remove it - topic for the call today!
> Of these, I have a slight preference for (2) over (3).
> I don't like (1) at all.
For using the current single-array structure, my preference is (3). Doing (2)
seems risky from an implementation perspective. In today's Agile SW world,
people don't consider tomorrow's change so much in today's code. Because
they're supposed to only consider that in tomorrow's code. But as we know
today's code isn't always maintained anymore when tomorrow comes ;)
Identifying the particular risk here is left as an exercise to the reader.
> If we really need extensibility, then I would suggest we consider instead:
On your CDDL proposal: using a map here doesn't seem necessary. We need to
limit the overhead of the JPY message to the absolute minimum - it may be
transported over 6lowpan links, where the DTLS packet size may be near the 1280
byte limit. Then there's hardly any space to add more JPY header...
If we really want a clear separation of Header and Content, which isn't the
case in the current draft, then we could use 2 arrays:
[
[
ip : bstr,
port: int,
family : int,
index : int
payload : bstr
],
payload : bstr
]
Only the embedded array (Header field) is extendible in length. Doing this
approach adds only 1 byte to the JPY message size; examples:
[h'FE80C0A801C8', 48551, 6, 0, h'0011'] --- 26
bytes ; what's currently specified
[[h'FE80C0A801C8', 48551, 6, 0], h'0011'] --- 27
bytes ; above dual array proposal
[{0:h'FE80C0A801C8', 1:48551, 2:6, 3:0}, h'0011'] --- 31
bytes ; the smallest possible 'map' approach.
But I'm also ok with a single-array structure if we choose the approach (3)
i.e. any extensions come *after* the payload element.
Esko
-Original Message-
From: Anima On Behalf Of Michael Richardson
Sent: Wednesday, December 1, 2021 19:32
To: anima@ietf.org
Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt
/ Section 9 proposed text
Esko Dijk wrote:
> 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.
Arrays are not as easily extensible as maps.
Receivers can't just ignore keys that they don't know.
Fortunately, it's CBOR, so things that the receiver doesn't know about can be
skipped, assuming they implement enough of CBOR.
{Right now, we have bstr, and int. The enclosing array can be open-coded as
a test for 0x85. Or processed as an array. No map, tstr, etc. code needed}
I don't think that we should make this extensible via IANA registry.
Any update will mostly have to Amend this document, probably it will have to
obsolete it. I don't think we can easily accomodate multiple documents
asking for a code.
There are three ways we can extend this array:
1) receiver can see that new array has 6+ elements, and then
can assume the "new" format. That could involve completely
changing the order of what is there.
2) receiver can process first four items as they are, and then
process the last element as the payload.
Anything between the fourth element and the payload would be
ignored in this version, but future versions put new things there.
3) receiver can process first five items as they are, and new items
can be placed after the payload, which older receivers are told
to ignore.
Of these, I have a slight preference for (2) over (3).
I don't like (1) at all.
Just remind other readers:
[
ip : bstr,
port: int,
family : int,
index : int
payload : bstr
]
If we really need extensibility, then I would suggest we consider instead:
JPY_message =
[
details : { ip : bstr,
port: int,
family : int,
index : int },
payload : bstr
]
{please forgive my poor CDDL here}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
Esko Dijk wrote:
> 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.
Arrays are not as easily extensible as maps.
Receivers can't just ignore keys that they don't know.
Fortunately, it's CBOR, so things that the receiver doesn't know about can be
skipped, assuming they implement enough of CBOR.
{Right now, we have bstr, and int. The enclosing array can be open-coded as
a test for 0x85. Or processed as an array. No map, tstr, etc. code needed}
I don't think that we should make this extensible via IANA registry.
Any update will mostly have to Amend this document, probably it will have to
obsolete it. I don't think we can easily accomodate multiple documents
asking for a code.
There are three ways we can extend this array:
1) receiver can see that new array has 6+ elements, and then
can assume the "new" format. That could involve completely
changing the order of what is there.
2) receiver can process first four items as they are, and then
process the last element as the payload.
Anything between the fourth element and the payload would be
ignored in this version, but future versions put new things there.
3) receiver can process first five items as they are, and new items
can be placed after the payload, which older receivers are told
to ignore.
Of these, I have a slight preference for (2) over (3).
I don't like (1) at all.
Just remind other readers:
[
ip : bstr,
port: int,
family : int,
index : int
payload : bstr
]
If we really need extensibility, then I would suggest we consider instead:
JPY_message =
[
details : { ip : bstr,
port: int,
family : int,
index : int },
payload : bstr
]
{please forgive my poor CDDL here}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
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 -Original Message- From: Michael Richardson Sent: Wednesday, November 24, 2021 19:00 To: Esko Dijk ; anima@ietf.org; Peter van der Stok Subject: Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text Esko Dijk 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 , Sandelman Software Works -= IPv6 IoT consulting =- ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
Esko Dijk 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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] I-D Action: draft-ietf-anima-constrained-join-proxy-05.txt / Section 9 proposed text
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 NameCBOR Type Description = == === 0 ip byte string Pledge IPv4/IPv6 link-local address (4 or 16 bytes) 1 portinteger 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 On Behalf Of internet-dra...@ietf.org Sent: Monday, October 18, 2021 14:12 To: i-d-annou...@ietf.org Cc: anima@ietf.org 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 Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
