Stewart, thanks for your review. I have entered a DISCUSS ballot on this point.
Alissa > On Aug 27, 2018, at 2:55 AM, Stewart Bryant <stewart.bry...@gmail.com> wrote: > > Clearly I think it makes better sense to sequence the drafts in dependency > order so that everything lines up. > > However, ultimately that is a decision to be made by the Chair and > responsible AD. > > Stewart > > On 27/08/2018 08:48, Luigi Iannone wrote: >> Hi Steward, >> >> see inline…. >> >> On 24 Aug 2018, at 12:58, Stewart Bryant <stewart.bry...@gmail.com >> <mailto:stewart.bry...@gmail.com>> wrote: >>> >>> Reviewer: Stewart Bryant >>> Review result: Ready >>> >>> 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 >>> >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq >>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>>. >>> >>> Document: draft-ietf-lisp-gpe-06 >>> Reviewer: Stewart Bryant >>> Review Date: 2018-08-24 >>> IETF LC End Date: 2018-09-06 >>> IESG Telechat date: Not scheduled for a telechat >>> >>> Summary: >>> >>> This is a well written draft, and I assume that everyone in the WG is happy >>> that the reduction in size of the Nonce/Map-Version field will not be a >>> problem >>> in operational networks. >>> >>> However, I do have a question of why this is being published now on the >>> Standards Track with a normative reference to draft-ietf-lisp-6834bis. >>> draft-ietf-lisp-6834bis is only a few weeks old. It will take its time to >>> get >>> through the IETF process and of course technically may change. If >>> draft-ietf-lisp-gpe is approved by the IESG it will simply sit on the RFC >>> Editor's queue until draft-ietf-lisp-6834bis gets through the system, and >>> even >>> then if there is a change to draft-ietf-lisp-6834bis, then >>> draft-ietf-lisp-gpe >>> may need to be pulled all the way back to the WG depending on the nature of >>> the >>> change. >>> >>> Maybe the plan is that ietf-lisp-rfc6830bis will only take a short while to >>> finish because I see that other bis drafts will also stall on it. If not I >>> would have thought that a better approach would be to make this experimental >>> and point to RFC6834. Then, when RFC6834bis is published to make this draft >>> a >>> PS pointing to it. >> >> These are we small documents. I am not sure this would really be necessary. >> We do not expect big changes in any bis document, since they are just the PS >> version of deployed technology. >> So the risk to have the gee document come back to the WG to do any change is >> quite inexistent. >> >>> >>> Whatever the conclusion this matter will need to be clearly written up in >>> the >>> Shepherd's report. >> >> I am the shepherd of the document and I duly pointed out this fact in my >> writeup, check point 14 of: >> https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/shepherdwriteup/ >> <https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/shepherdwriteup/> >> >> Ciao >> >> L. >> >> >>> >> >> >> >> >>> Major issues: No technical issues, but see summary. >>> >>> Minor issues: None >>> >>> Nits/editorial comments: None >>> >>> >> > > _______________________________________________ > Gen-art mailing list > gen-...@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ lisp mailing list lisp@ietf.org https://www.ietf.org/mailman/listinfo/lisp
