[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)
>My preference would definitely be for ABNF (for field-level >validation) but we should use the same approach for all the standards. >Anybody strongly *opposed* to ABNF? My only qualm with ABNF is that it’s not supported in JSON Schema for field-level validation; only regexes can be used [0]. [0] http://spacetelescope.github.io/understanding-json-schema/reference/regular_expressions.html Regards, Ivan On 1/21/16, 4:24 AM, "Trey Darley" <trey@soltra.com> wrote: >On 18.01.2016 12:01:40, Mark Davidson wrote: >> >> Would it make sense to start a spec type document so that these >> conversations can be tracked there? IMO something like the twigs >> document but for CybOX (or even do these in the twigs document, then >> decide the tearline between STIX/CybOX later on would be fine). Just >> so long as we have text that we are continually updating as progress >> toward a spec I think we will be in good shape. >> > >Excellent feedback, Mark, spot-on! Ivan and I are currently discussing >how we can most effectively pivot from Github wiki pages focused on >proposals around specific issues to something more like a >comprehensive draft spec. Both the STIX and TAXII SCs have set a good >example for us to follow; the major outstanding question is how to >deal with the nascent cti-common schema/library for constructs that >span multiple CTI standards. > > >> Note2: I’m making this comment off of >> https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-Address-Object-Refactoring#ipv4-address-object---option-1. >> If that’s not the right one, my comment should still be applicable >> to whatever we’re doing. >> >> Presuming we go with the optional /32, I would offer this text as a start: >> >> Field Name: ipv4_address >> Type: string >> Description: An IP address or CIDR block denoting either a single IP >> address or a range of IP addresses, respectively. The accept syntax >> defines a required IP address (e.g., 1.2.3.4) with an optional >> subnet mask (e.g., /32). Omitted subnet masks MUST be interpreted as >> “/32”. >> > >Thanks for the draft normative text, Mark! (Ivan and I appreciate all >the help we can get!) > >> >> Accept syntax: (Are we doing ABNF or regex for this? The regex for >> IPs / CIDR blocks is kind of ugly: >> http://blog.markhatton.co.uk/2011/03/15/regular-expressions-for-ip-addresses-cidr-ranges-and-hostnames/) >> > >My preference would definitely be for ABNF (for field-level >validation) but we should use the same approach for all the standards. >Anybody strongly *opposed* to ABNF? > >-- >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 always possible to add another level of indirection." --RFC 1925
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]