Meral, thanks for your review. Pascal, thanks for the updates. I entered a No Objection ballot.
Alissa > On Sep 2, 2020, at 4:46 PM, Meral Shirazipour > <[email protected]> wrote: > > Hi, > Thanks a lot. > > Best, > Meral > > From: "Pascal Thubert (pthubert)" <[email protected]> > Date: Thursday, August 27, 2020 at 5:13 AM > To: Meral Shirazipour <[email protected]>, "[email protected]" > <[email protected]> > Subject: RE: Gen-ART Last Call review of draft-ietf-roll-turnon-rfc8138-09 > > Hello Meral > > Just to let you know that I published -11 that addresses your comments. Since > -10 the reference to MOP says “For a MOP value of 7, the compression MUST be > used by default …“ and the reference to values above is gone. > > Please let me now if we are all set; > > Take care; > > Pascal > > From: Pascal Thubert (pthubert) > Sent: mercredi 19 août 2020 10:20 > To: Meral Shirazipour <[email protected]>; [email protected]; > [email protected] > Subject: RE: Gen-ART Last Call review of draft-ietf-roll-turnon-rfc8138-09 > > Hello Meral > > Many thanks for your review! > > For now there is the MoP value for 7 is not defined. When it is, it will > signal an extension. So it means future. This draft covers the transition > with legacy nodes. A MoP of 7 when defined will not be usable with legacy > nodes, there will be a flag day in between. > > We want that future to support RFC 8138 so there is no need for transition > flag. And we want it always on after that, leaving management control only if > that’s wanted. > > Additional note: the current mind of the group is that RPLv2 will be > indicated by a MoP field set to 7 and the new mode of operation indicated in > a new option. If that happens as expected, a value of MoP<7 will mean RPLv1. > We could not really cast that in stone in this little draft, it may still > change, so we only specify the code behaviour without expanding on that > background. > > Was that your questions? > > Keep safe; > > Pascal > > From: Meral Shirazipour <[email protected] > <mailto:[email protected]>> > Sent: mercredi 19 août 2020 09:03 > To: [email protected] <mailto:[email protected]>; > [email protected] > <mailto:[email protected]> > Subject: Re: Gen-ART Last Call review of draft-ietf-roll-turnon-rfc8138-09 > > 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-roll-turnon-rfc8138-09 > > Reviewer: Meral Shirazipour > Review Date: 2020-08-18 > IETF LC End Date: 2020-08-18 > IESG Telechat date: NA > > > Summary: This draft is ready to be published as Standards Track RFC but I > have some comments. > > Major issues: > > Minor issues: > > Nits/editorial comments: > -[Page 4] Section 3: > "Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in > the DIO Base Object. For MOP values 0 to 6, the use of compression > depends on the "T" flag as specified in this document. A MOP value > of 7 and above MUST use compression by default and ignore the setting > of the "T" flag. > " > > It was not clear to me at first read why "A MOP value of 7 and above MUST use > compression by default and ignore the setting of the "T" flag" ? > > > Best Regards, > Meral > --- > Meral Shirazipour > Ericsson > Research > www.ericsson.com > <http://www.ericsson.com/>_______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
