Hi Erik, Thanks for your review and please check inline below for responses. We will include these changes in the next update.
On Fri, Feb 11, 2022 at 10:40 AM Erik Kline via Datatracker < nore...@ietf.org> wrote: > Erik Kline has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-16: 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/blog/handling-iesg-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-spring-segment-routing-policy/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > [S1; nit] > > * The sentence starting with "While" appears to be sentence fragment. > > perhaps just: ". While" -> ", while" > KT> Ack > > [S2.1; nit] > > * s/null address/unspecified address/ > > * s/comprising of/comprising/ (though see UTF-8 comment below) > KT> Ack > > [S2.1, 2.6; comment] > > * It seems unnecessarily restrictive to require names be in ASCII. How > about RFC 5198/UTF-8? If these names are purely for human consumption > anyway, I wonder if isn't best to allow the humans to name things in > their native language(s)... (I'm not sure if BCP 18 applies here.) > KT> These names are also signaled via routing protocols such as BGP and PCEP. This point did come up for discussion in the WGs ( https://mailarchive.ietf.org/arch/msg/spring/Wj3eNx_EBHtDrYVYTCYIlJ2Yq_w/) and it was decided to stick to printable ASCII for consistency between the protocols and architecture specs. > > [S4; question] > > * For each of the uses of "IPv4 Prefix" and "IPv6 Global Prefix" should > there be an additional "Unicast" qualifier before "Prefix"? If multicast > prefixes are acceptable or understand (somehow) to be out of scope, then > no worries. > > KT> The types defined in the document are all unicast since all of them are either associated with a node (i.e. Prefix Segment) or associated with a link address (i.e. Adjacency Segment). This does not preclude future documents from introducing new types that use multicast addresses. > [S8; nit] > > * s/of where come/of which some/? > KT> Ack Thanks, Ketan
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
