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


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-lang message

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

Subject: RE: [openc2-lang] Debugging option

Do you see the persistence of the parameter to be the length of an individual communication or something longer?


Would detailed logging of a firewall request, for example, log the individual request, or would it notify the requester of future firewall changes. Alternately, if port 17 (âQuote of the Dayâ) is blocked is it the intent to log all attempts to use port 17? Alternately, if port 17 is unblocked, do you want to see all use of port 17 logged?


Alternately, does every command merely have a DBG switch, and when it is set, more info is returned?


If the command is for an SBoM request, does it include, say, the CPU time spent gathering the information? Does Debug simply mean tell me whatever you have, but the actual content of the response is not standardized?


It would be good to have standards, but I think we need to go a little deeper on what sort of response is being imagined here.




From: openc2-lang@lists.oasis-open.org <openc2-lang@lists.oasis-open.org> On Behalf Of Brian Berliner
Sent: Monday, January 13, 2020 7:10 PM
To: duncan sfractal.com <duncan@sfractal.com>
Cc: openc2-lang <openc2-lang@lists.oasis-open.org>
Subject: Re: [openc2-lang] Debugging option


Hu Duncan,




It would be great if the LS had a standard way to indicate the verbosity of the response, which may or may not include debugging information. It's the kind of thing that has been hard to standardize, I think, as everyone has many opinions about how to do it and they are all often "right enough". So, I don't know if there are good examples for us to copy.


In Java, we use logging levels to indicate how verbose we want our logging to be. They are most typically "ERROR", "WARN", "INFO", "DEBUG", and "TRACE". Logging is not the same as API response verbosity or debugging, but you could imagine that verboseness can have levels too. We see this in many linux command-line apps which have a default verbose level, but accept a "-v" arg for making the output verbose, as well as a "-vv" for "even more verbose" and even a "-vvv" for "really, really verbose, like a TRACE".


I think you wanted to focus on "debugging" as opposed to "verboseness", and that's fine. I'm just pointing out that we'd want to allow for levels of debugging info as opposed to a boolean on/off setting... Numbers could be perfectly fine for that (which is essentially what the textual ones described above turn into, of course)...







On Mon, Jan 13, 2020 at 3:48 PM duncan sfractal.com <duncan@sfractal.com> wrote:

Preparing for the plugfest I noticed https://github.com/bberliner/openc2-json-schema/blob/master/src/test/resources/commands/good/query_features_extension_args_number.json has an extension arg for debugging. I think we should have a standard debugging parameter in args. As a security geek I think âproductionâ interfaces should provide as little info as possible ie no need to assist hackers -but as a developer writing/debugging I find the extra info on error conditions is quite helpful. So the answer to my dual personality is a debugging option to use in development but ignore in production. So I propose we add this argument to the language spec. 


iPhone, iTypo, iApologize

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