Subject: [Cbor] 🔔 WGLC with request for reviews on cbor-file-magic-02

From: Christian Amsüss <[email-masked]>
Date: Fri, 16 Jul 2021 17:08:26 +0200

Hello CBOR group,

this mail marks the start of a two week WGLC on cbor-file-magic[1],
which will end at the CBOR meeting of IETF111.

While this document has been discussed during interims and seen two
mid-sized threads on the list, I'd appreciate any additional pair of
reviewing eyes before starting a shepherd write-up.

Everyone interested in this document, please have a look at the latest
version (it's just 8 pages of text), especially the recently added parts
on from tag-coap-content-format, and send questions, comments and
preferably a short review to this list.

Best regards,
Christian

[1]: https://datatracker.ietf.org/doc/draft-ietf-cbor-file-magic/

-- 
We are dreamers, shapers, singers, and makers.
  -- Elric

---

From: Barry Leiba <[email-masked]>
Date: Fri, 16 Jul 2021 11:23:15 -0400

Hello CBOR group,

This mail marks the start of a two week working group last call on
cbor-network-addresses[1], which will end at the CBOR meeting of
IETF111.

While this document has been discussed during interims and on the
list, the number of participants discussing it so far is small.  I'd
appreciate a few more reviews on this before we proceed with it.

Everyone, please have a look at the latest version  -- it's small,
just a few pages of actual content -- and post a review to the list.
Even, "I've reviewed it and it's ready to go," is useful.

Thanks,
Barry

[1]: https://datatracker.ietf.org/doc/draft-ietf-cbor-network-addresses/

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 17 Jul 2021 15:24:30 +1200

Hi,

This is by way of an implementation report. I have a demo implementation
of RFC8992 (Autonomic IPv6 Edge Prefix Management in Large-Scale Networks) and I just made a version of it that uses Tags 52 and 54 instead of the format defined in the RFC.
Up and running on this machine as I type. It only uses the 3rd format for each tag (address followed by prefix length) so it isn't a complete implementation, but anyway it works.**

Code at https://github.com/becarpenter/graspy/blob/master/pfxm4.py

So, I've reviewed the draft and it's ready to go.

Regards
   Brian Carpenter

** It says things like:
_MainThread 3532 IPv6 pool size 6 /64s 
_MainThread 3532 IPv4 pool size 10 /24s 
delegator 4948 1190 prefixes were delegated 
_MainThread 3532 IPv6 prefix pool is low, will ask for /61 
delegator 4948 1200 prefixes were delegated 
_MainThread 3532 Trying the only peer 
_MainThread 3532 Obtained 2001:db8:ffff:fde8::/61 
_MainThread 3532 IPv4 prefix pool is low, will ask for /20 
_MainThread 3532 Trying the only peer 
_MainThread 3532 Obtained 10.255.64.0/20 
_MainThread 3532 IPv6 pool size 7 /64s 
_MainThread 3532 IPv4 pool size 23 /24s 
delegator 4948 1220 prefixes were delegated 

On 17-Jul-21 03:23, Barry Leiba wrote:
> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor
>

---

From: Laurence Lundblade <[email-masked]>
Date: Sat, 17 Jul 2021 11:47:23 -0700

Read it and it seems fine to me.

I plan to add support for it to QCBOR, but due to other things on my list it will be a while.

LL

> On Jul 16, 2021, at 8:23 AM, Barry Leiba <[email-masked]> wrote:
> 
> Hello CBOR group,
>

---

From: Marco Tiloca <[email-masked]>
Date: Sat, 17 Jul 2021 20:57:04 +0200

Hi all,

I've reviewed the document and it looks good to me. Please, see below a 
few minor comments.

Best,
/Marco

[Section 1]

* The normative statement "Prefixes MUST omit ..." feels strange for the 
introduction, also as the recap of BCP14 terminology comes after that. I 
suggest to rather use "must omit" or even just "omit"; the intended 
normative text comes later on in Section 3.1 and 3.2 anyway.

[Section 3]

* Maybe some details can be made clearer in the third from last 
paragraph. For instance, it can be easier here to think only in terms of 
bit lengths. Proposed rephrasing

    "Then, taking whichever is smaller between the length in bits of the 
included byte-string and the prefix-length possibly rounded up to the 
next multiple of 8, copy that many bits from the byte-string into the 
array."

* I guess "of 8 values" should be "with value 8" ?

== Nits ==

[Section 1]

s/261 was later/261 were later

s/addressees/addresses

In the second and third paragraph, I suggest to use only "document" 
rather than "specification", consistently with the rest of the text.

In the third paragraph, please add a ',' after "testing" :-)

[Section 3]

s/can applied/can be applied

[Section 4]

s/otherewise/otherwise

[Section 5]

s/for implementation/for implementations

s/set it/and then set it

