Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

Hi Med,

That looks fine to me. Thanks!

Regards
   Brian Carpenter

On 2019-01-10 20:42, mohamed.boucad...@orange.com wrote:
> Hi Brian, all,
> 
> The changes are now available online: 
> https://tools.ietf.org/html/draft-ietf-lisp-rfc8113bis-02 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc8113bis-02
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
>> Envoyé : vendredi 21 décembre 2018 07:57
>> À : Dino Farinacci; Brian E Carpenter
>> Cc : Joel M. Halpern; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
>> rfc8113bis@ietf.org
>> Objet : RE: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>
>> Re-,
>>
>> Seems we are all in agreement.
>>
>> I implemented the changes to 8113bis in my local copy.
>>
>> Thank you, Brian.
>>
>> Cheers,
>> Med
>>
>>> -Message d'origine-
>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>> Envoyé : vendredi 21 décembre 2018 00:29
>>> À : Brian E Carpenter
>>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-...@ietf.org;
>>> lisp@ietf.org; draft-ietf-lisp-rfc8113bis@ietf.org
>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>>
>>>> On 2018-12-21 09:18, Dino Farinacci wrote:
>>>>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine
>> with
>>> that. That reference being at the top of the draft saying “Updates
>> 6833bis”.
>>> If we remove that, he may concur. Please confirm Brian (again).
>>>>
>>>> Yes, that would resolve my concern.
>>>
>>> Thanks.
>>>
>>>>> Like I have mentioned to you before, the IETF “Updates” lingo is
>> confusing
>>> and really not useful unless a draft replaces a previous draft. And this is
>>> not the case here.
>>>>
>>>> That's a debate for the RFC-interest list perhaps. IMHO the issue is that
>>> "Updates" sometimes means "Extends" and sometimes means "Modifies".
>>> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to
>>> create confusion.
>>>
>>> Then maybe those words should be used.
>>>
>>> Dino
>>>
>>>>
>>>> Thanks
>>>>   Brian
>>>>
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern 
>>> wrote:
>>>>>>
>>>>>> Dino, Med, please confirm if I am reading the thread properly:
>>>>>>
>>>>>> I believe that the proposal is to make the small change below to
>> 6833bis
>>> and to drop the "updates" reference from 8113bis to 6833bis.
>>>>>>
>>>>>> I believe Dino's question was whether Brian agreed that the combination
>>> suggested would address his concern.
>>>>>>
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>>>>> I may be missing something but I don't see how 8113bis can
>>>>>>> logically cite 8113, which it replaces.
>>>>>>> Frankly I think you've collectively created a plate of citation
>>>>>>> spaghetti by not moving the IANA considerations for the type field
>>>>>>> registry into 6830bis, which is where they naturally belong. If you
>>>>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>>>>> I can see.
>>>>>>> Regards
>>>>>>>   Brian
>>>>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>>>>>
>>>>>>>> Dino
>>>>>>>> ngo
>>>>>>>>> On Dec 19, 2018, at 11:35 PM, 
>>>  wrote:
>>>>>>>>>
>>>>>>>>> Hi Dino,
>>>>>>>>>
>>>>>>>>> OLD:
>>>>>>>>>
>>>>>>>>>  Values in the "Not Assigned" range can be ass

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Diff looks good to me. Thanks Med!

Dino

> On Jan 9, 2019, at 11:42 PM,  
>  wrote:
> 
> Hi Brian, all,
> 
> The changes are now available online: 
> https://tools.ietf.org/html/draft-ietf-lisp-rfc8113bis-02 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-rfc8113bis-02
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : mohamed.boucad...@orange.com [mailto:mohamed.boucad...@orange.com]
>> Envoyé : vendredi 21 décembre 2018 07:57
>> À : Dino Farinacci; Brian E Carpenter
>> Cc : Joel M. Halpern; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
>> rfc8113bis....@ietf.org
>> Objet : RE: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> Re-,
>> 
>> Seems we are all in agreement.
>> 
>> I implemented the changes to 8113bis in my local copy.
>> 
>> Thank you, Brian.
>> 
>> Cheers,
>> Med
>> 
>>> -Message d'origine-
>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>> Envoyé : vendredi 21 décembre 2018 00:29
>>> À : Brian E Carpenter
>>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-...@ietf.org;
>>> lisp@ietf.org; draft-ietf-lisp-rfc8113bis@ietf.org
>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>> 
>>>> On 2018-12-21 09:18, Dino Farinacci wrote:
>>>>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine
>> with
>>> that. That reference being at the top of the draft saying “Updates
>> 6833bis”.
>>> If we remove that, he may concur. Please confirm Brian (again).
>>>> 
>>>> Yes, that would resolve my concern.
>>> 
>>> Thanks.
>>> 
>>>>> Like I have mentioned to you before, the IETF “Updates” lingo is
>> confusing
>>> and really not useful unless a draft replaces a previous draft. And this is
>>> not the case here.
>>>> 
>>>> That's a debate for the RFC-interest list perhaps. IMHO the issue is that
>>> "Updates" sometimes means "Extends" and sometimes means "Modifies".
>>> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to
>>> create confusion.
>>> 
>>> Then maybe those words should be used.
>>> 
>>> Dino
>>> 
>>>> 
>>>> Thanks
>>>>  Brian
>>>> 
>>>>> 
>>>>> Dino
>>>>> 
>>>>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern 
>>> wrote:
>>>>>> 
>>>>>> Dino, Med, please confirm if I am reading the thread properly:
>>>>>> 
>>>>>> I believe that the proposal is to make the small change below to
>> 6833bis
>>> and to drop the "updates" reference from 8113bis to 6833bis.
>>>>>> 
>>>>>> I believe Dino's question was whether Brian agreed that the combination
>>> suggested would address his concern.
>>>>>> 
>>>>>> Yours,
>>>>>> Joel
>>>>>> 
>>>>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>>>>> I may be missing something but I don't see how 8113bis can
>>>>>>> logically cite 8113, which it replaces.
>>>>>>> Frankly I think you've collectively created a plate of citation
>>>>>>> spaghetti by not moving the IANA considerations for the type field
>>>>>>> registry into 6830bis, which is where they naturally belong. If you
>>>>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>>>>> I can see.
>>>>>>> Regards
>>>>>>>  Brian
>>>>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>>>>> 
>>>>>>>> Dino
>>>>>>>> ngo
>>>>>>>>> On Dec 19, 2018, at 11:35 PM, 
>>>  wrote:
>>>>>>>>> 
>>>>>>>>> Hi Dino,
>>>>>>>>> 
>>>>>>>>> OLD:
>>>>>>>>> 
>>>>>>>>> Values in the "Not Assigned" range can be a

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Thanks all.

Dino

