Yes, that would work. I don't think you need the first sentence, but I can live with it.
On Mon, Aug 31, 2020 at 3:04 AM Stephane Litkowski (slitkows) < slitk...@cisco.com> wrote: > Yep sorry. > > I would like to keep the cap code value that has been allocated. > > > > What about: > > This document does not define any new code point compared to <xref > target="RFC5549"/> > > RFC5549 added "Extended Next Hop Encoding" to the Capability Codes > registry, which was created by [RFC5492]. IANA is requested to update the > definition of that entry to refer instead to this document. > > The value allocated for this Capability Code is 5. > > > > > > > > *From:* Murray S. Kucherawy <superu...@gmail.com> > *Sent:* lundi 31 août 2020 10:53 > *To:* slitkows.i...@gmail.com > *Cc:* The IESG <i...@ietf.org>; draft-ietf-bess-rfc5549revis...@ietf.org; > bess-cha...@ietf.org; bess@ietf.org; Matthew Bocci < > matthew.bo...@nokia.com> > *Subject:* Re: Murray Kucherawy's Discuss on > draft-ietf-bess-rfc5549revision-04: (with DISCUSS and COMMENT) > > > > Hi, > > > > I saw the change. However the text of that section still says "new" > twice. Since the registration was made by RFC 5549, it isn't appropriate > to call it "new". > > > > Any comments on the text I proposed in my DISCUSS? It's more typical of > "bis" style work, in my experience. > > > > -MSK > > > > On Mon, Aug 31, 2020 at 1:49 AM <slitkows.i...@gmail.com> wrote: > > Hi Murray, > > I have uploaded a new revision that clarifies the IANA section. > > -----Original Message----- > From: Murray Kucherawy via Datatracker <nore...@ietf.org> > Sent: mercredi 26 août 2020 21:01 > To: The IESG <i...@ietf.org> > Cc: draft-ietf-bess-rfc5549revis...@ietf.org; bess-cha...@ietf.org; > bess@ietf.org; Matthew Bocci <matthew.bo...@nokia.com> > Subject: Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: > (with DISCUSS and COMMENT) > > Murray Kucherawy has entered the following ballot position for > draft-ietf-bess-rfc5549revision-04: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bess-rfc5549revision/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > An easy one, but necessary IMHO: > > I'm confused by the IANA Considerations section. It looks like a verbatim > copy from RFC 5549 which made the original registration for "Extended Next > Hop Encoding", but this isn't actually a new registration. Shouldn't this > therefore be something like the following? > > NEW: > > RFC 5549 added "Extended Next Hop Encoding" to the Capability Codes > registry, which was created by [RFC5492]. IANA is requested to update the > definition of that entry to refer instead to this document. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this document. It was easy to read even for people like me who > don't get involved in routing too much. > > Thank you also for the shepherd writeup, which (unlike most lately) > actually answered the question "Why is this the proper type of RFC?" > > > >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
