Re: [GROW] I-D Action: draft-ietf-grow-wkc-behavior-01.txt

[Job Snijders <[e-mail]>]

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