[spring] Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Mon, 21 September 2020 18:24 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: spring@ietf.org
Delivered-To: spring@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2133A0B72; Mon, 21 Sep 2020 11:24:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-spring-srv6-network-programming@ietf.org, spring-chairs@ietf.org, spring@ietf.org, Bruno Decraene <bruno.decraene@orange.com>, Joel Halpern <jmh@joelhalpern.com>, jmh@joelhalpern.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <160071265366.14948.8163350323208659826@ietfa.amsl.com>
Date: Mon, 21 Sep 2020 11:24:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/Q9_NahAmiShmAoRIHJ0WcWvMSmw>
Subject: [spring] Roman Danyliw's Discuss on draft-ietf-spring-srv6-network-programming-19: (with DISCUSS and COMMENT)
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2020 18:24:14 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-spring-srv6-network-programming-19: 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-spring-srv6-network-programming/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 3.1. (In case I missed it, please provide the obvious reference) Per “In such a case, the semantics and format of the ARG bits are defined as part of the SRv6 endpoint behavior specification”, is “endpoint behavior specification” Section 4 or another document? If the former, I don’t see any references to argument bits in the pseudo-code of the Section 4.* subsections. If the latter, what document? Can the behaviors be polymorphic (i.e., same network behavior accepting different arguments)? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for responding to the SECDIR review (and thank you to Brian Weis for doing it) ** Section 3.2. Per “An SR Source Node cannot infer the behavior by examination of the FUNCT value of a SID”, isn’t there at least some hint provided by the use of the FUNCT from the IANA registry? ** Section 3.2. Per “Function 11 associated with the behavior End.X …” AND Per “Function 12 associated with the behavior End.X …” The initial registrations for Endpoint Behavior per Section 10.2.1 suggest that Function 11 and 12 are End.T. ** Section 4.1. Pseudo-code without formal definition might be open to interpretation. My nits (which likely apply to other sections) are that: -- it might not be clear that S03, S06 and S10 are effectively returns/exits from this “behavior”, and if they are run, S12-S15 should never be reached (otherwise Segments Left or Hop Limit = -1) -- (for consistency) the IF … ELSEIF … END construct is used in Section 4.8, but not here. -- What does it mean to indent the code? For example S06 is: S06. Send an ICMP Time Exceeded message to the Source Address, Code 0 (Hop limit exceeded in transit), Interrupt packet processing and discard the packet. I can see why “Code 0 …” is indented under “Send an … “ as this is a line wrap, but why is “Interrupt packet processing?” ** A few other psuedo code nits: -- Section 4.1. S05 uses “IPv6 Hop Limit” but S12 uses “Hop Limit”. Recommend consistency. -- Section 4.4. Per S05. Is “next header” purposely lower case? I asked because it looks like explicit field names are in upper case (e.g., S03 says “Segments Left field”). -- Section 4.16.3. As a style/consistency note, the other sections which check the upper header type seem use of a construct of != 41 or 4 to “Process per Section 4.1.1”. (e.g., Section 4.4, 4.5, 4.6, etc.) ** Section 8. Given how meticulously the Section 4 guidance was described, it would be helpful to say that the HMAC TLV processing, if present, happens as a notional Step “S0” per guidance in Section 2.1.2.1 of RFC8754. ** Editorial Nits: -- Section 3.2. Typo. s/an network/a network/ -- Section 3.2. Typo. s/is minimum/is minimal/
- [spring] Roman Danyliw's Discuss on draft-ietf-sp… Roman Danyliw via Datatracker
- Re: [spring] Roman Danyliw's Discuss on draft-iet… Pablo Camarillo (pcamaril)
- Re: [spring] Roman Danyliw's Discuss on draft-iet… Pablo Camarillo (pcamaril)
- Re: [spring] Roman Danyliw's Discuss ondraft-ietf… peng.shaofu
- Re: [spring] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [spring] Roman Danyliw's Discuss on draft-iet… Pablo Camarillo (pcamaril)
- Re: [spring] Roman Danyliw's Discuss on draft-iet… Roman Danyliw