Erik, Please see inline (prefixed [Pavan])
Regards, -Pavan On Wed, Feb 12, 2025 at 7:31 PM Erik Kline <ek.i...@gmail.com> wrote: > > > On Wed, Feb 12, 2025 at 2:32 PM Vishnu Pavan Beeram <vishnupa...@gmail.com> > wrote: > >> Erik, >> >> Thanks for the review. Please see the inline below (prefixed VPB). >> >> Regards, >> -Pavan >> >> On Tue, Feb 11, 2025 at 10:23 PM Erik Kline via Datatracker < >> nore...@ietf.org> wrote: >> >>> Erik Kline has entered the following ballot position for >>> draft-ietf-pce-pcep-color-09: 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-pce-pcep-color/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> # Internet AD comments for draft-ietf-pce-pcep-color-09 >>> CC @ekline >>> >>> * comment syntax: >>> - https://github.com/mnot/ietf-comments/blob/main/format.md >>> >>> * "Handling Ballot Positions": >>> - >>> https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/ >>> >>> ## Comments >>> >>> ### Abstract >>> >>> * "a 32-bit numerical attribute" -> "a non-zero 32-bit numerical >>> attribute" >>> >>> vis. RFC 9256 S2.1, or perhaps that doesn't apply here? >>> >> >> [VPB] Good question. We use two references for the color attribute -- >> RFC9012 and RFC9256. In RFC9012, there is no restriction to use zero to >> represent a color, while in RFC9256, there is (as you point out) an >> explicit restriction. We decided to err on the side of being lenient in >> this scenario. We are also aware of at least one implementation that allows >> the use of "zero" to represent color. The following text in Section 2 would >> come into play if a PCC implementation does not allow using "zero" to >> represent a color: >> "If a PCC is unable to honor a color value passed in a PCUpd or a >> PCInitiate message, the PCC MUST reject the message and send a PCErr >> message with Error-type=19 (Invalid Operation) and error-value=TBD1 >> (Invalid color)." >> >> [VPB] That said, the authors don't have a strong preference for this. We >> will add the restriction if it is deemed essential to have parity with the >> semantics used in RFC9256. >> > > ah, yeah, I see -- sometimes zero is fine sometimes it might not be. > hurray for standards! > > I'm fine if you just want to leave a little note to implementers that says > "hey you: zero might not be a valid color in all contexts; YMMV" or > something. > [Pavan] Please see if the following text in Section 2 ( https://author-tools.ietf.org/iddiff?url2=draft-ietf-pce-pcep-color-10) addresses the comment: If a PCC is unable to honor a color value passed in a PCUpd or a PCInitiate message, the PCC MUST reject the message and send a PCErr message with Error-type=19 (Invalid Operation) and error-value=TBD1 (Invalid color). This is expected behavior in scenarios where a PCC implementation does not support a color value of zero for specific path setup types, and it receives that value in the COLOR TLV of a PCUpd or a PCInitiate message. Regards, -Pavan > >>> ### S2, S3.2, or thereabouts >>> >>> * How should a color value of zero be handled? >>> >> >> [VPB] This document does not make any special distinction for a >> zero-color tag. >> >>> >>> >>> >>> _______________________________________________ >>> Pce mailing list -- pce@ietf.org >>> To unsubscribe send an email to pce-le...@ietf.org >>> >>
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
