[SEA-XSG] XML Standards and Guidelines (XSG) combined with SSG, Thursday, 12 Nov, Argentum room, 2.06, from 1430-1600

Thu Nov 12 08:18:05 UTC 2015

Hi,

Took a very quick look at the other book and noticed that there were many
mentions of MACAO and rules about them.  Also seems to be details of other
registries.  I think this is a totally wrong approach.  This is sort of like
Social Security trying to define requirements for taxes or health
information systems because SSN is used for an identifier in those places.

I understood that SANA would be defining general registries such as
(distributed) organization registry and person registry.  Then my MACAO BB
could require that our users first register their organization in the SANA
organization registry and get an ID affiliated with that registration.  Then
my standard would specify how that organization ID fit into my needs for my
registry. 

From: sea-xsg-bounces at mailman.ccsds.org
[mailto:sea-xsg-bounces at mailman.ccsds.org] On Behalf Of John Garrett
Sent: Wednesday, November 11, 2015 8:59 PM
To: 'Shames, Peter M (312B)' <peter.m.shames at jpl.nasa.gov>; 'SEA-XSG'
<sea-xsg at mailman.ccsds.org>
Subject: RE: [SEA-XSG] XML Standards and Guidelines (XSG) combined with SSG,
Thursday, 12 Nov, Argentum room, 2.06, from 1430-1600

Hi Peter,

I don't expect to make it to the meeting due to other scheduled meetings.
Also since we are just receiving these documents, I haven't been able to
provide a sufficient review.  I provide some comments now and will try to
review it more once I return home.

First comment is in regards to inserting these items into the SAWG.  My
personal preference would be that they two efforts be kept separate.  I
think combining them will make scheduling to accommodate other meetings even
harder and it will become even harder to contribute to either one.

A procedural comment to keep in mind for future updates is to show the
updates.  That way I could have concentrated my review time to spend more
time reviewing the updated sections.  By the way, is there a Word version of
the current issue 1 SANA - Roles and Responsibilities available?  If so, I
could possibly to a compare to get that info.

Now for some comments on updated draft

Page ii - Delete. This is a extra Forward page

Page iv - Document Control - Should status list updates made?  I think most
books do so, but I'm not sure what is proper to do according to Pubs Manual.

Section 1.6 - conventions and definitions   - suggest name be changed.
Doesn't seem to describe any conventions used in the book. Perhaps rename to
Terminology as in other CCSDS documents. glossary has not been alphabetized.

Several places (e.g. Section 3.4 in Traceability bullet) talk about
standards track documents - since these YBs are not standards track
documents, but they are now creating and providing details of registries,
different or additional wording may be needed.  Or should tht restriction be
changed?

Section 3.6 - CESG relationship - I prefer the original version of this
section.  Some problems with updates is I think WGs should be specifying
what is needed in their books.  SANA operator should just be implementing
what is requested not making a determination of what should be done.  I also
think CESG should not have its options to decide things restricted as in the
Note.  Perhaps that is the normal situation, but CESG should have power to
make exceptions if they so desire.  Also I think notification of SANA should
be automated part of submission to CESG for approval.  I also think that Red
Book review should be able to go forward before SANA actually creates the
registry.  As long as they have the info they need, it should be OK.  We
don't need another thing to slow down the process.

Section 3.8 - SANA Considerations - again I prefer the original and I do not
like the updates.  Having different requirements for what is in draft
documents and final documents will cause problems.  This will mean that
extra efforts will be needed both by WG, by the CCSDS Editor, and by the
SANA operator to ensure that correct changes are made between the draft
document and the final document.

Also I'm not sure why user guidance is included in the SANA Considerations
section.

Section 3.9 Second paragraph - change "protocol writers" to "document
editors". 

Also I'm concerned that a whole new document of rules for a WG is being
created.  There are already many requirements being inflicted on the WG.  I
am concerned that if the policies cannot be included in this document, then
perhaps there are too many or too complicated to actually use.

Section 3.10 - SANA now exists.  Should probably remove text referring to
creation of SANA.

Why can't an Orange Book specify a register?  I prefer the original where a
CCSDS approved document can specify a registry. This was consistent in
original document.  Proposed updates here are inconsistent with CCSDS
approved documents mentioned in other sections.

Talk about re-use of registries should be general and not specific mentions
of specific registries (especially ones that do not yet exist) should be
here.

MACAO update will use SANA registries if they support the functionality
required and if we continue to require those items in the MACAO
registration.  As we've discussed, we will likely drop the need to register
some of the items now required.  WG should decide whether to use SANA
registries.  If WG decides not to use SANA registries, CESG should evaluate
reasons and approve it or not.  Hopefully SANA registries will be
implemented well and WGs will want to use them and not be forced to use
something they feel doesn't meet their needs.

