[pim] Gorry Fairhurst's No Objection on draft-ietf-pim-sr-p2 mp-policy-14: (with COMMENT)

Gorry Fairhurst via Datatracker <[email protected]>
Newsgroups gmane.ietf.pim
Message-ID <175430300674.1028810.8381396669618197946@dt-datatracker-5bd446d5fd-c47nq>
Gorry Fairhurst has entered the following ballot position for
draft-ietf-pim-sr-p2mp-policy-14: 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-pim-sr-p2mp-policy/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I did not find any transport-specific concerns in my review of this document.

Thank you for the TSV-ART review by David Black, who noticed one
discrepancy that I think could usefully be addressed:

"- Section 2 says: "An SR P2MP policy is a specialized form of an SR policy as
defined in[RFC9256] ..." - Section 2.1 says: "A SR P2MP Policy is uniquely
identified by the tuple <Root, Tree-ID>, where: ..." - RFC 9256 Section 2.1
says: "An SR Policy MUST be identified through the tuple <Headend, Color,
Endpoint>."

I don't understand how <Root, Tree-ID> is a "specialized form of" <Headend,
Color, Endpoint> that satisfies the RFC 9256 "MUST" requirement quoted above.
In particular, Color appears to be missing from <Root, Tree-ID>. I'm reading
"specialized form of" as implying a "subtype of" relationship, which may be
more restrictive than what was intended.

I suggest adding a paragraph to the end of Section 2.1 (SR P2MP Policy
Identification) that explains the relationship between those two types of
identification tuples and how policies are uniquely identified in an
environment that uses both RFC 9256 SR Policies and this draft's SR PMP
Policies."



_______________________________________________
pim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.