Hi Luigi,
Fully agree that changing the text and updating the figures would be
appropriate.
Please note that a similar action is needed for draft-ietf-lisp-rfc6830bis-24,
e.g.,
R: The R-bit is a Reserved bit for future use. It MUST be set to 0
on transmit and MUST be ignored on receipt.
Cheers,
Med
> -----Message d'origine-----
> De : Luigi Iannone [mailto:[email protected]]
> Envoyé : mercredi 24 octobre 2018 10:01
> À : Dino Farinacci
> Cc : BOUCADAIR Mohamed TGI/OLN; [email protected]
> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned
>
> Hi All,
>
> disclaimer: this is my personal point of view.
>
> I didn’t catch before this part of RFC 8126. Thanks Med from bringing it up.
>
> While I understand Dino’s reply, because I my self as well always thought
> “reserved = can be used in the future”, I think that Med is right.
>
> To be compliant with RFC 8126, and because we may need those “reserved” bits
> in the future, we better mark them as “unassigned”.
> This means changing the text and clearly spell out that this is conform to
> RFC 8126 definitions.
>
> At the end, it is as simple as adding the following sentence in section 2
> “Requirements Notation”:
>
> The “Unassigned” and “Reserved” terminology for bits and fields of
> messages and headers defined in this documents is the Well-Known
> Registration Status Terminology defined in Section 6 of [RFC8126].
>
>
> Then we just replace “reserved” with “unassigned” throughout the document.
>
> Ciao
>
> L.
>
>
>
> > On 23 Oct 2018, at 18:27, Dino Farinacci <[email protected]> wrote:
> >
> > I am not sure if we should make this distinction. What does the WG think?
> Because fields marked “reserved” are obviously unassigned and don’t know if
> they will be assigned in the future.
> >
> > So I am not sure how helpful in making the distinction.
> >
> > Dino
> >
> >> On Oct 23, 2018, at 12:44 AM, [email protected] wrote:
> >>
> >> Hi Dino, all,
> >>
> >> Apologies for raising this late easy to fix comment:
> >>
> >> RFC8126 says the following:
> >>
> >> Unassigned: Not currently assigned, and available for assignment
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> via documented procedures. While it's generally clear that
> >> any values that are not registered are unassigned and
> >> available for assignment, it is sometimes useful to
> >> explicitly specify that situation. Note that this is
> >> distinctly different from "Reserved".
> >>
> >> Reserved: Not assigned and not available for assignment.
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> Reserved values are held for special uses, such as to extend
> >> the namespace when it becomes exhausted. "Reserved" is also
> >> sometimes used to designate values that had been assigned
> >> but are no longer in use, keeping them set aside as long as
> >> other unassigned values are available. Note that this is
> >> distinctly different from "Unassigned".
> >>
> >> This is well handled in Section 5.1, but not in other sections which are
> using Reserved instead of Unassigned as per RFC8126.
> >>
> >> It would be appropriate to update the text accordingly. Thank you.
> >>
> >> Cheers,
> >> Med
> >> _______________________________________________
> >> lisp mailing list
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/lisp
> >
> > _______________________________________________
> > lisp mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