Annex A: Eliminate.  This is incorrect since most of these are already SANA
registries. There is no longer a need for  a list of candidate registries.
SANA already provides a list of registries that it supports.  This list is
an excellent example of something that could be in a registry to prevent the
need to update the document whenever a change is made to the list.

>From the quick review, I'm not sure if this document is requiring any
registries.  If so, I think this document should take its own medicine and
include an actual SANA Considerations section.

I'll probably have more later, but it is late now.

Live, Laugh, Love, and Work for Peace,

-JOhn

From:  <mailto:sea-xsg-bounces at mailman.ccsds.org>
sea-xsg-bounces at mailman.ccsds.org [
<mailto:sea-xsg-bounces at mailman.ccsds.org>
mailto:sea-xsg-bounces at mailman.ccsds.org] On Behalf Of Shames, Peter M
(312B)
Sent: Tuesday, November 10, 2015 8:33 AM
To: SEA-XSG < <mailto:sea-xsg at mailman.ccsds.org> sea-xsg at mailman.ccsds.org>
Subject: [SEA-XSG] XML Standards and Guidelines (XSG) combined with SSG,
Thursday, 12 Nov, Argentum room, 2.06, from 1430-1600

Dear XSG members,

We nominally have a SEA-XSG meeting scheduled for Thursday afternoon.
Because there is no ability in the scheduling system to indicate two
different 1-2 hour meetings both the SANA Steering Group (SSG) and the XSG
are shown as separate meetings and in their own meeting rooms.

For Thursday, 12 Nov, we will be holding a single joint meeting of the SSG
and the XSG.  This will be in the Argentum room, 2.06, from 1430-1600.  I
have to do the Boot Camp from 1330-1430 or I would have started earlier.
The focus of the agenda will primarily be the SANA re-engineering topics,
relating to the proposed re-work of the SANA registries.  You are welcome to
join us for this discussion.  The documents are attached.  You will see that
the XML registries in the SANA are a topic of interest, so it may pay to
attend.  See attached SANA documents (revised YB and new RMP) to see what is
being proposed.

The primary XSG specific topic that I am aware of is that the CCSDS URN RFC
has been aproved by the IETF and is now awaiting final tech editor
processing.  This is extremely good news.  If there are other topics that
should be addressed at this meeting please bring then up now.  If needed we
will schedule a splinter session on Wed or Thursday to address them.  

I think you should all be aware that we are proposing to wrap this XSG work
into the SEA SAWG that is being re-started.   I do think that we will still
need something like an XML expert group to coordinate changes to the XML
registries, so the XSG in something like its present form and membership may
persist.  Comments on all of this are welcome.

Thanks, Peter

From: Shames Peter < <mailto:messenger at webex.com> messenger at webex.com>
Reply-To: Peter Shames < <mailto:peter.m.shames at jpl.nasa.gov>
peter.m.shames at jpl.nasa.gov>
Date: Tuesday, November 10, 2015 at 5:01 AM
To: Peter Shames < <mailto:peter.m.shames at jpl.nasa.gov>
peter.m.shames at jpl.nasa.gov>
Subject: (Forward to others) WebEx meeting invitation: SANA Steering Group

You can forward this invitation to others. 

Hello, 

Shames Peter invites you to join this WebEx meeting. 

SANA Steering Group 

Thursday, November 12, 2015 

2:30 pm  |  Europe Time (Berlin, GMT+01:00)  |  1 hr 30 mins 

<https://iso-meetings.webex.com/iso-meetings/j.php?MTID=m0119eb06bff29d68707
e72c3db2ea1e2> Join WebEx meeting

Meeting number: 

959 231 422 

Meeting password:

inSANA

Join by phone

0800-051-3810 Call-in toll-free number (UK)

+44-203-478-5289 Call-in toll number (UK)

Access code: 959 231 422

<https://iso-meetings.webex.com/iso-meetings/globalcallin.php?serviceType=MC
&ED=363869527&tollFree=1> Global call-in numbers  |
<http://www.webex.com/pdf/tollfree_restrictions.pdf> Toll-free calling
restrictions

<https://iso-meetings.webex.com/iso-meetings/j.php?MTID=mc9f4cceccda04ed22bc
1a1ac3ad9d51f> Add this meeting to your calendar.

Can't join the meeting?  <https://iso-meetings.webex.com/iso-meetings/mc>
Contact support. 

IMPORTANT NOTICE: Please note that this WebEx service allows audio and other
information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you automatically
consent to such recordings. If you do not consent to being recorded, discuss
your concerns with the host or do not join the session.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sea-xsg/attachments/20151112/cf07cb3d/attachment.html>