Suggestion for new "alias" IPTypeEnum type

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Suggestion for new "alias" IPTypeEnum type

Blake Hartstein
Hey folks,
Would it be possible to add a third type to simpleType IPTypeEnum for
"alias" or "mask string", basically I'm wanting to use this potential
new enum type for a internal IP address, internal DNS server, broadcast
address, or other known IP addresses that won't have any meaning on
networks outside of my own. Adding this type will assist others in
determining not to block a benign or internal IP address and it will
make the output more standardized so that two MAEC outputs will be more
closely aligned when performed by different systems.

Thoughts?
Blake
Reply | Threaded
Open this post in threaded view
|

RE: Suggestion for new "alias" IPTypeEnum type

Kirillov, Ivan A.
Hi Blake,

Thanks for the suggestion.

I agree that it would be useful to specify whether an IP address is benign or internal. However, I'm not sure if the IPTypeEnum is the right place for it, as it is intended for specifying the IP version of the address, i.e. ipv4 or ipv6. Perhaps we can extend the IPAddress type, and add an optional Boolean attribute called "benign" that you can use to specify such addresses. That way you can simply check this attribute, and not block any addresses where "benign == 1." What does everyone think?

Regards,
Ivan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Blake Hartstein
Sent: Wednesday, May 11, 2011 6:15 PM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Suggestion for new "alias" IPTypeEnum type

Hey folks,
Would it be possible to add a third type to simpleType IPTypeEnum for
"alias" or "mask string", basically I'm wanting to use this potential
new enum type for a internal IP address, internal DNS server, broadcast
address, or other known IP addresses that won't have any meaning on
networks outside of my own. Adding this type will assist others in
determining not to block a benign or internal IP address and it will
make the output more standardized so that two MAEC outputs will be more
closely aligned when performed by different systems.

Thoughts?
Blake
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for new "alias" IPTypeEnum type

Wes Young
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://tools.ietf.org/html/rfc5070#section-3.16

On May 13, 2011, at 9:17 AM, Kirillov, Ivan A. wrote:

> Hi Blake,
>
> Thanks for the suggestion.
>
> I agree that it would be useful to specify whether an IP address is benign or internal. However, I'm not sure if the IPTypeEnum is the right place for it, as it is intended for specifying the IP version of the address, i.e. ipv4 or ipv6. Perhaps we can extend the IPAddress type, and add an optional Boolean attribute called "benign" that you can use to specify such addresses. That way you can simply check this attribute, and not block any addresses where "benign == 1." What does everyone think?
>
> Regards,
> Ivan
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Blake Hartstein
> Sent: Wednesday, May 11, 2011 6:15 PM
> To: maec-discussion-list Malware Attribute Enumeration Discussion
> Subject: Suggestion for new "alias" IPTypeEnum type
>
> Hey folks,
> Would it be possible to add a third type to simpleType IPTypeEnum for
> "alias" or "mask string", basically I'm wanting to use this potential
> new enum type for a internal IP address, internal DNS server, broadcast
> address, or other known IP addresses that won't have any meaning on
> networks outside of my own. Adding this type will assist others in
> determining not to block a benign or internal IP address and it will
> make the output more standardized so that two MAEC outputs will be more
> closely aligned when performed by different systems.
>
> Thoughts?
> Blake

- --
Wes
claimid.com/wesyoung
[hidden email]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk3NM04ACgkQKezpZd226UbJTgCfQIHvT5/pl38all2FHx/siNlN
3pIAoJjyLTmQ6UQ3yS9bzkZXKJhS4r/n
=MEyW
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

RE: Suggestion for new "alias" IPTypeEnum type

Kirillov, Ivan A.
Interesting. I suppose this begs the question of how much we want to overlap with incident reporting in terms of covering nodes/resources and other infrastructure elements in MAEC. If a piece of malware propagates inside a network, this is certainly something we want to capture, but probably only in terms of the IP addresses that it propagated to. I don't think we want to go as far as the Node class inside IODEF.  

