see inline — Chris Inacio SEC AD
> On Wednesday, Oct 21, 2026 at 10:52 AM, Les Ginsberg (ginsberg) > <[email protected] (mailto:[email protected])> wrote: > Christopher - > > Thanx for your thorough review. > One response inline. > > > -----Original Message----- > > From: Christopher Inacio via Datatracker <[email protected]> > > Sent: Wednesday, October 21, 2026 6:25 AM > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected] > > Subject: Christopher Inacio's No Objection on > > draft-ietf-lsr-l2-bundle-member- > > remote-id-10: (with COMMENT) > > > > Christopher Inacio has entered the following ballot position for > > draft-ietf-lsr-l2-bundle-member-remote-id-10: No Objection > > > > 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/about/groups/iesg/statements/handling- > > ballot-positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-l2-bundle-member-remote-id/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for the quick update, I'll remove my discuss. I believe there could > > be > > slightly more clarity between the possibility of sending 0s as an identifier > > vs. not advertising anything because the router doesn't know the remote ID. > > > > But as written, I believe this is implementable. > > > > ~-~-~-~-~-~-~-~-~-~-~- > > > > Thanks to Brian W. for the SECDIR review. > > > > Thanks to the authors for a clear (especially for the non-BGP audience) and > > concise draft. > > > > I also support Med's comment about the diagram in section 5 and would > > change > > his comment to say that the field should be labeled `reserved` with a > > statement > > as to how it should be transmitted (e.g. all zeros). > > > [LES:] IS-IS (unlike OSPF) does not pad TLV fields to a 32 bit boundary. Nor > would it help if we did since TLVs are sent inside an LSP which has many TLVs > - none of which are defined to start on a 32 bit boundary. > So this comment is not applicable. > The diagram has been updated as per Med's comment (i.e., removing the > unnecessary portion of the bit numbers). > > [ci] makes sense. that works too. > > > Les > > > >
signature.asc
Description: PGP signature
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
