Subject: [mile] FW: New Version Notification for draft-montville-mile-enum-reference-format-00.txt

From: Adam Montville <[email-masked]>
Date: Sat, 1 Sep 2012 13:54:18 +0000

On 9/1/12 6:46 AM, "[email-masked]" <[email-masked]>
wrote:

>
>A new version of I-D, draft-montville-mile-enum-reference-format-00.txt
>has been successfully submitted by Adam W. Montville and posted to the
>IETF repository.
>
>Filename:	 draft-montville-mile-enum-reference-format
>Revision:	 00
>Title:		 IODEF Enumeration Reference Format
>Creation date:	 2012-09-01
>WG ID:		 Individual Submission
>Number of pages: 6
>URL:             
>http://www.ietf.org/internet-drafts/draft-montville-mile-enum-reference-fo
>rmat-00.txt
>Status:          
>http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-format
>Htmlized:        
>http://tools.ietf.org/html/draft-montville-mile-enum-reference-format-00
>
>
>Abstract:
>   Some standards, such as the Incident Object Description Exchange
>   Format [IODEF], provide classes used to reference external entities
>   (such as enumeration identifiers).  At the time of standardization,
>   however, needed references may not be known, and the method of
>   external entity identification is often left unstructured.  This
>   document describes, using [IODEF] as an example, a method to provide
>   structure after the fact.
>
>
>                  
>        
>
>
>The IETF Secretariat
>
>
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Wed, 5 Sep 2012 10:35:57 -0400

Adam,

Thank you very much for your work on this draft!  

MILE members: Please review and comment on the draft.  

Thank you!
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Montville [[email-masked]]
Sent: Saturday, September 01, 2012 9:54 AM
To: [email-masked]
Subject: [mile] FW: New Version Notification for draft-montville-mile-enum-reference-format-00.txt

>   structure after the fact.

_______________________________________________
mile mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mile

---

From: Adam Montville <[email-masked]>
Date: Thu, 6 Sep 2012 13:54:30 +0000

>Thank you very much for your work on this draft!

You're welcome, Kathleen!

>MILE members: Please review and comment on the draft.

I already have at least one improvement in the security considerations
section.  I need to add information relative to protective measures to
take such that references are not tampered with in transit, at least.

I look forward to the community's comments.

>Subject: [mile] FW: New Version Notification for
>draft-montville-mile-enum-reference-format-00.txt
>

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Thu, 27 Sep 2012 09:17:24 -0400

Adam & MILE members,

I read through the draft and think it looks great!  I did notice that the identifier format after the id: is not specified.  An example is provided, but am wondering if it would be helpful to provide an explicit format to help developers when formatting and parsing the content.

Any thoughts - Adam or others on the MILE list?

Thank you!
Kathleen
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Moriarty, Kathleen [[email-masked]]
Sent: Wednesday, September 05, 2012 10:35 AM
To: Adam Montville; [email-masked]
Subject: Re: [mile] FW: New Version Notification for draft-montville-mile-enum-reference-format-00.txt

Adam,

Thank you!
Kathleen

---

From: Adam Montville <[email-masked]>
Date: Thu, 27 Sep 2012 22:28:19 +0000

On 9/27/12 6:17 AM, "Moriarty, Kathleen" <[email-masked]> wrote:

>Adam & MILE members,
>
>I read through the draft and think it looks great!  I did notice that the
>identifier format after the id: is not specified.  An example is
>provided, but am wondering if it would be helpful to provide an explicit
>format to help developers when formatting and parsing the content.
>

Kathleen, thanks for reviewing the specification.  I think there's a
misunderstanding.  I'm looking at the id_type:id item described in 2.1.
The id in that item *is* the identifier, and it's format should be
explicitly defined by a document or available specification that would be
attainable from the registry (Specification URI).

Does that help or are we talking about two different things?

Adam

>From: [email-masked] [[email-masked]] On Behalf Of
>Moriarty, Kathleen [[email-masked]]
>Subject: Re: [mile] FW: New Version Notification for

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 28 Sep 2012 09:19:39 -0400

Hi Adam,

I am sorry for the confusion!  I was referring to the full value contained in the "ReferenceName".  The example shows:

 <Reference>
         <ReferenceName>CXI:CXI-1234-XYZ</ReferenceName>
         <URL>http://cxi.example.com</URL>
         <Description>Foo</Description>
      </Reference>

   Information in the IANA table (see Section 4) would include:

      Name: Concept X Identifier
      Version: x.y
      Specification URI: http://cxi.example.com/spec_url
      Reference: Foo.

