To solve this issue, I suggest to add text to 7.2.  of 
draft-ietf-6lo-prefix-registration:

"

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Length    |F|PrefixLength |    Opaque     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | |C| P | I |R|T|     TID       |     Registration Lifetime     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
    ...             Registration Ownership Verifier                 ...
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 5: EARO Option Format in NS messages

   New and updated Option Fields:
<..>

   C:  1-bit flag; moved from its position in Figure 1 of [RFC8928], see
      Section 9.

"
And in section 9:
"
  [RFC8928] defines the "C" flag but fails to explicit the bit number
   and fails to make a IANA registration for that bit position.  On the
   other hand, a position for the bit (bit 3) is represented in Figure 1
   of [RFC8928].  [RFC9685] defines the P-Field in bits 2 and 3 of the
   EARO flags field, obtains a proper IANA registration, but causes an
   overlap with the representation in Figure 1 of [RFC8928].  This
   specification updates [RFC8928] to position the "C" flag as bit 1 of
   the EARO flag, as represented in Figure 5, to avoid the overlapping
   definitions.
"
And finally in the IANA section:
"
12.2.  Bit Position of the "C" Flag

   This specification updates the location of the "C" flag introduced in
   [RFC8928] to position it as bit 1 in the EARO flags.  IANA is
   requested to make an addition to the "Address Registration Option
   Flags" [IANA.ICMP.ARO.FLG] registry under the heading "Internet
   Control Message Protocol version 6 (ICMPv6) Parameters" as indicated
   in Table 3:

                 +---------------+----------+-----------+
                 | ARO flag      | Meaning  | Reference |
                 +---------------+----------+-----------+
                 | 1 (suggested) | "C" Flag | RFC 8928  |
                 +---------------+----------+-----------+

                  Table 3: Bit Position of the "C" Flag
"

Does that work?

All the best



-----Message d'origine-----
De : Pascal Thubert <pascal.thub...@gmail.com> 
Envoyé : jeudi 20 mars 2025 20:21
À : Errata System RFC <rfc-edi...@rfc-editor.org>
Cc : ek.i...@gmail.com; evyn...@cisco.com; shwetha.bhand...@gmail.com; 
carles.go...@upc.edu; adnanrashi...@gmail.com; 6lo@ietf.org; 
rfc-edi...@rfc-editor.org
Objet : Re: [6lo] [Technical Errata Reported] RFC9685 (8340)

Dear all

I’d suggest that the mistake is on RFC 8928 not this. 
The reason being that we failed at the time to ask for a IANA registration 
which would have allowed to detect the overlap.
This erratum would imply to change IANA but wouldn’t fix the missing entry…


A bientôt;

Pascal

> Le 20 mars 2025 à 14:52, RFC Errata System <rfc-edi...@rfc-editor.org> a 
> écrit :
> 
> The following errata report has been submitted for RFC9685, "Listener 
> Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid8340
> 
> --------------------------------------
> Type: Technical
> Reported by: Adnan Rashid <adnanrashi...@gmail.com>
> 
> Section: 7.1
> 
> Original Text
> -------------
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |     Type      |     Length    |    Status     |    Opaque     |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |Rsv| P | I |R|T|     TID       |     Registration Lifetime     |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                                                               |
> ...          Registration Ownership Verifier (ROVR)              ...
>  |                                                               |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Corrected Text
> --------------
>   0                   1                   2                   3
>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1  
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |     Type      |     Length    |    Status     |    Opaque     |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |R| P |C| I |R|T|     TID       |     Registration Lifetime     |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |                                                               |
> ...          Registration Ownership Verifier (ROVR)              ...
>  |                                                               |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Notes
> -----
> The EARO format in RFC 9685  (Figure 5) omits the C-flag, which was 
> previously defined in RFC 8928. This inconsistency could lead to issues in 
> implementation and interoperability. It is important to ensure that newer 
> standards respect and align with existing conventions.
> small "R" is a single unused/Reserved bit.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please use 
> "Reply All" to discuss whether it should be verified or rejected. When 
> a decision is reached, the verifying party will log in to change the 
> status and edit the report, if necessary.
> 
> --------------------------------------
> RFC9685 (draft-ietf-6lo-multicast-registration-19)
> --------------------------------------
> Title               : Listener Subscription for IPv6 Neighbor Discovery 
> Multicast and Anycast Addresses
> Publication Date    : November 2024
> Author(s)           : P. Thubert, Ed.
> Category            : PROPOSED STANDARD
> Source              : IPv6 over Networks of Resource-constrained Nodes
> Stream              : IETF
> Verifying Party     : IESG
> 
> _______________________________________________
> 6lo mailing list -- 6lo@ietf.org
> To unsubscribe send an email to 6lo-le...@ietf.org

_______________________________________________
6lo mailing list -- 6lo@ietf.org
To unsubscribe send an email to 6lo-le...@ietf.org

Reply via email to