From david.black@emc.com Thu Dec 6 10:47:47 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B438C21F8599 for ; Thu, 6 Dec 2012 10:47:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oj9hkZm4Gzjf for ; Thu, 6 Dec 2012 10:47:44 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFC421F8826 for ; Thu, 6 Dec 2012 10:47:44 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qB6Ilf0D023790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2012 13:47:43 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Thu, 6 Dec 2012 13:47:34 -0500 Received: from mxhub03.corp.emc.com (mxhub03.corp.emc.com [10.254.141.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qB6IlYmU012473; Thu, 6 Dec 2012 13:47:34 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub03.corp.emc.com ([10.254.141.105]) with mapi; Thu, 6 Dec 2012 13:47:33 -0500 From: "Black, David" To: Adam Montville Date: Thu, 6 Dec 2012 13:47:32 -0500 Thread-Topic: Updated IODEF Enumeration Reference Format Draft Thread-Index: AQHNvQ3c5igWirSip0ScCVgUmvLL1JfuMxLggBO5WgCAClvW0A== Message-ID: <8D3D17ACE214DC429325B2B98F3AE712879BD396@MX15A.corp.emc.com> References: <18EDCB49-399F-44DC-BF11-9A77F3E459FC@tripwire.com> <8D3D17ACE214DC429325B2B98F3AE71284B5A565@MX15A.corp.emc.com> <74613456-C11E-434C-91FF-23F2AAF7B87D@tripwire.com> In-Reply-To: <74613456-C11E-434C-91FF-23F2AAF7B87D@tripwire.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712879BD396MX15Acorpemccom_" MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "" Subject: Re: [mile] Updated IODEF Enumeration Reference Format Draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 18:47:47 -0000 --_000_8D3D17ACE214DC429325B2B98F3AE712879BD396MX15Acorpemccom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, Thanks you for considering these comments. I have a couple of follow-ups: > So, what you're proposing is that the versioning information be attached = to id > rather than id_type. That seems reasonable to me. Yes, although I might say "associated with" as opposed to "attached to". For example, a useful (at least, IMHO) consequence is that if the same id i= s used in multiple versions of the same spec without change (e.g., new revi= sed spec versions add ids to enumerations but don't change existing ids), t= han this approach removes the need in IODEF to explicitly indicate which of= the various possible versions of the spec is involved. > In that message you mention guidance being provided to the Designated Exp= ert. > Where would that guidance be provided in the draft (or is it provided els= ewhere)? It would go in the IANA Considerations section - we (the WG) get to write t= hat guidance to help a future Designated Expert do the proverbial "right th= ing". Thanks, --David From: Adam Montville [mailto:amontville@tripwire.com] Sent: Thursday, November 29, 2012 3:29 PM To: Black, David Cc: Subject: Re: Updated IODEF Enumeration Reference Format Draft Hi David, Thank you for your diligence! I do appreciate it. Please see comments inline. Regards, Adam On Nov 17, 2012, at 7:42 AM, "Black, David" > wrote: Adam, Thanks for working on this draft. I see that the version is included in the id_type string prefix. I'm assuming that this version is the version number of the registered specification. That makes sense if the version doesn't change often and especially if a version change results in a change to the identifier format. How often does the version change for the specs that are the sources of the enumerations of interest? >From what I've seen, rarely. However, emerging enumerations could be used = and they might change more frequently. If the spec version changes often, and especially if enumeration identifiers from previous versions usually remain valid in new versions, an alternative approach would be to tie the version to the identifier format rather than the spec version - this could avoid having several dozen id_type strings for versions of a single spec. So, what you're proposing is that the versioning information be attached to= id rather than id_type. That seems reasonable to me. Please also take a look at these two emails that I sent to the list earlier= : identifier formats: http://www.ietf.org/mail-archive/web/mile/current/msg00= 853.html With respect to this message, which is about id and id_type formatting, I'm= happy to make adjustments to the draft where necessary. In that message y= ou mention guidance being provided to the Designated Expert. Where would t= hat guidance be provided in the draft (or is it provided elsewhere)? Additionally, I'm interested to know what others think about these approach= es. Again, I'm here to create a draft based on what the community wants to= see implemented, so chime in if you have an opinion in these matters. more on versions: http://www.ietf.org/mail-archive/web/mile/current/msg0085= 4.html Take and I had an opportunity to speak in Atlanta, and I understand the con= cern represented in the message above. This will be addressed in a forthco= ming revision. I have some additional editorial concerns that I'll send to you directly. Thanks, --David From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, November 07, 2012 12:32 PM To: > Subject: [mile] Updated IODEF Enumeration Reference Format Draft All: I'm pleased to submit draft-montville-mile-enum-reference-format-01 availab= le at http://www.ietf.org/id/draft-montville-mile-enum-reference-format-01.txt Changes: * IANA Table Request Changes * Removed "Name" * Added "Full Name * Added "Abbreviation" * Specified id_type to be _ * Reviewed text for scope statements and limited scope to IODEF, while a= lluding to the method's potential usefulness elsewhere. * Ensured that the Reference class diagram is explicitly referenced as [= IODEF]. * Updated IANA Considerations to request creation of the table * Updated IANA table format fields with simple descriptions I look forward to your comments. Regards, Adam W. Montville | Security and Compliance Architect CISA, CISSP Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com --_000_8D3D17ACE214DC429325B2B98F3AE712879BD396MX15Acorpemccom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Adam,

 

=

Thanks you for considering these comments.  I have a = couple of follow-ups:

 

> So, what you're proposing is that the ve= rsioning information be attached to id

 

= Yes,= although I might say “associated with” as opposed to “at= tached to”.

 

For example, a useful (at least, IMHO) consequenc= e is that if the same id is used in multiple versions of the same spec with= out change (e.g., new revised spec versions add ids to enumerations but don= ’t change existing ids), than this approach removes the need in IODEF= to explicitly indicate which of the various possible versions of the spec = is involved.

 =

> In that message you mention guidance being provid= ed to the Designated Expert.

> Whe= re would that guidance be provided in the draft (or is it provided elsewher= e)?  

 

It would go in the IANA Considerations section - we (the= WG) get to write that guidance to help a future Designated Expert do the p= roverbial “right thing”.

=  

Thanks,
--David

 

From: Adam Montville [mailto:a= montville@tripwire.com]
Sent: Thursday, November 29, 2012 3:29 P= M
To: Black, David
Cc: <mile@ietf.org>
Subj= ect: Re: Updated IODEF Enumeration Reference Format Draft

 

Hi David,

 

Thank you for your diligence!  I = do appreciate it.

 =

Please see comments inline.<= /o:p>

 

Regards,

<= o:p> 

Adam

 

On Nov 17, 2012, at 7:42 AM, "Black, David" <<= a href=3D"mailto:david.black@emc.com">david.black@emc.com> wrote:



 

Thanks for working on this draft.

=

 

I see that the versio= n is included in the id_type string prefix.

I’m assuming that this version is the version number of the reg= istered

specification.  That make= s sense if the version doesn’t change often

and especially if a version change results in a change to the i= dentifier

format. 

 

How oft= en does the version change for the specs that are the sources of

the enumerations of interest?<= /p>

 

From what I've seen, rarely.  However, emerging enu= merations could be used and they might change more frequently.



 

If the spec version changes often, and = especially if enumeration

identifiers = from previous versions usually remain valid in new versions,

an alternative approach would be to tie the version = to the identifier

format rather than t= he spec version - this could avoid having several

dozen id_type strings for versions of a single spec.

 

So, what you're proposing is that the versioning= information be attached to id rather than id_type.  That seems reason= able to me.

 =



 =

Please also take a look at these two = emails that I sent to the list earlier:

 

With respect to this message, which is abo= ut id and id_type formatting, I'm happy to make adjustments to the draft wh= ere necessary.  In that message you mention guidance being provided to= the Designated Expert.  Where would that guidance be provided in the = draft (or is it provided elsewhere)?  

 

Additio= nally, I'm interested to know what others think about these approaches. &nb= sp;Again, I'm here to create a draft based on what the community wants to s= ee implemented, so chime in if you have an opinion in these matters.



 

Take and I had an o= pportunity to speak in Atlanta, and I understand the concern represented in= the message above.  This will be addressed in a forthcoming revision.=



=

 

I have some additional edi= torial concerns that I’ll send to you directly.

=

 

Thanks,--David

 

From: = mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Adam Montville
Sent: Wednesday, November 07, 2012 12:32 PM=
To: <mile@ietf.org= >
Subject: [mile] Updated IODEF Enumeration Reference Format Draft<= /p>

 

<= div>

All:

 

I'm p= leased to submit draft-montville-mile-enum-reference-format-01 available at=

 =

 

Changes:<= o:p>

 <= /p>

  • IANA Table Request Changes
    • Removed "Name"
    • Added "Full Name
    • Added "Abbreviation"
  • Specified id_type to be <= Abbreviation>_<Version>
  • Reviewed text for scope statements and limited= scope to IODEF, while alluding to the method's potential usefulness elsewh= ere.
  • Ensured that the Reference class diagram is explicitly referenced as [IODE= F].
  • = Updated IANA Considerations to request creation of the table
  • Updated IANA table= format fields with simple descriptions

 

 

I look forward to your comments.

 

<= div>

Regards,

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif"'> 

Adam W. Montville | Security and Compliance Architect<= o:p>

CISA, CISSP

 

D= irect: 503 276-7661

Mobile: 360 471= -7815

 

TRIPWIRE | Take CONTROL<= o:p>

 

 

<= /div>

 

 

 

 

= --_000_8D3D17ACE214DC429325B2B98F3AE712879BD396MX15Acorpemccom_-- From david.black@emc.com Thu Dec 6 11:04:04 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FDD21F8690 for ; Thu, 6 Dec 2012 11:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwkVyQ4QiEPK for ; Thu, 6 Dec 2012 11:04:03 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0DD21F8432 for ; Thu, 6 Dec 2012 11:03:57 -0800 (PST) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qB6J3uAV015036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2012 14:03:57 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 6 Dec 2012 14:03:35 -0500 Received: from mxhub11.corp.emc.com (mxhub11.corp.emc.com [10.254.92.106]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qB6J3SU7031828; Thu, 6 Dec 2012 14:03:28 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub11.corp.emc.com ([10.254.92.106]) with mapi; Thu, 6 Dec 2012 14:03:28 -0500 From: "Black, David" To: Adam Montville , "" Date: Thu, 6 Dec 2012 14:03:26 -0500 Thread-Topic: IODEF Enum Reference Format - Unicode support? Thread-Index: AQHNzwpRUNHbSaH+bU2zRtF3rlP8/JgMKBOA Message-ID: <8D3D17ACE214DC429325B2B98F3AE712879BD3A2@MX15A.corp.emc.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: [mile] IODEF Enum Reference Format - Unicode support? X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Dec 2012 19:04:04 -0000 Hi Adam, Allow me to (try to) answer your question with another question :-) ... > * Should this draft support Unicode characters? =20 Does anyone know of any spec whose enumerations need non-ASCII Unicode characters now? If so, what do that spec's enumeration identifiers look like as character strings? > IODEF presently does not > support the Unicode character set, but I presume this will be one of the > addressed concerns when work on 5070-bis begins. Still, at issue is whet= her > Unicode support should simply be called out now rather than rely on 5070 > rework. Uhm - I'm afraid that "simply called out" Unicode support tends to be in the same mythical category as Santa Claus, the Tooth Fairy and the Easter Bunny ;-). I might suggest caution about what is wished for here. Thanks, --David > -----Original Message----- > From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of A= dam > Montville > Sent: Friday, November 30, 2012 9:52 AM > To: > Subject: [mile] Working on IODEF Enum Reference Format >=20 > All: >=20 > I'm working on the IODEF Enumeration Reference Format draft. Several > suggestions have been made since 02 publication during the week in Atlant= a. > Here's what's happening now: >=20 > * Abstract is being narrowed to the scope of IODEF exclusively >=20 > * The term "enumeration identifiers" is used consistently >=20 > * Additional guidance for and is provided >=20 > * Format of ReferenceName string is id_type:version:id >=20 > Open Questions: >=20 > * Should this draft support Unicode characters? IODEF presently does not > support the Unicode character set, but I presume this will be one of the > addressed concerns when work on 5070-bis begins. Still, at issue is whet= her > Unicode support should simply be called out now rather than rely on 5070 > rework. >=20 > Thoughts? >=20 > Adam >=20 > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile From johnp.field@emc.com Tue Dec 11 08:46:22 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3B921F888C for ; Tue, 11 Dec 2012 08:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUMgX0-KscuB for ; Tue, 11 Dec 2012 08:46:21 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id DDE5E21F888B for ; Tue, 11 Dec 2012 08:46:20 -0800 (PST) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBBGkGUM017050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Dec 2012 11:46:18 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd02.lss.emc.com [10.254.221.253]) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Tue, 11 Dec 2012 11:45:56 -0500 Received: from mxhub01.corp.emc.com (mxhub01.corp.emc.com [10.254.141.103]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBBGjsxg001974; Tue, 11 Dec 2012 11:45:55 -0500 Received: from mx14a.corp.emc.com ([169.254.1.248]) by mxhub01.corp.emc.com ([10.254.141.103]) with mapi; Tue, 11 Dec 2012 11:45:54 -0500 From: "Field, John" To: "mile@ietf.org" Date: Tue, 11 Dec 2012 11:45:53 -0500 Thread-Topic: [mile] RFC6546 possible editorial errata Thread-Index: Ac3OT8pf70q1PEcNRWuAaO1603nF/AJYnEqQ Message-ID: References: , <6.2.5.6.2.20121121074441.09c00288@resistor.net> , <8D3D17ACE214DC429325B2B98F3AE71284D40403@MX15A.corp.emc.com> <4FB1BD7D-F1B1-4A2C-B795-6DAB2B1163D8@tik.ee.ethz.ch> <0064D4AE-6339-4A97-97F7-3543B91595B1@tik.ee.ethz.ch> <50B78F21.9050001@ieca.com> In-Reply-To: <50B78F21.9050001@ieca.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Subject: Re: [mile] RFC6546 possible editorial errata X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2012 16:46:22 -0000 Sorry for the long message and for chiming in a bit late here...been busy t= rying to implement this stuff :-) I'd suggest a couple of points, which I think can summarize where we are, a= nd help us converge: - If the RID message was successful, then the Acknowledgement message shoul= d be optional. - return HTTP status code 200. - If the RID message was received OK (actual transport worked), but RID mes= sage was unsuccessful, then the (negative) Acknowledgement is required. - If the failure was in processing the RID message *content*, then = HTTP status code is 200 because delivery (transport) worked fine. - The Acknowledgement message will explain the failure, i.e= . use RequestStatus=3DDenied and - Justification=3D(CannotProcess | UnrecognizedForm= at | etc. ) as appropriate. - CannotProcess -> legal/policy exception. Unrecog= nizedFormat -> syntax failure. - There may be other Justifications needed.= ...TBD. I don't think we should require HTTP status 400 if the RID application mess= age content was the problem. The 400 code is specifically referring to the= validity of the HTTP request. For example, one must return 400 if the siz= e of the actual HTTP body received does not agree with the value of the HTT= P header "Content-length: nnn". Finally, it's important to note that an HTTP 4xx return code may be generat= ed by the HTTP transport layer. But in this case, my RID application code -= - higher up in the stack -- probably never even sees the RID message and so= I don't get a chance to send the Acknowledgement. In general, then, I think I agree with the original intent of RFC 6546 whic= h was to use HTTP status codes 200 and 202, and use the Acknowledgement mes= sage to convey RID-specific status information. Other HTTP status codes su= ch as 400 or 405 may be generated by the lower layers in the stack, but the= se are not generated by RID processing logic. So, I think I agree with the change that was originally proposed at the beg= inning of this thread (repeated here for your convenience :-) >>>>> Section 3, paragraph 12: >>>>> Change from: >>>>> If a RID system receives an improper RID message in an HTTP Request, >>>>> it MUST return an appropriate 4xx Client Error result code to the >>>>> requesting RID system. >>>>> >>>>> To: >>>>> If a RID system receives an improper HTTP Request, >>>>> it MUST return an appropriate 4xx Client Error result code to the >>>>> requesting RID system. >>>> However, now that I look at it, I wonder whether the statement is simply re= dundant, and out of scope for the RID transport specification. Maybe we sh= ould say nothing at all about 400, since all we are doing with this new tex= t is just restating HTTP behavior. (This still does constitute a technical= change since we would no longer be requiring the 400 status code when the = error is with the RID content). In addition, the 500 condition is required whenever the RID message cannot = be processed *and the RID server is unable to generate an Acknowledgement*. Last, but not least, I suggest that the comments in the previous paragraph = of RFC 6546 about not generating/following 30x redirects are valid and shou= ld remain, but could be moved to the security considerations section (Not s= ure, but I think that would be an editorial change, not a technical one). Sorry again for the long message. I hope this helps. Regards, John -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Sea= n Turner Sent: Thursday, November 29, 2012 11:37 AM To: mile@ietf.org Subject: Re: [mile] RFC6546 possible editorial errata wfm spt On 11/28/12 3:49 PM, Brian Trammell wrote: > Hi, Kathleen, all, > > I suppose if we view 6546 as a completely separate layer for RID, it make= s sense for 200 OK to mean "I accepted your RID message", or "here is a res= ponse" even if that response indicates error. > > In that case, the original fix (remove "improper RID message") would be t= he correct one; I (as a contributor) would be okay with that. But yes, it's= clearly a technical ambiguity (in any case, the new text changes how I'd i= mplement it) and therefore a technical erratum. > > Best regards, > > Brian > > On 28 Nov 2012, at 1:30, "Moriarty, Kathleen" = wrote: > >> Hi Brian, >> >> Malformed is the wrong word, we are really talking about the IODEF schem= a or some embedded schema via the SCI draft not being conformant. Or you c= ould have some other schema sent in RID that is not recognized by the recei= ving system (something other than IODEF). As such, handling that error at = the RID application layer is easier than at the HTTP layer from a developme= nt perspective. There are a range of possible things that could occur and = malformed is not really the right word to describe UnrecognizedFormat. By = changing the response to a 400 with an Acknowledgement now, that is pretty = significant as the flows and tables change to allow an Ack to come back in = either a 200 or a 400 depending on the Justification value selected. I thi= nk for developers, handling HTTP at the HTTP layer is easier and then appli= cation errors at the RID layer. I think it is a smaller change and may be = better for adoption by developers rather than having them do both before se= nding an HTTP 4 0 > 0 message. >> >> Does that help clear up your confusion? Any thoughts? >> >> Thanks, >> Kathleen >> >> -----Original Message----- >> From: Brian Trammell [mailto:trammell@tik.ee.ethz.ch] >> Sent: Tuesday, November 27, 2012 6:50 PM >> To: Moriarty, Kathleen >> Cc: Black, David; Waltermire, David A.; mile@ietf.org >> Subject: Re: [mile] RFC6546 possible editorial errata >> >> Hi, Kathleen, all, >> >> (chair hat off) (6546 author hat on) >> >> I'm a little confused on terminology here; "malformed" with respect to a= RID message meaning "not well-formed XML", or "XML not corresponding to th= e RID schema"? >> >> In any case, since there's an application-layer mechanism for reporting = such errors it makes sense to use it, of course. However, I'd find somethin= g deeply odd about returning a 200 OK which inside it contained an Acknowle= dgment signaling UnrecognizedFormat -- the response status and response bod= y would mismatch then. >> >> I'd suggest instead 400 Bad Request, with Acknowledgment as response bod= y. >> >> Which leaves us with NEW (a little stilted, can probably stand some edit= orial improvement...) >> >> If a RID system receives an improper HTTP Request, >> it MUST return an appropriate 4xx Client Error result code to the >> requesting RID system. If a RID system receives a malformed RID messag= e, >> it MUST return an Acknowledgment RID message, with 'Denied' as the >> AuthorizationStatus attribute of RequestStatus and 'UnrecognizedFormat= ' >> as the Justification attribute of RequestStatus, in a response with >> result code 400 Bad Request. If a RID system cannot process a RID mess= age >> received in an HTTP Request due to an error on its own side, it MUST >> return an appropriate 5xx Server Error result code to the requesting >> RID system. >> >> Best regards, >> Brian >> >> On Nov 27, 2012, at 10:11 PM, Moriarty, Kathleen wrote: >> >>> Thanks, David. >>> >>> Yes, UnrecognizedFormat for the Justification attribute would be the co= rrect response at the RID layer. >>> >>> We have some consensus it seems. Brian and Sean may want to weigh in a= s well (or anyone else). >>> >>> Best regards, >>> Kathleen >>> >>> -----Original Message----- >>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of= Black, David >>> Sent: Tuesday, November 27, 2012 3:48 PM >>> To: Waltermire, David A. >>> Cc: mile@ietf.org >>> Subject: Re: [mile] RFC6546 possible editorial errata >>> >>> Hi Dave, >>> >>> I like the approach of reporting errors at the layer at which they >>> occur, but I do agree that this would be a technical change. >>> >>> For the RID Acknowledgement message, what should be in the >>> RequestStatus instance to indicate that the RID message that is >>> being acknowledged was malformed (and hence has been discarded)? >>> Would UnrecognizedFormat cover this case? >>> >>> Thanks, >>> --David >>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf O= f >>>> Waltermire, David A. >>>> Sent: Tuesday, November 27, 2012 10:57 AM >>>> To: Moriarty, Kathleen; SM >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] RFC6546 possible editorial errata >>>> >>>> I think it makes sense to classify any change to the original wording = in >>>> question as technical, since it changes the technical meaning of the t= ext. >>>> >>>> I am good with using the application layer Acknowledgement message to = report a >>>> malformed RID request message. This looks like it is aligned well wit= h the >>>> text in rfc6545 section 6.2. >>>> >>>> My only concern is introducing ambiguity from the other direction with= the >>>> change. Relative to the transport, is the use of the acknowledgement = approach >>>> clear? Have the developers you mentioned weighed in on the change fro= m their >>>> perspectives? >>>> >>>> Any other thoughts? >>>> >>>> Thanks, >>>> Dave >>>> >>>> -----Original Message----- >>>> From: Moriarty, Kathleen [mailto:kathleen.moriarty@emc.com] >>>> Sent: Wednesday, November 21, 2012 9:22 PM >>>> To: Waltermire, David A.; SM >>>> Cc: mile@ietf.org >>>> Subject: RE: [mile] RFC6546 possible editorial errata >>>> >>>> Hi Dave, >>>> >>>> Thanks for taking a look at this as well! >>>> >>>> At the application layer, you have the ability to figure out what is w= rong >>>> with the RID/IODEF document and provide a response with details via th= e >>>> Acknowledgement message. This would be in a 200 HTTP code according t= o the >>>> table and then the 'Justification' can be set appropriately (xml encry= ption >>>> error, xml schema error, etc.). As a result, the language in the sent= ences >>>> provided is causing some confusion. I should have provided that conte= xt in >>>> the initial message. Does the additional context change your view? I= think >>>> it would be easier for developers (and meet the intended objective wit= h the >>>> language change, but it may be technical and not editorial). Does tha= t change >>>> your view? >>>> >>>> Anyone other thoughts from the list? >>>> >>>> Thanks, >>>> Kathleen >>>> ________________________________________ >>>> From: Waltermire, David A. [david.waltermire@nist.gov] >>>> Sent: Wednesday, November 21, 2012 6:46 PM >>>> To: Moriarty, Kathleen; SM >>>> Cc: mile@ietf.org >>>> Subject: RE: [mile] RFC6546 possible editorial errata >>>> >>>> The document is focused on applying the HTTP transport to define an >>>> application-layer protocol for RID (at least according to the abstract= ), so to >>>> some extent it has its feet on both sides of the fence. ;-) >>>> >>>> If the text is changed it might clarify what to do in the case of an i= nvalid >>>> HTTP request at the transport layer. In doing so, wouldn't we then be >>>> introducing the same ambiguity at the application layer for an invalid= RID >>>> message? In this case it would be undefined as to what to do if you h= ave a >>>> valid HTTP request from a transport perspective with an invalid RID me= ssage >>>> from an application perspective. It might make sense instead to chang= e it to: >>>> >>>> "If a RID system receives an improper HTTP Request or an improper RID = message >>>> in a valid HTTP Request, it MUST return an appropriate 4xx Client Err= or >>>> result code to the requesting RID system." >>>> >>>> Something like this would cover both cases making it clear to both dev= elopers. >>>> >>>> Happy Thanksgiving to those celebrating! >>>> >>>> Sincerely, >>>> Dave >>>> >>>> -----Original Message----- >>>> From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf O= f >>>> Moriarty, Kathleen >>>> Sent: Wednesday, November 21, 2012 11:21 AM >>>> To: SM >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] RFC6546 possible editorial errata >>>> >>>> SM, >>>> >>>> Thanks for the review! Here is the text that SM is referring to: >>>> >>>> "If a RID system receives an improper RID message in an HTTP Request, >>>> it MUST return an appropriate 4xx Client Error result code to the >>>> requesting RID system. If a RID system cannot process a RID message >>>> received in an HTTP Request due to an error on its own side, it MUST >>>> return an appropriate 5xx Server Error result code to the requesting >>>> RID system." >>>> >>>> I agree that the text is confusing as one developer interpreted it to = apply to >>>> the RID messages and another interpreted it as applying to HTTP since = the >>>> codes are specific to HTTP and not the application layer. I believe t= he >>>> intent was that it applied to the HTTP error level as this document wa= s >>>> focused on transport. I see your point that this may be a technical c= hange. >>>> The following sentence has the same problem, do you agree with the ass= essment >>>> and what do others think? >>>> >>>> Thanks, >>>> Kathleen >>>> ________________________________________ >>>> From: SM [sm@resistor.net] >>>> Sent: Wednesday, November 21, 2012 11:00 AM >>>> To: Moriarty, Kathleen >>>> Cc: mile@ietf.org >>>> Subject: Re: [mile] RFC6546 possible editorial errata >>>> >>>> Hi Kathleen, >>>> At 15:31 20-11-2012, Moriarty, Kathleen wrote: >>>>> There has been some confusion by a developer on when to use a HTTP 4x= x >>>>> response versus the use of an HTTP 200 response with an >>>>> acknowledgement. I think to get to the intent of RFC6545 and >>>>> RFC6546 a proposed text fix could address this confusion and just get >>>>> filed as an editorial errata: >>>>> >>>>> Section 3, paragraph 12: >>>>> Change from: >>>>> If a RID system receives an improper RID message in an HTTP Request, >>>>> it MUST return an appropriate 4xx Client Error result code to the >>>>> requesting RID system. >>>>> >>>>> To: >>>>> If a RID system receives an improper HTTP Request, >>>>> it MUST return an appropriate 4xx Client Error result code to the >>>>> requesting RID system. >>>> >>>> The above suggested text changes the RFC 2119 requirement. I wouldn't >>>> consider it as editorial as the intent is debatable if there wasn't an= y >>>> (prior) discussion to support it. >>>> >>>> BTW, the requirement is similar to the one in the sentence that follow= s the >>>> one quoted above. >>>> >>>> Regards, >>>> -sm >>>> >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>>> >>>> _______________________________________________ >>>> mile mailing list >>>> mile@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >>> >>> _______________________________________________ >>> mile mailing list >>> mile@ietf.org >>> https://www.ietf.org/mailman/listinfo/mile >> > > _______________________________________________ > mile mailing list > mile@ietf.org > https://www.ietf.org/mailman/listinfo/mile > _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From bchandra@secpod.com Fri Dec 14 00:10:04 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F3521F8929; Fri, 14 Dec 2012 00:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m5yQ6Pf0kfMH; Fri, 14 Dec 2012 00:10:03 -0800 (PST) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id C73C221F88E7; Fri, 14 Dec 2012 00:10:02 -0800 (PST) Received: from [182.72.99.242] (port=2837 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TjQLH-0000Wl-9e; Fri, 14 Dec 2012 13:39:59 +0530 From: "Chandrashekhar B" To: "'Field, John'" , "'Luis Nunez'" References: In-Reply-To: Date: Fri, 14 Dec 2012 13:39:49 +0530 Organization: SecPod Technologies Message-ID: <010201cdd9d2$658b4d00$30a1e700$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbiXiqSOwA== Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Get-Message-Sender-Via: cpanel23.interactivedns.com: authenticated_id: bchandra@secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 08:10:04 -0000 Reopening an old thread... >The issues that would need to be resolved include making the authentication to the scaprepo seamless >(possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in >interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations >(including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST >for write operations. But, this is a relatively minor issue at this point. The more important point is that by >using a REST approach such an integration would become possible, and that would be of benefit to users >dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together >quite nicely. We have now addressed these concerns in SCAP Repo's web service interface. The authentication and authorization rely on an HTTP Authorization header containing an optional authorization assertion. I say optional because that is to be used by subscribers. Also, all the interfaces are now HTTP GET based. The interface document is available here: https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be downloaded from https://www.scaprepo.com Appreciate your feedback! Chandra. -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues. -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, > > Cross posting this announcement from MILE to SACM, as I think this may be of interest within the SCAP community as well. > > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. > > I hope you'll find this draft to be of interest. > > Please post any questions or comments to the MILE list. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > > > > -----Original Message----- > From: Field, John > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt > > All, > > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt > > > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. > > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 > > > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. > > > > > The IETF Secretariat > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From bchandra@secpod.com Fri Dec 14 06:15:20 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5B21F8689; Fri, 14 Dec 2012 06:15:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN+btgE2YHJy; Fri, 14 Dec 2012 06:15:19 -0800 (PST) Received: from cpanel23.interactivedns.com (cpanel23.interactivedns.com [184.173.122.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8D60F21F85BF; Fri, 14 Dec 2012 06:15:19 -0800 (PST) Received: from [182.72.99.242] (port=1692 helo=hpPC) by cpanel23.interactivedns.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1TjW2o-0003Bh-PI; Fri, 14 Dec 2012 19:45:19 +0530 From: "Chandrashekhar B" To: "'Michael Hammer'" References: <010201cdd9d2$658b4d00$30a1e700$@secpod.com> <00C069FD01E0324C9FFCADF539701DB33270490B@EX2K10MB1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB33270490B@EX2K10MB1.corp.yaanatech.com> Date: Fri, 14 Dec 2012 19:45:09 +0530 Organization: SecPod Technologies Message-ID: <017c01cdda05$6e594c10$4b0be430$@secpod.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbgClUlQ2AHLYVJ/l2kwg0A= Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cpanel23.interactivedns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - secpod.com X-Get-Message-Sender-Via: cpanel23.interactivedns.com: authenticated_id: bchandra@secpod.com X-Source: X-Source-Args: X-Source-Dir: Cc: mile@ietf.org, sacm@ietf.org Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: bchandra@secpod.com List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 14:15:20 -0000 Mike, There was a comment about SCAP Repo in this thread, which was not initiated by me. I am responding to that comment now as we addressed that. Now, is this contribution to IETF? There's a good amount of discussion happening in the SACM list around content repository. If this is useful, whoever authors the draft, am happy to share it. The intention is not to influence anybody but to share it if it make sense. Chandra. -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com] Sent: Friday, December 14, 2012 7:22 PM To: bchandra@secpod.com; johnp.field@emc.com; lnunez@c3isecurity.com Cc: mile@ietf.org; sacm@ietf.org Subject: RE: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Is this intended to be a contribution to the IETF? Mike -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Chandrashekhar B Sent: Friday, December 14, 2012 3:10 AM To: 'Field, John'; 'Luis Nunez' Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Reopening an old thread... >The issues that would need to be resolved include making the >authentication to the scaprepo seamless >(possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in >interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations >(including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST >for write operations. But, this is a relatively minor issue at this point. The more important point is that by >using a REST approach such an integration would become possible, and that would be of benefit to users >dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together >quite nicely. We have now addressed these concerns in SCAP Repo's web service interface. The authentication and authorization rely on an HTTP Authorization header containing an optional authorization assertion. I say optional because that is to be used by subscribers. Also, all the interfaces are now HTTP GET based. The interface document is available here: https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be downloaded from https://www.scaprepo.com Appreciate your feedback! Chandra. -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues. -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, > > Cross posting this announcement from MILE to SACM, as I think this may > be of interest within the SCAP community as well. > > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. > > I hope you'll find this draft to be of interest. > > Please post any questions or comments to the MILE list. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > > > > -----Original Message----- > From: Field, John > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt > > All, > > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. > > Regards, > John > > // John P. Field > // Security Architect > // EMC Office of the CTO > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt > > > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. > > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 > > > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. > > > > > The IETF Secretariat > > > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile From kathleen.moriarty@emc.com Fri Dec 14 07:02:06 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AAA21F85BF; Fri, 14 Dec 2012 07:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnKHFDbPlkpc; Fri, 14 Dec 2012 07:02:04 -0800 (PST) Received: from mexforward.lss.emc.com (hop-nat-141.emc.com [168.159.213.141]) by ietfa.amsl.com (Postfix) with ESMTP id E37AF21F85A6; Fri, 14 Dec 2012 07:02:03 -0800 (PST) Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBEF22QH006166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 Dec 2012 10:02:02 -0500 Received: from mailhub.lss.emc.com (mailhubhoprd01.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Fri, 14 Dec 2012 10:01:48 -0500 Received: from mxhub10.corp.emc.com (mxhub10.corp.emc.com [10.254.92.105]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qBEF1gL1019645; Fri, 14 Dec 2012 10:01:42 -0500 Received: from mx15a.corp.emc.com ([169.254.1.210]) by mxhub10.corp.emc.com ([10.254.92.105]) with mapi; Fri, 14 Dec 2012 10:01:41 -0500 From: "Moriarty, Kathleen" To: "bchandra@secpod.com" , "'Michael Hammer'" Date: Fri, 14 Dec 2012 10:01:40 -0500 Thread-Topic: [sacm] [mile] New draft for review and comment: draft-field-mile-rolie-00.txt Thread-Index: AQIDkLRwduFPN/39ahIvZ01+DQBPpAF1d2SmAqBmgbgClUlQ2AHLYVJ/l2kwg0CAABEZoA== Message-ID: References: <010201cdd9d2$658b4d00$30a1e700$@secpod.com> <00C069FD01E0324C9FFCADF539701DB33270490B@EX2K10MB1.corp.yaanatech.com> <017c01cdda05$6e594c10$4b0be430$@secpod.com> In-Reply-To: <017c01cdda05$6e594c10$4b0be430$@secpod.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: "mile@ietf.org" , "sacm@ietf.org" Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 15:02:06 -0000 Yes, any document posted as an internet draft has been contributed to the I= ETF. John has said he would work on a revision based on comments and we wi= ll be altering the MILE charter to have this part of the MILE WG documents = as it was viewed favorably. If you have comments, please post them to the = MILE list. The discussed changes were to show the generalized approach first, then the= specific examples to MILE so it clearly applies more broadly. Thank you! Kathleen -----Original Message----- From: sacm-bounces@ietf.org [mailto:sacm-bounces@ietf.org] On Behalf Of Cha= ndrashekhar B Sent: Friday, December 14, 2012 9:15 AM To: 'Michael Hammer' Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [sacm] [mile] New draft for review and comment: draft-field-mi= le-rolie-00.txt Mike, There was a comment about SCAP Repo in this thread, which was not initiated by me. I am responding to that comment now as we addressed that. Now, is this contribution to IETF? There's a good amount of discussion happening in the SACM list around content repository. If this is useful, whoever authors the draft, am happy to share it. The intention is not to influence anybody but to share it if it make sense. Chandra. -----Original Message----- From: Michael Hammer [mailto:michael.hammer@yaanatech.com]=20 Sent: Friday, December 14, 2012 7:22 PM To: bchandra@secpod.com; johnp.field@emc.com; lnunez@c3isecurity.com Cc: mile@ietf.org; sacm@ietf.org Subject: RE: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Is this intended to be a contribution to the IETF? Mike -----Original Message----- From: mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Chandrashekhar B Sent: Friday, December 14, 2012 3:10 AM To: 'Field, John'; 'Luis Nunez' Cc: mile@ietf.org; sacm@ietf.org Subject: Re: [mile] [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt Reopening an old thread... >The issues that would need to be resolved include making the=20 >authentication to the scaprepo seamless >(possible, at least in principal, using existing Web Single Sign On protocols) and dealing with differences in >interaction style...for example, I notice that scaprepo seems to prefer the use of POST for all operations >(including a read operation). As a general rule, it is best to support GET for read operations, and reserve POST >for write operations. But, this is a relatively minor issue at this point. The more important point is that by >using a REST approach such an integration would become possible, and that would be of benefit to users >dealing with indicators, incident response, and assessment and compliance, etc....we could tie it all together >quite nicely. We have now addressed these concerns in SCAP Repo's web service interface. The authentication and authorization rely on an HTTP Authorization header containing an optional authorization assertion. I say optional because that is to be used by subscribers.=20 Also, all the interfaces are now HTTP GET based.=20 The interface document is available here: https://www.scaprepo.com/SCAPRepoWebService and the client SDK can be downloaded from https://www.scaprepo.com Appreciate your feedback! Chandra. -----Original Message----- From: Luis Nunez [mailto:lnunez@c3isecurity.com] Sent: Thursday, September 06, 2012 11:36 AM To: Field, John Cc: sacm@ietf.org; mile@ietf.org Subject: Re: [sacm] New draft for review and comment: draft-field-mile-rolie-00.txt John, this definitely is of interest and could be related to past discussions around content repositories. =20 I know of two publicly accessible (REST) repositories that could potential host this type of content. http://scaprepo.com/SCAPRepoWebService http://scapsync.com/api/ NIST is also working on a repository with webservices. It would be interesting to prototype a sample document and flesh out issues= . -ln On Sep 6, 2012, at 11:10 AM, Field, John wrote: > All, >=20 > Cross posting this announcement from MILE to SACM, as I think this may=20 > be of interest within the SCAP community as well. =20 >=20 > The new draft referenced below describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. In particular, the draft includes a suggested approach to retrieving a related benchmark resource. =20 >=20 > I hope you'll find this draft to be of interest. =20 >=20 > Please post any questions or comments to the MILE list. >=20 > Regards, > John >=20 > // John P. Field > // Security Architect > // EMC Office of the CTO >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Field, John=20 > Sent: Thursday, September 06, 2012 10:53 AM > To: > Subject: New draft for review and comment: draft-field-mile-rolie-00.txt >=20 > All, >=20 > Please note that I have just posted a new draft for review and comment. As stated in the abstract, the draft describes a RESTful HTTP binding for sharing incident, indicator, and other cyber security-related information. I hope you'll find this document to be of interest, and I look forward to discussing any questions and/or comments that the group may have. >=20 > Regards, > John >=20 > // John P. Field=20 > // Security Architect=20 > // EMC Office of the CTO=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Wednesday, September 05, 2012 9:59 PM > To: Field, John > Subject: New Version Notification for draft-field-mile-rolie-00.txt >=20 >=20 > A new version of I-D, draft-field-mile-rolie-00.txt > has been successfully submitted by John P. Field and posted to the > IETF repository. >=20 > Filename: draft-field-mile-rolie > Revision: 00 > Title: Resource-Oriented Lightweight Indicator Exchange > Creation date: 2012-09-05 > WG ID: Individual Submission > Number of pages: 41 > URL: http://www.ietf.org/internet-drafts/draft-field-mile-rolie-00.txt > Status: http://datatracker.ietf.org/doc/draft-field-mile-rolie > Htmlized: http://tools.ietf.org/html/draft-field-mile-rolie-00 >=20 >=20 > Abstract: > This document defines a resource-oriented approach to cyber security > information sharing. Using this approach, a CSIRT or other > stakeholder may share and exchange representations of cyber security > incidents, indicators, and other related information as Web- > addressable resources. The transport protocol binding is specified > as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of > link relation types specific to cyber security information sharing is > defined. The resource representations leverage the existing IODEF > [RFC5070] and RID [RFC6545] specifications as appropriate. > Coexistence with deployments that conform to existing specifications > including RID [RFC6545] and Transport of Real-time Inter-network > Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via > appropriate use of HTTP status codes. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sacm mailing list > sacm@ietf.org > https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm _______________________________________________ mile mailing list mile@ietf.org https://www.ietf.org/mailman/listinfo/mile _______________________________________________ sacm mailing list sacm@ietf.org https://www.ietf.org/mailman/listinfo/sacm From amontville@tripwire.com Fri Dec 14 09:50:18 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5238221F8A8A for ; Fri, 14 Dec 2012 09:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhYSE8ssSZjU for ; Fri, 14 Dec 2012 09:50:17 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 6410721F8A82 for ; Fri, 14 Dec 2012 09:50:16 -0800 (PST) Received: from mail182-tx2-R.bigfish.com (10.9.14.235) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 17:50:15 +0000 Received: from mail182-tx2 (localhost [127.0.0.1]) by mail182-tx2-R.bigfish.com (Postfix) with ESMTP id 82D914A00E3 for ; Fri, 14 Dec 2012 17:50:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz98dI9371I1431Jd6eah9f17Rc85eh148cI1432I4015I1415Izz1de0h1202h1e76h1d1ah1d2ahzz18c673h17326ah18602eh8275bh8275dh1033IL1954cbhz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail182-tx2 (localhost.localdomain [127.0.0.1]) by mail182-tx2 (MessageSwitch) id 1355507410434080_1859; Fri, 14 Dec 2012 17:50:10 +0000 (UTC) Received: from TX2EHSMHS024.bigfish.com (unknown [10.9.14.235]) by mail182-tx2.bigfish.com (Postfix) with ESMTP id 6200622005A for ; Fri, 14 Dec 2012 17:50:10 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by TX2EHSMHS024.bigfish.com (10.9.99.124) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 17:50:08 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id 992682321243 for ; Fri, 14 Dec 2012 09:38:11 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id DD32323211D0; Fri, 14 Dec 2012 09:38:10 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 14 Dec 2012 09:55:21 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Fri, 14 Dec 2012 09:49:56 -0800 From: Adam Montville To: "Black, David" Thread-Topic: Updated IODEF Enumeration Reference Format Draft Thread-Index: AQHNvQ3c5igWirSip0ScCVgUmvLL1JfuMxLggBO5WgCAClvW0IANCpiA Date: Fri, 14 Dec 2012 17:49:56 +0000 Message-ID: <9F8FFFFE-D2D7-4AA8-9655-57F606D96540@tripwire.com> References: <18EDCB49-399F-44DC-BF11-9A77F3E459FC@tripwire.com> <8D3D17ACE214DC429325B2B98F3AE71284B5A565@MX15A.corp.emc.com> <74613456-C11E-434C-91FF-23F2AAF7B87D@tripwire.com> <8D3D17ACE214DC429325B2B98F3AE712879BD396@MX15A.corp.emc.com> In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE712879BD396@MX15A.corp.emc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_9F8FFFFED2D74AA8965557F606D96540tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 7e5ed15d-ea78-4d9d-b001-44f283a5a744 X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Cc: "" Subject: Re: [mile] Updated IODEF Enumeration Reference Format Draft X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 17:50:18 -0000 --_000_9F8FFFFED2D74AA8965557F606D96540tripwirecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greetings all... I'm trying to get this IODEF Enumeration Reference draft = nailed down. I'd like to call your attention to the point David makes belo= w about the IANA Considerations section - the WG needs to provide guidance = for the Designated Expert. I'll be publishing an 02 version of this draft = later today and we can improve on that. Just wanted to provide a heads up. On Dec 6, 2012, at 10:47 AM, "Black, David" > wrote: Hi Adam, Thanks you for considering these comments. I have a couple of follow-ups: > So, what you're proposing is that the versioning information be attached = to id > rather than id_type. That seems reasonable to me. Yes, although I might say =93associated with=94 as opposed to =93attached t= o=94. For example, a useful (at least, IMHO) consequence is that if the same id i= s used in multiple versions of the same spec without change (e.g., new revi= sed spec versions add ids to enumerations but don=92t change existing ids),= than this approach removes the need in IODEF to explicitly indicate which = of the various possible versions of the spec is involved. > In that message you mention guidance being provided to the Designated Exp= ert. > Where would that guidance be provided in the draft (or is it provided els= ewhere)? It would go in the IANA Considerations section - we (the WG) get to write t= hat guidance to help a future Designated Expert do the proverbial =93right = thing=94. Thanks, --David From: Adam Montville [mailto:amontville@tripwire.com] Sent: Thursday, November 29, 2012 3:29 PM To: Black, David Cc: > Subject: Re: Updated IODEF Enumeration Reference Format Draft Hi David, Thank you for your diligence! I do appreciate it. Please see comments inline. Regards, Adam On Nov 17, 2012, at 7:42 AM, "Black, David" > wrote: Adam, Thanks for working on this draft. I see that the version is included in the id_type string prefix. I=92m assuming that this version is the version number of the registered specification. That makes sense if the version doesn=92t change often and especially if a version change results in a change to the identifier format. How often does the version change for the specs that are the sources of the enumerations of interest? >From what I've seen, rarely. However, emerging enumerations could be used = and they might change more frequently. If the spec version changes often, and especially if enumeration identifiers from previous versions usually remain valid in new versions, an alternative approach would be to tie the version to the identifier format rather than the spec version - this could avoid having several dozen id_type strings for versions of a single spec. So, what you're proposing is that the versioning information be attached to= id rather than id_type. That seems reasonable to me. Please also take a look at these two emails that I sent to the list earlier= : identifier formats: http://www.ietf.org/mail-archive/web/mile/current/msg00= 853.html With respect to this message, which is about id and id_type formatting, I'm= happy to make adjustments to the draft where necessary. In that message y= ou mention guidance being provided to the Designated Expert. Where would t= hat guidance be provided in the draft (or is it provided elsewhere)? Additionally, I'm interested to know what others think about these approach= es. Again, I'm here to create a draft based on what the community wants to= see implemented, so chime in if you have an opinion in these matters. more on versions: http://www.ietf.org/mail-archive/web/mile/current/msg0085= 4.html Take and I had an opportunity to speak in Atlanta, and I understand the con= cern represented in the message above. This will be addressed in a forthco= ming revision. I have some additional editorial concerns that I=92ll send to you directly. Thanks, --David From: mile-bounces@ietf.org [mailto:mile-boun= ces@ietf.org] On Behalf Of Adam Montville Sent: Wednesday, November 07, 2012 12:32 PM To: > Subject: [mile] Updated IODEF Enumeration Reference Format Draft All: I'm pleased to submit draft-montville-mile-enum-reference-format-01 availab= le at http://www.ietf.org/id/draft-montville-mile-enum-reference-format-01.txt Changes: * IANA Table Request Changes * Removed "Name" * Added "Full Name * Added "Abbreviation" * Specified id_type to be _ * Reviewed text for scope statements and limited scope to IODEF, while = alluding to the method's potential usefulness elsewhere. * Ensured that the Reference class diagram is explicitly referenced as = [IODEF]. * Updated IANA Considerations to request creation of the table * Updated IANA table format fields with simple descriptions I look forward to your comments. Regards, Adam W. Montville | Security and Compliance Architect CISA, CISSP Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | Take CONTROL http://www.tripwire.com Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_9F8FFFFED2D74AA8965557F606D96540tripwirecom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <49A068006DF3FB46876AD2D1D00612CD@tripwire.com> Content-Transfer-Encoding: quoted-printable Greetings all...  I'm trying to get this IODEF Enumeration Reference d= raft nailed down.  I'd like to call your attention to the point David = makes below about the IANA Considerations section - the WG needs to provide= guidance for the Designated Expert.  I'll be publishing an 02 version of this draft later today and we can improve o= n that.  Just wanted to provide a heads up.



On Dec 6, 2012, at 10:47 AM, "Black, David" <david.black@emc.com> wrote:

Hi Adam,=
 =
Thanks you fo= r considering these comments.  I have a couple of follow-ups:
 =
> So, what= you're proposing is that the versioning information be attached to id=
> rather t= han id_type.  That seems reasonable to me.
 =
Yes, although= I might say =93associated with=94 as opposed to =93attached to=94.
 =
For example, = a useful (at least, IMHO) consequence is that if the same id is used in mul= tiple versions of the same spec without change (e.g., new revised spec vers= ions add ids to enumerations but don=92t change existing ids), than this approach removes the need in IODEF to expl= icitly indicate which of the various possible versions of the spec is invol= ved.
 =
> In that = message you mention guidance being provided to the Designated Expert.<= /o:p>
> Where wo= uld that guidance be provided in the draft (or is it provided elsewhere)? &= nbsp;
 =
It would go i= n the IANA Considerations section - we (the WG) get to write that guidance = to help a future Designated Expert do the proverbial =93right thing=94.
 =
Thanks,
--David
 =
From:=  Adam Montville [mailt= o:amontville@tripwire.com] 
Sent: Thursday, No= vember 29, 2012 3:29 PM
To: Black, David Cc: <mile@ietf.org>
Subject: Re: Updat= ed IODEF Enumeration Reference Format Draft
 
Hi David,
 
Thank you for your diligence!  I do appreciate it.
 
Please see comments inline.
 
Regards,
 
Adam
 
On Nov 17, 2012, at 7:42 AM, "Black, David" <david.black@emc.com> wrote:


Adam,<= o:p>
 =
Thanks for wo= rking on this draft.
 =
I see that th= e version is included in the id_type string prefix.
I=92m assumin= g that this version is the version number of the registered
specification= .  That makes sense if the version doesn=92t change often<= /o:p>
and especiall= y if a version change results in a change to the identifier
format. =
 =
How often doe= s the version change for the specs that are the sources of
the enumerati= ons of interest?
 
>From what I've seen, rarely.  However, emerging enumerations could be = used and they might change more frequently.


 =
If the spec v= ersion changes often, and especially if enumeration
identifiers f= rom previous versions usually remain valid in new versions,
an alternativ= e approach would be to tie the version to the identifier<= /div>
format rather= than the spec version - this could avoid having several<= /div>
dozen id_type= strings for versions of a single spec.
 
So, what you're proposing is that the versioning information be attached to= id rather than id_type.  That seems reasonable to me.
 


 =
Please also t= ake a look at these two emails that I sent to the list earlier:=
 =
 
With respect to this message, which is about id and id_type formatting, I'm= happy to make adjustments to the draft where necessary.  In that mess= age you mention guidance being provided to the Designated Expert.  Whe= re would that guidance be provided in the draft (or is it provided elsewhere)?  
 
Additionally, I'm interested to know what others think about these approach= es.  Again, I'm here to create a draft based on what the community wan= ts to see implemented, so chime in if you have an opinion in these matters.=


 
Take and I had an opportunity to speak in Atlanta, and I understand the con= cern represented in the message above.  This will be addressed in a fo= rthcoming revision.


 =
I have some a= dditional editorial concerns that I=92ll send to you directly.<= /o:p>
 =
Thanks,
--David
 =
From:=  mile-bounces@ietf.org [mailto:mile-bounces@ietf.org] On Behalf Of Adam Montv= ille
Sent: Wednesday, N= ovember 07, 2012 12:32 PM
To: <mile@ietf.org>
Subject: [mile] Up= dated IODEF Enumeration Reference Format Draft
 
All:
 
I'm pleased to submit draft-montville-mile-enum-reference-format-01 availab= le at
 
 
Changes:
 
  • IANA Table Request Changes
    • Removed "Name"
    • Added "Full Name
    • Added "Abbreviation"
  • Specified id_type to be <Abbreviation>_<Version>
  • Reviewed text for scope statements and limited scope to IODEF, while alludi= ng to the method's potential usefulness elsewhere.
  • Ensured that the Reference class diagram is explicitly referenced as [IODEF= ].
  • Updated IANA Considerations to request creation of the table
  • Updated IANA table format fields with simple descriptions
    •  
 
I look forward to your comments.
 
Regards,
 = ;
Adam W. Montville | Security and Compliance Archite= ct
CISA, CISSP<= /o:p>
 = ;
Direct: 503 276-7661
Mobile: 360 471-7815
 = ;
TRIPWIRE | Take CONTR= OL
&nb= sp;
&nb= sp;
 = ;

 

 



Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_9F8FFFFED2D74AA8965557F606D96540tripwirecom_-- From amontville@tripwire.com Fri Dec 14 10:01:16 2012 Return-Path: X-Original-To: mile@ietfa.amsl.com Delivered-To: mile@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27BB21F8AD8 for ; Fri, 14 Dec 2012 10:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.416 X-Spam-Level: X-Spam-Status: No, score=-4.416 tagged_above=-999 required=5 tests=[AWL=-0.818, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-J+h+gfr6SL for ; Fri, 14 Dec 2012 10:01:15 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE1F21F8AB4 for ; Fri, 14 Dec 2012 10:01:15 -0800 (PST) Received: from mail161-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE020.bigfish.com (10.43.70.77) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Dec 2012 18:01:14 +0000 Received: from mail161-ch1 (localhost [127.0.0.1]) by mail161-ch1-R.bigfish.com (Postfix) with ESMTP id D16DE1C043F for ; Fri, 14 Dec 2012 18:01:14 +0000 (UTC) X-Forefront-Antispam-Report: CIP:174.47.84.215; KIP:(null); UIP:(null); IPV:NLI; H:zgw01.tripwire.com; RD:174-47-84-215.static.twtelecom.net; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zf7Iz936eI9f17Rc85fhzz1de0h1202h1e76h1d1ah1d2ahz31iz18c673h17326ah18602eh8275bh8275dh1033ILz2dh2a8h668h839hd25he5bhf0ah1288h12a5h12bdh137ah1441h14ddh1504h1537h153bh162dh1631h1758hbe3k1155h) Received: from mail161-ch1 (localhost.localdomain [127.0.0.1]) by mail161-ch1 (MessageSwitch) id 1355508039164304_26502; Fri, 14 Dec 2012 18:00:39 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail161-ch1.bigfish.com (Postfix) with ESMTP id 24C3D200256 for ; Fri, 14 Dec 2012 18:00:39 +0000 (UTC) Received: from zgw01.tripwire.com (174.47.84.215) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 14 Dec 2012 18:00:37 +0000 Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.tripwire.com (Proprietary) with SMTP id F28A62321243 for ; Fri, 14 Dec 2012 09:48:45 -0800 (PST) Received: from PDXED01.tripwire.com (unknown [192.168.192.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by zgw01.tripwire.com (Proprietary) with ESMTPS id 549E7232122F for ; Fri, 14 Dec 2012 09:48:45 -0800 (PST) Received: from PDXHB01.tripwire.com (172.30.0.53) by PDXED01.tripwire.com (192.168.192.5) with Microsoft SMTP Server (TLS) id 14.1.379.0; Fri, 14 Dec 2012 10:05:51 -0800 Received: from PDXMB02.tripwire.com ([fe80::f997:7b65:8e64:438e]) by PDXHB01.tripwire.com ([fe80::d495:98d2:7df4:2154%11]) with mapi id 14.01.0421.002; Fri, 14 Dec 2012 10:00:26 -0800 From: Adam Montville To: "" Thread-Topic: New Version Notification for draft-montville-mile-enum-reference-format-02.txt Thread-Index: AQHN2iS8NOLv9ZZmv0SHL4xaApb1BQ== Date: Fri, 14 Dec 2012 18:00:25 +0000 Message-ID: References: <20121214175906.7889.76621.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.30.0.234] x-exclaimer-md-config: 79afcaa7-fdf4-4fa6-abe0-afeaa4640a4f Content-Type: multipart/alternative; boundary="_000_E626061C0308416D9C52F79DFBD97A41tripwirecom_" MIME-Version: 1.0 X-VPM-MSG-ID: 8098f85c-6703-41b0-8cfb-0e7b2d6d557b X-VPM-HOST: zgw01.tripwire.com X-VPM-ENC-REGIME: Plaintext X-VPM-CERT-FLAG: 0 X-VPM-IS-HYBRID: 0 X-OriginatorOrg: tripwire.com Subject: [mile] Fwd: New Version Notification for draft-montville-mile-enum-reference-format-02.txt X-BeenThere: mile@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Managed Incident Lightweight Exchange, IODEF extensions and RID exchanges" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Dec 2012 18:01:16 -0000 --_000_E626061C0308416D9C52F79DFBD97A41tripwirecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Begin forwarded message: A new version of I-D, draft-montville-mile-enum-reference-format-02.txt has been successfully submitted by Adam W. Montville and posted to the IETF repository. Filename: draft-montville-mile-enum-reference-format Revision: 02 Title: IODEF Enumeration Reference Format Creation date: 2012-12-14 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-montville-mile-e= num-reference-format-02.txt Status: http://datatracker.ietf.org/doc/draft-montville-mile-enum-= reference-format Htmlized: http://tools.ietf.org/html/draft-montville-mile-enum-refer= ence-format-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-montville-mile-en= um-reference-format-02 Abstract: The Incident Object Description Exchange Format [IODEF] provides a Reference class used to reference external entities (such as enumeration identifiers). However, the method of external entity identification has been left unstructured. This document describes a method to provide structure for referencing external entities for the [IODEF] Reference class. The IETF Secretariat Adam W. Montville | Security and Compliance Architect Direct: 503 276-7661 Mobile: 360 471-7815 TRIPWIRE | CONFIDENCE: SECURED www.tripwire.com --_000_E626061C0308416D9C52F79DFBD97A41tripwirecom_ Content-Type: text/html; charset="us-ascii" Content-ID: <556AC347F691CA4A8C3EB8FA6A1EA947@tripwire.com> Content-Transfer-Encoding: quoted-printable

Begin forwarded message:


A new version of I-D, draft-montville-mile-enum-reference-format-02.txt
has been successfully submitted by Adam W. Montville and posted to the<= br style=3D"font-family: Calibri; font-size: medium; font-style: normal; fo= nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh= t: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-tra= nsform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-te= xt-size-adjust: auto; -webkit-text-stroke-width: 0px; "> IETF repository.

Filename:  = ;draft-montville-mile-enum-reference-format
Revision:  = ;02
Title:  IODEF Enumeration Reference Format
Creation date:  = ;2012-12-14
WG ID:  Individual Submission
Number of pages: 7
URL:             http://www.ietf.org/internet-drafts/draft-montville-mile-enum-referen= ce-format-02.txt
Status:          http://datatracker.ietf= .org/doc/draft-montville-mile-enum-reference-format
Htmlized:        http://tools.ietf.org/html/draft-mont= ville-mile-enum-reference-format-02
Diff:            <= a href=3D"http://www.ietf.org/rfcdiff?url2=3Ddraft-montville-mile-enum-refe= rence-format-02" style=3D"font-family: Calibri; font-size: medium; font-sty= le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm= al; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent:= 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0= px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">http:= //www.ietf.org/rfcdiff?url2=3Ddraft-montville-mile-enum-reference-format-02=

Abstract:
  The Incident Object Description Exchange Format [IODEF] provides a
  Reference class used to reference external entities (such as
  enumeration identifiers).  However, the method of external entity
  identification has been left unstructured.  This document describes a
  method to provide structure for referencing external entities for the
  [IODEF] Reference class.





The IETF Secretariat


Adam W. Montville | Security and Compliance Architect

Direct: 503 276-7661
Mobile: 360 471-7815    


TRIPWIRE | CONFIDENCE:&nb= sp;SECURED
www.tripwire.com




--_000_E626061C0308416D9C52F79DFBD97A41tripwirecom_--