Re: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-ext-opt-param-11: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Thank you John for the explanations.

Got it about the IANA registry :)

And the goal of changing the figures is to ease the understanding indeed. But, I understand that this is slightly more complex than fixing a typo, OTOH, it is an editorial change and not a protocol change. Really up to you and your co-authors

-éric


-----Original Message-----
From: John Scudder <[e-mail]>
Date: Thursday, 22 April 2021 at 00:11
To: Eric Vyncke <[e-mail]>
Cc: The IESG <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Hares Susan <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's No Objection on draft-ietf-idr-ext-opt-param-11: (with COMMENT)

    Hi Éric,

    Thanks for your comments.

    > On Apr 12, 2021, at 10:57 AM, Éric Vyncke via Datatracker <[e-mail]> wrote:
    ...
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document. It sounds like it is really a
    > useful extension to BGP-4.
    > 
    > Having written that, I must admit that I failed to understand the mechanism at
    > first reading. It took me a while to cross reference this doc + IANA registry +
    > RFC 4271 (but, for sure, I am not a BGP SW engineer!).
    > 
    > I suggest to mention, in section 2, that the Code Capability IANA registry for
    > 255 was reserved per RFC 8810 (so not causing interoperation)

    Not quite! The code reserved in 8810 is a Capability Code. The code we’re reserving in this document is an Optional Parameter type. Capabilities nest inside Optional Parameters. (The reason it’s this way may qualify as ancient history by now.)

    > as well as using
    > the actual values 255 in figure 1 and finally add the figure 4.2 from RFC 4271
    > to be crystal clear for the reader.

    So, show two OPEN format diagrams: the non-extended, and the extended? I see your point, it could make some of the other text less painful as well; on the other hand, it’s a bigger rewrite than the other changes so I’m a little hesitant to tackle it at this late stage since the existing text has been pretty heavily reviewed by now. I’ll think on it, I’m not going to push it out with the other changes I’ll be posting today, though.

    > Should the "new speaker" behavior be specified when an "old speaker" close the
    > connection ? I.e., retry if possible without using this specification ?

    I don’t think so, because by definition (since we’ve mandated that the implementation MUST use the old format when possible) if the speaker sent the OPEN with the new format, it must need the new format in order to properly follow its configuration. I don’t want the router second-guessing the operator as to which capabilities are expendable; if this really has to be done the operator should intervene and make that decision.

    Regards,

    —John