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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

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


Subject: Re: [cti-cybox] IP Address Notation (or: I Love CIDR When It's Talking About More Than One IP Address)


On 22.01.2016 09:08:14, Jason Keirstead wrote:
> These are two different problems.
> 
> The way grammar is defined in an RFC or other spec and the way a
> library validates that grammar are aligned pretty much never. Do
> standard libraries use ABNF to validate the format of IPs? No they
> do not...
> 

Hi, Jason -

You assert that standard libraries don't use ABNF for input
validation. While that is surely true in a large number of cases [0],
there are plenty of standard libraries that do input processing via
parsers generated from ABNF (a la lex/yacc).

But setting aside that little nit, the real question is what do we as
a TC want to do in terms of specifying field-level validation? Ivan
already pointed out that ABNF isn't going to work with JSON Schema.
Looking to the "IDs should be UUIDs" proposal John Wunder shared
yesterday, I see both ABNF and JSON Schema (PCRE subset) definitions
for CTI Object IDs.

There are fields where we *should* provide this level of specificity
in the standards. But which fields? All? If not, what's a useful
heuristic in making that determination?

My strong preference would be that where we choose to provide this
level of specificity, that we do it in JSON Schema. We already have
enough of a problem keeping UML models in sync with JSON Schema
without adding to it the challenge of keeping ABNF and regex field
restrictions in sync.

Thoughts?


[0]: If I had a dollar for every parser out there in the wild that
     naively attempts to parse context-sensitive input formats via
     regex, I could retire today. :-P

-- 
Cheers,
Trey
--
Trey Darley
Senior Security Engineer
4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
Soltra | An FS-ISAC & DTCC Company
www.soltra.com
--
"It is easier to move a problem around (for example, by moving the
problem to a different part of the overall network architecture) than
it is to solve it." --RFC 1925

Attachment: signature.asc
Description: PGP signature



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