I think Blake's proposal makes sense, as there may be benign/internal IP addresses that are captured as part of the analysis of a malware instance, and we want to make sure that we have the ability to characterize them as such.

Regards,
Ivan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wes Young
Sent: Friday, May 13, 2011 9:34 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: Suggestion for new "alias" IPTypeEnum type

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://tools.ietf.org/html/rfc5070#section-3.16

On May 13, 2011, at 9:17 AM, Kirillov, Ivan A. wrote:

> Hi Blake,
>
> Thanks for the suggestion.
>
> I agree that it would be useful to specify whether an IP address is benign or internal. However, I'm not sure if the IPTypeEnum is the right place for it, as it is intended for specifying the IP version of the address, i.e. ipv4 or ipv6. Perhaps we can extend the IPAddress type, and add an optional Boolean attribute called "benign" that you can use to specify such addresses. That way you can simply check this attribute, and not block any addresses where "benign == 1." What does everyone think?
>
> Regards,
> Ivan
>
> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf Of Blake Hartstein
> Sent: Wednesday, May 11, 2011 6:15 PM
> To: maec-discussion-list Malware Attribute Enumeration Discussion
> Subject: Suggestion for new "alias" IPTypeEnum type
>
> Hey folks,
> Would it be possible to add a third type to simpleType IPTypeEnum for
> "alias" or "mask string", basically I'm wanting to use this potential
> new enum type for a internal IP address, internal DNS server, broadcast
> address, or other known IP addresses that won't have any meaning on
> networks outside of my own. Adding this type will assist others in
> determining not to block a benign or internal IP address and it will
> make the output more standardized so that two MAEC outputs will be more
> closely aligned when performed by different systems.
>
> Thoughts?
> Blake

- --
Wes
claimid.com/wesyoung
[hidden email]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk3NM04ACgkQKezpZd226UbJTgCfQIHvT5/pl38all2FHx/siNlN
3pIAoJjyLTmQ6UQ3yS9bzkZXKJhS4r/n
=MEyW
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for new "alias" IPTypeEnum type

Wes Young
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

there is a common mode of "re-using" those classes when needed in other stuff. Makes "having to build new code" or "understand what you mean by ip-address" easier to learn (reads: lowers the barrier to entry if you want me to use your format too). I posted the node-role, because it begins to drill down into this topic... at-worst, the address class handles most of what you want for the lower level stuff (if only because we do the same thing when describing attacks).