> On Dec 20, 2018, at 10:57 PM,  
>  wrote:
> 
> Re-,
> 
> Seems we are all in agreement. 
> 
> I implemented the changes to 8113bis in my local copy. 
> 
> Thank you, Brian. 
> 
> Cheers,
> Med 
> 
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : vendredi 21 décembre 2018 00:29
>> À : Brian E Carpenter
>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; gen-...@ietf.org;
>> lisp@ietf.org; draft-ietf-lisp-rfc8113bis....@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>>> On 2018-12-21 09:18, Dino Farinacci wrote:
>>>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine with
>> that. That reference being at the top of the draft saying “Updates 6833bis”.
>> If we remove that, he may concur. Please confirm Brian (again).
>>> 
>>> Yes, that would resolve my concern.
>> 
>> Thanks.
>> 
>>>> Like I have mentioned to you before, the IETF “Updates” lingo is confusing
>> and really not useful unless a draft replaces a previous draft. And this is
>> not the case here.
>>> 
>>> That's a debate for the RFC-interest list perhaps. IMHO the issue is that
>> "Updates" sometimes means "Extends" and sometimes means "Modifies".
>> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to
>> create confusion.
>> 
>> Then maybe those words should be used.
>> 
>> Dino
>> 
>>> 
>>> Thanks
>>>  Brian
>>> 
>>>> 
>>>> Dino
>>>> 
>>>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern 
>> wrote:
>>>>> 
>>>>> Dino, Med, please confirm if I am reading the thread properly:
>>>>> 
>>>>> I believe that the proposal is to make the small change below to 6833bis
>> and to drop the "updates" reference from 8113bis to 6833bis.
>>>>> 
>>>>> I believe Dino's question was whether Brian agreed that the combination
>> suggested would address his concern.
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>>>> I may be missing something but I don't see how 8113bis can
>>>>>> logically cite 8113, which it replaces.
>>>>>> Frankly I think you've collectively created a plate of citation
>>>>>> spaghetti by not moving the IANA considerations for the type field
>>>>>> registry into 6830bis, which is where they naturally belong. If you
>>>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>>>> I can see.
>>>>>> Regards
>>>>>>  Brian
>>>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>>>> 
>>>>>>> Dino
>>>>>>> ngo
>>>>>>>> On Dec 19, 2018, at 11:35 PM, 
>>  wrote:
>>>>>>>> 
>>>>>>>> Hi Dino,
>>>>>>>> 
>>>>>>>> OLD:
>>>>>>>> 
>>>>>>>> Values in the "Not Assigned" range can be assigned according to
>>>>>>>> procedures in [RFC8126].
>>>>>>>> 
>>>>>>>> NEW:
>>>>>>>> 
>>>>>>>> Values in the "Not Assigned" range can be assigned via Standards
>>>>>>>> Action [RFC8113].
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Med
>>>>>>>> 
>>>>>>>>> -Message d'origine-
>>>>>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org;
>> lisp@ietf.org;
>>>>>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-
>> rfc8113bis-01
>>>>>&g

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[mohamed.boucadair]

Brian, 

Please see inline. 

Cheers,
Med

> -Message d'origine-
> De : Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
> Envoyé : jeudi 20 décembre 2018 20:56
> À : Dino Farinacci; BOUCADAIR Mohamed TGI/OLN
> Cc : Joel M. Halpern; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
> rfc8113bis@ietf.org
> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
> 
> I may be missing something but I don't see how 8113bis can
> logically cite 8113, which it replaces.
> 

[Med] The change is for 6833bis NOT 8113bis. 6833bis already cites 8113, which 
describes the rules for assigning new types. 

