Hi Roman, On Mon, Sep 23, 2024 at 5:36 PM Roman Danyliw <r...@cert.org> wrote:
> Hi Druhv! > > > > Thanks for the follow-up. > > > > *From:* Dhruv Dhody <d...@dhruvdhody.com> > *Sent:* Monday, September 23, 2024 5:45 AM > *To:* Roman Danyliw <r...@cert.org> > *Cc:* pce@ietf.org > *Subject:* Re: [Pce] AD Review of > draft-ietf-pce-segment-routing-policy-cp-17 > > > > *Warning:* External Sender - do not click links or open attachments > unless you recognize the sender and know the content is safe. > > > > Hi Roman, > > > > Thanks for taking on the AD role for this I-D. > > > > On Sat, Sep 21, 2024 at 12:35 AM Roman Danyliw <r...@cert.org> wrote: > > > > > > ** Section 4.2.1 > SR Policy Name: SR Policy name, as defined in [RFC9256]. It SHOULD > be a string of printable ASCII characters, without a NULL terminator. > > The use of SHOULD here implies that the encoding could be something other > than printable ASCII. That would be prohibited by the text in Section 2.1 > of RFC9256. Perhaps s/SHOULD/must/. > > Same comment for nearly identical text in Section 4.2.3 > > > > Dhruv: FWIW past RFCs that encode strings in PCEP have used a similar > language - RFC 8231, RFC 9358! That said, I don't mind making a change > going forward. > > > > [Roman] Does the WG remember why this “SHOULD” was used? Would a UTF > string or non-printable ASCII be acceptable since the “SHOULD” suggests > there are cases where printable ASCII need not be used? > > > Dhruv: Not speaking for the WG, but my understanding of the SHOULD in the past was that as an implementation I will be liberal in what I accept and not throw an error if I receive non-printable ASCII characters from the peer. Thanks! Dhruv > Roman > > >
_______________________________________________ Pce mailing list -- pce@ietf.org To unsubscribe send an email to pce-le...@ietf.org