coming from the ops side, benign/internal is the wrong approach (imo), both in terms of scale and ops. There are only shades of grey (eg: that's what severity+confidence is for). Working "from the malware out"; you'll probably end up doing what we did "from the network to the malware"; where we encapsulating ICSG (malware) within the IODEF wrapper describing the attack...

<IODEF-Document><Incident restriction="need-to-know"><IncidentID name="5e3db61c-9ec8-3483-970f-858fa8b84cda"/><AlternativeID><IncidentID restriction="public" name="5e3db61c-9ec8-3483-970f-858fa8b84cda">http://malc0de.com/database/index.php?search=91b9221622555560407f6a4cbfc8d0c3&amp;MD5=on</IncidentID></AlternativeID><DetectTime>2011-02-18T00:00:00Z</DetectTime><Description>malware url md5:91b9221622555560407f6a4cbfc8d0c3</Description><Assessment><Impact severity="medium">malware url</Impact><Confidence rating="numeric">7</Confidence></Assessment><EventData><Record><RecordData>

<RecordItem dtype="xml" meaning="malware sample" formatid="icsg1.1" restriction="need-to-know">&lt;x0:malwareMetaData xmlns:x0=&quot;http://xml/metadataSharing.xsd&quot; id=&quot;91b9221622555560407f6a4cbfc8d0c3&quot;&gt;&lt;x0:company&gt;5e3db61c-9ec8-3483-970f-858fa8b84cda&lt;/x0:company&gt;&lt;x0:author&gt;5e3db61c-9ec8-3483-970f-858fa8b84cda&lt;/x0:author&gt;&lt;x0:comment&gt;malware url md5:91b9221622555560407f6a4cbfc8d0c3&lt;/x0:comment&gt;&lt;x0:timestamp&gt;2011-02-18T00:00:00Z&lt;/x0:timestamp&gt;&lt;x0:objects&gt;&lt;x0:file id=&quot;91b9221622555560407f6a4cbfc8d0c3&quot;&gt;&lt;x0:md5&gt;91b9221622555560407f6a4cbfc8d0c3&lt;/x0:md5&gt;&lt;/x0:file&gt;&lt;x0:classification id=&quot;&quot; type=&quot;dirty&quot;&gt;&lt;x0:classificationName&gt;malware url&lt;/x0:classificationName&gt;&lt;x0:companyName&gt;5e3db61c-9ec8-3483-970f-858fa8b84cda&lt;/x0:companyName&gt;&lt;/x0:classification&gt;&lt;/x0:objects&gt;&lt;/x0:malwareMetaData&gt;</RecordItem>
</RecordData></Record></EventData></Incident></IODEF-Document>

the idea being... (imo): keep the two (or three or four) types of "classes" separate. That will make for better re-use (either by you or by others that use your 'standard'). That makes it easier for me to re-use your specific classes in the standard I use (etc). When we go down the road that "this one xsd has a datatype for everything"... it raises the barrier to entry a great deal (in terms of learning the spec, writing code for the spec, maintaing it, etc). You don't have to use everything in NodeRole, but if you re-use the pieces you do need, it'll help me use your standard(s) down the road for the bits that I use (IODEF) doesn't do well (malware behavior stuff).

ymmv. thinking out-loud here, don't take it the wrong way :)

On May 13, 2011, at 10:14 AM, Kirillov, Ivan A. wrote:

> Interesting. I suppose this begs the question of how much we want to overlap with incident reporting in terms of covering nodes/resources and other infrastructure elements in MAEC. If a piece of malware propagates inside a network, this is certainly something we want to capture, but probably only in terms of the IP addresses that it propagated to. I don't think we want to go as far as the Node class inside IODEF.  
>
> I think Blake's proposal makes sense, as there may be benign/internal IP addresses that are captured as part of the analysis of a malware instance, and we want to make sure that we have the ability to characterize them as such.

- --
Wes
claimid.com/wesyoung
[hidden email]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk3NR1EACgkQKezpZd226UaeNACfZzWobFlsLr5hJPYlrNBRiWxN
pk0An0HpWkz0vqQgWuuLUv4/WahSqtBJ
=ebQl
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

RE: Suggestion for new "alias" IPTypeEnum type

Kirillov, Ivan A.
I'm all for re-using existing classes when appropriate, and this is something we've done in the current MAEC schema by importing  and using components of IEEE ICSG's MMDEF v1.1. Thus I certainly agree that it does not help adoption and use when every effort tries to type and define common data elements like IP addresses.

However, both MMDEF and IODEF define IP addresses, so the question now is which one do we import and reference? The IODEF piece, thus allowing better compatibility with incident response? Or from MMDEF, allowing MAEC to be used as a means of sharing additional malware information built on top of this framework? Right now we're doing the latter, since there is a stronger association between the two efforts. This is likely one of the few overlaps between MMDEF and IODEF, so it's not something we'll have to deal with often, but unfortunately we still have to occasionally pick and choose which "definition" of the same entity we wish to use.

Your point of 'shades of grey' from the ops side is well taken. It's hard to discern in an incident whether some associated node is truly benign or not, thus the impact and confidence measures in IODEF. The more I think about it, a simple 'benign/internal' indicator may be too arbitrary, and it may not be the best fit for inclusion in MAEC. We're just trying to capture and share the observable and behavioral information associated with malware; the judgment of whether an IP should be blocked or not, or is benign or not, is not something that should be dealt with in MAEC. Instead, it should be up to the operator or consumer of the MAEC document.

Thus, I think Blake's original suggestion of a mask or an alias makes better sense. Perhaps we can extend the IPAddress type to add such an attribute; either way, I still think that we need a way of specifying that an IP address is local and/or irrelevant.

Anyhow, thanks for the comments - more to think about, as always :) I now plan on taking a deeper look at IODEF to see other classes that may be useful for referencing in MAEC.

