Subject: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned

From: <[email-masked]>
Date: Tue, 23 Oct 2018 07:44:50 +0000

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

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 23 Oct 2018 09:27:08 -0700

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-masked] wrote:
> 
> Hi Dino, all,
>  
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Luigi Iannone <[email-masked]>
Date: Wed, 24 Oct 2018 10:00:35 +0200

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-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 24 Oct 2018 09:24:11 +0000

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-masked]]
> Envoyé : mercredi 24 octobre 2018 10:01
> À : Dino Farinacci
> Cc : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned
> 
> Hi All,
> 
> 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”.
> > 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.
> >
> >> This is well handled in Section 5.1, but not in other sections which are
> using Reserved instead of Unassigned as per RFC8126.
> >>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Oct 2018 09:15:22 -0400

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

---

From: <[email-masked]>
Date: Wed, 24 Oct 2018 13:25:25 +0000

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: 
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

> De : Joel M. Halpern [mailto:[email-masked]]
> Envoyé : mercredi 24 octobre 2018 15:15
> À : BOUCADAIR Mohamed TGI/OLN; Luigi Iannone; Dino Farinacci
> Cc : [email-masked]

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 24 Oct 2018 09:26:41 -0400

As long as we keep the second sentence, I am flexible regarding the 
wording of the first one.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 24 Oct 2018 13:08:25 -0700

I believe to be crystal clear, we should use the text “reserved and unassigned” everywhere. I do not want to change names of bits or else they may clash with other fields.

Dino

> On Oct 24, 2018, at 6:25 AM, [email-masked] wrote:
> 
> Joel, 
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 24 Oct 2018 20:04:49 -0700

How about these changes? So we can not over complicate this.

Dino

> On Oct 24, 2018, at 2:24 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Luigi,
>

---

From: <[email-masked]>
Date: Thu, 25 Oct 2018 05:02:02 +0000

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-masked]]
Envoyé : jeudi 25 octobre 2018 05:05
À : BOUCADAIR Mohamed TGI/OLN
Cc : Luigi Iannone; [email-masked]
Objet : Re: [lisp] draft-ietf-lisp-rfc6833bis-19: Reserved/Unassigned

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 25 Oct 2018 08:04:22 -0700

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-masked]> <[email-masked]> wrote:
> 
> Hi Dino,
>  
> Thank you.
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 25 Oct 2018 11:09:04 -0400

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

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 25 Oct 2018 08:48:24 -0700

I don’t think there should be anything controversial with the changes I made. Can we move onto more pressing issues?

Dino

> On Oct 25, 2018, at 8:09 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> 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
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 25 Oct 2018 11:57:09 -0400

Is it a big deal?  No.
Is it likely someone will ask for it during IESG review?  Moderate.
Would I just do it in your shoes?  Yes.
Do you have to do it?  No.

Yours,
Joel

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 25 Oct 2018 09:01:42 -0700

Do you think what I added will be objected to?

Dino

> On Oct 25, 2018, at 8:57 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Is it a big deal?  No.

---

From: <[email-masked]>
Date: Mon, 29 Oct 2018 07:21:06 +0000

Hi Dino,

If I were the editor of the document, I would follow 8126.

Thank you. 

Cheers,
Med

> Envoyé : jeudi 25 octobre 2018 17:04
> > 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
> >
> > >> 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”:
> > >>

---

From: Luigi Iannone <[email-masked]>
Date: Mon, 29 Oct 2018 10:02:07 +0100

> On 25 Oct 2018, at 18:01, Dino Farinacci <[email-masked]> wrote:
> 

May be.

IMO The point is:

If you do not doing it now and someone complains you will slow down publication by weeks.

If you do it now you will spend 5 minutes and everybody will be happy.

Your call.

Ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 29 Oct 2018 08:32:55 -0700

Changing it to what? Be specific commenters.

Dino

> On Oct 29, 2018, at 2:02 AM, Luigi Iannone <[email-masked]> wrote:
> 
> 
>