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. >> ### 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
