Subject: Re: [bess] Murray Kucherawy's Discuss on draft-ietf-bess-rfc5549revision-04: (with DISCUSS and COMMENT)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 1 Sep 2020 21:01:56 -0700

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) <
[email-masked]> 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 <[email-masked]>
> *Sent:* lundi 31 août 2020 10:53
> *To:* [email-masked]
> *Cc:* The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; Matthew Bocci <
> [email-masked]>
> *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 <[email-masked]> wrote:
>
> Hi Murray,
>
> I have uploaded a new revision that clarifies the IANA section.
>
> -----Original Message-----
> From: Murray Kucherawy via Datatracker <[email-masked]>
> Sent: mercredi 26 août 2020 21:01
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Matthew Bocci <[email-masked]>
> 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?"
>
>
>
>