Thanks, Matthew. I didn’t think of searching for it under the individual submission name; when I read “cross-reviewed” I interpreted that as WGLC, not WG adoption.
It looks to me as though there was no reply to the notification message you reference, do you agree? (Of course there might have been people who commented on the BESS list, but I don’t see anything cc’d to IDR.) It does seem to me as though, considering the unusually close association between this spec and an active IDR draft, it would have made sense to cross-WGLC it, including a specific pointer to the overlap. I mean, I acknowledge that might have come to nothing since there’s considerable overlap between the groups — but it’s not universal overlap. Anyway, it’s water under the bridge now. I’ve added the IDR chairs to the cc just in case any of them want to comment. Regards, —John > On Feb 17, 2022, at 5:52 AM, Bocci, Matthew (Nokia - GB) > <matthew.bo...@nokia.com> wrote: > > > > Hi John > > Regarding comment (1), we sent a notice to the IDR WG at WG Adoption time: > > [Idr] FW: [bess] WG adoption and IPR poll for > draft-dawra-bess-srv6-services-02 (ietf.org) > > > Regards > > Matthew > > From: John Scudder via Datatracker <nore...@ietf.org> > Date: Wednesday, 16 February 2022 at 21:39 > To: The IESG <i...@ietf.org> > Cc: draft-ietf-bess-srv6-servi...@ietf.org > <draft-ietf-bess-srv6-servi...@ietf.org>, bess-cha...@ietf.org > <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Bocci, Matthew (Nokia > - GB) <matthew.bo...@nokia.com>, Bocci, Matthew (Nokia - GB) > <matthew.bo...@nokia.com> > Subject: John Scudder's Discuss on draft-ietf-bess-srv6-services-11: (with > DISCUSS and COMMENT) > > John Scudder has entered the following ballot position for > draft-ietf-bess-srv6-services-11: 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/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-bess-srv6-services/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 1. The shepherd writeup for this document says “It also received an RTG DIR > review and cross-reviewed with the IDR working group”. Searching in my IDR > inbox and the IDR mailing list archives, I don’t find any sign of the > cross-review — can you please point me to it? > > 2. One area of concern I would have hoped IDR might have looked into is, the > document makes a creative use of the MPLS Label field of the NLRI to carry the > Function part of the SID. This means the SID is effectively split across the > NLRI and the Prefix-SID attribute. What are the potential error modes if the > Prefix-SID attribute should be lost from the route, while the NLRI is > retained? > > (An obvious way of addressing this particular concern would be to define a new > NLRI type with the desired semantics, instead of creatively repurposing fields > within an existing NLRI type contrary to their definitions. Such an NLRI type > would, for example, presumably state in its specification that if it was > received without an accompanying Prefix-SID attribute, that would constitute > an > error.) > > 3. As Warren Kumari points out in his DISCUSS, “leaks happen”. Subsequent > discussion turned quickly to the assertion that no, they don’t, in VPN address > families. Let’s accept that claim for the sake of conversation. It’s still the > case that sometimes (often?) routes are distributed from VPN address families > into the Global Internet table. When this is done, by default, all the path > attributes come along for the ride. Anyone who thinks this is just a > hypothetical case might want to look back to (for example) significant network > outages that were caused around a decade ago by leakage of BGP Attribute 128 > (ATTR_SET, RFC 6368) into the global Internet. > > The SIDs contained in these if-they-were-to-leak routes potentially give an > attacker a means of directing packets into a VPN customer’s internal network. > > 4. Speaking of Warren’s DISCUSS, the shepherd’s writeup indicates “solid [WG] > consensus”; however, there doesn’t seem to be consensus even amongst the > authors as to whether Sections 5.3 and 5.4 are appropriate. This is a fairly > fundamental disagreement! An illustration of the disagreement is > https://mailarchive.ietf.org/arch/msg/bess/K1JKxGn19BXALs3rUzUAaGTZi0Y/: > > “So I can see why some people may have thought oh since transport in SRv6 > comes > for free let's load it with services in an attribute and be done. Yes I can > see > that flattening this make it potentially easier (one less SAFI to enable), > *but > I am not sure we have reached a broad agreement here.* This comes as a > consequence of moving service prefixes from MP_REACH_NLRI (perhaps new format > and new SAFI) to an attribute.” > > (Emphasis added.) > > It's of course possible for an author to be in the rough as regards consensus, > just as any other WG contributor, but it's a little unusual, and this > disagreement doesn't even seem to have been previously aired. For this reason, > I have to question the strength of the consensus behind this document, and ask > the WG chairs to weigh in regarding whether consensus on at least this point > needs to be checked before we proceed forward. > > 5. Finally, I have to question the length of the author list. As I’m sure you > know, the guidance is to limit author lists to no more than five, other than > under unusual circumstances. I would have expected to find an explanation of > the circumstances around the author list of this document in the shepherd > writeup; there is none. (It’s a specific check item in Guidelines to Authors > of > Internet-Drafts, https://www.ietf.org/how/ids/guidelines/) > > The easiest way to resolve this would be to trim the author list per the > suggestions in RFC 7322 §4.1.1, of course. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 1. I support Warren Kumari’s DISCUSS. > > 2. (Further comments TBD and I apologize for not providing them now; I wanted > to get this sent off though.) > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
