Joel,
"is a Reserved bit for future use" contradicts with its definition in RFC8126
which says "Reserved: Not assigned and not available for assignment".
The text should be tweaked IMO to avoid that. For example,
OLD:
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.
NEW:
U: The U-bit is unassigned and available for future use. It MUST be set
to 0
on transmit and MUST be ignored on receipt.
Cheers,
Med
> -----Message d'origine-----
> De : Joel M. Halpern [mailto:[email protected]]
> Envoyé : mercredi 24 octobre 2018 15:15
> À : BOUCADAIR Mohamed TGI/OLN; Luigi Iannone; Dino Farinacci
> Cc : [email protected]
> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned
>
> Med, just to be clear. Ar eyou saying that we should change the word
> Reserved to Unasigned? THe text would read weirdly, but I can live with
> it. We need to keep the rest of the text, as it is critical for future
> interoperability.
>
> Yours,
> Joel
>
> On 10/24/18 5:24 AM, [email protected] wrote:
> > 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
> >
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
