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