Brian, > For example, the word "pop" is used but still not defined. In computer > science, it generally refers to popping a stack. I understand that in the > MPLS context (a label stack) but not in the IPv6 context, where there is no > stack in the header.
You raised such comment on December 7th 2020 at the mailer with respect to draft-ietf-spring-srv6-network-programming-05. We iterated throughout December publishing the clarifications that you requested in rev06 and 07. https://mailarchive.ietf.org/arch/msg/spring/Y7XKvgshM8ces-HbkT2uQa37a_w/ https://mailarchive.ietf.org/arch/msg/spring/VpLfcUvDXHzMOU6fTE1_XPzhd68/ https://mailarchive.ietf.org/arch/msg/spring/mXcsWXaISqjzs7g_fJZYhcKabgY/ Also, the word pop is still used in the section title, but it has been removed from the definition of the behavior. Could you please see the latest version of the draft? Thanks, Pablo. -----Original Message----- From: Brian E Carpenter <brian.e.carpen...@gmail.com> Date: Wednesday, 26 February 2020 at 21:57 To: Lizhenbin <lizhen...@huawei.com>, "bruno.decra...@orange.com" <bruno.decra...@orange.com>, 'SPRING WG List' <spring@ietf.org> Cc: "6...@ietf.org" <6...@ietf.org>, draft-ietf-spring-srv6-network-programming <draft-ietf-spring-srv6-network-programm...@ietf.org> Subject: Re: Request to close the LC and move forward//RE: WGLC - draft-ietf-spring-srv6-network-programming Resent from: <alias-boun...@ietf.org> Resent to: <c...@cisco.com>, <pcama...@cisco.com>, <j...@leddy.net>, <daniel.vo...@bell.ca>, <satoru.matsush...@g.softbank.co.jp>, <lizhen...@huawei.com> Resent date: Wednesday, 26 February 2020 at 21:57 > In the process all the comments have been resolved Unfortunately, this is not true. For example, the word "pop" is used but still not defined. In computer science, it generally refers to popping a stack. I understand that in the MPLS context (a label stack) but not in the IPv6 context, where there is no stack in the header. The text explaining penultimate segment pop, quite apart from using "pop" in this undefined way, still does not explain how it is compatible with the RFC8200 interdiction of inserting or removing headers en route. It explicitly describes removing a header before the final routing hop, which is explicitly against RFC8200. As far as I'm concerned, these comments have been brushed aside. The fact that there's running code is good, but it doesn't resolve anything in the text. Regards Brian Carpenter _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
