[Cesg-all] Notes of the CESG Meeting on 24th October 2016

[Scott, Keith L.]

As I said in the meeting, I believe strongly that minimizing large (i.e. that would require additional agency reviews) technical RIDs coming during the final CESG poll would be a Good Thing.  My notion has always been that as an Area Director I had three opportunities to affect a book:


1.       During the initial CESG poll to release the book for agency review

2.       During the agency review RID process

3.       At the final CESG poll for publication

I get Peter’s point that CESG inputs during step 2 should be distinguished from agency inputs, and if that is indeed the case then I think we have a solution.  If it’s NOT the case then Ads should be more vigilant about raising issues during phase 1, with the intent/hope that no issues will need to be raised in phase 3.  But, if the AD finds that the book is simply not acceptable, stopping it at the last stage before publication, probably to be sent back for more agency reviews, is the right thing to do in order to maintain the overall technical quality and consistency of the evolving set of CCSDS Recommended Standards and Practices.

I read Nestor’s comments as essentially agreeing with the above.  CESG suggests that we try to get the issues identified and addressed early.  If we don’t/cant’, we risk stopping a book at the last stage and possibly sending it back for additional agency reviews, but we HAVE to maintain quality first.

                                --keith



From: CESG-All <cesg-all-bounces at mailman.ccsds.org> on behalf of Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Thursday, November 3, 2016 at 2:14 PM
To: Nestor Peccia <Nestor.Peccia at esa.int>, CCSDS All <cesg-all at mailman.ccsds.org>, "CCSDS Management Council(CMC at mailman.ccsds.org)" <CMC at mailman.ccsds.org>
Subject: Re: [Cesg-all] Notes of the CESG Meeting on 24th October 2016

Nestor, et al,

I have an real issue with one of the statements made in your meeting minutes.  This is under item 2, Other CESG Discussions, which states:

2. Other CESG discussions
1.         CESG Poll conditions:
·              Scope of conditions prior to Publication (including AD/DAD participation in Agency Reviews)
CESG suggests to the AD/DAD to minimize her/his conditions at time of CESG book publication polls. CESG members have the opportunity to raise technical issues prior / during Agency Review(s)
·              Are conditions un-rejectable by definition for all CESG Polls?
Conditions are not rejectable according to the YB, which contemplates a negotiation instance and possibly escalation if negotiation fails.
CESG recommends to raise PIDs (Poll Item Discrepancy) at least for showstopper conditions during polls and identify conditions that are non showstopper as such.
·              Discussion of CESG and AD responsibilities
   CESG reaffirms the spirit of the Proc & Org YB related to the AD responsibilities (for maintaining and upholding the overall technical quality and consistency of the evolving set of CCSDS Recommended Standards and Practices).

The issue, as we discussed extensively during the CESG meeting, is that CESG members have specific roles and duties in regard assuring the technical quality of CCSDS documents.  This was discussed at length and I provided the set of materials (attached) extracted from the CCSDS Organization and Processes (A02.1-Y-4) that document those duties.   My problem is that this wording in the minutes totally ignores the CESG responsibilities requiring review of all published documents and again suggests that somehow CESG conditions should be "minimized" and just treated as agency inputs.

As stated this is a total perversion of CESG responsibilities and it also, in essence, suggests that CESG inputs are just inputs from an agency instead of conditions placed by a member of the CCSDS Engineering Steering Group with the express intent of ensuring consistency of the CCSDS standards (sec 2.3.2.2.d), and …

" Sec 2.3.2.3.a, “maintaining and upholding the overall technical quality and consistency of the evolving set of CCSDS Recommended Standards and Practices”

There is no expectation that members of CCSDS agencies will attend to these stated CESG technical responsibilities.  These responsibilities are the expressly stated province of the CESG and they must not be swept under the rug or minimized lest the quality of CCSDS standards, as a whole, will suffer.  We already have far too many instances of CESG votes to "abstain, doesn't affect me" or "accept unconditionally", which signals, at least to me, that these CESG responsibilities are being taken lightly.

I acknowledge that one of the other concerns we discussed was that of efficient production of standards.  This is a concern, as is holding up review and publication for editorial "nits".  In fact, the addition in item 2 in this list, involving the adoption of a PIDs (Poll Item Discrepancy) for "showstopper conditions" was intended to make this distinction clear.  I think that the "scope of conditions" in item 1 was really resolved by the introduction of the PID and not by the notion that CESG inputs should be "minimized" or swept into the category of "agency inputs".

I would ask that you amend the minutes to reflect this actual outcome of the CESG discussion and not persist in promoting this "AD conditions may be treated as agency inputs" approach in the future.  The added clause in item 3 should also be added, since this was the specific topic that was discussed, not just random AD responsibilities such as proving meeting agendas.

One last comment on this topic.  During the reorganization we intentionally patterned our procedures and even the new organization on the Internet, particularly the Internet Engineering Task Force (IETF) and the Internet Engineering Steering Board (IESG). Our working organization is equivalent to the IETF and the CESG is equivalent to the IESG.  There are very many parallels in the CCSDS procedures and much of the wording in A02.1-Y-4 was lifted directly from IETF documents.

Just yesterday Scott Burleigh pointed me to an excellent IETF document called the Tao of the IETF (https://www.ietf.org/tao.html).  There is one particular section I would draw your attention to now, which we might consider adopting in this context to augment the CCSDS procedures, from Sec 2.2.2:

" The ADs for a particular Area are expected to know more about the combined work of the WGs in that Area than anyone else. On the other hand, the entire IESG reviews each Internet-Draft that is proposed to become an RFC. Any AD may record a "DISCUSS" ballot position against a draft if he or she has serious concerns. If these concerns cannot be resolved by discussion, an override procedure is defined such that at least two IESG members must express concerns before a draft can be blocked from moving forward. These procedures help ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the IETF protocols and that an AD's "pet peeve" cannot indefinitely block something. "

This is the IETF language, but AD == CCSDS AD and WG == CCSDS WGs.  Similarly, IESG == CESG.  I'm reluctant to suggest more "rules", but would offer for discussion in the CESG an approach patterned on this, as an augmentation to A02.1-Y-4 Polling process, Sec 5.3.5.   Perhaps we could add the following to the clauses in sec 5.3.5.4.3 Conditional Approval.

If these conditions cannot be resolved by discussion, an override procedure is defined such that at least two CESG or CMC members must express concerns before a document can be blocked from moving forward.

NOTE: These procedures help ensure that an AD's "pet project" doesn't make it onto the standards track if it will have a negative effect on the rest of the CCSDS protocols and that an AD's "pet peeve" cannot indefinitely block something.

We do not have such a process now and it occurs to me that this addition might be a useful one in the case of "stand-offs" like the recent one that prompted this discussion in the first place.

Regards, Peter


From: CESG-All <cesg-all-bounces at mailman.ccsds.org> on behalf of Nestor Peccia <Nestor.Peccia at esa.int>
Date: Thursday, November 3, 2016 at 12:27 AM
To: CCSDS Engineering Steering Group - CESG All <cesg-all at mailman.ccsds.org>, CMC <CMC at mailman.ccsds.org>
Subject: [Cesg-all] Notes of the CESG Meeting on 24th October 2016

Dear all,

Please find attached the notes of the last CESG meeting



ciao
nestor

this message and any attachments are intended for the use of the addressee or addressees only.

The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its

content is not permitted.

If you received this message in error, please notify the sender and delete it from your system.

Emails can be altered and their integrity cannot be guaranteed by the sender.



Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg-all/attachments/20161103/45477deb/attachment.html>