> > To be honest at this point I'm sort of reflexively > > anti-process-documents, unless there's an actual problem > > that needs actual solution. > Which is why this isn't a process document. Watching this thread, I sense the authors trying hard not to make a process document, presumably because that would be hard, contentious, low probability of success, or something. But this idea that this ID is just a random collection of thoughts that folk might find interesting and therefore is informative is also pretty silly. Melinda has it right. First decide on what problem you are solving. If you can't do that, no solution (or document) will be satisfactory. IMO, this document absolutely needs to be a "process" document if it is to have any value. It is presumably trying to collect experience and wisdom. Presumably folk should make use of that experience and wisdom. If that is not a best practices document, what is? If this document doesn't provide guidance, in the "should" sense, with an explanation of why a particular practice makes sense and what can go wrong if that advice is not followed... then what good is it? > The origin is a WG chairs Edu session. Turns out there was not a lot > of clarity among a bunch of WG chairs about what they did and > why. My assumption is that if the chairs needed some time to > discuss this, the community might need that as well. If this document is clarifying, isn't that "updating" an existing document and charting new ground? I.e, how can this not be normative? > NOTE: This draft is intentionally non-normative. It is meant as a > guide to common practice, rather than as a formal definition of > what is permissible. What is the difference between a "guide to common practice" and a BCP? Is attempting to find a difference a case of hair splitting? Thomas