Hello Abdussalam: I added the suggested IANA https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-22#section-8.4 . I trust the IESG on the meaning of updating.
Stay safe, Pascal From: 6lo <6lo-boun...@ietf.org> On Behalf Of Abdussalam Baryun Sent: lundi 27 avril 2020 14:00 To: Benjamin Kaduk <ka...@mit.edu> Cc: 6lo-cha...@ietf.org; Pascal Thubert (pthubert) <pthubert=40cisco....@dmarc.ietf.org>; Mohit Sethi <mohit.m.se...@ericsson.com>; Rene Struik <rstruik....@gmail.com>; Shwetha Bhandari (shwethab) <shwet...@cisco.com>; 6lo@ietf.org; Erik Kline <e...@loon.com>; Jim Schaad <i...@augustcellars.com> Subject: Re: [6lo] AP-ND 22 On Mon, Apr 27, 2020 at 5:52 AM Benjamin Kaduk <ka...@mit.edu<mailto:ka...@mit.edu>> wrote: On Sun, Apr 26, 2020 at 09:10:33AM +0200, Abdussalam Baryun wrote: > The draft should indicated on top first page that it updates RFC6775, > 7400, and 8505, it only shows updating RFC8505. The 6775 case was discussed extensively during IESG Evaluation. Note that 8505 itself Updates 6775, and the changes in this document affect only what 8505 does (IIRC). I'm not sure why you want this document to update 7400 -- it seems to just be allocating some bits from the "6LoWPAN capability Bits" registry established by 7400. IMO it updates section 3.4 in RFC7400, it is not only adding bits, it is adding the way of using 6CIO, we would not add bits only to add tasks in protocols, (Well, it would be if the IANA considerations were updated to state that, at least.) Allocating bits from a registry is usually not seen to need an Updates relationship. yes IMO it should include also the IANA considerations best regards AB -Ben
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