> Frankly I think you've collectively created a plate of citation
> spaghetti by not moving the IANA considerations for the type field
> registry into 6830bis, which is where they naturally belong. If you
> don't want to do that, I think you have to leave them in 8113bis and
> simply lose the citation of 6833bis, which serves no purpose that
> I can see.
> 
> Regards
>Brian
> 
> On 2018-12-21 06:32, Dino Farinacci wrote:
> > I’ll make that change if Brian thinks it fixes the issues he raised.
> >
> > Dino
> >
> >> On Dec 19, 2018, at 11:35 PM, 
>  wrote:
> >>
> >> Hi Dino,
> >>
> >> OLD:
> >>
> >>   Values in the "Not Assigned" range can be assigned according to
> >>   procedures in [RFC8126].
> >>
> >> NEW:
> >>
> >>   Values in the "Not Assigned" range can be assigned via Standards
> >>   Action [RFC8113].
> >>
> >> Cheers,
> >> Med
> >>
> >>> -Message d'origine-
> >>> De : Dino Farinacci [mailto:farina...@gmail.com]
> >>> Envoyé : mercredi 19 décembre 2018 19:00
> >>> À : BOUCADAIR Mohamed TGI/OLN
> >>> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
> >>> draft-ietf-lisp-rfc8113bis@ietf.org
> >>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
> 01
> >>>
> >>> What does fixing in (1) mean?
> >>>
> >>> Dino
> >>>
> >>>> On Dec 19, 2018, at 3:51 AM, 
> >>>  wrote:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Brian, whether to maintain the document standalone was discussed by the
> WG.
> >>> You may refer, for example, to the message from Deborah which clarifies
> this
> >>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html.
> One
> >>> of the outcomes of that discussion is to add an "updates" header to
> 8113bis.
> >>>>
> >>>> FWIW, one of the issues that led to that conclusion was whether to cite
> >>> rfc8113bis as normative in 6833bis (the approach I initially supported)
> and
> >>> agreed by Dino (https://www.ietf.org/mail-
> >>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
> >>> 8113bis will lead to circular dependency. Which is a fair argument.
> >>>>
> >>>> The "updates" tag was justified as follows:
> >>>>
> >>>> (1)
> >>>>
> >>>> RFC6833bis includes the following:
> >>>>
> >>>>  Values in the "Not Assigned" range can be assigned according to
> >>>>  procedures in [RFC8126].
> >>>>
> >>>> That text is updated by RFC8113bis to be aligned with 8113:
> >>>>
> >>>>  Values can be assigned via Standards Action
> >>>>
> >>>> (2)
> >>>>
> >>>> RFC8113bis extends the type field to grab more bits/values when the
> >>> available types are exhausted. This is captured in 8113bis:
> >>>>
> >>>>  The values in the range 0-1023 are assigned via Standards Action.
> >>>>  This range is provisioned to anticipate, in particular, the
> >>>>  exhaustion of the LISP Packet types.
> >>>>
> >>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove
> the
> >>> "updates" header because (2) can be also seen as an extension.
> >>>>
> >>>> Cheers,
> >>>> Med
> >>>>
> >>>>> -Message d'origine-
> >>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
> >>>>> Envoyé : mercredi 19 décembre 2018 06:37
> >>>

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

> On 2018-12-21 09:18, Dino Farinacci wrote:
>> Brian wants to drop the reference to 6833bis from 8113bis. I am fine with 
>> that. That reference being at the top of the draft saying “Updates 6833bis”. 
>> If we remove that, he may concur. Please confirm Brian (again).
> 
> Yes, that would resolve my concern.

Thanks.

>> Like I have mentioned to you before, the IETF “Updates” lingo is confusing 
>> and really not useful unless a draft replaces a previous draft. And this is 
>> not the case here.
> 
> That's a debate for the RFC-interest list perhaps. IMHO the issue is that 
> "Updates" sometimes means "Extends" and sometimes means "Modifies". 
> "Obsoletes" sometimes also implies "Replaces", but that doesn't seem to 
> create confusion.

Then maybe those words should be used.

Dino

> 
> Thanks
>   Brian
> 
>> 
>> Dino
>> 
>>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern  wrote:
>>> 
>>> Dino, Med, please confirm if I am reading the thread properly:
>>> 
>>> I believe that the proposal is to make the small change below to 6833bis 
>>> and to drop the "updates" reference from 8113bis to 6833bis.
>>> 
>>> I believe Dino's question was whether Brian agreed that the combination 
>>> suggested would address his concern.
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>>> I may be missing something but I don't see how 8113bis can
>>>> logically cite 8113, which it replaces.
>>>> Frankly I think you've collectively created a plate of citation
>>>> spaghetti by not moving the IANA considerations for the type field
>>>> registry into 6830bis, which is where they naturally belong. If you
>>>> don't want to do that, I think you have to leave them in 8113bis and
>>>> simply lose the citation of 6833bis, which serves no purpose that
>>>> I can see.
>>>> Regards
>>>>   Brian
>>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>> 
>>>>> Dino
>>>>> ngo 
>>>>>> On Dec 19, 2018, at 11:35 PM,  
>>>>>>  wrote:
>>>>>> 
>>>>>> Hi Dino,
>>>>>> 
>>>>>> OLD:
>>>>>> 
>>>>>>  Values in the "Not Assigned" range can be assigned according to
>>>>>>  procedures in [RFC8126].
>>>>>> 
>>>>>> NEW:
>>>>>> 
>>>>>>  Values in the "Not Assigned" range can be assigned via Standards
>>>>>>  Action [RFC8113].
>>>>>> 
>>>>>> Cheers,
>>>>>> Med
>>>>>> 
>>>>>>> -Message d'origine-
>>>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; 
>>>>>>> lisp@ietf.org;
>>>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>>>> Objet : Re: [lisp] Genart last call review of 
>>>>>>> draft-ietf-lisp-rfc8113bis-01
>>>>>>> 
>>>>>>> What does fixing in (1) mean?
>>>>>>> 
>>>>>>> Dino
>>>>>>> 
>>>>>>>> On Dec 19, 2018, at 3:51 AM, 
>>>>>>>  wrote:
>>>>>>>> 
>>>>>>>> Hi all,
>>>>>>>> 
>>>>>>>> Brian, whether to maintain the document standalone was discussed by 
>>>>>>>> the WG.
>>>>>>> You may refer, for example, to the message from Deborah which clarifies 
>>>>>>> this
>>>>>>> point: 
>>>>>>> https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
>>>>>>> of the outcomes of that discussion is to add an "updates" header to 
>>>>>>> 8113bis.
>>>>>>>> 
>>>>>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>>>>>> rfc8113bis as normative in 6833bis (the approach I initially supported) 
>>>>>>&g

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

On 2018-12-21 09:18, Dino Farinacci wrote:
> Brian wants to drop the reference to 6833bis from 8113bis. I am fine with 
> that. That reference being at the top of the draft saying “Updates 6833bis”. 
> If we remove that, he may concur. Please confirm Brian (again).

Yes, that would resolve my concern.

> Like I have mentioned to you before, the IETF “Updates” lingo is confusing 
> and really not useful unless a draft replaces a previous draft. And this is 
> not the case here.

That's a debate for the RFC-interest list perhaps. IMHO the issue is that 
"Updates" sometimes means "Extends" and sometimes means "Modifies". "Obsoletes" 
sometimes also implies "Replaces", but that doesn't seem to create confusion.

Thanks
   Brian

> 
> Dino
> 
>> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern  wrote:
>>
>> Dino, Med, please confirm if I am reading the thread properly:
>>
>> I believe that the proposal is to make the small change below to 6833bis and 
>> to drop the "updates" reference from 8113bis to 6833bis.
>>
>> I believe Dino's question was whether Brian agreed that the combination 
>> suggested would address his concern.
>>
>> Yours,
>> Joel
>>
>> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>>> I may be missing something but I don't see how 8113bis can
>>> logically cite 8113, which it replaces.
>>> Frankly I think you've collectively created a plate of citation
>>> spaghetti by not moving the IANA considerations for the type field
>>> registry into 6830bis, which is where they naturally belong. If you
>>> don't want to do that, I think you have to leave them in 8113bis and
>>> simply lose the citation of 6833bis, which serves no purpose that
>>> I can see.
>>> Regards
>>>Brian
>>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>>>
>>>> Dino
>>>> ngo 
>>>>> On Dec 19, 2018, at 11:35 PM,  
>>>>>  wrote:
>>>>>
>>>>> Hi Dino,
>>>>>
>>>>> OLD:
>>>>>
>>>>>   Values in the "Not Assigned" range can be assigned according to
>>>>>   procedures in [RFC8126].
>>>>>
>>>>> NEW:
>>>>>
>>>>>   Values in the "Not Assigned" range can be assigned via Standards
>>>>>   Action [RFC8113].
>>>>>
>>>>> Cheers,
>>>>> Med
>>>>>
>>>>>> -Message d'origine-
>>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
>>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>>> Objet : Re: [lisp] Genart last call review of 
>>>>>> draft-ietf-lisp-rfc8113bis-01
>>>>>>
>>>>>> What does fixing in (1) mean?
>>>>>>
>>>>>> Dino
>>>>>>
>>>>>>> On Dec 19, 2018, at 3:51 AM, 
>>>>>>  wrote:
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Brian, whether to maintain the document standalone was discussed by the 
>>>>>>> WG.
>>>>>> You may refer, for example, to the message from Deborah which clarifies 
>>>>>> this
>>>>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. 
>>>>>> One
>>>>>> of the outcomes of that discussion is to add an "updates" header to 
>>>>>> 8113bis.
>>>>>>>
>>>>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>>>>> rfc8113bis as normative in 6833bis (the approach I initially supported) 
>>>>>> and
>>>>>> agreed by Dino (https://www.ietf.org/mail-
>>>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>>>>>> 8113bis will lead to circular dependency. Which is a fair argument.
>>>>>>>
>>>>>>> The "updates" tag was justified as follows:
>>>>>>>
>>>>>>> (1)
>>>>>>>
>>>>>>> RFC683

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Brian wants to drop the reference to 6833bis from 8113bis. I am fine with that. 
That reference being at the top of the draft saying “Updates 6833bis”. If we 
remove that, he may concur. Please confirm Brian (again).

Like I have mentioned to you before, the IETF “Updates” lingo is confusing and 
really not useful unless a draft replaces a previous draft. And this is not the 
case here.

Dino

> On Dec 20, 2018, at 11:58 AM, Joel M. Halpern  wrote:
> 
> Dino, Med, please confirm if I am reading the thread properly:
> 
> I believe that the proposal is to make the small change below to 6833bis and 
> to drop the "updates" reference from 8113bis to 6833bis.
> 
> I believe Dino's question was whether Brian agreed that the combination 
> suggested would address his concern.
> 
> Yours,
> Joel
> 
> On 12/20/18 2:55 PM, Brian E Carpenter wrote:
>> I may be missing something but I don't see how 8113bis can
>> logically cite 8113, which it replaces.
>> Frankly I think you've collectively created a plate of citation
>> spaghetti by not moving the IANA considerations for the type field
>> registry into 6830bis, which is where they naturally belong. If you
>> don't want to do that, I think you have to leave them in 8113bis and
>> simply lose the citation of 6833bis, which serves no purpose that
>> I can see.
>> Regards
>>Brian
>> On 2018-12-21 06:32, Dino Farinacci wrote:
>>> I’ll make that change if Brian thinks it fixes the issues he raised.
>>> 
>>> Dino
>>> ngo 
>>>> On Dec 19, 2018, at 11:35 PM,  
>>>>  wrote:
>>>> 
>>>> Hi Dino,
>>>> 
>>>> OLD:
>>>> 
>>>>   Values in the "Not Assigned" range can be assigned according to
>>>>   procedures in [RFC8126].
>>>> 
>>>> NEW:
>>>> 
>>>>   Values in the "Not Assigned" range can be assigned via Standards
>>>>   Action [RFC8113].
>>>> 
>>>> Cheers,
>>>> Med
>>>> 
>>>>> -Message d'origine-
>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>> Envoyé : mercredi 19 décembre 2018 19:00
>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
>>>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>>>> Objet : Re: [lisp] Genart last call review of 
>>>>> draft-ietf-lisp-rfc8113bis-01
>>>>> 
>>>>> What does fixing in (1) mean?
>>>>> 
>>>>> Dino
>>>>> 
>>>>>> On Dec 19, 2018, at 3:51 AM, 
>>>>>  wrote:
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> Brian, whether to maintain the document standalone was discussed by the 
>>>>>> WG.
>>>>> You may refer, for example, to the message from Deborah which clarifies 
>>>>> this
>>>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. 
>>>>> One
>>>>> of the outcomes of that discussion is to add an "updates" header to 
>>>>> 8113bis.
>>>>>> 
>>>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>>>> rfc8113bis as normative in 6833bis (the approach I initially supported) 
>>>>> and
>>>>> agreed by Dino (https://www.ietf.org/mail-
>>>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>>>>> 8113bis will lead to circular dependency. Which is a fair argument.
>>>>>> 
>>>>>> The "updates" tag was justified as follows:
>>>>>> 
>>>>>> (1)
>>>>>> 
>>>>>> RFC6833bis includes the following:
>>>>>> 
>>>>>>  Values in the "Not Assigned" range can be assigned according to
>>>>>>  procedures in [RFC8126].
>>>>>> 
>>>>>> That text is updated by RFC8113bis to be aligned with 8113:
>>>>>> 
>>>>>>  Values can be assigned via Standards Action
>>>>>> 
>>>>>> (2)
>>>>>> 
>>>>>> RFC8113bis extends the type field to grab more bits/values when the
>>>>> available types are exhausted. This is captured in 8113bis:
>>>>>> 
>>>>>>  The values in the range 0-1

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Joel M. Halpern]

Dino, Med, please confirm if I am reading the thread properly:

I believe that the proposal is to make the small change below to 6833bis 
and to drop the "updates" reference from 8113bis to 6833bis.


I believe Dino's question was whether Brian agreed that the combination 
suggested would address his concern.


Yours,
Joel

On 12/20/18 2:55 PM, Brian E Carpenter wrote:

I may be missing something but I don't see how 8113bis can
logically cite 8113, which it replaces.

Frankly I think you've collectively created a plate of citation
spaghetti by not moving the IANA considerations for the type field
registry into 6830bis, which is where they naturally belong. If you
don't want to do that, I think you have to leave them in 8113bis and
simply lose the citation of 6833bis, which serves no purpose that
I can see.

Regards
Brian

On 2018-12-21 06:32, Dino Farinacci wrote:

I’ll make that change if Brian thinks it fixes the issues he raised.

Dino


On Dec 19, 2018, at 11:35 PM,  
 wrote:

Hi Dino,

OLD:

   Values in the "Not Assigned" range can be assigned according to
   procedures in [RFC8126].

NEW:

   Values in the "Not Assigned" range can be assigned via Standards
   Action [RFC8113].

Cheers,
Med


-Message d'origine-
De : Dino Farinacci [mailto:farina...@gmail.com]
Envoyé : mercredi 19 décembre 2018 19:00
À : BOUCADAIR Mohamed TGI/OLN
Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
draft-ietf-lisp-rfc8113bis....@ietf.org
Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

What does fixing in (1) mean?

Dino


On Dec 19, 2018, at 3:51 AM, 

 wrote:


Hi all,

Brian, whether to maintain the document standalone was discussed by the WG.

You may refer, for example, to the message from Deborah which clarifies this
point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
of the outcomes of that discussion is to add an "updates" header to 8113bis.


FWIW, one of the issues that led to that conclusion was whether to cite

rfc8113bis as normative in 6833bis (the approach I initially supported) and
agreed by Dino (https://www.ietf.org/mail-
archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
8113bis will lead to circular dependency. Which is a fair argument.


The "updates" tag was justified as follows:

(1)

RFC6833bis includes the following:

  Values in the "Not Assigned" range can be assigned according to
  procedures in [RFC8126].

That text is updated by RFC8113bis to be aligned with 8113:

  Values can be assigned via Standards Action

(2)

RFC8113bis extends the type field to grab more bits/values when the

available types are exhausted. This is captured in 8113bis:


  The values in the range 0-1023 are assigned via Standards Action.
  This range is provisioned to anticipate, in particular, the
  exhaustion of the LISP Packet types.

Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the

"updates" header because (2) can be also seen as an extension.


Cheers,
Med


-Message d'origine-
De : Dino Farinacci [mailto:farina...@gmail.com]
Envoyé : mercredi 19 décembre 2018 06:37
À : Joel M. Halpern
Cc : Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
rfc8113bis....@ietf.org
Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-

01


Mohmad to comment.

Dino


On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:

That is the other fix he offered.  Just remove the updates tag.
I will leav eit to you and the the authors to determine which is correct.
Yours,
Joel

On 12/18/18 11:43 PM, Dino Farinacci wrote:

8113bis should say that is it *extending* the type field so we can have

more types. The word “update” I always had a problem with because it can

be

interpreted as “replacing". Replacing something to fix a problem.

8113 is simply asking for one of the type value codepoint, so there can

be

another format to have more types.

Dino

On Dec 18, 2018, at 9:24 PM, Joel M. Halpern 

wrote:


Authors: that sounds like a reasonable addition to me?

Yours,
Joel

On 12/18/18 10:48 PM, Brian E Carpenter wrote:

On 2018-12-19 15:46, Joel M. Halpern wrote:

This is part of the package to move the coherent set of base LISP

specs

to PS.

The reason we did this rather than folding it into 6830bis / 6833bis

is

that we had originally simply cited 8113, and then realized that

needed

to move to PS along with everything else.  It seemed (and is) simpler

to

do it separately rather than to further modify 6830bis / 6933bis.

As for why it updates 6833bis, that is because one of the cahnges in
moving the set to PS was to improve the split as to which information
belonged in which document.

OK, but I still don't find it logical The text doesn't explain which

part of

6833bis is impacted, and normally these days we require such an

explanation.

And if there is an impact, 

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

I may be missing something but I don't see how 8113bis can
logically cite 8113, which it replaces.

Frankly I think you've collectively created a plate of citation
spaghetti by not moving the IANA considerations for the type field
registry into 6830bis, which is where they naturally belong. If you
don't want to do that, I think you have to leave them in 8113bis and
simply lose the citation of 6833bis, which serves no purpose that
I can see.

Regards
   Brian

On 2018-12-21 06:32, Dino Farinacci wrote:
> I’ll make that change if Brian thinks it fixes the issues he raised.
> 
> Dino
> 
>> On Dec 19, 2018, at 11:35 PM,  
>>  wrote:
>>
>> Hi Dino, 
>>
>> OLD: 
>>
>>   Values in the "Not Assigned" range can be assigned according to
>>   procedures in [RFC8126].
>>
>> NEW:
>>
>>   Values in the "Not Assigned" range can be assigned via Standards
>>   Action [RFC8113].
>>
>> Cheers,
>> Med
>>
>>> -Message d'origine-
>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>> Envoyé : mercredi 19 décembre 2018 19:00
>>> À : BOUCADAIR Mohamed TGI/OLN
>>> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
>>> draft-ietf-lisp-rfc8113bis@ietf.org
>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>>>
>>> What does fixing in (1) mean?
>>>
>>> Dino
>>>
>>>> On Dec 19, 2018, at 3:51 AM, 
>>>  wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Brian, whether to maintain the document standalone was discussed by the WG.
>>> You may refer, for example, to the message from Deborah which clarifies this
>>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
>>> of the outcomes of that discussion is to add an "updates" header to 8113bis.
>>>>
>>>> FWIW, one of the issues that led to that conclusion was whether to cite
>>> rfc8113bis as normative in 6833bis (the approach I initially supported) and
>>> agreed by Dino (https://www.ietf.org/mail-
>>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>>> 8113bis will lead to circular dependency. Which is a fair argument.
>>>>
>>>> The "updates" tag was justified as follows:
>>>>
>>>> (1)
>>>>
>>>> RFC6833bis includes the following:
>>>>
>>>>  Values in the "Not Assigned" range can be assigned according to
>>>>  procedures in [RFC8126].
>>>>
>>>> That text is updated by RFC8113bis to be aligned with 8113:
>>>>
>>>>  Values can be assigned via Standards Action
>>>>
>>>> (2)
>>>>
>>>> RFC8113bis extends the type field to grab more bits/values when the
>>> available types are exhausted. This is captured in 8113bis:
>>>>
>>>>  The values in the range 0-1023 are assigned via Standards Action.
>>>>  This range is provisioned to anticipate, in particular, the
>>>>  exhaustion of the LISP Packet types.
>>>>
>>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
>>> "updates" header because (2) can be also seen as an extension.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -Message d'origine-
>>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>>> Envoyé : mercredi 19 décembre 2018 06:37
>>>>> À : Joel M. Halpern
>>>>> Cc : Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
>>>>> rfc8113bis@ietf.org
>>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
>>> 01
>>>>>
>>>>> Mohmad to comment.
>>>>>
>>>>> Dino
>>>>>
>>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  
>>>>>> wrote:
>>>>>>
>>>>>> That is the other fix he offered.  Just remove the updates tag.
>>>>>> I will leav eit to you and the the authors to determine which is correct.
>>>>>> Yours,
>>>>>> Joel
>>>>>>
>>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>>>>>>> 8113bis should say that is it *extending* the type field so we can have
>>>>> more types. The word “update” I always had a problem with because it can
&

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

I’ll make that change if Brian thinks it fixes the issues he raised.

Dino

> On Dec 19, 2018, at 11:35 PM,  
>  wrote:
> 
> Hi Dino, 
> 
> OLD: 
> 
>   Values in the "Not Assigned" range can be assigned according to
>   procedures in [RFC8126].
> 
> NEW:
> 
>   Values in the "Not Assigned" range can be assigned via Standards
>   Action [RFC8113].
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : mercredi 19 décembre 2018 19:00
>> À : BOUCADAIR Mohamed TGI/OLN
>> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
>> draft-ietf-lisp-rfc8113bis@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> What does fixing in (1) mean?
>> 
>> Dino
>> 
>>> On Dec 19, 2018, at 3:51 AM, 
>>  wrote:
>>> 
>>> Hi all,
>>> 
>>> Brian, whether to maintain the document standalone was discussed by the WG.
>> You may refer, for example, to the message from Deborah which clarifies this
>> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
>> of the outcomes of that discussion is to add an "updates" header to 8113bis.
>>> 
>>> FWIW, one of the issues that led to that conclusion was whether to cite
>> rfc8113bis as normative in 6833bis (the approach I initially supported) and
>> agreed by Dino (https://www.ietf.org/mail-
>> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
>> 8113bis will lead to circular dependency. Which is a fair argument.
>>> 
>>> The "updates" tag was justified as follows:
>>> 
>>> (1)
>>> 
>>> RFC6833bis includes the following:
>>> 
>>>  Values in the "Not Assigned" range can be assigned according to
>>>  procedures in [RFC8126].
>>> 
>>> That text is updated by RFC8113bis to be aligned with 8113:
>>> 
>>>  Values can be assigned via Standards Action
>>> 
>>> (2)
>>> 
>>> RFC8113bis extends the type field to grab more bits/values when the
>> available types are exhausted. This is captured in 8113bis:
>>> 
>>>  The values in the range 0-1023 are assigned via Standards Action.
>>>  This range is provisioned to anticipate, in particular, the
>>>  exhaustion of the LISP Packet types.
>>> 
>>> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
>> "updates" header because (2) can be also seen as an extension.
>>> 
>>> Cheers,
>>> Med
>>> 
>>>> -Message d'origine-
>>>> De : Dino Farinacci [mailto:farina...@gmail.com]
>>>> Envoyé : mercredi 19 décembre 2018 06:37
>>>> À : Joel M. Halpern
>>>> Cc : Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
>>>> rfc8113bis@ietf.org
>>>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
>> 01
>>>> 
>>>> Mohmad to comment.
>>>> 
>>>> Dino
>>>> 
>>>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
>>>>> 
>>>>> That is the other fix he offered.  Just remove the updates tag.
>>>>> I will leav eit to you and the the authors to determine which is correct.
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>>>>>> 8113bis should say that is it *extending* the type field so we can have
>>>> more types. The word “update” I always had a problem with because it can
>> be
>>>> interpreted as “replacing". Replacing something to fix a problem.
>>>>>> 8113 is simply asking for one of the type value codepoint, so there can
>> be
>>>> another format to have more types.
>>>>>> Dino
>>>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern 
>> wrote:
>>>>>>> 
>>>>>>> Authors: that sounds like a reasonable addition to me?
>>>>>>> 
>>>>>>> Yours,
>>>>>>> Joel
>>>>>>> 
>>>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>>>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>>>>>>>> This is part of the package to move the coherent set of base LISP
>>

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[mohamed.boucadair]

Hi Dino, 

OLD: 

   Values in the "Not Assigned" range can be assigned according to
   procedures in [RFC8126].

NEW:

   Values in the "Not Assigned" range can be assigned via Standards
   Action [RFC8113].

Cheers,
Med

> -Message d'origine-
> De : Dino Farinacci [mailto:farina...@gmail.com]
> Envoyé : mercredi 19 décembre 2018 19:00
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Joel M. Halpern; Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org;
> draft-ietf-lisp-rfc8113bis....@ietf.org
> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
> 
> What does fixing in (1) mean?
> 
> Dino
> 
> > On Dec 19, 2018, at 3:51 AM, 
>  wrote:
> >
> > Hi all,
> >
> > Brian, whether to maintain the document standalone was discussed by the WG.
> You may refer, for example, to the message from Deborah which clarifies this
> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One
> of the outcomes of that discussion is to add an "updates" header to 8113bis.
> >
> > FWIW, one of the issues that led to that conclusion was whether to cite
> rfc8113bis as normative in 6833bis (the approach I initially supported) and
> agreed by Dino (https://www.ietf.org/mail-
> archive/web/lisp/current/msg07882.html). Deborah convinced me that citing
> 8113bis will lead to circular dependency. Which is a fair argument.
> >
> > The "updates" tag was justified as follows:
> >
> > (1)
> >
> > RFC6833bis includes the following:
> >
> >   Values in the "Not Assigned" range can be assigned according to
> >   procedures in [RFC8126].
> >
> > That text is updated by RFC8113bis to be aligned with 8113:
> >
> >   Values can be assigned via Standards Action
> >
> > (2)
> >
> > RFC8113bis extends the type field to grab more bits/values when the
> available types are exhausted. This is captured in 8113bis:
> >
> >   The values in the range 0-1023 are assigned via Standards Action.
> >   This range is provisioned to anticipate, in particular, the
> >   exhaustion of the LISP Packet types.
> >
> > Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the
> "updates" header because (2) can be also seen as an extension.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-
> >> De : Dino Farinacci [mailto:farina...@gmail.com]
> >> Envoyé : mercredi 19 décembre 2018 06:37
> >> À : Joel M. Halpern
> >> Cc : Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
> >> rfc8113bis@ietf.org
> >> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-
> 01
> >>
> >> Mohmad to comment.
> >>
> >> Dino
> >>
> >>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
> >>>
> >>> That is the other fix he offered.  Just remove the updates tag.
> >>> I will leav eit to you and the the authors to determine which is correct.
> >>> Yours,
> >>> Joel
> >>>
> >>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
> >>>> 8113bis should say that is it *extending* the type field so we can have
> >> more types. The word “update” I always had a problem with because it can
> be
> >> interpreted as “replacing". Replacing something to fix a problem.
> >>>> 8113 is simply asking for one of the type value codepoint, so there can
> be
> >> another format to have more types.
> >>>> Dino
> >>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern 
> wrote:
> >>>>>
> >>>>> Authors: that sounds like a reasonable addition to me?
> >>>>>
> >>>>> Yours,
> >>>>> Joel
> >>>>>
> >>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
> >>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote:
> >>>>>>> This is part of the package to move the coherent set of base LISP
> specs
> >>>>>>> to PS.
> >>>>>>>
> >>>>>>> The reason we did this rather than folding it into 6830bis / 6833bis
> is
> >>>>>>> that we had originally simply cited 8113, and then realized that
> needed
> >>>>>>> to move to PS along with everything else.  It seemed (and is) simpler
> >> to
> >>>>>>> do it separately rather than to further modify 6830bis / 6933bis.
> >>>>>>>

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

What does fixing in (1) mean?

Dino

> On Dec 19, 2018, at 3:51 AM,  
>  wrote:
> 
> Hi all, 
> 
> Brian, whether to maintain the document standalone was discussed by the WG. 
> You may refer, for example, to the message from Deborah which clarifies this 
> point: https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One 
> of the outcomes of that discussion is to add an "updates" header to 8113bis.
> 
> FWIW, one of the issues that led to that conclusion was whether to cite 
> rfc8113bis as normative in 6833bis (the approach I initially supported) and 
> agreed by Dino 
> (https://www.ietf.org/mail-archive/web/lisp/current/msg07882.html). Deborah 
> convinced me that citing 8113bis will lead to circular dependency. Which is a 
> fair argument. 
> 
> The "updates" tag was justified as follows:
> 
> (1)
> 
> RFC6833bis includes the following:
> 
>   Values in the "Not Assigned" range can be assigned according to
>   procedures in [RFC8126].
> 
> That text is updated by RFC8113bis to be aligned with 8113: 
> 
>   Values can be assigned via Standards Action
> 
> (2) 
> 
> RFC8113bis extends the type field to grab more bits/values when the available 
> types are exhausted. This is captured in 8113bis:
> 
>   The values in the range 0-1023 are assigned via Standards Action.
>   This range is provisioned to anticipate, in particular, the
>   exhaustion of the LISP Packet types.
> 
> Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the 
> "updates" header because (2) can be also seen as an extension. 
> 
> Cheers,
> Med
> 
>> -Message d'origine-
>> De : Dino Farinacci [mailto:farina...@gmail.com]
>> Envoyé : mercredi 19 décembre 2018 06:37
>> À : Joel M. Halpern
>> Cc : Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
>> rfc8113bis@ietf.org
>> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> Mohmad to comment.
>> 
>> Dino
>> 
>>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
>>> 
>>> That is the other fix he offered.  Just remove the updates tag.
>>> I will leav eit to you and the the authors to determine which is correct.
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>>>> 8113bis should say that is it *extending* the type field so we can have
>> more types. The word “update” I always had a problem with because it can be
>> interpreted as “replacing". Replacing something to fix a problem.
>>>> 8113 is simply asking for one of the type value codepoint, so there can be
>> another format to have more types.
>>>> Dino
>>>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
>>>>> 
>>>>> Authors: that sounds like a reasonable addition to me?
>>>>> 
>>>>> Yours,
>>>>> Joel
>>>>> 
>>>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>>>>>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>>>>>> This is part of the package to move the coherent set of base LISP specs
>>>>>>> to PS.
>>>>>>> 
>>>>>>> The reason we did this rather than folding it into 6830bis / 6833bis is
>>>>>>> that we had originally simply cited 8113, and then realized that needed
>>>>>>> to move to PS along with everything else.  It seemed (and is) simpler
>> to
>>>>>>> do it separately rather than to further modify 6830bis / 6933bis.
>>>>>>> 
>>>>>>> As for why it updates 6833bis, that is because one of the cahnges in
>>>>>>> moving the set to PS was to improve the split as to which information
>>>>>>> belonged in which document.
>>>>>> OK, but I still don't find it logical The text doesn't explain which
>> part of
>>>>>> 6833bis is impacted, and normally these days we require such an
>> explanation.
>>>>>> And if there is an impact, you're missing the opportunity of fixing the
>> error
>>>>>> or gap in 6833bis, so the reader of 6833bis will be none the wiser
>> unless
>>>>>> you insert a reference to 8113bis.
>>>>>> On the other hand, if there is no error or gap, you don't need
>> "Updates:"
>>>>>> at all. (Unfortunately, we don't have an "Extends:" header.)
>>>>>>   Brian
>&

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

> IMHO we just drop the “update 6833bis” and we are fine.

I agree.

Dino

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[mohamed.boucadair]

Hi all, 

Brian, whether to maintain the document standalone was discussed by the WG. You 
may refer, for example, to the message from Deborah which clarifies this point: 
https://www.ietf.org/mail-archive/web/lisp/current/msg07886.html. One of the 
outcomes of that discussion is to add an "updates" header to 8113bis.

FWIW, one of the issues that led to that conclusion was whether to cite 
rfc8113bis as normative in 6833bis (the approach I initially supported) and 
agreed by Dino 
(https://www.ietf.org/mail-archive/web/lisp/current/msg07882.html). Deborah 
convinced me that citing 8113bis will lead to circular dependency. Which is a 
fair argument. 

The "updates" tag was justified as follows:

(1)

RFC6833bis includes the following:
 
   Values in the "Not Assigned" range can be assigned according to
   procedures in [RFC8126].

That text is updated by RFC8113bis to be aligned with 8113: 

   Values can be assigned via Standards Action

(2) 

RFC8113bis extends the type field to grab more bits/values when the available 
types are exhausted. This is captured in 8113bis:

   The values in the range 0-1023 are assigned via Standards Action.
   This range is provisioned to anticipate, in particular, the
   exhaustion of the LISP Packet types.

Dino: If (1) is fixed directly in RFC6833bis, then I'm fine to remove the 
"updates" header because (2) can be also seen as an extension. 

Cheers,
Med

> -Message d'origine-
> De : Dino Farinacci [mailto:farina...@gmail.com]
> Envoyé : mercredi 19 décembre 2018 06:37
> À : Joel M. Halpern
> Cc : Brian E Carpenter; gen-...@ietf.org; lisp@ietf.org; draft-ietf-lisp-
> rfc8113bis@ietf.org
> Objet : Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01
> 
> Mohmad to comment.
> 
> Dino
> 
> > On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
> >
> > That is the other fix he offered.  Just remove the updates tag.
> > I will leav eit to you and the the authors to determine which is correct.
> > Yours,
> > Joel
> >
> > On 12/18/18 11:43 PM, Dino Farinacci wrote:
> >> 8113bis should say that is it *extending* the type field so we can have
> more types. The word “update” I always had a problem with because it can be
> interpreted as “replacing". Replacing something to fix a problem.
> >> 8113 is simply asking for one of the type value codepoint, so there can be
> another format to have more types.
> >> Dino
> >>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
> >>>
> >>> Authors: that sounds like a reasonable addition to me?
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
> >>>> On 2018-12-19 15:46, Joel M. Halpern wrote:
> >>>>> This is part of the package to move the coherent set of base LISP specs
> >>>>> to PS.
> >>>>>
> >>>>> The reason we did this rather than folding it into 6830bis / 6833bis is
> >>>>> that we had originally simply cited 8113, and then realized that needed
> >>>>> to move to PS along with everything else.  It seemed (and is) simpler
> to
> >>>>> do it separately rather than to further modify 6830bis / 6933bis.
> >>>>>
> >>>>> As for why it updates 6833bis, that is because one of the cahnges in
> >>>>> moving the set to PS was to improve the split as to which information
> >>>>> belonged in which document.
> >>>> OK, but I still don't find it logical The text doesn't explain which
> part of
> >>>> 6833bis is impacted, and normally these days we require such an
> explanation.
> >>>> And if there is an impact, you're missing the opportunity of fixing the
> error
> >>>> or gap in 6833bis, so the reader of 6833bis will be none the wiser
> unless
> >>>> you insert a reference to 8113bis.
> >>>> On the other hand, if there is no error or gap, you don't need
> "Updates:"
> >>>> at all. (Unfortunately, we don't have an "Extends:" header.)
> >>>>Brian
> >>>>>
> >>>>> Yours,
> >>>>> Joel
> >>>>>
> >>>>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
> >>>>>> Reviewer: Brian Carpenter
> >>>>>> Review result: Ready with Issues
> >>>>>>
> >>>>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
> >>>>>>
> >>>>>> I am the assigned Gen-ART reviewer f

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Luigi Iannone]

Hi,

may be we do not need a state anything with respect of 6833bis.

Looking at the IANA considerations section of both 8113bis and 6833bis, they 
just request IANA to rename/allocate something in an existing registry.

In particular, 8113bis does not extend/update nothing in 6833bis.

IMHO we just drop the “update 6833bis” and we are fine.

Ciao

L.



> On 19 Dec 2018, at 06:37, Dino Farinacci  wrote:
> 
> Mohmad to comment.
> 
> Dino
> 
>> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
>> 
>> That is the other fix he offered.  Just remove the updates tag.
>> I will leav eit to you and the the authors to determine which is correct.
>> Yours,
>> Joel
>> 
>> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>>> 8113bis should say that is it *extending* the type field so we can have 
>>> more types. The word “update” I always had a problem with because it can be 
>>> interpreted as “replacing". Replacing something to fix a problem.
>>> 8113 is simply asking for one of the type value codepoint, so there can be 
>>> another format to have more types.
>>> Dino
 On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
 
 Authors: that sounds like a reasonable addition to me?
 
 Yours,
 Joel
 
 On 12/18/18 10:48 PM, Brian E Carpenter wrote:
> On 2018-12-19 15:46, Joel M. Halpern wrote:
>> This is part of the package to move the coherent set of base LISP specs
>> to PS.
>> 
>> The reason we did this rather than folding it into 6830bis / 6833bis is
>> that we had originally simply cited 8113, and then realized that needed
>> to move to PS along with everything else.  It seemed (and is) simpler to
>> do it separately rather than to further modify 6830bis / 6933bis.
>> 
>> As for why it updates 6833bis, that is because one of the cahnges in
>> moving the set to PS was to improve the split as to which information
>> belonged in which document.
> OK, but I still don't find it logical The text doesn't explain which part 
> of
> 6833bis is impacted, and normally these days we require such an 
> explanation.
> And if there is an impact, you're missing the opportunity of fixing the 
> error
> or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
> you insert a reference to 8113bis.
> On the other hand, if there is no error or gap, you don't need "Updates:"
> at all. (Unfortunately, we don't have an "Extends:" header.)
>   Brian
>> 
>> Yours,
>> Joel
>> 
>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>>> Reviewer: Brian Carpenter
>>> Review result: Ready with Issues
>>> 
>>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> .
>>> 
>>> Document: draft-ietf-lisp-rfc8113bis-01.txt
>>> Reviewer: Brian Carpenter
>>> Review Date: 2018-12-19
>>> IETF LC End Date: 2018-12-27
>>> IESG Telechat date:
>>> 
>>> Summary: Ready with issues
>>> 
>>> 
>>> Comments:
>>> -
>>> 
>>> I note that this is being raised from Experimental to the standards 
>>> track.
>>> Presumably that depends on the base LISP spec becoming PS.
>>> 
>>> Minor issues:
>>> -
>>> 
>>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>>> explain which text is updated. This is in contrast to RFC8113, which
>>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>>> this draft claim to update rfc6830bis? I'm going to assume that
>>> is an error.
>>> 
>>> In fact, why wasn't the definition of the LISP Packet Types registry
>>> moved into the base spec (rfc6830bis)? That is where it belongs.
>>> 
>>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>>> in them that needs updating should be updated! The fact is that 
>>> rfc8113bis
>>> extends rfc6830bis, which is not the same thing as "updates".
>>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>>> there should be a normative reference in 6830bis to 8113bis.
>>> 
>>> 
>> 
 
 ___
 lisp mailing list
 lisp@ietf.org
 https://www.ietf.org/mailman/listinfo/lisp
> 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

Mohmad to comment.

Dino

> On Dec 18, 2018, at 8:49 PM, Joel M. Halpern  wrote:
> 
> That is the other fix he offered.  Just remove the updates tag.
> I will leav eit to you and the the authors to determine which is correct.
> Yours,
> Joel
> 
> On 12/18/18 11:43 PM, Dino Farinacci wrote:
>> 8113bis should say that is it *extending* the type field so we can have more 
>> types. The word “update” I always had a problem with because it can be 
>> interpreted as “replacing". Replacing something to fix a problem.
>> 8113 is simply asking for one of the type value codepoint, so there can be 
>> another format to have more types.
>> Dino
>>> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
>>> 
>>> Authors: that sounds like a reasonable addition to me?
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
 On 2018-12-19 15:46, Joel M. Halpern wrote:
> This is part of the package to move the coherent set of base LISP specs
> to PS.
> 
> The reason we did this rather than folding it into 6830bis / 6833bis is
> that we had originally simply cited 8113, and then realized that needed
> to move to PS along with everything else.  It seemed (and is) simpler to
> do it separately rather than to further modify 6830bis / 6933bis.
> 
> As for why it updates 6833bis, that is because one of the cahnges in
> moving the set to PS was to improve the split as to which information
> belonged in which document.
 OK, but I still don't find it logical The text doesn't explain which part 
 of
 6833bis is impacted, and normally these days we require such an 
 explanation.
 And if there is an impact, you're missing the opportunity of fixing the 
 error
 or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
 you insert a reference to 8113bis.
 On the other hand, if there is no error or gap, you don't need "Updates:"
 at all. (Unfortunately, we don't have an "Extends:" header.)
Brian
> 
> Yours,
> Joel
> 
> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>> 
>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>> 
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> .
>> 
>> Document: draft-ietf-lisp-rfc8113bis-01.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-12-19
>> IETF LC End Date: 2018-12-27
>> IESG Telechat date:
>> 
>> Summary: Ready with issues
>> 
>> 
>> Comments:
>> -
>> 
>> I note that this is being raised from Experimental to the standards 
>> track.
>> Presumably that depends on the base LISP spec becoming PS.
>> 
>> Minor issues:
>> -
>> 
>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>> explain which text is updated. This is in contrast to RFC8113, which
>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>> this draft claim to update rfc6830bis? I'm going to assume that
>> is an error.
>> 
>> In fact, why wasn't the definition of the LISP Packet Types registry
>> moved into the base spec (rfc6830bis)? That is where it belongs.
>> 
>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>> in them that needs updating should be updated! The fact is that 
>> rfc8113bis
>> extends rfc6830bis, which is not the same thing as "updates".
>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>> there should be a normative reference in 6830bis to 8113bis.
>> 
>> 
> 
>>> 
>>> ___
>>> lisp mailing list
>>> lisp@ietf.org
>>> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Joel M. Halpern]

That is the other fix he offered.  Just remove the updates tag.
I will leav eit to you and the the authors to determine which is correct.
Yours,
Joel

On 12/18/18 11:43 PM, Dino Farinacci wrote:

8113bis should say that is it *extending* the type field so we can have more types. 
The word “update” I always had a problem with because it can be interpreted as 
“replacing". Replacing something to fix a problem.

8113 is simply asking for one of the type value codepoint, so there can be 
another format to have more types.

Dino


On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:

Authors: that sounds like a reasonable addition to me?

Yours,
Joel

On 12/18/18 10:48 PM, Brian E Carpenter wrote:

On 2018-12-19 15:46, Joel M. Halpern wrote:

This is part of the package to move the coherent set of base LISP specs
to PS.

The reason we did this rather than folding it into 6830bis / 6833bis is
that we had originally simply cited 8113, and then realized that needed
to move to PS along with everything else.  It seemed (and is) simpler to
do it separately rather than to further modify 6830bis / 6933bis.

As for why it updates 6833bis, that is because one of the cahnges in
moving the set to PS was to improve the split as to which information
belonged in which document.

OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.
On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)
Brian


Yours,
Joel

On 12/18/18 9:25 PM, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-lisp-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date:

Summary: Ready with issues


Comments:
-

I note that this is being raised from Experimental to the standards track.
Presumably that depends on the base LISP spec becoming PS.

Minor issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.






___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Dino Farinacci]

8113bis should say that is it *extending* the type field so we can have more 
types. The word “update” I always had a problem with because it can be 
interpreted as “replacing". Replacing something to fix a problem. 

8113 is simply asking for one of the type value codepoint, so there can be 
another format to have more types.

Dino

> On Dec 18, 2018, at 9:24 PM, Joel M. Halpern  wrote:
> 
> Authors: that sounds like a reasonable addition to me?
> 
> Yours,
> Joel
> 
> On 12/18/18 10:48 PM, Brian E Carpenter wrote:
>> On 2018-12-19 15:46, Joel M. Halpern wrote:
>>> This is part of the package to move the coherent set of base LISP specs
>>> to PS.
>>> 
>>> The reason we did this rather than folding it into 6830bis / 6833bis is
>>> that we had originally simply cited 8113, and then realized that needed
>>> to move to PS along with everything else.  It seemed (and is) simpler to
>>> do it separately rather than to further modify 6830bis / 6933bis.
>>> 
>>> As for why it updates 6833bis, that is because one of the cahnges in
>>> moving the set to PS was to improve the split as to which information
>>> belonged in which document.
>> OK, but I still don't find it logical The text doesn't explain which part of
>> 6833bis is impacted, and normally these days we require such an explanation.
>> And if there is an impact, you're missing the opportunity of fixing the error
>> or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
>> you insert a reference to 8113bis.
>> On the other hand, if there is no error or gap, you don't need "Updates:"
>> at all. (Unfortunately, we don't have an "Extends:" header.)
>>Brian
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 12/18/18 9:25 PM, Brian Carpenter wrote:
 Reviewer: Brian Carpenter
 Review result: Ready with Issues
 
 Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
 
 I am the assigned Gen-ART reviewer for this draft. The General Area
 Review Team (Gen-ART) reviews all IETF documents being processed
 by the IESG for the IETF Chair.  Please treat these comments just
 like any other last call comments.
 
 For more information, please see the FAQ at
 .
 
 Document: draft-ietf-lisp-rfc8113bis-01.txt
 Reviewer: Brian Carpenter
 Review Date: 2018-12-19
 IETF LC End Date: 2018-12-27
 IESG Telechat date:
 
 Summary: Ready with issues
 
 
 Comments:
 -
 
 I note that this is being raised from Experimental to the standards track.
 Presumably that depends on the base LISP spec becoming PS.
 
 Minor issues:
 -
 
 "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
 explain which text is updated. This is in contrast to RFC8113, which
 explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
 this draft claim to update rfc6830bis? I'm going to assume that
 is an error.
 
 In fact, why wasn't the definition of the LISP Packet Types registry
 moved into the base spec (rfc6830bis)? That is where it belongs.
 
 Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
 in them that needs updating should be updated! The fact is that rfc8113bis
 extends rfc6830bis, which is not the same thing as "updates".
 If the WG thinks that implementers of 6830bis need to read 8113bis,
 there should be a normative reference in 6830bis to 8113bis.
 
 
>>> 
> 
> ___
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Joel M. Halpern]

Authors: that sounds like a reasonable addition to me?

Yours,
Joel

On 12/18/18 10:48 PM, Brian E Carpenter wrote:

On 2018-12-19 15:46, Joel M. Halpern wrote:

This is part of the package to move the coherent set of base LISP specs
to PS.

The reason we did this rather than folding it into 6830bis / 6833bis is
that we had originally simply cited 8113, and then realized that needed
to move to PS along with everything else.  It seemed (and is) simpler to
do it separately rather than to further modify 6830bis / 6933bis.

As for why it updates 6833bis, that is because one of the cahnges in
moving the set to PS was to improve the split as to which information
belonged in which document.


OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.

On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)

Brian



Yours,
Joel

On 12/18/18 9:25 PM, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-lisp-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date:

Summary: Ready with issues


Comments:
-

I note that this is being raised from Experimental to the standards track.
Presumably that depends on the base LISP spec becoming PS.

Minor issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.








___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Brian E Carpenter]

On 2018-12-19 15:46, Joel M. Halpern wrote:
> This is part of the package to move the coherent set of base LISP specs 
> to PS.
> 
> The reason we did this rather than folding it into 6830bis / 6833bis is 
> that we had originally simply cited 8113, and then realized that needed 
> to move to PS along with everything else.  It seemed (and is) simpler to 
> do it separately rather than to further modify 6830bis / 6933bis.
> 
> As for why it updates 6833bis, that is because one of the cahnges in 
> moving the set to PS was to improve the split as to which information 
> belonged in which document.

OK, but I still don't find it logical The text doesn't explain which part of
6833bis is impacted, and normally these days we require such an explanation.
And if there is an impact, you're missing the opportunity of fixing the error
or gap in 6833bis, so the reader of 6833bis will be none the wiser unless
you insert a reference to 8113bis.

On the other hand, if there is no error or gap, you don't need "Updates:"
at all. (Unfortunately, we don't have an "Extends:" header.)

   Brian

> 
> Yours,
> Joel
> 
> On 12/18/18 9:25 PM, Brian Carpenter wrote:
>> Reviewer: Brian Carpenter
>> Review result: Ready with Issues
>>
>> Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>> .
>>
>> Document: draft-ietf-lisp-rfc8113bis-01.txt
>> Reviewer: Brian Carpenter
>> Review Date: 2018-12-19
>> IETF LC End Date: 2018-12-27
>> IESG Telechat date:
>>
>> Summary: Ready with issues
>> 
>>
>> Comments:
>> -
>>
>> I note that this is being raised from Experimental to the standards track.
>> Presumably that depends on the base LISP spec becoming PS.
>>
>> Minor issues:
>> -
>>
>> "This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
>> explain which text is updated. This is in contrast to RFC8113, which
>> explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
>> this draft claim to update rfc6830bis? I'm going to assume that
>> is an error.
>>
>> In fact, why wasn't the definition of the LISP Packet Types registry
>> moved into the base spec (rfc6830bis)? That is where it belongs.
>>
>> Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
>> in them that needs updating should be updated! The fact is that rfc8113bis
>> extends rfc6830bis, which is not the same thing as "updates".
>> If the WG thinks that implementers of 6830bis need to read 8113bis,
>> there should be a normative reference in 6830bis to 8113bis.
>>
>>
> 

___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp

Re: [lisp] Genart last call review of draft-ietf-lisp-rfc8113bis-01

[Joel M. Halpern]

This is part of the package to move the coherent set of base LISP specs 
to PS.


The reason we did this rather than folding it into 6830bis / 6833bis is 
that we had originally simply cited 8113, and then realized that needed 
to move to PS along with everything else.  It seemed (and is) simpler to 
do it separately rather than to further modify 6830bis / 6933bis.


As for why it updates 6833bis, that is because one of the cahnges in 
moving the set to PS was to improve the split as to which information 
belonged in which document.


Yours,
Joel

On 12/18/18 9:25 PM, Brian Carpenter wrote:

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-lisp-rfc8113bis-01

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-lisp-rfc8113bis-01.txt
Reviewer: Brian Carpenter
Review Date: 2018-12-19
IETF LC End Date: 2018-12-27
IESG Telechat date:

Summary: Ready with issues


Comments:
-

I note that this is being raised from Experimental to the standards track.
Presumably that depends on the base LISP spec becoming PS.

Minor issues:
-

"This document updates I-D.ietf-lisp-rfc6833bis." The text doesn't
explain which text is updated. This is in contrast to RFC8113, which
explains clearly how it updates RFC6830 (*not* RFC6833). Why doesn't
this draft claim to update rfc6830bis? I'm going to assume that
is an error.

In fact, why wasn't the definition of the LISP Packet Types registry
moved into the base spec (rfc6830bis)? That is where it belongs.

Since rfc6830bis (and rfc6833bis) are still under IESG review, anything
in them that needs updating should be updated! The fact is that rfc8113bis
extends rfc6830bis, which is not the same thing as "updates".
If the WG thinks that implementers of 6830bis need to read 8113bis,
there should be a normative reference in 6830bis to 8113bis.




___
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp