Actually, given the existence of RFC 8126, varying from that
recommendation for the distinction between Reserved and Unassigned (by
which, what we mean is Unassigned) should only be done with very good
reason.
Yours,
Joel
On 10/25/18 11:04 AM, Dino Farinacci wrote:
It doesn’t *have to be* what 8126 is. It needs to be what we believe the the
unassigned bits are labeled.
Dino
On Oct 24, 2018, at 10:02 PM, <[email protected]>
<[email protected]> wrote:
Hi Dino,
Thank you.
I’m afraid that « reserved and unassigned » is still not appropriate (see 8126). Please change it with “unassigned and available for future use”.
Cheers,
Med
De : Dino Farinacci [mailto:[email protected]]
Envoyé : jeudi 25 octobre 2018 05:05
À : BOUCADAIR Mohamed TGI/OLN
Cc : Luigi Iannone; [email protected]
Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned
How about these changes? So we can not over complicate this.
Dino
On Oct 24, 2018, at 2:24 AM, <[email protected]>
<[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
