OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Comments received in and out of Public Review...


We discussed "accepting" comments received out of formal windows the other day, but in a sparsely attended meeting, so it bears repeating.


I have never seen any significant attention paid within the OASIS process to “only comments submitted during the PR”.  The intent of almost every rule in OASIS is to increase public comment, and to increase the perspectives that can improve a standard. That said, even a comment submitted during a PR can be rejected by a TC, but the TC usually records a reason why it was rejected.

 

The restrictions on comments are almost always to protect the IP of a standard, that is, to ensure that people can implement software that uses the standard without fear of soma claim. Standards elsewhere have been queered by someone injecting some encumbered IP into the standard, and then that same person coming back later and claiming the right to a fee per device or per message. It is less trouble in such circumstances to abandon the standard than to fight it out. A party may assert a later claim, waiting wait until the standard is in wider use to assert the IP, counting on larger investments to preserve use.

 

Most of the restrictions on OASIS participation are to protect against this type of poisoning. A company typically asserts that any words contributed by active participants are IP contributed by that company to the TC, and that grant includes any work done world-wide embraced by those words, whether the participant is aware of the work or not. OASIS TCs tend to have small subject matter and tight focus. Changes of TC charter can only restrict the scope of the TC, not expand it. The OASIS company rep must approve all TC participation. TC observers may not speak during meetings because there is no assumption that they are authorized to contribute any IP.  And so on.

 

The comment process is of a part with this concern with producing a standard with clean IP. Comments must come in through the Comments listserve, that it be public and visible. Enrollment to the listserve includes accepting the IP rules governing the TC (its in the subscription verification).

 

The exception is when a TC is trying to complete work or needs to protect its work. There are those that may prefer the pre-standard environment, and act to slow or cripple the standard. There are those that are never timely, or come late to the party and want to re-open issues long discussed, and long closed. The OASIS process enables the TC to get past this by bypassing certain submissions. This is where the “outside the comment period” rules MAY be applied.

 

TC’s I have worked on have accepted comments on nearly every working draft, whether in public review or not.

 

The rule prohibiting work during a PR has the intent of increasing the number of comments received. Nothing cuts off public participation and comments more effectively than to say “We already changed that part you worked on coding for a week on”. With a stable draft, implementers share a document widely, attempt implementations, provide better comments. The complement is that the TC must be able to move on. It is reasonable for a TC moving to final publication after five public reviews to opt to ignore further comments on PR01.

 

A TC may also announce going into a PR that they are limiting comments. “We haven’t touched Section  2 since the last PR, so only Sections 3 and 4 are up for review.” The OASIS process supports such claims from a TC when it is submitting a CD to the OASIS staff. Even so, I have never been on a TC that would not accept a inciteful and useful comment or correct a serious error in the static section (Section 2 in this example) if one came in.

 

In most TCs, the bulk of the PR comments seem to come from TC members. The Comment process allows one to assemble one’s thoughts, be specific, perhaps to get sign-off from internal IP and brand managers, and put them in front of the TC. If the comment is significant (as compared to “merely” editorial), it provides a means for the TC to document its decision to provide traceability which increases openness and can provide the basis for not re-fighting the same issues again and again.

 

Considered this way, a TC member MAY want to submit a formal comment at any time, whether during the PR or not. The TC may OPT to ignore it, or declare it to be already hashed out, but that is part of the process.

 

The end of the PR commenting process should be considered as permission to move on, and only rarely as a hard legalistic deadline. I also note, that I worked on two standards in which the consortium that includes all Electric Power Wholesalers in North America participated had a single active member of the TC. The ponderous decision making process in that highly regulated industry meant that each and every issue they raised was (1) submitted as a formal comment and (2) submitted after the PR was over.


I personally submitted some comments by email (rather than in meeting) right before PR while we were waiting for the PR to formally start with the intent that it be part of the process.


On the other hand a late comment received when the work is done may and perhaps should invoke the rules to complete the work.


tc



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]