Hi,
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.
At the end of the day, no matter whether it's an update or a bis, it's the actual changes/updates that matter. Also, when it comes to SDOs, backward compatibility has a big impact.
So, I wonder whether the draft should include some text regarding backward compatibility, and whether the lightweight process should not be used for such changes?
---
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.
I also think it would be good to include some text saying that, once the scope of a bis has been agreed upon, people should be allowed to add their favorite-thing-to-fix as the work progresses. Or, IF someone wants to add a fix/update A, adding that fix/update should go through the same process as for making the bis in the first place.
This of course apply to any draft we work on, but as we know the scope quite often change in our drafts.
Regards,
Christer
