Quantcast

unsubscribe xccdf-dev

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

unsubscribe xccdf-dev

charlespak



-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Harrison,
Tim
Sent: Friday, July 01, 2011 10:40 AM
To: Multiple recipients of list
Subject: RE: Deprecation of Group extension


Hi Charles,

I think we're throwing the baby out with the bath water here.

Lack of usage does not infer lack of interest or support.  I think a
significant amount of content was written based on content which did not
make use of this capability and is why you do not see much, if any, use in
content today.  From what I recall most, if not all, SCAP validated tools
were tested to support group extension which addresses the potential for
lack of support.  I think there could be benefit in retaining group
extension as we move forward and begin to try and provide some form of
content management paradigm which minimizes the need to create new and
subsequently to perform maintenance.  It seems to me that there are a number
of other items that are rarely, if ever, used so why this and not also
those? If we consider that the ability to include an external Benchmark(u)
in another Benchmark(v) is supported and there exists a need to modify some
aspect of a Rule(x) in Group (w) within Benchmark(u).  It is my
understanding that without Group extension iRule(x) !
 could not be extended by Rule(z) in Group(y) from Benchmark(v), but instead
Rule(z) would need to include the needed modification plus any unmodified
aspects of Rule(x).  As a result there would be duplication of content and a
need to ensure the duplicate content is updated when updates are made to the
original.  However, if Group(y) could extend Group(w) Rule(z) could simple
extend Rule(x) and override the needed items which must be modified.  If
this understanding is correct, then not allowing group extension would tend
to limit the augmentation argument for including external benchmarks as
discussed at developer. days.

I'm not sure how it prevents profile tailoring, but in my mind, as twisted
as it may be, the unique rule ids could be context driven, think xpath.
There may be some challenges, but I think we could at least take some clues
from xpath and/or programming languages which support
extension/inheritance/multiple-instantiation.  It does complicate manual
tailoring, but this issue could be mitigated if we had a well-funded solid
tool for tailoring Benchmarks which could abstract away some, if not all, of
the complexity involved.  Most of the complexity issues could probably be
addressed by defining new constraints and/or elaborating on the expected
behavior.

Based on your explanation it just does not follow that this is broken.  I
would agree there is room for improvement, but I don't see getting rid of it
being an improvement.

V/r,
Tim Harrison
[hidden email]
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Schmidt, Charles
M. [[hidden email]]
Sent: Monday, June 20, 2011 12:59 PM
To: Multiple recipients of list
Subject: RE: Deprecation of Group extension

Hi Tim,

My recollection is that there were two primary reasons that deprecation went
forward: 1) no one was using group extension, and 2) that group extension
required the auto-generation of unique Rule IDs, which would then prevent
Profile tailoring, complicate manual tailoring, and complicate reporting.
Due to point 2, the community was faced with doing a lot of work to develop
mechanics so that there could be compatibility on Group extension. Given the
lack of use, the community decided to remove the feature rather than allow
it to remain in a broken state.

>The inheritance model set forth in the XCCDF specification specifies
>that a Rule (m) can extend a Rule (h) if Rule (h) is a direct child of
>a Group (d)
which
>is also an ancestor of Rule (m).  My understanding of "ancestor" is
>such
that
>there must be a direct line between Rule(m) and Group (d).  If this is
>the correct understanding then if Rule (m) is a child of Group(j) which
>is a
sibling
>of Group(d) then Rule (m) cannot extend Rule (h) as it is not an ancestor.

Your description is correct.

>So, when using the term ancestor is direct-line inferred?

Yes, at least between containing Groups. (That is, if one were to draw a
line from the Benchmark (we'll call this the top of the line) to some leaf
Group (the bottom of a line) via a set of containing Groups, a Rule could
extend any other Rule that was a child of a Group-or-Benchmark at the same
point on the line as it or higher.)

>I see
>Group extension helping to maintain the original grouping(s) as
>including
the
>Rules on their own throughout a Benchmark may complicate maintenance
>tasks.  Additionally, it seems to go against the specifications
>suggestion
that
>an organization might define a foundation XCCDF document with the
>expectation that it will be extended.

I can see your point and can certainly imagine cases where this might occur.
However, in practice, there doesn't seem to be much demand for these uses,
possibly due to the resulting reporting confusion that this would entail.

If there is a desire to reverse the previous decision and keep Group
extension in, then the community is going to need to develop mechanics so
that Group extension is not as disruptive to normal processing as it is
right now. Those certainly could be worked out, but right now all indicators
are that this would be a lot of work for a feature that no one is using
anyway. Does anyone else think that this is a capability worth revisiting?

Thanks,
Charles

>-----Original Message-----
>From: [hidden email] [mailto:[hidden email]] On Behalf Of
>Harrison, Tim
>Sent: Tuesday, June 14, 2011 2:47 PM
>To: Multiple recipients of list
>Subject: FW: Deprecation of Group extension
>
>Given the proposed deprecation of Groups extending other Groups a
>question comes to mind.  Consider, that someone creates base Rules
>which are contained in a Group and intended to be extended by other
>Rules.  I see Group extension helping to maintain the original
>grouping(s) as including
the
>Rules on their own throughout a Benchmark may complicate maintenance
>tasks.  Additionally, it seems to go against the specifications
>suggestion
that
>an organization might define a foundation XCCDF document with the
>expectation that it will be extended.
>
>
>
>The inheritance model set forth in the XCCDF specification specifies
>that a Rule (m) can extend a Rule (h) if Rule (h) is a direct child of
>a Group (d)
which
>is also an ancestor of Rule (m).  My understanding of "ancestor" is
>such
that
>there must be a direct line between Rule(m) and Group (d).  If this is
>the correct understanding then if Rule (m) is a child of Group(j) which
>is a
sibling
>of Group(d) then Rule (m) cannot extend Rule (h) as it is not an ancestor.
>
>
>
>So, when using the term ancestor is direct-line inferred?
>
>
>
>If not, is deprecating the ability for Groups to extend other Groups
muddying
>the waters for Rules extending other Rules and/or the creation of
Foundation
>XCCDF documents?
>
>
>
>V/r,
>
>Tim Harrison
>[hidden email]


---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the body. You
will need to send this from the email account that you used to initially
subscribe to xccdf-dev.



---------------------------------------------------------------

To unsubscribe from this mailing list, please send an e-mail to
[hidden email] with the words "unsubscribe xccdf-dev" in the
body. You will need to send this from the email account that you
used to initially subscribe to xccdf-dev.

Loading...