How would you get from the IANA table entry to what is included in the example?    The name gets abbreviated.  Is the version part of the name and a new version would be a new name?  How is the structure after the colon formed?  What characters are permitted.

Thank you,
Kathleen

________________________________________
From: Adam Montville [[email-masked]]
Sent: Thursday, September 27, 2012 6:28 PM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] FW: New Version Notification for draft-montville-mile-enum-reference-format-00.txt

Adam

---

From: Adam Montville <[email-masked]>
Date: Fri, 28 Sep 2012 13:31:19 +0000

On 9/28/12 6:19 AM, "Moriarty, Kathleen" <[email-masked]> wrote:

>Hi Adam,
>
>I am sorry for the confusion!  I was referring to the full value
>contained in the "ReferenceName".

That makes more sense to me, sorry.  This is a great point, Kathleen.

>The example shows:
>How would you get from the IANA table entry to what is included in the
>example?    The name gets abbreviated.  Is the version part of the name
>and a new version would be a new name?  How is the structure after the
>colon formed?  What characters are permitted.

I think I was taking the "Name" in the IANA table to be the identifier,
rather than the full name (so, for example, "CPE" rather than "Common
Platform Enumeration").  So, we could simply add an abbreviation to the
IANA table, where the abbreviation would consist of lowercase alphabetical
characters for the type identifier ("CXI" in the example above).

The character limitations should be none, such that this method would not
encumber any enumeration specification.  That said, I think it would be
reasonable to make it alphanumeric with some punctuation (but I'd like to
hear from the list as to what they think) - so essentially a string with
some character restrictions.

As I mention above, I'd really like to hear from others on the list as to
what they feel is best.

Thanks again for pointing this out.

>>>http://www.ietf.org/internet-drafts/draft-montville-mile-enum-reference-
>>>f
>>>o
>>>rmat-00.txt
>>>Status:
>>>http://datatracker.ietf.org/doc/draft-montville-mile-enum-reference-form
>>>a
>>>t
>>>Htmlized:

---

From: John Howie <[email-masked]>
Date: Fri, 28 Sep 2012 10:00:26 -0700

Hi all,

DISCLAIMER: This is a personal observation here, and not necessarily
endorsed by the organization I work for.

I think I have reached a tipping point with respect to a key direction
this and other efforts (both related and unrelated) are taking. Can we
please have a discussion about the suitability of HTTP/HTTPS/XML for this
type of information exchange.

The HTTP/HTTPS protocol was never designed for this type of data exchange,
and is a wordy, fat protocol that consumes a heck of a lot of bandwidth.
If you are exchanging just a few bytes of data the protocol overhead can
dwarf the actual meaningful data being exchanged, especially when using
HTTPS and authentication. The packet exchanges between client and server
are numerous before even a byte of meaningful data is exchanged.

XML just makes the situation worse. In the example below we are exchanging
177 characters with only 44 characters actually being meaningful. There
are better options such as JSON. The overhead in parsing XML is a real
problem, and, let's face it, different implementations of XML generators
and parsers often cause compatibility issues even before versioning is
factored in.

When we use HTTP/HTTPS/XML we also use, by necessity, web servers and XML
parsers and a cursory look as US-CERT and other notification lists shows
that these are hardly vulnerability free, and we are simply building a
potentially critical infrastructure on commodity components that are the
cause of many security and privacy issues today.

I would really like to see information exchange be secure, fast and
lightweight, and a new protocol could well be preferable here.

Regards,

John

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Sep 2012 11:10:05 -0600

On 9/28/12 11:00 AM, John Howie wrote:

> I would really like to see information exchange be secure, fast
> and lightweight, and a new protocol could well be preferable here.

If you didn't have a bias against XML, XMPP would be a good solution
to the requirements you've outlined.

(With regard to the "bloat" of XML, note that XMPP uses long-lived XML
streams so the compression ratios are significant.)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Brian Trammell <[email-masked]>
Date: Fri, 28 Sep 2012 19:36:07 +0200

Hi, John,

We can certainly have that discussion. Indeed, RID may be transported over alternate protocols (that one's easy, just write a document with the bindings) and the IODEF data model may be represented using alternate formats as well (this one would take a little more work, but not much, and we hope to have a 5070bis document soon, so alternate formats might be on the table for that effort).

I'll reserve comment for now on the goodness, badness, or ugliness of any particular technology or protocol, though I will admit to being a little skeptical that the solution to vulnerabilities in existing software is brand new software from scratch implementing a brand new protocol from scratch, especially if that new protocol needs to provide security guarantees.

Best regards,

Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 28 Sep 2012 11:43:07 -0600

On 9/28/12 11:36 AM, Brian Trammell wrote:
> Hi, John,
> 
> We can certainly have that discussion. Indeed, RID may be
> transported over alternate protocols (that one's easy, just write a
> document with the bindings) and the IODEF data model may be
> represented using alternate formats as well (this one would take a
> little more work, but not much, and we hope to have a 5070bis
> document soon, so alternate formats might be on the table for that
> effort).

I'll volunteer to write an XMPP binding for RID, but I can't promise
it immediately.

> I'll reserve comment for now on the goodness, badness, or ugliness
> of any particular technology or protocol, though I will admit to
> being a little skeptical that the solution to vulnerabilities in
> existing software is brand new software from scratch implementing a
> brand new protocol from scratch, especially if that new protocol
> needs to provide security guarantees.

I tend to agree, which is why using HTTP or XMPP makes sense to me.
They are stable technologies that have undergone lots of real-world
deployment, intensive security review, etc.

Peter

---

From: Francis Brosnan Blazquez <[email-masked]>
Date: Fri, 28 Sep 2012 19:45:44 +0200

Hi,

The working group could also consider BEEP. It is lightweight,
extensible and it allows any format for your message (since it sees the
payload as a bunch of octets). 

Specifically, we are using it in a real-time monitoring solution where
hundred of nodes are watched and queried, without having to use a
polling solutions to get those events...

Best Regards,

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> 
> iEYEARECAAYFAlBl2e0ACgkQNL8k5A2w/vwQ/ACfQ/JoLf08je6WoBkk9A+OpqTo
> 09wAoOoCRYp1ImSAJMKMWClDKL26qlJ4
> =DJzM
> -----END PGP SIGNATURE-----

-- 
Francis Brosnan Blázquez <[email-masked]>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).

---

From: "Moriarty, Kathleen" <[email-masked]>
Date: Fri, 28 Sep 2012 14:04:34 -0400

Interesting...  RID used BEEP in an earlier version because of the suitability to the protocol needs, but because of low deployment of BEEP, we switched to HTTPS.

I am curious to see if different exchange types may use different bindings.  The RESTful binding in the ROLIE draft may be well suited for repository access and IODEF + RID + transport where object security is needed.  What are the use cases for each if they differ and what do folks prefer and think will help adoption.

As Brian said, other formats are possible.  IODEF has been implemented in JSON from the data model description already.

I would love to see more views on this discussion!

Thanks,
Kathleen

Sent from my iPhone

---

From: "Panos Kampanakis (pkampana)" <[email-masked]>
Date: Fri, 28 Sep 2012 18:15:18 +0000

Defining the abbreviation to be used in the name of the reference (before the ":") in the IANA table that has the reference entries seems like a simple and good idea.

As for the character restriction of the ID after the ":", I think a restriction like [A-Za-z0-9_\-\.]+ would cover all cases, or at least that is what I think.

Panos

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Montville
Sent: Friday, September 28, 2012 9:31 AM
To: Moriarty, Kathleen; [email-masked]
Subject: Re: [mile] FW: New Version Notification for draft-montville-mile-enum-reference-format-00.txt

>colon formed?  What characters are permitted.

I think I was taking the "Name" in the IANA table to be the identifier, rather than the full name (so, for example, "CPE" rather than "Common Platform Enumeration").  So, we could simply add an abbreviation to the IANA table, where the abbreviation would consist of lowercase alphabetical characters for the type identifier ("CXI" in the example above).

The character limitations should be none, such that this method would not encumber any enumeration specification.  That said, I think it would be reasonable to make it alphanumeric with some punctuation (but I'd like to hear from the list as to what they think) - so essentially a string with some character restrictions.

As I mention above, I'd really like to hear from others on the list as to what they feel is best.

>>I read through the draft and think it looks great!  I did notice that 
>>the identifier format after the id: is not specified.  An example is 
>>provided, but am wondering if it would be helpful to provide an 
>>explicit format to help developers when formatting and parsing the content.
>>
>explicitly defined by a document or available specification that would 
>be attainable from the registry (Specification URI).
>
>>>A new version of I-D, 
>>>has been successfully submitted by Adam W. Montville and posted to 
>>>the IETF repository.
>>>

---

From: Francis Brosnan Blázquez <[email-masked]>
Date: Fri, 28 Sep 2012 20:36:47 +0200

Hi,

In the case it is required, I'll be glad to define a BEEP profile to
transport RID over BEEP.

Best Regards,