> On Dec 14, 2017, at 8:42 AM, [email protected] wrote: > > Ben, > > Thanks for your review and comments. > More inline. [Bruno] > >> From: Ben Campbell [mailto:[email protected]] >> >> Ben Campbell has entered the following ballot position for >> draft-ietf-grow-bgp-gshut-12: Yes >> >> 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/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-grow-bgp-gshut/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I'm balloting "yes" because I think it's important to publish this. But, like >> Alvaro, I wonder why this is not standards track, BCP, or just about >> anything >> but informational. So I support his DISCUSS, including his the comments on >> how >> to resolve it. > > [Bruno] Well noted: we now have 3 AD asking for STD track. > If you don't mind, to avoid duplication, I'll follow up on Alvaro's email. > (in short, STD track is ok for me)
Thanks, I will follow the discussion there. > >> -1, last paragraph: This references RFC 8174, but does not use the actual >> 8174 >> boilerplate. Is there a reason not to do so? > > [Bruno] My mistake: I had a comment to reference RFC 8174 rather than RFC > 2119. I was not aware that this also implied changing the text. > My understanding is the following: > OLD: > <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", > "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", > and "OPTIONAL" in this document are to be interpreted as > described in RFC 8174 <xref target="RFC8174"/>.</t> > > > NEW > <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", > "MAY", and "OPTIONAL" in this document are to be interpreted as > described in [BCP14] <xref target="RFC2119"/> <xref target="RFC8174"/> > when, and only when, they > appear in all capitals, as shown here.</t> > Works for me. > > > That being said, the irony is that RFC 8174 does not use an upper case > "should": > "Authors who follow these guidelines should incorporate this phrase near the > beginning of their document:" > https://tools.ietf.org/html/rfc8174#section-2 > I think that was carefully chosen, since the 2119/8174 keywords are intended to be about interoperability among protocol implementations more than requirements for the standards process. OTOH, RFC 2119 has an all-caps MUST in the sentence that states that, making it a self-violating requirement: "In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm." So, go figure :-) Thanks! Ben.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
