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
