Subject: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Mon, 10 Sep 2018 14:43:45 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

There are several issues in §5.1 (LISP Control Packet Type Allocations) that
need to be fixed.  I don't think any of them raise up to a DISCUSS, but I would
like to see them resolved before publication.

§5.1 "defines the LISP control message formats and summarizes for IANA the LISP
Type codes assigned by this document".

(1) Instructions (or anything directed) to IANA should be in the IANA
Considerations section.  There isn't even a pointer to this section later on
for IANA to look at it.

(2) The text seems to imply ("Message type definitions are") that the types are
defined here (or at least in rfc6833, which this document Obsoletes), but they
are defined in rfc6830, rfc8111 and rfc8113.  Please properly identify the
source (only the rfc8113 line has a reference).

(3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830, I
think that, because of how the contents of that RFC were distributed, this
document should also be tagged as Obsoleting rfc6830.

(4) The LISP Packet Types registry was set up in rfc8113.  This document asks
that IANA "refers to this document as well as [RFC8113] as references" (§11.2),
and it seems to try to change the registration (or the text is incomplete) in
(§5.1): "Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126]."  Which procedure?  s/Not Assigned/Unassigned (§6 in
rfc8126)

(5) Because of the point above, this draft should (at least) Update rfc8113
(see also below).

(6) This document says that "Protocol designers experimenting with new message
formats SHOULD use the LISP Shared Extension Message Type".  I think this
statement makes rfc8113 a Normative reference -- which results in a DownRef. 
Suggestion: given that this document already updates the registry set up in
rfc8113, and recommends the use of the Shared Extension Message, it may be a
good idea to simply adopt the contents of that document here (grand total of 6
pages) and declare it Obsolete.

(7) Type 7 is missing.

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 11 Sep 2018 11:15:32 +0200

Hi Alvaro,

thanks for your feedback.

See my comments inline and let us know what you think.

> On 10 Sep 2018, at 23:43, Alvaro Retana <[email-masked]> wrote:
> 

This can be easily fixed changing the first sentence to:

	This section defines the LISP control message formats and summarizes
   	for IANA the LISP Type codes assigned by this document (see details IANA considerations in Section 11).

What do you think?

> source (only the rfc8113 line has a reference).

Would it be sufficient to add a sentence listing the messages that this documents re-defines and the original RFC which is obsoleted?

> document should also be tagged as Obsoleting rfc6830.

Meaning that 6833bis obsoletes both 6830 and 6833?

> procedures in [RFC8126]."  Which procedure?  s/Not Assigned/Unassigned (§6 in

I think that there is some missing  text, and that most proper sentence would be:

	Note that according to [RFC8113] the LISP Packet Type values 7 and 9 to 14 can be assigned via Standards
   	Action [RFC5226 <https://tools.ietf.org/html/rfc5226>].

> pages) and declare it Obsolete.

Or just make a 8113bis standard track. The RFC Editor will hold the document until an RFC number is assigned to all normative references.

Having said that, I wonder if we really need that “SHOULD”. 
If I experiment with new messages and I make sure that nothing goes beyond my own deployment, why being constrained?
And what if (still isolating my experiment) for any reason I would like to play with the reserved bits of existing messages? How do I do it?
I would change the sentence in:
 
	The LISP Shared Extension Message is for experimentation purposes as described in [RFC8113 <https://tools.ietf.org/html/rfc8113>].

> (7) Type 7 is missing.

It is not assigned, and yes… should be stated (see above).

Ciao

L.

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 11 Sep 2018 10:05:03 -0400

On September 11, 2018 at 5:15:38 AM, Luigi Iannone ([email-masked]) wrote:

Luigi:

Hi!

Some comments below.  Thanks!

Alvaro.

Hi Alvaro,

There are several issues in §5.1 (LISP Control Packet Type Allocations) that
need to be fixed.  I don't think any of them raise up to a DISCUSS, but I
would
like to see them resolved before publication.

§5.1 "defines the LISP control message formats and summarizes for IANA the
LISP
Type codes assigned by this document".

 This section defines the LISP control message formats and summarizes
           for IANA the LISP Type codes assigned by this document (see
details IANA considerations in Section 11).

What do you think?

The main point is that is you want IANA to look at this text, then the best
way is to put it in the IANA Considerations section.  They may be ok with a
pointer the other way around: from Section 11 to this section (otherwise
they might not notice).

(2) The text seems to imply ("Message type definitions are") that the types
are
defined here (or at least in rfc6833, which this document Obsoletes), but
they
are defined in rfc6830, rfc8111 and rfc8113.  Please properly identify the
source (only the rfc8113 line has a reference).

Would it be sufficient to add a sentence listing the messages that this
documents re-defines and the original RFC which is obsoleted?

I just want the text to be clear about what is defined here and what
isn’t.  I think that references (like the one in there for rfc8113) would
be enough.

(3) Even though draft-ietf-lisp-rfc6830bis is tagged as Obsoleting rfc6830,
I
think that, because of how the contents of that RFC were distributed, this
document should also be tagged as Obsoleting rfc6830.

Yes.

(4) The LISP Packet Types registry was set up in rfc8113.  This document
asks
that IANA "refers to this document as well as [RFC8113] as references"
(§11.2),
and it seems to try to change the registration (or the text is incomplete)
in
(§5.1): "Values in the "Not Assigned" range can be assigned according to
procedures in [RFC8126]."  Which procedure?  s/Not Assigned/Unassigned (§6
in
rfc8126)

I think that there is some missing  text, and that most proper sentence
would be:

    Note that according to [RFC8113] the LISP Packet Type values 7 and
9 to 14 can be assigned via Standards
           Action [RFC5226 <https://tools.ietf.org/html/rfc5226>].

(6) This document says that "Protocol designers experimenting with new
message
formats SHOULD use the LISP Shared Extension Message Type".  I think this
statement makes rfc8113 a Normative reference -- which results in a
DownRef.
Suggestion: given that this document already updates the registry set up in
rfc8113, and recommends the use of the Shared Extension Message, it may be a
good idea to simply adopt the contents of that document here (grand total
of 6
pages) and declare it Obsolete.

Or just make a 8113bis standard track. The RFC Editor will hold the
document until an RFC number is assigned to all normative references.

Having said that, I wonder if we really need that “SHOULD”.
If I experiment with new messages and I make sure that nothing goes beyond
my own deployment, why being constrained?
And what if (still isolating my experiment) for any reason I would like to
play with the reserved bits of existing messages? How do I do it?

In general because you want to avoid squatting on code points, leaking,
etc..  We’ve seen cases in other WGs where experiments later became
mainstream and changing code points was then a huge pain.

In any case, I’m fine with the sentence below.

Thanks!!

Alvaro.

 The LISP Shared Extension Message is for experimentation purposes as
described in [RFC8113 <https://tools.ietf.org/html/rfc8113>].

(7) Type 7 is missing.

Ciao

L.

---

From: Luigi Iannone <[email-masked]>
Date: Tue, 11 Sep 2018 16:39:23 +0200

Hi Alvaro,

thanks for the reply. I think everything is clear. I need just one clarification:

> On 11 Sep 2018, at 16:05, Alvaro Retana <[email-masked]> wrote:
> 
> On September 11, 2018 at 5:15:38 AM, Luigi Iannone ([email-masked] <mailto:[email-masked]>) wrote:
>>> 
> The main point is that is you want IANA to look at this text, then the best way is to put it in the IANA Considerations section.  They may be ok with a pointer the other way around: from Section 11 to this section (otherwise they might not notice).
> 
>> 
>> 
>> 
>>> 
> I just want the text to be clear about what is defined here and what isn’t.  I think that references (like the one in there for rfc8113) would be enough.
> 
>> 

I think I’ve got now you point. What we should do is not modify section 5.1, is modifying section 11.2.
We should update the text and following table:
	Name                 Number          Defined in
        ----                 ------          -----------
        LISP Map-Notify-Ack  5               RFC6833bis

We should add there all the code points of messages that are re-defined in this document and ask IANA to update the registry so that the entries point to this document (and not anymore 6830).

Did I got it right?

Ciao

L.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Sep 2018 09:23:02 -0700

> https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/

Thanks for your comments Alvaro. See my responses below.

These are not instructions. The instructions are in the IANA Considerations section. And IANA already knows what to do and already have done so. So there is no confusion with them.

> source (only the rfc8113 line has a reference).

It means exactly what it says. Only type 15 extensions are defined in 8113. I have added text that this document, RFC6833bis does obsolete both 6830 and 6833.

> document should also be tagged as Obsoleting rfc6830.

Done.

> procedures in [RFC8126]."  Which procedure?  s/Not Assigned/Unassigned (§6 in

The early values are already registered with IANA. This document is asking to register the new ones which include type 15. And the values *within* type 15 are documented in RFC8113.

> (5) Because of the point above, this draft should (at least) Update rfc8113

Don’t follow.

> pages) and declare it Obsolete.

I’m yielding to the lisp-chairs and Deborah for this one.

> (7) Type 7 is missing.

Fixed.

Thanks again,
Dino

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 24 Sep 2018 15:33:30 +0000

On September 11, 2018 at 12:23:04 PM, Dino Farinacci ([email-masked])
wrote:

Hi!

I’m back to this document…after the Defer...

...

Done.

The text is there, but the tag in the header is missing ("Obsoletes: 6833
(if approved)”).

asks
(§11.2),
in
> rfc8126)

The early values are already registered with IANA. This document is asking
to register the new ones which include type 15. And the values *within*
type 15 are documented in RFC8113.

The only place where I see type 15 referenced is in §5.1.  If that section
is "asking to register the new ones which include type 15”, then these are
instructions to IANA.

Regardless, a pointer from §11.2 to §5.1 won’t hurt the document.

Don’t follow.

This document asks that the LISP Packet Type registry point also to this
registry.  That is a change to the registry, which was defined in rfc8113
(which is the only current reference).  Updating the registry this way
should be signaled with an update to rfc8113 in this document.

message
DownRef.
of 6

I see that there’s a WG adoption call for rfc8113bis.  That’s fine with me
— but I still think that the reference should be normative.

Thanks!

Alvaro.

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 24 Sep 2018 10:38:57 -0700

Alvaro, I don’t know what you want to be satisified with the text. And rather than go 20 questions, with weeks of turn-around time, can you offer text please?

Dino

> On Sep 24, 2018, at 8:33 AM, Alvaro Retana <[email-masked]> wrote:
> 
> On September 11, 2018 at 12:23:04 PM, Dino Farinacci ([email-masked]) wrote:
> 
> Hi!
> 
> The text is there, but the tag in the header is missing ("Obsoletes: 6833 (if approved)”).
> 
> 
> 
> The only place where I see type 15 referenced is in §5.1.  If that section is "asking to register the new ones which include type 15”, then these are instructions to IANA.
> 
> This document asks that the LISP Packet Type registry point also to this registry.  That is a change to the registry, which was defined in rfc8113 (which is the only current reference).  Updating the registry this way should be signaled with an update to rfc8113 in this document.
> 
> 
> 
> I see that there’s a WG adoption call for rfc8113bis.  That’s fine with me — but I still think that the reference should be normative.
> 
> Thanks!
> 
> Alvaro.
>

---

From: <[email-masked]>
Date: Tue, 25 Sep 2018 09:22:34 +0000

Hi Dino, 

I think that Alvaro has a valid point about rfc8113bis to be cited as normative. 

This is easy to fix, IMO. Thanks.  

Cheers,
Med

> -----Message d'origine-----
> De : lisp [mailto:[email-masked]] De la part de Dino Farinacci
> Envoyé : lundi 24 septembre 2018 19:39
> À : Alvaro Retana
> Cc : [email-masked]; The IESG; [email-masked];
> [email-masked]
> Objet : Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-
> rfc6833bis-13: (with COMMENT)
> 
> Alvaro, I don’t know what you want to be satisified with the text. And rather
> than go 20 questions, with weeks of turn-around time, can you offer text
> please?
> 
> Dino
> 
> to register the new ones which include type 15. And the values *within* type
> 15 are documented in RFC8113.
> (which is the only current reference).  Updating the registry this way should
> be signaled with an update to rfc8113 in this document.
> >
> >
> >
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Sep 2018 09:03:10 -0700

That is not the part I had a problem with. Consider it added.

Dino

> On Sep 25, 2018, at 2:22 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Dino, 
>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Tue, 25 Sep 2018 20:10:05 +0000

As Alvaro suggested, we could have incorporated all of RFC8113 here, and obsolete it. But it also is ok as a standalone. The group wanted to continue with it as a standalone. I think though we need to be clear on the relationships. I think Dino is right, RFC8113 is only (and should be only) informative here. There are some inter-relationships which we should clarify in this document and 8113bis. Also need to clarify a bit more what is to be done in the IANA section - I'm sure IANA will do ok - but it will make it clearer for others.

(Thanks Alvaro!!!)

Section 5.1
=========
OLD
For completeness, this document references the LISP Shared Extension Message assigned by [RFC8113].
NEW
For completeness, the summary below includes the LISP Shared Extension Message assigned by [RFC8113].
OLD
Values in the "Not Assigned" range can be assigned according to procedures in [RFC8126].  Documents that request for a new LISP packet type may indicate a preferred value.
NEW
Values in the "Not Assigned" range can be assigned according to procedures in [RFC8113].
(Deborah: 8113 set up the guidelines for the unassigned, the reader should refer to it. This will answer Alvaro's question on the procedures. Hint for Alvaro: unassigned is done via standards action.)
OLD
Protocol designers experimenting with new message formats SHOULD use the LISP Shared Extension Message Type and request a [RFC8113] sub-type assignment.
NEW
Protocol designers experimenting with new message formats are recommended to use the LISP Shared Extension Message Type [RFC8113].
(Deborah: I think this sentence could be deleted, but if want to keep, I think it should not be "normative")

LISP Packet Type Codes
===================
* For authors of RFC8113bis: need to add to 8113bis "updates 6833bis"
Suggest:
OLD
It is being requested that the IANA be authoritative for LISP Packet Type definitions and that it refers to this document as well as [RFC8113] as references.
New
It is being requested that the IANA be authoritative for LISP Packet Type definitions and it is requested to replace the [RFC6830] registry message references with the RFC number assigned to this document.

OLD
message type 5, was added to this document NEW message type 5,
NEW
message type 5, was added by this document NEW message type 5,

LISP ACT and Flag Fields
====================
OLD
Four values have already been allocated by [RFC6830].  
NEW
Four values have already been allocated by [RFC6830], IANA is requested to replace the [RFC6830] reference for this registry with the RFC number assigned to this document and the [RFC6830] Action values references with the RFC number assigned to this document.

-----Original Message-----
From: iesg <[email-masked]> On Behalf Of Dino Farinacci
Sent: Tuesday, September 25, 2018 12:03 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]; Alvaro Retana <[email-masked]>
Subject: Re: [lisp] Alvaro Retana's No Objection on draft-ietf-lisp-rfc6833bis-13: (with COMMENT)

Dino

>> Envoyé : lundi 24 septembre 2018 19:39 À : Alvaro Retana Cc : 
>> [email-masked]; The IESG; [email-masked];
>> [email-masked]
>> Alvaro, I don’t know what you want to be satisified with the text. 
>> And rather than go 20 questions, with weeks of turn-around time, can 
>> you offer text please?
>> 
>> Dino
>> 
>>>>> think that, because of how the contents of that RFC were 
>>>>> distributed,
>> this
>>>>> (§5.1): "Values in the "Not Assigned" range can be assigned 
>>>>> according to procedures in [RFC8126]." Which procedure? s/Not 
>>>>> Assigned/Unassigned (§6
>> in
>>>>> rfc8126)
>>>> 
>> is "asking to register the new ones which include type 15”, then 
>> these are instructions to IANA.
>>> 
>>>>> (5) Because of the point above, this draft should (at least) 
>>>>> Update
>> rfc8113
>>>>> (see also below).
>>>> 
>>>> Don’t follow.
>> registry.  That is a change to the registry, which was defined in 
>> rfc8113 (which is the only current reference).  Updating the registry 
>> this way should be signaled with an update to rfc8113 in this document.
>>> 
>>> 
>>> 
>>>>> formats SHOULD use the LISP Shared Extension Message Type". I 
>>>>> think this statement makes rfc8113 a Normative reference -- which 
>>>>> results in a
>> DownRef.
>>>>> Suggestion: given that this document already updates the registry 
>>>>> set up
>> in
>>>>> rfc8113, and recommends the use of the Shared Extension Message, 
>>>>> it may
>> be a
>>>>> good idea to simply adopt the contents of that document here 
>>>>> (grand
>> total of 6
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>> lman_listinfo_lisp&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7
>> jYlxXD8w&m=oId2sNzdWAJ97tLbuZUKthdnDylZ3Imi2N7zYcMdkbc&s=5h76BQw8IAJV
>> MN23ujgggCFwRXldKTwkRTWpxrH-_Mk&e=

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Sep 2018 13:41:37 -0700

I’ll add the suggested text. Queued up for draft-ietf-lisp-rfc6833bis-16.

Thanks,
Dino

> On Sep 25, 2018, at 1:10 PM, BRUNGARD, DEBORAH A <[email-masked]> wrote:
>