Regards,
Ivan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wes Young
Sent: Friday, May 13, 2011 10:59 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: Suggestion for new "alias" IPTypeEnum type

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

there is a common mode of "re-using" those classes when needed in other stuff. Makes "having to build new code" or "understand what you mean by ip-address" easier to learn (reads: lowers the barrier to entry if you want me to use your format too). I posted the node-role, because it begins to drill down into this topic... at-worst, the address class handles most of what you want for the lower level stuff (if only because we do the same thing when describing attacks).

coming from the ops side, benign/internal is the wrong approach (imo), both in terms of scale and ops. There are only shades of grey (eg: that's what severity+confidence is for). Working "from the malware out"; you'll probably end up doing what we did "from the network to the malware"; where we encapsulating ICSG (malware) within the IODEF wrapper describing the attack...

<IODEF-Document><Incident restriction="need-to-know"><IncidentID name="5e3db61c-9ec8-3483-970f-858fa8b84cda"/><AlternativeID><IncidentID restriction="public" name="5e3db61c-9ec8-3483-970f-858fa8b84cda">http://malc0de.com/database/index.php?search=91b9221622555560407f6a4cbfc8d0c3&amp;MD5=on</IncidentID></AlternativeID><DetectTime>2011-02-18T00:00:00Z</DetectTime><Description>malware url md5:91b9221622555560407f6a4cbfc8d0c3</Description><Assessment><Impact severity="medium">malware url</Impact><Confidence rating="numeric">7</Confidence></Assessment><EventData><Record><RecordData>

<RecordItem dtype="xml" meaning="malware sample" formatid="icsg1.1" restriction="need-to-know">&lt;x0:malwareMetaData xmlns:x0=&quot;http://xml/metadataSharing.xsd&quot; id=&quot;91b9221622555560407f6a4cbfc8d0c3&quot;&gt;&lt;x0:company&gt;5e3db61c-9ec8-3483-970f-858fa8b84cda&lt;/x0:company&gt;&lt;x0:author&gt;5e3db61c-9ec8-3483-970f-858fa8b84cda&lt;/x0:author&gt;&lt;x0:comment&gt;malware url md5:91b9221622555560407f6a4cbfc8d0c3&lt;/x0:comment&gt;&lt;x0:timestamp&gt;2011-02-18T00:00:00Z&lt;/x0:timestamp&gt;&lt;x0:objects&gt;&lt;x0:file id=&quot;91b9221622555560407f6a4cbfc8d0c3&quot;&gt;&lt;x0:md5&gt;91b9221622555560407f6a4cbfc8d0c3&lt;/x0:md5&gt;&lt;/x0:file&gt;&lt;x0:classification id=&quot;&quot; type=&quot;dirty&quot;&gt;&lt;x0:classificationName&gt;malware url&lt;/x0:classificationName&gt;&lt;x0:companyName&gt;5e3db61c-9ec8-3483-970f-858fa8b84cda&lt;/x0:companyName&gt;&lt;/x0:classification&gt;&lt;/x0:objects&gt;&lt;/x0:malwareMetaData&gt;</RecordItem>
</RecordData></Record></EventData></Incident></IODEF-Document>

the idea being... (imo): keep the two (or three or four) types of "classes" separate. That will make for better re-use (either by you or by others that use your 'standard'). That makes it easier for me to re-use your specific classes in the standard I use (etc). When we go down the road that "this one xsd has a datatype for everything"... it raises the barrier to entry a great deal (in terms of learning the spec, writing code for the spec, maintaing it, etc). You don't have to use everything in NodeRole, but if you re-use the pieces you do need, it'll help me use your standard(s) down the road for the bits that I use (IODEF) doesn't do well (malware behavior stuff).

ymmv. thinking out-loud here, don't take it the wrong way :)

On May 13, 2011, at 10:14 AM, Kirillov, Ivan A. wrote:

> Interesting. I suppose this begs the question of how much we want to overlap with incident reporting in terms of covering nodes/resources and other infrastructure elements in MAEC. If a piece of malware propagates inside a network, this is certainly something we want to capture, but probably only in terms of the IP addresses that it propagated to. I don't think we want to go as far as the Node class inside IODEF.  
>
> I think Blake's proposal makes sense, as there may be benign/internal IP addresses that are captured as part of the analysis of a malware instance, and we want to make sure that we have the ability to characterize them as such.

- --
Wes
claimid.com/wesyoung
[hidden email]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk3NR1EACgkQKezpZd226UaeNACfZzWobFlsLr5hJPYlrNBRiWxN
pk0An0HpWkz0vqQgWuuLUv4/WahSqtBJ
=ebQl
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for new "alias" IPTypeEnum type

Wes Young
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

interestingly enough; had this discussion with our crew today (re: notifications). If we hand you "a flow"; which end are you supposed to care about (one of the ip's is yours, one is not...).

my take was/is:

"i'm not sure that belongs in the spec when you're making an observation"

imo: that belongs in the specific software your adapting around this spec "to do stuff".

for instance:

take the "list of addresses" run them through your database and act on them as your specific application dictates. If you're motive is to build an IDS feed; you're taking the addresses that aren't yours and using those. If your purpose is notification, then you're taking the addresses that are yours and using those.

try to stay away from specific assumptions in the design of the spec and leave those up to the applications using the spec. The more specific the spec, the less it can be re-used else-ware.. too generic, the more specific your apps need to be. There's a sweet spot there somewhere... I think it's labeling the facts and letting your applications derive what they are (or are not).

cheers,

On May 16, 2011, at 9:50 AM, Kirillov, Ivan A. wrote:

> I still think that we need a way of specifying that an IP address is local and/or irrelevant.

- --
Wes
claimid.com/wesyoung
[hidden email]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk3RSKYACgkQKezpZd226UbgDQCfW5/uurdCeotAUmRKdO0T78rZ
XkYAoIbVSVKrmWHHiBHMU9FWE3MfWShW
=ihKn
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

RE: Suggestion for new "alias" IPTypeEnum type

Kirillov, Ivan A.
Good point. With MAEC, we're trying to create a framework for relaying the facts about malware in terms of attributes and characteristics. Adorning extra metadata attributes can be useful, but it can also take away from the value that applications can derive.

There's certainly a sweet spot, a balance, that we have to strike in this regard. Ultimately it will not please everyone, but our hope is to make it applicable to as a large an audience as possible. In that vein, I do agree that we should try to stay away from too many specific assumptions, and let the use cases and applications drive the design.

Regards,
Ivan

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Wes Young
Sent: Monday, May 16, 2011 11:54 AM
To: maec-discussion-list Malware Attribute Enumeration Discussion
Subject: Re: Suggestion for new "alias" IPTypeEnum type

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

interestingly enough; had this discussion with our crew today (re: notifications). If we hand you "a flow"; which end are you supposed to care about (one of the ip's is yours, one is not...).

my take was/is:

"i'm not sure that belongs in the spec when you're making an observation"

imo: that belongs in the specific software your adapting around this spec "to do stuff".

for instance:

take the "list of addresses" run them through your database and act on them as your specific application dictates. If you're motive is to build an IDS feed; you're taking the addresses that aren't yours and using those. If your purpose is notification, then you're taking the addresses that are yours and using those.

try to stay away from specific assumptions in the design of the spec and leave those up to the applications using the spec. The more specific the spec, the less it can be re-used else-ware.. too generic, the more specific your apps need to be. There's a sweet spot there somewhere... I think it's labeling the facts and letting your applications derive what they are (or are not).

cheers,

On May 16, 2011, at 9:50 AM, Kirillov, Ivan A. wrote:

> I still think that we need a way of specifying that an IP address is local and/or irrelevant.

- --
Wes
claimid.com/wesyoung
[hidden email]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.16 (Darwin)

iEYEARECAAYFAk3RSKYACgkQKezpZd226UbgDQCfW5/uurdCeotAUmRKdO0T78rZ
XkYAoIbVSVKrmWHHiBHMU9FWE3MfWShW
=ihKn
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Suggestion for new "alias" IPTypeEnum type

Chase, Melissa P.
One thing to keep in mind is that MAEC is trying to support both local
applications sharing/manipulating data and sharing information across
organizations.

The ability to identify information as local and "unimportant" comes up in
other contexts besides IP addresses. A dynamic analysis tool might report
that a file was created giving the full pathname, but the leading part of
the path depends upon the execution environment (e.g., the directory in
which the malware launched). So having a way to specify that part of the
path is irrelevant, or dependent upon execution context, facilitates
sharing information: the recipient won't expect to see the exact pathname
reported by dynamic analysis tool, but only the relevant part.

Similarly if you're sharing IP connection information, I would think that
the information would be more useful to the recipient if they knew which
addresses were local and which were remote. The recipient might not have
the databases to determine that computationally, so making it explicit
would be helpful. If you're sharing information across local applications,
that might not be necessary.

Penny

On 5/16/11 4:37 PM, "Kirillov, Ivan A." <[hidden email]> wrote:

>Good point. With MAEC, we're trying to create a framework for relaying
>the facts about malware in terms of attributes and characteristics.
>Adorning extra metadata attributes can be useful, but it can also take
>away from the value that applications can derive.
>
>There's certainly a sweet spot, a balance, that we have to strike in this
>regard. Ultimately it will not please everyone, but our hope is to make
>it applicable to as a large an audience as possible. In that vein, I do
>agree that we should try to stay away from too many specific assumptions,
>and let the use cases and applications drive the design.
>
>Regards,
>Ivan
>
>-----Original Message-----
>From: [hidden email]
>[mailto:[hidden email]] On Behalf Of Wes Young
>Sent: Monday, May 16, 2011 11:54 AM
>To: maec-discussion-list Malware Attribute Enumeration Discussion
>Subject: Re: Suggestion for new "alias" IPTypeEnum type
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>interestingly enough; had this discussion with our crew today (re:
>notifications). If we hand you "a flow"; which end are you supposed to
>care about (one of the ip's is yours, one is not...).
>
>my take was/is:
>
>"i'm not sure that belongs in the spec when you're making an observation"
>
>imo: that belongs in the specific software your adapting around this spec
>"to do stuff".
>
>for instance:
>
>take the "list of addresses" run them through your database and act on
>them as your specific application dictates. If you're motive is to build
>an IDS feed; you're taking the addresses that aren't yours and using
>those. If your purpose is notification, then you're taking the addresses
>that are yours and using those.
>
>try to stay away from specific assumptions in the design of the spec and
>leave those up to the applications using the spec. The more specific the
>spec, the less it can be re-used else-ware.. too generic, the more
>specific your apps need to be. There's a sweet spot there somewhere... I
>think it's labeling the facts and letting your applications derive what
>they are (or are not).
>
>cheers,
>
>On May 16, 2011, at 9:50 AM, Kirillov, Ivan A. wrote:
>
>> I still think that we need a way of specifying that an IP address is
>>local and/or irrelevant.
>
>- --
>Wes
>claimid.com/wesyoung
>[hidden email]
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG/MacGPG2 v2.0.16 (Darwin)
>
>iEYEARECAAYFAk3RSKYACgkQKezpZd226UbgDQCfW5/uurdCeotAUmRKdO0T78rZ
>XkYAoIbVSVKrmWHHiBHMU9FWE3MfWShW
>=ihKn
>-----END PGP SIGNATURE-----