Hi Med, That looks fine to me. Thanks!
Regards Brian Carpenter On 2019-01-10 20:42, [email protected] 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 : [email protected] [mailto:[email protected]] >> Envoyé : vendredi 21 décembre 2018 07:57 >> À : Dino Farinacci; Brian E Carpenter >> Cc : Joel M. Halpern; [email protected]; [email protected]; draft-ietf-lisp- >> [email protected] >> 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:[email protected]] >>> Envoyé : vendredi 21 décembre 2018 00:29 >>> À : Brian E Carpenter >>> Cc : Joel M. Halpern; BOUCADAIR Mohamed TGI/OLN; [email protected]; >>> [email protected]; [email protected] >>> 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 <[email protected]> >>> 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, <[email protected]> >>> <[email protected]> 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:[email protected]] >>>>>>>>>> Envoyé : mercredi 19 décembre 2018 19:00 >>>>>>>>>> À : BOUCADAIR Mohamed TGI/OLN >>>>>>>>>> Cc : Joel M. Halpern; Brian E Carpenter; [email protected]; >>> [email protected]; >>>>>>>>>> [email protected] >>>>>>>>>> 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, <[email protected]> >>>>>>>>>> <[email protected]> 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:[email protected]] >>>>>>>>>>>> Envoyé : mercredi 19 décembre 2018 06:37 >>>>>>>>>>>> À : Joel M. Halpern >>>>>>>>>>>> Cc : Brian E Carpenter; [email protected]; [email protected]; draft- >>> ietf-lisp- >>>>>>>>>>>> [email protected] >>>>>>>>>>>> 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 >> <[email protected]> >>> 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 >>> <[email protected]> >>>>>>>>>> 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 >>>>>>>>>>>>>>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/lisp >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> >>>> > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
