On 5/8/19 6:37 AM, Christer Holmberg wrote:
Hi, A couple of comments: Q1: In general, I like a "lightweight" process for producing a bis, instead of having a number of update specs, or spending much time on a bis the old way for a minor change/update. But, while it's easier, I still think we need to be rather conservative when it comes to producing bis. For example, external SDOs reference our RFCs, and it is typically easier for them to adopt an update spec to a referenced RFC than to replace the referenced RFC with a bis.
I find this a bit surprising; but I've made a note to check with our various liaisons about whether they think this kind of process would cause a problem, and, if so, what we might be able to do to help other SDOs in the face of such changes.
Q2: Related to Q1, assume that we have two cases what would justify a bis. Those cases are however completely unrelated to each other. Should we make two bis, or should we fix both cases in a single bis?
That's the sort of thing I would expect a working group to make a decision about. Currently, WGs decide whether to roll updaing documents together or whether to keep them separate. I expect it would be a very similar decision-making process.
Q3: Regarding deprecated technology, isn't removing deprecated technology a good use-case for a bis using the lightweight process? I guess this is related to Q2: if the original reason for the bis is to fix feature A, could we in the same bis remove deprecated technology?
I would certainly hope so. The point, however, is that we're not going to *require* that work to be done before a bis document can be produced.
/a