s/the lower bits, non/the lower, non

On 2021-07-16 17:23, Barry Leiba wrote:
> [1]: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-cbor-network-addresses%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C83296b46a4af4ff9edcb08d9486db2b2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637620458272270158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Ie2Pi5EFq5W2y8Yo2qtReGFTD3trXaYoqEOQND6GBTQ%3D&amp;reserved=0
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcbor&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C83296b46a4af4ff9edcb08d9486db2b2%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637620458272270158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=n8bmphDA%2F8ysNZ7gCtBMy0hClEj5hp4kpctHj7CYoXg%3D&amp;reserved=0

-- 
Marco Tiloca
Ph.D., Senior Researcher

Division: Digital System
Department: Computer Science
Unit: Cybersecurity

RISE Research Institutes of Sweden
https://www.ri.se

Phone: +46 (0)70 60 46 501
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 17 Jul 2021 22:31:45 +0200

Hi Marco,

Thank you for your quick and detailed comments.

> [Section 1]
> 
> * The normative statement "Prefixes MUST omit ..." feels strange for the introduction, also as the recap of BCP14 terminology comes after that. I suggest to rather use "must omit" or even just "omit"; the intended normative text comes later on in Section 3.1 and 3.2 anyway.

I like the simple “omit”.

> [Section 3]
> 
> * Maybe some details can be made clearer in the third from last paragraph. For instance, it can be easier here to think only in terms of bit lengths. Proposed rephrasing
> 
>    "Then, taking whichever is smaller between the length in bits of the included byte-string and the prefix-length possibly rounded up to the next multiple of 8, copy that many bits from the byte-string into the array."

People won’t know how to copy bits.

So here is my merged text:

Then taking whichever is smaller between (a) the length of the
included byte-string, and (b) the number of bytes covered by the
prefix-length rounded up to the next multiple of 8: fail if that
number is greater than 16 (or 4), and then copy that many bytes from
the byte-string into the array.

Might be easier in pseudocode :-)

> * I guess "of 8 values" should be "with value 8" ?

Well, I’d not use a static array of 8 values here (and why let the readers guess about that array?), I’d simply use 0xFF << unused_bits:

unused_bits = (-prefix_length_in_bits) & 7;
if (length_in_bytes > 0)
  address_bytes[length_in_bytes - 1] &= (0xFF << unused_bits);

Or if you want to check:

if (length_in_bytes > 0 &&
    (address_bytes[length_in_bytes - 1] & ~(0xFF << unused_bits))
    != 0)
  fail();

Writing a test for this code is left as an exercise for the reader :-)

I’m not sure we even want to cover the masking out case; we should tell people to fail on incorrectly set bits (i.e., tag is invalid).

> == Nits ==

(Done unless mentioned:)

> In the second and third paragraph, I suggest to use only "document" rather than "specification", consistently with the rest of the text.

I went the other direction (document ➔ specification).

> s/set it/and then set it

I rephrased this and the next nit as above.

Now in https://github.com/cbor-wg/cbor-network-address/pull/5

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Jul 2021 18:36:08 -0400

Brian E Carpenter <[email-masked]> wrote:
    > of RFC8992 (Autonomic IPv6 Edge Prefix Management in Large-Scale
    > Networks) and I just made a version of it that uses Tags 52 and 54
    > instead of the format defined in the RFC.

    > Up and running on this machine as I type. It only uses the 3rd format
    > for each tag (address followed by prefix length) so it isn't a complete
    > implementation, but anyway it works.**

I'm surprised in an address allocation ASA that you'd use interface format
rather than prefix format.

(as I write this, I realize that maybe we should name each format)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 18 Jul 2021 11:39:43 +1200

> rather than prefix format.

Pure laziness, because it meant less change to my code, given what we
specified in RFC8992. The prefix format would work fine, but I would
need to suppress the excess bytes. Next time I feel like a little
recreational programming, I can add that.
 
> (as I write this, I realize that maybe we should name each format)

Good idea.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Jul 2021 20:33:24 -0400

> Good idea.

https://github.com/cbor-wg/cbor-network-address/pull/6/files

New/adjusted text below, please comment on github.
I'm not sure about the ToC levels here.

## Three Forms

### Addresses

These tags can be applied to byte strings to represent a single address.

This form is called the Address Format.

### Prefixes

When applied to an array that starts with a number, they represent a
CIDR-style prefix of that length.

When an Address (byte string), i.e., without prefix) appears in a context where a prefix is expected, then it is to be assumed that all bits are relevant.
That is, for IPv4, a /32 is implied, and for IPv6, a /128 is implied.

This form is called the Prefix Format.

### Interface Definition

When applied to an array that starts with a byte string, that stands
for an IP address, followed by the bit length of a prefix built out of
the first `length` bits of the address.

This form is called the Interface Format, or Interface Definition.