This email just to summarize conclusions to the list.

Esko Dijk <[email protected]> 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 <draft-ietf-cbor-network-addresses-13.txt> 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  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [


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



Attachment: signature.asc
Description: PGP signature

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

Reply via email to