As long as we keep the second sentence, I am flexible regarding the
wording of the first one.
Yours,
Joel
On 10/24/18 9:25 AM, [email protected] wrote:
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
