Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt
Could you change "community set" to "set community" in action items please. "community set" can also refer to a set of communities, the container kind of set. Regards, Jakob. -Original Message- From: GROW On Behalf Of heasley Sent: Monday, January 21, 2019 9:03 AM To: Job Snijders Cc: grow@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt Mon, Jan 21, 2019 at 01:51:50PM +0100, Job Snijders: > > On the other side, the sentence "Vendors SHOULD share the behavior of > > their implementations" perhaps can be made stronger by replacing the > > SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this > > document". s/share/clearly document/ is perhaps what is meant? ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt
Mon, Jan 21, 2019 at 01:51:50PM +0100, Job Snijders: > > On the other side, the sentence "Vendors SHOULD share the behavior of > > their implementations" perhaps can be made stronger by replacing the > > SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this > > document". s/share/clearly document/ is perhaps what is meant? ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt
See inline. On Mon, Jan 7, 2019 at 4:56 PM Jay Borkenhagen wrote: > Hello Grow, > > The draft-ietf-grow-wkc-behavior-01.txt posted today makes just a few > small changes w.r.t. -00: > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-grow-wkc-behavior-01.txt > > Specifically: > > - the Abstract has been adjusted to indicate more clearly what things > vendors should do and what things network operators should do. > > - some loose wording in the Introduction has been tightened up. > > - the Section 6 "Action Items" are clarified similarly to the > clarifications in the Abstract. Also, in response to WGLC comments > from David Farmer, a paragraph was added to urge network operators > not to depend on any assumed treatment of bgp communities by any > neighbor networks: for example, do not assume that your transmitted > NO_EXPORT will be honored, unless the neighbor confirms that it will > be. > Your statement effectively changes the three Well-Known Communities defined in RFC1997 from "MUST NOT" to "SHOULD NOT". Basically, if you can not rely on those communities not being stripped then "MUST NOT" is way too strong of a statement. Maybe formally updating RFC1997 and changing the definition of the three communities to "SHOULD NOT" is an appropriate addition to this document. Also, a meta-data link from RFC1997 to this document seems like a good idea in general and by effect references in IANA Well-Known Community Registry to this document as well. Thanks -- === David Farmer Email:far...@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SEPhone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 === ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt
resending to include working group On Fri, Jan 18, 2019 at 11:26:58AM +0100, Job Snijders wrote: > Dear Jay, > > On Tue, Jan 08, 2019 at 07:01:09PM -0500, Jay Borkenhagen wrote: > > Since Job's message of 10-December extending the WGLC by one week, I > > have seen only two replies, both on-list, both in support of > > publication. > > > > One respondent (Shunwan) recommended collecting more vendor defaults. > > I am not opposed to that, but (i) I would expect vendors (or possibly > > their customers) to volunteer that information, and (ii) I'm not sure > > the document is actually improved by listing more behaviors -- I think > > it's good enough to let people know that different behaviors exist, > > and that vendors are unlikely to change their defaults now, so network > > operators need to take care in this regard. > > That seems reasonable. > > > David Farmer also responded. David's point that some operators have > > been surprised by a neighbor network's handling of NO_EXPORT is valid. > > I believe that -01 addresses it -- just not in the way that David had > > suggested. > > > > So, how do you esteemed chairs suggest we proceed now? > > I think the document is mostly ready to proceed down the publication > pipeline, but speaking as WG participant I'm not entirely sure about a > normative term in the Action Items section: > > "Vendors MUST ensure that any well-known communities specified after > this document's publication are removed by the "community set" > action." > > While I think I understand the intent, but I'm not convinced this is the > right approach, the implications of the sentence are complex. Since > there is no formal definition of what "community set" means in all > contexts, we should treat it as pseudo-code, which means (lacking > definitions of what it /is/), we shouldn't be specifying what it /is > not/. What perhaps can be specified is that 'new WKC' should be treated > the same as the implementation treats regular communities when it comes > to add or remove actions, to avoid increasing the inconsistency? > > On the other side, the sentence "Vendors SHOULD share the behavior of > their implementations" perhaps can be made stronger by replacing the > SHOULD with a MUST. And perhaps remove the phrase "for inclusion in this > document". > > Another action item could be to suggest that operators should avoid > using routing policy language constructs that treat some communities > special, e.g. avoiding the use of 'community set' will result in easier > to read and more consistent configurations across multiple platforms. > > Kind regards, > > Job ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
