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

Dino

> On Sep 25, 2018, at 2:22 AM, <[email protected]> 
> <[email protected]> wrote:
> 
> 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 protected]] De la part de Dino Farinacci
>> Envoyé : lundi 24 septembre 2018 19:39
>> À : Alvaro Retana
>> Cc : [email protected]; The IESG; [email protected];
>> [email protected]
>> 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
>> 
>>> On Sep 24, 2018, at 8:33 AM, Alvaro Retana <[email protected]> wrote:
>>> 
>>> On September 11, 2018 at 12:23:04 PM, Dino Farinacci ([email protected])
>> wrote:
>>> 
>>> Hi!
>>> 
>>> I’m back to this document…after the Defer...
>>> 
>>> ...
>>>>> (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.
>>>> 
>>>> Done.
>>> The text is there, but the tag in the header is missing ("Obsoletes: 6833
>> (if approved)”).
>>> 
>>> 
>>> 
>>>>> (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)
>>>> 
>>>> 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.
>>> 
>>> 
>>> 
>>>>> (5) Because of the point above, this draft should (at least) Update
>> rfc8113
>>>>> (see also below).
>>>> 
>>>> 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.
>>> 
>>> 
>>> 
>>>>> (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.
>>>> 
>>>> I’m yielding to the lisp-chairs and Deborah for this one.
>>> 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.
>>> 
>> 
>> _______________________________________________
>> lisp mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/lisp

_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp

Reply via email to