Subject: Re: [dtn-interest] Fwd: Nits on draft-irtf-dtnrg-bundle-security
From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>
Cc: Sean Turner <[email-masked]>, Peter Lovell <[email-masked]>, DTN interest <[email-masked]>
Date: Mon, 31 Jan 2011 13:11:16 +0000
List-Id: Delay Tolerant Networking Interest List <dtn-interest.maillists.intel-research.net>

On 31/01/11 13:04, Elwyn Davies wrote:
> On Mon, 2011-01-31 at 11:14 +0000, Stephen Farrell wrote:
>> I suspect that we won't get to do those before the IESG chat so
>> lets see if any other ADs have useful comments and then address
>> 'em then.
> OK.  However I think it would be useful to think about the sign
> first/encrypt first comments.  Not being a security geek I am not
> qualified to offer opinions...

Yep. Will do that when we've the full set of comments.

> Do we also get a secdir review of this document? 

Nope. (Except sometimes by accident, but I'll let secdir folks know
not to bother if it happens again;-)

S.

>>
>> S.
>>
>> PS: If Peter doesn't have time, I can probably take a stab at
>> this.
> Thanks!
> 
> /E
>>
>> On 31/01/11 10:50, Elwyn Davies wrote:
>>> Hi
>>>
>>> Thanks to Sean for the review.  I see from the datatracker that you
>>> don't think these are blocking issues.
>>>
>>> Authors:  any responses to the comments?  I guess we need to fix up the
>>> nits anyway.  I think Peter has the editorial pencil at the moment.. do
>>> you have cycles to do the fixes?
>>>
>>> Regards,
>>> Elwyn
>>> Document Shepherd
>>>
>>> Couple of (trivial) comments in line below...
>>>
>>> On Sat, 2011-01-29 at 17:28 -0500, Sean Turner wrote:
>>>
>>>> -------- Original Message --------
>>>> Subject: Nits on draft-irtf-dtnrg-bundle-security
>>>> Date: Sat, 29 Jan 2011 17:23:28 -0500
>>>> From: Sean Turner <[email-masked]>
>>>> To: [email-masked]
>>>> CC: [email-masked], The IESG <[email-masked]>
>>>>
>>>> Hi,
>>>>
>>>> Here's some comments/questions I have on this document (note this isn't
>>>> my RFC 5742 review):
>>>>
>>>> - No 'Intended status' indicated for this document; I'm assuming
>>>> Experimental as per the datatracker.  I think you should probably add
>>>> the header line to make sure though.
>>>>
>>>> - There are two unused references: RFC 3370 and RFC 4106.
>>>>
>>>> I think 3370 could we worked in somewhere when describing the CMS bits.
>>>>
>>>> For the 4106 I think the checker is barfing on the following from
>>>> Section 4.3 and 4.4:
>>>>
>>>> [Note: parts of the following description are borrowed from RFC 4106].
>>>>
>>>> Maybe replace it with:
>>>>
>>>> Note: parts of the following description is borrowed from [RFC4106].
>>>>
>>>> - Obsolete reference to [RFC3280].  Should be to [RFC5280].
>>>>
>>>> - Couldn't find the [DTNRB] reference.  Did the document die a graceful
>>>> death?
>>> No.  The version is out of date.  Version 06 exists.
>>>>
>>>> - Expand DTN, EID, SDNV, BA, and PI on first use
>>>>
>>>> - Authentication is mentioned for the first time in Sec 2 when
>>>> discussing the PIB.  Wouldn't it be better to mention it earlier?
>>>>
>>>> - Section 2.1: When describing the two EIDs and cipher suite flags as
>>>> "(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
>>>>   Same for the Figure 3 description (i.e., the paragraph before the figure).
>>>>
>>>> - Section 2.3: r/the key information item Section 2.6 is optional, and
>>>> if not provided then the key should be/the key information item Section
>>>> 2.6 is OPTIONAL, and if not provided then the key SHOULD be
>>>>
>>>> - Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
>>>> used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
>>>> Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
>>>> you do this need to add "NOT RECOMMENDED" to the first para in section 1
>>>> like the errata 499:
>>>> http://www.rfc-editor.org/errata_search.php?rfc=2119
>>>>
>>>> - Section 2.4: Some "SHOULDs":
>>>>
>>>>     It is RECOMMENDED to apply a Payload
>>>>     Confidentiality ciphersuite to non-payload blocks only if these
>>>>     SHOULD be super-encrypted with the payload.  If super-encryption of
>>>>     ^^^^^^
>>>>     the block is not desired then protection of the block SHOULD be done
>>>>                                                           ^^^^^^
>>>>     using the Extension Security Block mechanism rather than PCB.
>>>>
>>>> - Section 2.4: "SHOULD NOT" instead of "should not":
>>>>
>>>>     These multiple PCB instances, are
>>>>     not "related" and SHOULD NOT contain correlators.
>>>>                       ^^^^^^^^^^
>>>>
>>>> - Section 2.8: In the paragraph about authenticated and encrypted
>>>> bundles, I think the last sentence should be "RECOMMENDED".  It's
>>>> interesting to note that you'd prefer encrypt then sign as opposed to
>>>> sign and then encrypt.  Looking forward to the security consideration
>>>> about why.
>>>>
>>>> - Section 3.2: r/MUST not/MUST NOT ?
>>>>
>>>> - Section 3.2: r/No other blocks are
>>>>     required to follow the payload block and it is RECOMMENDED that they
>>>>     NOT do so./No other blocks are
>>>>     required to follow the payload block and it is NOT RECOMMENDED
>>>>     that they do so.
>>>>
>>>> - Section 3.4.2: r/This algorithm is intended to protect parts of the
>>>> bundle which should not be changed in-transit./This algorithm is
>>>> intended to protect parts of the bundle which SHOULD NOT be changed
>>>> in-transit.
>>>>
>>>> - Sections 3.4.1 & 3.4.2: Need a reference for URI.
>>>>
>>>> - Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
>>>> id-data, but you should probably be explicit about it.
>>>>
>>>> - Section 4.1: r/Security parameters are optional with this
>>>> scheme/Security parameters are OPTIONAL with this scheme
>>>>
>>>> - Section 4.1: A couple of comments/questions on the following:
>>>>
>>>>     Implementations MUST support use of "AuthenticatedData" type as
>>>>     defined in [RFC5652] section 9.1, with RecipientInfo type
>>>>     KeyTransRecipientInfo containing the issuer and serial number of a
>>>>     suitable certificate.  They MAY support additional RecipientInfo
>>>>     types.  They MAY additionally use the "SignedData" type described in
>>>>     [RFC5652] Section 5.1.  In either case, the "eContent" field in
>>>>     EncapsulatedContentInfo contains the encrypted HMAC key.
>>>>
>>>> 1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
>>>> reason you chose differently?  Most certificates have SKIs (now) and
>>>> it's probably smaller than the issuer/serial # combo.
>>>>
>>>> 2. How is SignedData used here?  It says it MAY be used - is that in
>>>> addition to?  There's no RecipientInfo with SignedData so I am a little
>>>> confused.
>>>>
>>>> - Section 4.1 and 4.2: Should probably say something about whether you'd
>>>> recommend no unsigned/unauthenticated and signed/authenticated
>>>> attributes.  I'm assuming you're not recommending any ;)
>>>>
>>>> - Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
>>>> issuer/serial # combo.  Any reason you chose differently?  Most
>>>> certificates have SKIs and it's probably smaller than the issuer/serial
>>>> # combo.
>>>>
>>>> - Section 4.2: Had the following:
>>>>
>>>>    RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
>>>>    signature scheme in [RFC4055].
>>>>
>>>> Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
>>>> RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
>>>> RSASSA-PSS-params or something else.  Also wouldn't you have to say more
>>>> like what's the hashAlgorithm, maskGenAlgorithm, whether
>>>> RSASSA-PSS-params is included in certificates?
>>>>
>>>> Also r/RSA with SHA256/RSA with SHA-256
>>>>
>>>> - Sections 4.1-4.4: The eContent values for the CMS content types threw
>>>> me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
>>>> just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
>>>> reads like there are two sets of operation for each of the four Block
>>>> Types.  You do one for the BAB, PIB, etc. values and then another for
>>>> the CMS structures?  Am I reading that right?  The parts about the
>>>> "eContent" e.g.,:
>>>>
>>>> The "eContent" field in EncapsulatedContentInfo contains the signed
>>>> checksum (SignatureValue) of the data.
>>>>
>>>> That tells me the CMS processing generates a message digest over the PIB
>>>> SignatureValue and then signs the output of the message digest and put
>>>> it in the SignerInfo.signature value field.
>>>>
>>>> Couldn't you just omit all the eContents?  They're optional in all cases
>>>> and can be gotten from elsewhere in the CMS blobs.
>>>>
>>>> - Section 7: You should point to [RFC5652]/[RFC5280] for it's security
>>>> considerations when using CMS/certificates.  This save you recreating
>>>> text about keeping keys secret, etc.  Need some additional motherhood
>>>> and apple pie statements about randomly generating keys and point to
>>>> [RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.
>>>>
>>>> - Section 7: I didn't see a security consideration that addresses why
>>>> you'd prefer to encrypt then authenticate.  The text earlier implied and
>>>> attack of some kind.  RFC 5751 also had something to say about this:
>>>>
>>>>     There are security ramifications to choosing whether to sign first or
>>>>     encrypt first.  A recipient of a message that is encrypted and then
>>>>     signed can validate that the encrypted block was unaltered, but
>>>>     cannot determine any relationship between the signer and the
>>>>     unencrypted contents of the message.  A recipient of a message that
>>>>     is signed then encrypted can assume that the signed message itself
>>>>     has not been altered, but that a careful attacker could have changed
>>>>     the unauthenticated portions of the encrypted message.
>>>>
>>> (The following comment was withdrawn.. all new ones have 'specification
>>> required' quoted.)
>>>> - IANA Considerations: When defining an IANA controlled registry the
>>>> document needs to indicate how the registry is updated (e.g., RFC
>>>> required, expert review, etc.).  See Section 4 of RFC 5226.
>>>>
>>>> Cheers,
>>>>
>>>> spt
>>>>
>>>
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
> 
> 

From: Elwyn Davies <[email-masked]>
To: Stephen Farrell <[email-masked]>
Date: Mon, 31 Jan 2011 13:04:25 +0000
Cc: Sean Turner <[email-masked]>, Peter Lovell <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] Fwd: Nits on draft-irtf-dtnrg-bundle-security

On Mon, 2011-01-31 at 11:14 +0000, Stephen Farrell wrote:
> I suspect that we won't get to do those before the IESG chat so
> lets see if any other ADs have useful comments and then address
> 'em then.
OK.  However I think it would be useful to think about the sign
first/encrypt first comments.  Not being a security geek I am not
qualified to offer opinions...

Do we also get a secdir review of this document? 
> 
> S.
> 
> PS: If Peter doesn't have time, I can probably take a stab at
> this.
Thanks!

/E
> 
> On 31/01/11 10:50, Elwyn Davies wrote:
> > Hi
> > 
> > Thanks to Sean for the review.  I see from the datatracker that you
> > don't think these are blocking issues.
> > 
> > Authors:  any responses to the comments?  I guess we need to fix up the
> > nits anyway.  I think Peter has the editorial pencil at the moment.. do
> > you have cycles to do the fixes?
> > 
> > Regards,
> > Elwyn
> > Document Shepherd
> > 
> > Couple of (trivial) comments in line below...
> > 
> > On Sat, 2011-01-29 at 17:28 -0500, Sean Turner wrote:
> > 
> >> -------- Original Message --------
> >> Subject: Nits on draft-irtf-dtnrg-bundle-security
> >> Date: Sat, 29 Jan 2011 17:23:28 -0500
> >> From: Sean Turner <[email-masked]>
> >> To: [email-masked]
> >> CC: [email-masked], The IESG <[email-masked]>
> >>
> >> Hi,
> >>
> >> Here's some comments/questions I have on this document (note this isn't
> >> my RFC 5742 review):
> >>
> >> - No 'Intended status' indicated for this document; I'm assuming
> >> Experimental as per the datatracker.  I think you should probably add
> >> the header line to make sure though.
> >>
> >> - There are two unused references: RFC 3370 and RFC 4106.
> >>
> >> I think 3370 could we worked in somewhere when describing the CMS bits.
> >>
> >> For the 4106 I think the checker is barfing on the following from
> >> Section 4.3 and 4.4:
> >>
> >> [Note: parts of the following description are borrowed from RFC 4106].
> >>
> >> Maybe replace it with:
> >>
> >> Note: parts of the following description is borrowed from [RFC4106].
> >>
> >> - Obsolete reference to [RFC3280].  Should be to [RFC5280].
> >>
> >> - Couldn't find the [DTNRB] reference.  Did the document die a graceful
> >> death?
> > No.  The version is out of date.  Version 06 exists.
> >>
> >> - Expand DTN, EID, SDNV, BA, and PI on first use
> >>
> >> - Authentication is mentioned for the first time in Sec 2 when
> >> discussing the PIB.  Wouldn't it be better to mention it earlier?
> >>
> >> - Section 2.1: When describing the two EIDs and cipher suite flags as
> >> "(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
> >>   Same for the Figure 3 description (i.e., the paragraph before the figure).
> >>
> >> - Section 2.3: r/the key information item Section 2.6 is optional, and
> >> if not provided then the key should be/the key information item Section
> >> 2.6 is OPTIONAL, and if not provided then the key SHOULD be
> >>
> >> - Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
> >> used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
> >> Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
> >> you do this need to add "NOT RECOMMENDED" to the first para in section 1
> >> like the errata 499:
> >> http://www.rfc-editor.org/errata_search.php?rfc=2119
> >>
> >> - Section 2.4: Some "SHOULDs":
> >>
> >>     It is RECOMMENDED to apply a Payload
> >>     Confidentiality ciphersuite to non-payload blocks only if these
> >>     SHOULD be super-encrypted with the payload.  If super-encryption of
> >>     ^^^^^^
> >>     the block is not desired then protection of the block SHOULD be done
> >>                                                           ^^^^^^
> >>     using the Extension Security Block mechanism rather than PCB.
> >>
> >> - Section 2.4: "SHOULD NOT" instead of "should not":
> >>
> >>     These multiple PCB instances, are
> >>     not "related" and SHOULD NOT contain correlators.
> >>                       ^^^^^^^^^^
> >>
> >> - Section 2.8: In the paragraph about authenticated and encrypted
> >> bundles, I think the last sentence should be "RECOMMENDED".  It's
> >> interesting to note that you'd prefer encrypt then sign as opposed to
> >> sign and then encrypt.  Looking forward to the security consideration
> >> about why.
> >>
> >> - Section 3.2: r/MUST not/MUST NOT ?
> >>
> >> - Section 3.2: r/No other blocks are
> >>     required to follow the payload block and it is RECOMMENDED that they
> >>     NOT do so./No other blocks are
> >>     required to follow the payload block and it is NOT RECOMMENDED
> >>     that they do so.
> >>
> >> - Section 3.4.2: r/This algorithm is intended to protect parts of the
> >> bundle which should not be changed in-transit./This algorithm is
> >> intended to protect parts of the bundle which SHOULD NOT be changed
> >> in-transit.
> >>
> >> - Sections 3.4.1 & 3.4.2: Need a reference for URI.
> >>
> >> - Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
> >> id-data, but you should probably be explicit about it.
> >>
> >> - Section 4.1: r/Security parameters are optional with this
> >> scheme/Security parameters are OPTIONAL with this scheme
> >>
> >> - Section 4.1: A couple of comments/questions on the following:
> >>
> >>     Implementations MUST support use of "AuthenticatedData" type as
> >>     defined in [RFC5652] section 9.1, with RecipientInfo type
> >>     KeyTransRecipientInfo containing the issuer and serial number of a
> >>     suitable certificate.  They MAY support additional RecipientInfo
> >>     types.  They MAY additionally use the "SignedData" type described in
> >>     [RFC5652] Section 5.1.  In either case, the "eContent" field in
> >>     EncapsulatedContentInfo contains the encrypted HMAC key.
> >>
> >> 1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
> >> reason you chose differently?  Most certificates have SKIs (now) and
> >> it's probably smaller than the issuer/serial # combo.
> >>
> >> 2. How is SignedData used here?  It says it MAY be used - is that in
> >> addition to?  There's no RecipientInfo with SignedData so I am a little
> >> confused.
> >>
> >> - Section 4.1 and 4.2: Should probably say something about whether you'd
> >> recommend no unsigned/unauthenticated and signed/authenticated
> >> attributes.  I'm assuming you're not recommending any ;)
> >>
> >> - Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
> >> issuer/serial # combo.  Any reason you chose differently?  Most
> >> certificates have SKIs and it's probably smaller than the issuer/serial
> >> # combo.
> >>
> >> - Section 4.2: Had the following:
> >>
> >>    RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
> >>    signature scheme in [RFC4055].
> >>
> >> Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
> >> RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
> >> RSASSA-PSS-params or something else.  Also wouldn't you have to say more
> >> like what's the hashAlgorithm, maskGenAlgorithm, whether
> >> RSASSA-PSS-params is included in certificates?
> >>
> >> Also r/RSA with SHA256/RSA with SHA-256
> >>
> >> - Sections 4.1-4.4: The eContent values for the CMS content types threw
> >> me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
> >> just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
> >> reads like there are two sets of operation for each of the four Block
> >> Types.  You do one for the BAB, PIB, etc. values and then another for
> >> the CMS structures?  Am I reading that right?  The parts about the
> >> "eContent" e.g.,:
> >>
> >> The "eContent" field in EncapsulatedContentInfo contains the signed
> >> checksum (SignatureValue) of the data.
> >>
> >> That tells me the CMS processing generates a message digest over the PIB
> >> SignatureValue and then signs the output of the message digest and put
> >> it in the SignerInfo.signature value field.
> >>
> >> Couldn't you just omit all the eContents?  They're optional in all cases
> >> and can be gotten from elsewhere in the CMS blobs.
> >>
> >> - Section 7: You should point to [RFC5652]/[RFC5280] for it's security
> >> considerations when using CMS/certificates.  This save you recreating
> >> text about keeping keys secret, etc.  Need some additional motherhood
> >> and apple pie statements about randomly generating keys and point to
> >> [RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.
> >>
> >> - Section 7: I didn't see a security consideration that addresses why
> >> you'd prefer to encrypt then authenticate.  The text earlier implied and
> >> attack of some kind.  RFC 5751 also had something to say about this:
> >>
> >>     There are security ramifications to choosing whether to sign first or
> >>     encrypt first.  A recipient of a message that is encrypted and then
> >>     signed can validate that the encrypted block was unaltered, but
> >>     cannot determine any relationship between the signer and the
> >>     unencrypted contents of the message.  A recipient of a message that
> >>     is signed then encrypted can assume that the signed message itself
> >>     has not been altered, but that a careful attacker could have changed
> >>     the unauthenticated portions of the encrypted message.
> >>
> > (The following comment was withdrawn.. all new ones have 'specification
> > required' quoted.)
> >> - IANA Considerations: When defining an IANA controlled registry the
> >> document needs to indicate how the registry is updated (e.g., RFC
> >> required, expert review, etc.).  See Section 4 of RFC 5226.
> >>
> >> Cheers,
> >>
> >> spt
> >>
> > 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Mon, 31 Jan 2011 11:14:28 +0000
From: Stephen Farrell <[email-masked]>
To: Elwyn Davies <[email-masked]>
Cc: Peter Lovell <[email-masked]>, DTN interest <[email-masked]>, Sean Turner <[email-masked]>
Subject: Re: [dtn-interest] Fwd: Nits on draft-irtf-dtnrg-bundle-security

I suspect that we won't get to do those before the IESG chat so
lets see if any other ADs have useful comments and then address
'em then.

S.

PS: If Peter doesn't have time, I can probably take a stab at
this.

On 31/01/11 10:50, Elwyn Davies wrote:
> Hi
> 
> Thanks to Sean for the review.  I see from the datatracker that you
> don't think these are blocking issues.
> 
> Authors:  any responses to the comments?  I guess we need to fix up the
> nits anyway.  I think Peter has the editorial pencil at the moment.. do
> you have cycles to do the fixes?
> 
> Regards,
> Elwyn
> Document Shepherd
> 
> Couple of (trivial) comments in line below...
> 
> On Sat, 2011-01-29 at 17:28 -0500, Sean Turner wrote:
> 
>> -------- Original Message --------
>> Subject: Nits on draft-irtf-dtnrg-bundle-security
>> Date: Sat, 29 Jan 2011 17:23:28 -0500
>> From: Sean Turner <[email-masked]>
>> To: [email-masked]
>> CC: [email-masked], The IESG <[email-masked]>
>>
>> Hi,
>>
>> Here's some comments/questions I have on this document (note this isn't
>> my RFC 5742 review):
>>
>> - No 'Intended status' indicated for this document; I'm assuming
>> Experimental as per the datatracker.  I think you should probably add
>> the header line to make sure though.
>>
>> - There are two unused references: RFC 3370 and RFC 4106.
>>
>> I think 3370 could we worked in somewhere when describing the CMS bits.
>>
>> For the 4106 I think the checker is barfing on the following from
>> Section 4.3 and 4.4:
>>
>> [Note: parts of the following description are borrowed from RFC 4106].
>>
>> Maybe replace it with:
>>
>> Note: parts of the following description is borrowed from [RFC4106].
>>
>> - Obsolete reference to [RFC3280].  Should be to [RFC5280].
>>
>> - Couldn't find the [DTNRB] reference.  Did the document die a graceful
>> death?
> No.  The version is out of date.  Version 06 exists.
>>
>> - Expand DTN, EID, SDNV, BA, and PI on first use
>>
>> - Authentication is mentioned for the first time in Sec 2 when
>> discussing the PIB.  Wouldn't it be better to mention it earlier?
>>
>> - Section 2.1: When describing the two EIDs and cipher suite flags as
>> "(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
>>   Same for the Figure 3 description (i.e., the paragraph before the figure).
>>
>> - Section 2.3: r/the key information item Section 2.6 is optional, and
>> if not provided then the key should be/the key information item Section
>> 2.6 is OPTIONAL, and if not provided then the key SHOULD be
>>
>> - Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
>> used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
>> Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
>> you do this need to add "NOT RECOMMENDED" to the first para in section 1
>> like the errata 499:
>> http://www.rfc-editor.org/errata_search.php?rfc=2119
>>
>> - Section 2.4: Some "SHOULDs":
>>
>>     It is RECOMMENDED to apply a Payload
>>     Confidentiality ciphersuite to non-payload blocks only if these
>>     SHOULD be super-encrypted with the payload.  If super-encryption of
>>     ^^^^^^
>>     the block is not desired then protection of the block SHOULD be done
>>                                                           ^^^^^^
>>     using the Extension Security Block mechanism rather than PCB.
>>
>> - Section 2.4: "SHOULD NOT" instead of "should not":
>>
>>     These multiple PCB instances, are
>>     not "related" and SHOULD NOT contain correlators.
>>                       ^^^^^^^^^^
>>
>> - Section 2.8: In the paragraph about authenticated and encrypted
>> bundles, I think the last sentence should be "RECOMMENDED".  It's
>> interesting to note that you'd prefer encrypt then sign as opposed to
>> sign and then encrypt.  Looking forward to the security consideration
>> about why.
>>
>> - Section 3.2: r/MUST not/MUST NOT ?
>>
>> - Section 3.2: r/No other blocks are
>>     required to follow the payload block and it is RECOMMENDED that they
>>     NOT do so./No other blocks are
>>     required to follow the payload block and it is NOT RECOMMENDED
>>     that they do so.
>>
>> - Section 3.4.2: r/This algorithm is intended to protect parts of the
>> bundle which should not be changed in-transit./This algorithm is
>> intended to protect parts of the bundle which SHOULD NOT be changed
>> in-transit.
>>
>> - Sections 3.4.1 & 3.4.2: Need a reference for URI.
>>
>> - Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
>> id-data, but you should probably be explicit about it.
>>
>> - Section 4.1: r/Security parameters are optional with this
>> scheme/Security parameters are OPTIONAL with this scheme
>>
>> - Section 4.1: A couple of comments/questions on the following:
>>
>>     Implementations MUST support use of "AuthenticatedData" type as
>>     defined in [RFC5652] section 9.1, with RecipientInfo type
>>     KeyTransRecipientInfo containing the issuer and serial number of a
>>     suitable certificate.  They MAY support additional RecipientInfo
>>     types.  They MAY additionally use the "SignedData" type described in
>>     [RFC5652] Section 5.1.  In either case, the "eContent" field in
>>     EncapsulatedContentInfo contains the encrypted HMAC key.
>>
>> 1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
>> reason you chose differently?  Most certificates have SKIs (now) and
>> it's probably smaller than the issuer/serial # combo.
>>
>> 2. How is SignedData used here?  It says it MAY be used - is that in
>> addition to?  There's no RecipientInfo with SignedData so I am a little
>> confused.
>>
>> - Section 4.1 and 4.2: Should probably say something about whether you'd
>> recommend no unsigned/unauthenticated and signed/authenticated
>> attributes.  I'm assuming you're not recommending any ;)
>>
>> - Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
>> issuer/serial # combo.  Any reason you chose differently?  Most
>> certificates have SKIs and it's probably smaller than the issuer/serial
>> # combo.
>>
>> - Section 4.2: Had the following:
>>
>>    RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
>>    signature scheme in [RFC4055].
>>
>> Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
>> RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
>> RSASSA-PSS-params or something else.  Also wouldn't you have to say more
>> like what's the hashAlgorithm, maskGenAlgorithm, whether
>> RSASSA-PSS-params is included in certificates?
>>
>> Also r/RSA with SHA256/RSA with SHA-256
>>
>> - Sections 4.1-4.4: The eContent values for the CMS content types threw
>> me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
>> just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
>> reads like there are two sets of operation for each of the four Block
>> Types.  You do one for the BAB, PIB, etc. values and then another for
>> the CMS structures?  Am I reading that right?  The parts about the
>> "eContent" e.g.,:
>>
>> The "eContent" field in EncapsulatedContentInfo contains the signed
>> checksum (SignatureValue) of the data.
>>
>> That tells me the CMS processing generates a message digest over the PIB
>> SignatureValue and then signs the output of the message digest and put
>> it in the SignerInfo.signature value field.
>>
>> Couldn't you just omit all the eContents?  They're optional in all cases
>> and can be gotten from elsewhere in the CMS blobs.
>>
>> - Section 7: You should point to [RFC5652]/[RFC5280] for it's security
>> considerations when using CMS/certificates.  This save you recreating
>> text about keeping keys secret, etc.  Need some additional motherhood
>> and apple pie statements about randomly generating keys and point to
>> [RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.
>>
>> - Section 7: I didn't see a security consideration that addresses why
>> you'd prefer to encrypt then authenticate.  The text earlier implied and
>> attack of some kind.  RFC 5751 also had something to say about this:
>>
>>     There are security ramifications to choosing whether to sign first or
>>     encrypt first.  A recipient of a message that is encrypted and then
>>     signed can validate that the encrypted block was unaltered, but
>>     cannot determine any relationship between the signer and the
>>     unencrypted contents of the message.  A recipient of a message that
>>     is signed then encrypted can assume that the signed message itself
>>     has not been altered, but that a careful attacker could have changed
>>     the unauthenticated portions of the encrypted message.
>>
> (The following comment was withdrawn.. all new ones have 'specification
> required' quoted.)
>> - IANA Considerations: When defining an IANA controlled registry the
>> document needs to indicate how the registry is updated (e.g., RFC
>> required, expert review, etc.).  See Section 4 of RFC 5226.
>>
>> Cheers,
>>
>> spt
>>
> 

From: Elwyn Davies <[email-masked]>
To: Susan Symington <[email-masked]>, Stephen Farrell <[email-masked]>, Peter Lovell <[email-masked]>, Sean Turner <[email-masked]>, Howard Weiss <[email-masked]>
Date: Mon, 31 Jan 2011 10:50:02 +0000
Cc: DTN interest <[email-masked]>
Subject: Re: [dtn-interest] Fwd: Nits on draft-irtf-dtnrg-bundle-security

Hi

Thanks to Sean for the review.  I see from the datatracker that you
don't think these are blocking issues.

Authors:  any responses to the comments?  I guess we need to fix up the
nits anyway.  I think Peter has the editorial pencil at the moment.. do
you have cycles to do the fixes?

Regards,
Elwyn
Document Shepherd

Couple of (trivial) comments in line below...

On Sat, 2011-01-29 at 17:28 -0500, Sean Turner wrote:

> -------- Original Message --------
> Subject: Nits on draft-irtf-dtnrg-bundle-security
> Date: Sat, 29 Jan 2011 17:23:28 -0500
> From: Sean Turner <[email-masked]>
> To: [email-masked]
> CC: [email-masked], The IESG <[email-masked]>
> 
> Hi,
> 
> Here's some comments/questions I have on this document (note this isn't
> my RFC 5742 review):
> 
> - No 'Intended status' indicated for this document; I'm assuming
> Experimental as per the datatracker.  I think you should probably add
> the header line to make sure though.
> 
> - There are two unused references: RFC 3370 and RFC 4106.
> 
> I think 3370 could we worked in somewhere when describing the CMS bits.
> 
> For the 4106 I think the checker is barfing on the following from
> Section 4.3 and 4.4:
> 
> [Note: parts of the following description are borrowed from RFC 4106].
> 
> Maybe replace it with:
> 
> Note: parts of the following description is borrowed from [RFC4106].
> 
> - Obsolete reference to [RFC3280].  Should be to [RFC5280].
> 
> - Couldn't find the [DTNRB] reference.  Did the document die a graceful
> death?
No.  The version is out of date.  Version 06 exists.
> 
> - Expand DTN, EID, SDNV, BA, and PI on first use
> 
> - Authentication is mentioned for the first time in Sec 2 when
> discussing the PIB.  Wouldn't it be better to mention it earlier?
> 
> - Section 2.1: When describing the two EIDs and cipher suite flags as
> "(optional)" they should be "(OPTIONAL)" if conveying 2119 requirements.
>   Same for the Figure 3 description (i.e., the paragraph before the figure).
> 
> - Section 2.3: r/the key information item Section 2.6 is optional, and
> if not provided then the key should be/the key information item Section
> 2.6 is OPTIONAL, and if not provided then the key SHOULD be
> 
> - Sections 2.4 & 2.5: r/and that encryption-only ciphersuites NOT be
> used/and it is NOT RECOMMENDED that encryption-only ciphersuites be used
> Using NOT so far after the RECOMMENDED isn't "NOT RECOMMENDED".  Also if
> you do this need to add "NOT RECOMMENDED" to the first para in section 1
> like the errata 499:
> http://www.rfc-editor.org/errata_search.php?rfc=2119
> 
> - Section 2.4: Some "SHOULDs":
> 
>     It is RECOMMENDED to apply a Payload
>     Confidentiality ciphersuite to non-payload blocks only if these
>     SHOULD be super-encrypted with the payload.  If super-encryption of
>     ^^^^^^
>     the block is not desired then protection of the block SHOULD be done
>                                                           ^^^^^^
>     using the Extension Security Block mechanism rather than PCB.
> 
> - Section 2.4: "SHOULD NOT" instead of "should not":
> 
>     These multiple PCB instances, are
>     not "related" and SHOULD NOT contain correlators.
>                       ^^^^^^^^^^
> 
> - Section 2.8: In the paragraph about authenticated and encrypted
> bundles, I think the last sentence should be "RECOMMENDED".  It's
> interesting to note that you'd prefer encrypt then sign as opposed to
> sign and then encrypt.  Looking forward to the security consideration
> about why.
> 
> - Section 3.2: r/MUST not/MUST NOT ?
> 
> - Section 3.2: r/No other blocks are
>     required to follow the payload block and it is RECOMMENDED that they
>     NOT do so./No other blocks are
>     required to follow the payload block and it is NOT RECOMMENDED
>     that they do so.
> 
> - Section 3.4.2: r/This algorithm is intended to protect parts of the
> bundle which should not be changed in-transit./This algorithm is
> intended to protect parts of the bundle which SHOULD NOT be changed
> in-transit.
> 
> - Sections 3.4.1 & 3.4.2: Need a reference for URI.
> 
> - Sections 4.1-4.4: What's the OIDs for these "eContents"?  I assume
> id-data, but you should probably be explicit about it.
> 
> - Section 4.1: r/Security parameters are optional with this
> scheme/Security parameters are OPTIONAL with this scheme
> 
> - Section 4.1: A couple of comments/questions on the following:
> 
>     Implementations MUST support use of "AuthenticatedData" type as
>     defined in [RFC5652] section 9.1, with RecipientInfo type
>     KeyTransRecipientInfo containing the issuer and serial number of a
>     suitable certificate.  They MAY support additional RecipientInfo
>     types.  They MAY additionally use the "SignedData" type described in
>     [RFC5652] Section 5.1.  In either case, the "eContent" field in
>     EncapsulatedContentInfo contains the encrypted HMAC key.
> 
> 1. Normally, we'd use the SKI instead of the issuer/serial # combo.  Any
> reason you chose differently?  Most certificates have SKIs (now) and
> it's probably smaller than the issuer/serial # combo.
> 
> 2. How is SignedData used here?  It says it MAY be used - is that in
> addition to?  There's no RecipientInfo with SignedData so I am a little
> confused.
> 
> - Section 4.1 and 4.2: Should probably say something about whether you'd
> recommend no unsigned/unauthenticated and signed/authenticated
> attributes.  I'm assuming you're not recommending any ;)
> 
> - Sections 4.2, 4.3, & 4.4: Normally, we'd use the SKI instead of the
> issuer/serial # combo.  Any reason you chose differently?  Most
> certificates have SKIs and it's probably smaller than the issuer/serial
> # combo.
> 
> - Section 4.2: Had the following:
> 
>    RSA is used with SHA256 as specified for the id-sha256 PKCSv2.1
>    signature scheme in [RFC4055].
> 
> Is this RSA with SHA-256 PKCS#1 Version 1.5 or RSA with SHA-256 using
> RSASSA-PSS?  If it's the later is the id-sha256 the hashAlgorithm in the
> RSASSA-PSS-params or something else.  Also wouldn't you have to say more
> like what's the hashAlgorithm, maskGenAlgorithm, whether
> RSASSA-PSS-params is included in certificates?
> 
> Also r/RSA with SHA256/RSA with SHA-256
> 
> - Sections 4.1-4.4: The eContent values for the CMS content types threw
> me for a loop.  You're not using them to protect the BAB, PIB, etc. it's
> just the encrypted HMAC key, signed checksum, and encrypted BEK.  It
> reads like there are two sets of operation for each of the four Block
> Types.  You do one for the BAB, PIB, etc. values and then another for
> the CMS structures?  Am I reading that right?  The parts about the
> "eContent" e.g.,:
> 
> The "eContent" field in EncapsulatedContentInfo contains the signed
> checksum (SignatureValue) of the data.
> 
> That tells me the CMS processing generates a message digest over the PIB
> SignatureValue and then signs the output of the message digest and put
> it in the SignerInfo.signature value field.
> 
> Couldn't you just omit all the eContents?  They're optional in all cases
> and can be gotten from elsewhere in the CMS blobs.
> 
> - Section 7: You should point to [RFC5652]/[RFC5280] for it's security
> considerations when using CMS/certificates.  This save you recreating
> text about keeping keys secret, etc.  Need some additional motherhood
> and apple pie statements about randomly generating keys and point to
> [RFC4106].  And a pointer to [RFC5084] for concerns about AES-GCM.
> 
> - Section 7: I didn't see a security consideration that addresses why
> you'd prefer to encrypt then authenticate.  The text earlier implied and
> attack of some kind.  RFC 5751 also had something to say about this:
> 
>     There are security ramifications to choosing whether to sign first or
>     encrypt first.  A recipient of a message that is encrypted and then
>     signed can validate that the encrypted block was unaltered, but
>     cannot determine any relationship between the signer and the
>     unencrypted contents of the message.  A recipient of a message that
>     is signed then encrypted can assume that the signed message itself
>     has not been altered, but that a careful attacker could have changed
>     the unauthenticated portions of the encrypted message.
> 
(The following comment was withdrawn.. all new ones have 'specification
required' quoted.)
> - IANA Considerations: When defining an IANA controlled registry the
> document needs to indicate how the registry is updated (e.g., RFC
> required, expert review, etc.).  See Section 4 of RFC 5226.
> 
> Cheers,
> 
> spt
> 

Date: Fri, 28 Jan 2011 14:05:30 +0100 (CET)
From: "Ilaria Giannetti" <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [dtn-interest] SustaInet 2011: Submission Deadline Extended to Feb. 14, 2011

------------------------------------------------------------------------

                        PRELIMINARY CALL FOR PAPERS

                             SustaInet 2011
                    First International Workshop on
          Sustainable Internet and Internet for Sustainability

                  http://www.dinfo.unipa.it/sustainet/

                             sponsored by
                    IEEE, IEEE Computer Society

                  Co-located with IEEE WoWMoM 2011
                           June 20-24, 2011
                        Lucca, Tuscany, Italy

------------------------------------------------------------------------

****       SUBMISSION DEADLINE EXTENDED TO FEBRUARY 14, 2011       *****

------------------------------------------------------------------------

In the last years, the increasing social awareness about the need for
containing energy consumption within sustainable rates has caught the
interest of both the industrial and academic communities. In this scenario
Internet - and more generally ICT - may play a twofold role, being both a
significant energy consumer and a potential actor in steering a more
clever overall usage of the energy resources.

Both aspects of the problem raise interesting scientific challenges and
require a comprehensive effort and inter-disciplinary research at all
levels of abstraction. The goal of this workshop is to bring together
people from different research areas, and provide a forum to exchange
ideas, discuss solutions, and share experiences among researchers,
professionals, and application developers both from industry and academia.

Original papers addressing both theoretical and practical aspects of
energy-awareness for Internet-based systems, and the design of distributed
systems for eco-sustainability are solicited. Topics of interest include
but are not limited to:

 - Power-aware Internet applications
 - Energy-efficient network architecture and protocols
 - Power-aware middleware and software
 - Resource management for power optimization
 - Energy efficiency and Quality of Service
 - Energy efficiency and reliability
 - Power management and energy-efficient design
 - Algorithms for reduced power, energy and heat
 - Pervasive computing for energy efficiency
 - Energy efficiency in large-scale distributed systems
 - Energy-efficient data centers
 - Energy-efficient buildings
 - Energy efficiency in industrial environments
 - Advances in energy savings thanks to ICT
 - Sustainability achievements due to ICT-based optimization
 - Monitoring tools for power and performance
 - Modeling and performance evaluation of green computing systems
 - Measurements

EDITORIAL FOLLOW-UP
------------------------------------------------------------------------
Papers of particular merit will be considered for a possible fast-track
publication in the Elsevier Journal of Computer Communications (COMCOM).

PAPER SUBMISSION AND PUBLICATION
------------------------------------------------------------------------
All submissions must describe original research, not published or
currently under review for another workshop, conference, or journal.

Papers must be submitted electronically through EDAS
(http://edas.info/newPaper.php?c=9973). Detailed submission instructions
will be made available at: http://www.dinfo.unipa.it/sustainet/.

*******************************************************************************
Accepted papers will be included in the proceedings of IEEE WoWMoM 2011
workshops and published in the IEEE Digital Library.

Submission implies the willingness of, at least, one author to register
and attend the workshop to present the paper. Registration is to the
entire event (there is no workshop-only registration).

The organizers reserve the right to exclude a paper from distribution
after the conference (e.g., removal from IEEE Xplore) if the paper is not
presented at the workshop.
********************************************************************************

IMPORTANT DATES
------------------------------------------------------------------------
- Submission deadline:	    EXTENDED TO February 14, 2011
- Acceptance notification:  March 28, 2011

CONTACTS
------------------------------------------------------------------------
For further information, please visit the workshop website at
http://www.dinfo.unipa.it/sustainet/, or contact the TPC Chair at
[email-masked]

ORGANIZING COMMITTEE
------------------------------------------------------------------------
GENERAL CO-CHAIRS
  Marco Conti, IIT-CNR, Italy
  Jean-Marc Pierson, University Paul Sabatier, Toulouse France

PROGRAM CHAIR
  Giuseppe Anastasi, University of Pisa, Italy

VICE PROGRAM CHAIR
  Marco Ortolani, University of Palermo, Italy

PUBLICITY CHAIR
  Ilaria Giannetti, University of Pisa, Italy

WEB MANAGER
  Marco Morana, University of Palermo, Italy

TECHNICAL PROGRAM COMMITTEE
  Ishfaq Ahmad, University of Texas at Arlington, USA
  Lachlan Andrew, Swinburne University of Technology, Australia
  Antonio Capone, Politecnico di Milano, Italy
  Ken Christensen, University of South Florida, USA
  Jon Crowcroft, University of Cambridge, UK
  Sajal K. Das, National Science Foundation, USA
  Hermann de Meer, University of Passau, Germany
  Lars Dittmann, Technical University of Denmark, Denmark
  Alberto García, University of Cantabria, Spain
  Qi Han, Colorado School of Mines, USA
  Helmut Hlavacs, University of Vienna, Austria
  Karin Hummel, University of Vienna, Austria
  David Hutchison, Lancaster University, UK
  Gianluca Iannaccone, Intel Corporation, USA
  Randy H. Katz, University of California at Berkeley, USA
  Laurent Lefevre, INRIA, France
  Giuseppe Lo Re, University of Palermo, Italy
  Tommaso Melodia, State University of New York at Buffalo, USA
  Michela Meo, Politecnico di Torino, Italy
  Archan Misra, Singapore Management University, Singapore
  Hiroyuki Morikawa, The University of Tokyo, Japan
  Bruce Nordman, Lawrence Berkeley National Laboratory, Berkeley, USA
  Andrea Passarella, IIT-CNR, Italy
  Marcelo Pias, Cambridge University, UK
  Antonio Puliafito, University of Messina, Italy
  Sanjay Ranka, University of Florida, USA
  Andrew Rice, University of Cambridge, UK
  Behrooz Shirazi, Washington State University, USA
  Suresh Singh, Portland State University, USA
  Domenico Talia, University of Calabria, Italy
  Athena Vakali, Aristotle University of Thessaloniki, Greece
  Nalini Venkatasubramanian, University of California at Irvine, USA

Date: Thu, 27 Jan 2011 17:31:15 +0000
From: Stephen Farrell <[email-masked]>
To: Peter Saint-Andre <[email-masked]>
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Six DTNRG drafts have just gone for IESG "end-run" review

Mea culpa:-) I left out the "-bundle". Fixed URLs
below.

Thanks for catching that.
S.

http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-metadata-block
http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-previous-hop-block

On 27/01/11 17:16, Peter Saint-Andre wrote:
> On 1/27/11 9:41 AM, Stephen Farrell wrote:
> 
>> draft:  http://tools.ietf.org/html/draft-irtf-dtnrg-metadata-block
>>
>> draft: http://tools.ietf.org/html/draft-irtf-dtnrg-previous-hop-block
> 
> HTTP 404 Not Found.
> 
> ???
> 
> 
> 
> 

Date: Thu, 27 Jan 2011 10:16:01 -0700
From: Peter Saint-Andre <[email-masked]>
To: Stephen Farrell <[email-masked]>
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Cc: DTN <[email-masked]>
Subject: Re: [dtn-interest] Six DTNRG drafts have just gone for IESG "end-run" review

This is a cryptographically signed message in MIME format.

--------------ms030507060005090606070305
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 1/27/11 9:41 AM, Stephen Farrell wrote:

> draft:  http://tools.ietf.org/html/draft-irtf-dtnrg-metadata-block
>=20
> draft: http://tools.ietf.org/html/draft-irtf-dtnrg-previous-hop-block

HTTP 404 Not Found.

???

--------------ms030507060005090606070305
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

AAAA
--------------ms030507060005090606070305--

Date: Thu, 27 Jan 2011 16:41:04 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Six DTNRG drafts have just gone for IESG "end-run" review

Hi all,

Just to let you know. The six DTNRG drafts below have now
been sent to the IESG for their end-run review to make
sure we're not stepping on some IETF WG's toes. They get
a month for that, and then those drafts should go to the
RFC editor. Of course there may be comments from the
IESG member that does the checking, and those may well
be worth thinking about and even acting on, but the IESG
don't get to block things unless we are stepping on IETF
toes. (That's all described in RFC5742 for any process
fans.)

Thanks for your extended patience with all of this, and
especially to Elwyn for shepherding them.

As an aside, I reckon that in retrospect, the (well, my;-)
idea of handling them as a bunch turned out to be dumb since
it slowed us down quite a bit. (I suspect that's because
each time we did something, we ended up checking the status
of all six.) Anyway, in future, I'd plan to just take each
draft when its ready and push it forward.

So, if you've a draft you think is ready just mail the
list saying so and we'll take 'em as they come.

Thanks,
Stephen.

PS: Prophet isn't on this list because its authors had a
few more changes. Once they're ready I'll start the ball
rolling on that again.

1) draft-irtf-dtnrg-sdnv
ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/30
draft: http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv

2) draft-irtf-dtnrg-bundle-security
ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/31
draft: http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-security

3) draft-irtf-dtnrg-chbe
ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/32
draft: http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe

4) draft-irtf-dtnrg-bundle-metadata-block
ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/33
draft:  http://tools.ietf.org/html/draft-irtf-dtnrg-metadata-block

5) draft-irtf-dtnrg-bundle-previous-hop-block
ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/34
draft: http://tools.ietf.org/html/draft-irtf-dtnrg-previous-hop-block

6) draft-irtf-dtnrg-iana-bp-registries
ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/40
draft: http://tools.ietf.org/html/draft-irtf-dtnrg-iana-bp-registries

From: Elwyn Davies <[email-masked]>
To: Lachlan Andrew <[email-masked]>, "Eddy, Wesley M. (GRC-RCN0)[VZ]" <[email-masked]>, "Wesley M. Eddy" <[email-masked]>
Organization: Folly Consulting
Date: Wed, 26 Jan 2011 21:52:38 +0000
Cc: DTN interest <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] IRSG poll for draft-irttf-dtnrg-sdnv: special request

Hi.

I have submitted an updated version (-08) of the draft which
incorporates the changes suggested by Lachlan Andrew and Michael Welzl.

I also fixed a few residual typos.

A new version of I-D, draft-irtf-dtnrg-sdnv-08.txt has been successfully
submitted by Elwyn Davies and posted to the IETF repository.

Filename:        draft-irtf-dtnrg-sdnv
Revision:        08
Title:           Using Self-Delimiting Numeric Values in Protocols
Creation_date:   2011-01-26
WG ID:           Independent Submission
Number_of_pages: 22

AFAICS this is now ready for the IESG.

Regards,
Elwyn

========================================================

Comments from Michael Welzl:

> > 1) draft-irtf-dtnrg-sdnv
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/30
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
> > ready to publish:
> >       Juergen Schoenwaelder, 2010-03-03
> 
> I also vote "ready to publish" here.
> 
> Comments:
> 
> I think this is a very useful document and even enjoyed reading it.
> A  
> few nits:
> - section 1.1 par 3 line 2: remove "0" before "IP header format"
Done.

> - second last line: might have to be "...to have _a_ visible impact  
> on..."   (don't know for sure, I'm not a native speaker)
I think this is OK as is.

> - 1.3 bullet list: I suggest to remove the last ("Etc.") bullet,
> this  
> is just a waste of space because you say "such as" anyway
Done.

> - section 4: as I read this, I became more and more curious what  
> SDNV-8 and SDNV-16 really look like. Given that it probably won't be  
> very complicated to explain them, you could make this an easier read  
> with a brief explanation of these formats.
There is a description further down on see the reference [BRF04].

> - paragraph just below table 1: this is a repetition of some earlier  
> text, and as such maybe unnecessary. If you think it adds value to  
> repeat this here, at least refer to the other text ("as initially  
> stated, .." or something like that).
Added 'As previously discussed'.

> - Reference ASN1-BER: strange line break here
The current version looks OK to me.  The RFC Editor will check this sort
of thing later.

===========

Response by Wes to Lachlan's comments below:
> 
> On the question of bit-fields, I think Lachlan has a good point that
> we should mention.  Not pre-pending a 1 to the field is only safe if:
> 1 - completely feature-compatible implementations are communicating,
> so that the decoded field width is implicit
> 2 - leading zeros can be safely ignored in the bit-field (perhaps
> representing optimizations rather than basic protocol functionality)

Some text added to the end of s2 make sure that users are aware that
they need to get consistent interpretation between sender and receiver,
and how this can be done.

======================================================================
Lachlan's comments:

> On the issue of algorithms, I think Lachlan has a decent point that we
> should mention that the included examples focus on decoding/encoding
> SDNVs serially within blobs of protocol data.  Other approaches are
> possible with different efficiency.

Words added to the end of the first para in s3.

> 
> On the question of Elias coding, I'm not particularly familiar with
> it, though we do already cite similar (or identical) mechanisms that
> have been used in the past (e.g. in ASN.1 representations), so I
> wouldn't imagine we'd be adding more than a sentence to say how Elias
> coding might be related (or differs).  If Elwyn or Lachlan would have
> a sentence or two to suggest, I'd be totally fine with that.

Two references and some text added to the end of s2 including a note
pointing out that extensibility rather than compression is the main
motivation here whereas both Variable Byte Encoding and Elias encoding
are primarily compression motivated.
> 
> On 13/01/11 23:47, Lachlan Andrew wrote:
> > Greetings Elwyn,
> > 
> > I agree that not a lot needs to be done, but I still think some things do.
> > 
> > On 23 December 2010 11:39, Elwyn Davies <[email-masked]> wrote:
> >>
> >> I have had a look at your comments and made various responses below.  I
> >> think Wes needs to take a view of whether we should make further
> >> changes, but in any case I don't think we need to do a great deal to
> >> address your comments.
> >>
> >> Wes:  what is your view?
> >>
> >> On Wed, 2010-12-22 at 15:17 +1100, Lachlan Andrew wrote:
> >>>
> >>> I'm still uncomfortable with the comment on arbitrary bit-fields,
> >>> since
> >>> leading zeros cannot be safely encoded.  You might want to say that an
> >>> arbitrary bit-field can be encoded by prepending a 1 and then applying
> >>> SDNV.
> >>
> >> I don't follow how it is 'safer' to have the leading zeroes explicitly
> >> in the transmitted data rather than implicitly (I assume that is what
> >> you are implying).
> > 
> > No, I was saying that the entire bit field should be prefixed by a
> > "1", so that there is a one-to-one mapping between the integer that
> > SDNV encodes and the bit-field.  That is the only way an  arbitrary
> > bitfield can be encoded and decoded.
> > 
> >>  If you have two interoperating instances of a
> >> protocol, they (implicitly) know what the size of the bit field that is
> >> SDNV encoded actually is.
> > 
> > If they know the size of the bit field, then they don't need to use
> > SDNV.  The whole point of SDNV is (I thought) for cases when the bit
> > field is not known in advance.  If you want to assume a given
> > application requirement, that should be specified in the document as a
> > limitation.
> > 
> > As a toy example, consider a protocol which want to send a summary of
> > a document, by specifying which pages do *not* contain a given word,
> > such as "the".  That will be a bit field.  If we do not specify the
> > leading zeros, we can't tell the difference between a document in
> > which the first (or last) page contains "the", and a document which is
> > a page shorter.  If we are making a query "how many pages contain the
> > word 'the'?", then we will get the wrong answer.
> > 
> > In summary, SDNV sends arbitrary integers, not arbitrary bit fields.
> > If you want to use it to send arbitrary bit fields, you should
> > describe an accurate method to do that in general.
> > 
> >>  If you put an extra delimiting bit into the
> >> SDNV you seem to be potentially throwing away any (probably small)
> >> efficiency gains from using an SDNV.  Combining these two points and
> >> assuming that the transmission is over a transmission medium that
> >> detects bit corruptions, I am think this suggestion doesn't help. (one
> >> has to say that for production protocols (as opposed to experimental
> >> ones where adding new flags might be useful) the gains from using SDNVs
> >> seem fairly minimal - but we have them in DTN.
> > 
> > If you aim is efficiency, then you are better off using a compression
> > algorithm; we can discuss that if you think it is important.
> > 
> >>> Sections 3.1 and 3.2 seem to suggest an asymmetry between the problem
> >>> of
> >>> not knowing the output length when encoding and decoding.  In both
> >>> cases,
> >>> the size of the output is not known until the entire input has been
> >>> read
> >>> in (unless you assume the input to encoding is stored in a format like
> >>> TLV), but in both cases, it a single pass of the input can tell you
> >>> the
> >>> size of the output.
> >>
> >> In general you do know the size of the item you are encoding - you
> >> aren't usually deserializing it.
> > 
> > Again that is making an unstated assumption about the application.  If
> > we're reading data off disk, we're deserializing; if we're collecting
> > data from a real-time source, we're deserializing.  If we're sending
> > an "arbitrary sized Python integer" (which is internally stored using
> > something analogous to SDNV) then the size is also only implicitly in
> > the data.
> > 
> > If you want to distinguish between (the efficiency of
> > encoding/decoding from a serial source) vs (the efficiency of
> > encoding/decoding from a randomly accessible source), then make that
> > distinction.  There is no need to conflate that with which is encoding
> > and which is decoding.
> > 
> >> The point that is being made is that
> >> you can preallocate the output buffer in the encoding case and dump the
> >> output direct into the target octets, so no shifting is needed.  In the
> >> decoding case you generally would be deserializing and (particularly if
> >> you were hoping for hardware assistance) you would have to do a
> >> multi-octet shift as the octets came off the wire in the general case
> >> which is not very efficient.  So yes there *is* generally an asymmetry
> >> between the two cases.  I think it is clear what is meant and doesn't
> >> need any improvement.
> > 
> > The asymmetry is in the input (serialized vs "known" in advance), not
> > the encoding/decoding algorithms.  The document should make that
> > clear.
> > 
> >>> I'm still surprised that there is no mention of Elias coding, which is
> >>> extremely similar.
> >>
> >> I would beg to differ.  The various forms of Elias coding make rather
> >> different assumptions about the distribution of the values to be
> >> encoded.  SDNVs are actually an incarnation of Variable Byte Coding or
> >> Comma Coding.  I think that bringing Elias Coding into the document
> >> would be distracting.
> > 
> > To my mind, an informational RFC should include enough information for
> > the reader to decide "is this what I'm looking for?".  As such, I
> > think that at least mentioning when SDNV is more appropriate than all
> > three of these alternatives (and why) is entirely within scope.  My
> > first (and still strongest) impression in reading this document was
> > "There are many universal codes.  Why are the re-inventing the wheel?"
> >  Something showing how this relates to the standard CS literature
> > would help dispel that.
> > 
> > Cheers,
> > Lachlan
> > 

Date: Wed, 26 Jan 2011 17:47:48 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] Open DTN postdoc position in TCD

Hi all,

We've an open position for a postdoc to do DTN stuff. See
the web page [1] for details and follow the instructions
there if you're qualified and interested.

Regards,
Stephen.

[1] http://www.dsg.cs.tcd.ie/node/727

Date: Wed, 26 Jan 2011 08:46:28 -0500
From: Marc Blanchet <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] (not) meeting in Prague in March, maybe in Quebec in July?

Le 11-01-26 07:19, Stephen Farrell a écrit :
>
> Hi all,
>
> I guess that we don't need to request a meeting slot at
> the Prague IETF. [1] If you disagree, please say so here
> and if there's enough interest and stuff to do, I'll
> request a slot. (Cutoff date for meeting requests is
> Feb 14.)
>
> I do think it might be worthwhile to meet in July [2]
> though, at the Quebec IETF, so any early opinions on
> that are welcome. (Or on other possible meeting dates/
> venues for this year.)
>

- well, it is probably a bit early to identify the topics to be 
discussed in July. We have something on the plate right now that should 
be submitted at some point.

- having said that, as local (non sponsoring) host for the Quebec city 
IETF, I would be happy to host a DTN party and may be some DTN interop 
or disconnectathon during IETF July in the lovely Quebec city ;-). Bring 
your spouses and relatives to the DTN party!

How's that for a reason to host a DTN meeting in Quebec city?

Marc.

> Cheers,
> S.
>
> [1] http://www.ietf.org/meeting/80/index.html
> [2] http://www.ietf.org/meeting/upcoming.html
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

-- 
=========
IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca
Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca
DTN Implementation: http://postellation.viagenie.ca
NAT64-DNS64 Opensource: http://ecdysis.viagenie.ca

Date: Wed, 26 Jan 2011 12:19:58 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] (not) meeting in Prague in March, maybe in Quebec in July?

Hi all,

I guess that we don't need to request a meeting slot at
the Prague IETF. [1] If you disagree, please say so here
and if there's enough interest and stuff to do, I'll
request a slot. (Cutoff date for meeting requests is
Feb 14.)

I do think it might be worthwhile to meet in July [2]
though, at the Quebec IETF, so any early opinions on
that are welcome. (Or on other possible meeting dates/
venues for this year.)

Cheers,
S.

[1] http://www.ietf.org/meeting/80/index.html
[2] http://www.ietf.org/meeting/upcoming.html

Date: Tue, 25 Jan 2011 20:27:12 +0200
From: Hannes Tschofenig <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Workshop on "Interconnecting Smart Objects with the Internet"

Hi all,

some of you might have missed the announcement on the IETF announcement 
list. The workshop on "Interconnecting Smart Objects with the Internet" 
will take place on the Friday before the IETF#80 meeting in Prague. Here 
is the link to the workshop page:
http://www.iab.org/about/workshops/smartobjects

There is also a tutorial day attached to the workshop (on Saturday):
http://www.iab.org/about/workshops/smartobjects/tutorial.html

I believe that the DTN community could be interested in this event for 
two reasons:

a) We would like to get a better understanding of challenges with IP 
protocol implementations on constrained devices. I was told that this 
community has some experience in that area.

b) Attention in the DTN community has also been paid to various 
application scenarios. We would like to get your feedback about the 
mismatch between the research and the deployment community. For example, 
what characteristics (e.g. energy constraints, mobility requirements, 
certain security threats) have you seen in your application context?

Ciao
Hannes

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Andrew J Jenkins <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 25 Jan 2011 08:41:33 -0800
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

Good point, Andrew.  I'll add this.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew J Jenkins
Sent: Tuesday, January 25, 2011 7:55 AM
To: [email-masked]
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

If you add this protocol, it may be worth adding a note to the security
considerations pointing out that malicious nodes could construct
0-dictionary-length bundles pretending to be sent by other nodes to cause
denial-of-service:

- Node A and B have never spoken; A assumes B doesn't know CBHE.
- Node M generates a bundle with 0-dictionary-length, and sends it to A,
pretending to be sent by B.
- Node A now thinks that B knows CBHE, but B does not.
- Node A sends bundles to B using CBHE, and B is confused.

(doesn't work if BAB or authenticating CLs are required)

Andrew

On 01/24/2011 08:17 PM, Burleigh, Scott C (313B) wrote:
> Okay, I see your point.  I'm concerned, though, that if I add a definition of a new extension block or admin record in this spec then the change will be so significant that we'll have to open it up for another review cycle, and I'd like to avoid delaying publication of the spec if possible.
> 
> How about this?  Suppose I just add a line to the effect that reception of a bundle with zero-length dictionary -- that is, a CBHE-compressed bundle -- shall indicate that the sender of the bundle is able to do CBHE compression and decompression.  The decision on when to send such a bundle and exactly how to act on this information is left up to node administration policy, so it's not an elaborate full-fledged protocol and needn't generate a lot of controversy, but it does provide a simple mechanism by which node B could do as you propose.  Would that do the job?
> 
> Scott
> 
> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]] 
> Sent: Monday, January 24, 2011 6:30 PM
> To: Burleigh, Scott C (313B)
> Cc: Elwyn Davies; Internet Research Steering Group; DTN interest
> Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...
> 
> Hi,
> 
> (on CBHE)
> 
>>> - section 3.1, par 2: the last sentence here, "The manner in which 
>>> this determination is made is an implementation matter." made me stop 
>>> and think. Isn't the point of standards to be interoperable? If you 
>>> don't define how to determine whether CBHE is applied or not, doesn't 
>>> this make this whole specification a bit pointless? I have a feeling 
>>> that this is a key element which should be a part of this 
>>> specification.
>>
>> I think this goes to a recurring dilemma in configuring DTNs - when to 
>> define a discovery mechanism and when to rely on a management 
>> procedure.  Discovery protocols reduce network administration workload 
>> and ensure interoperability, but they typically rely on fairly prompt 
>> round-trip message exchange, which we can't always count on in a DTN; 
>> in some cases DTN transmission may even be strictly simplex, making 
>> discovery impossible.
>>
>> That is, in the most general case I believe we have to be able to 
>> support CBHE even on nodes that are on "fire and forget" devices that 
>> can never tell us how they are configured.  This throws the 
>> responsibility for this determination back on the source node, and in 
>> the near term I think mandating any particular local node management 
>> procedure for this purpose goes beyond the standardization that this 
>> specification should be aiming for.
>>
>> The long-term answer may be different: there is ongoing work on 
>> definition of DTN network management protocols, and eventually I think 
>> information about the CBHE-readiness of a node could very reasonably 
>> be among the items noted in the messages of those protocols.  But DTN 
>> network management is a complex problem, and I think it makes more 
>> sense to leverage (and conform to) a general solution to that problem 
>> when it emerges than to try to invent a separate solution to a small 
>> subset of it in the CBHE spec.
> 
> What I'd like to see is something that *could* be applied in case the necessary communication happens. Here's the scenario:
> A sends to B.
> A doesn't know whether B can deal with CBHE or not. So A can't use it.
> B is not entirely unlikely to ever speak to A... and in a message, it could tell A "hey, I can do CBHE!"
> If, and when, that happens, A should be able to say "cool, so let's use it!".
> 
> The point is not to *require* the message from B to A, but to define it such that it can be used if B should send A a message, and A could then make a switch. Is that really out of scope? If we don't define such a message, B never has a chance to tell A about this capability.  
> Will DTN management protocols fill this exact gap in the right way?  
> Fine with me if you say they will.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest
_______________________________________________
dtn-interest mailing list
[email-masked]
http://maillists.intel-research.net/mailman/listinfo/dtn-interest

Date: Tue, 25 Jan 2011 08:55:21 -0700
From: Andrew J Jenkins <[email-masked]>
To: [email-masked]
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

If you add this protocol, it may be worth adding a note to the security
considerations pointing out that malicious nodes could construct
0-dictionary-length bundles pretending to be sent by other nodes to cause
denial-of-service:

- Node A and B have never spoken; A assumes B doesn't know CBHE.
- Node M generates a bundle with 0-dictionary-length, and sends it to A,
pretending to be sent by B.
- Node A now thinks that B knows CBHE, but B does not.
- Node A sends bundles to B using CBHE, and B is confused.

(doesn't work if BAB or authenticating CLs are required)

Andrew

On 01/24/2011 08:17 PM, Burleigh, Scott C (313B) wrote:
> Okay, I see your point.  I'm concerned, though, that if I add a definition of a new extension block or admin record in this spec then the change will be so significant that we'll have to open it up for another review cycle, and I'd like to avoid delaying publication of the spec if possible.
> 
> How about this?  Suppose I just add a line to the effect that reception of a bundle with zero-length dictionary -- that is, a CBHE-compressed bundle -- shall indicate that the sender of the bundle is able to do CBHE compression and decompression.  The decision on when to send such a bundle and exactly how to act on this information is left up to node administration policy, so it's not an elaborate full-fledged protocol and needn't generate a lot of controversy, but it does provide a simple mechanism by which node B could do as you propose.  Would that do the job?
> 
> Scott
> 
> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]] 
> Sent: Monday, January 24, 2011 6:30 PM
> To: Burleigh, Scott C (313B)
> Cc: Elwyn Davies; Internet Research Steering Group; DTN interest
> Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...
> 
> Hi,
> 
> (on CBHE)
> 
>>> - section 3.1, par 2: the last sentence here, "The manner in which 
>>> this determination is made is an implementation matter." made me stop 
>>> and think. Isn't the point of standards to be interoperable? If you 
>>> don't define how to determine whether CBHE is applied or not, doesn't 
>>> this make this whole specification a bit pointless? I have a feeling 
>>> that this is a key element which should be a part of this 
>>> specification.
>>
>> I think this goes to a recurring dilemma in configuring DTNs - when to 
>> define a discovery mechanism and when to rely on a management 
>> procedure.  Discovery protocols reduce network administration workload 
>> and ensure interoperability, but they typically rely on fairly prompt 
>> round-trip message exchange, which we can't always count on in a DTN; 
>> in some cases DTN transmission may even be strictly simplex, making 
>> discovery impossible.
>>
>> That is, in the most general case I believe we have to be able to 
>> support CBHE even on nodes that are on "fire and forget" devices that 
>> can never tell us how they are configured.  This throws the 
>> responsibility for this determination back on the source node, and in 
>> the near term I think mandating any particular local node management 
>> procedure for this purpose goes beyond the standardization that this 
>> specification should be aiming for.
>>
>> The long-term answer may be different: there is ongoing work on 
>> definition of DTN network management protocols, and eventually I think 
>> information about the CBHE-readiness of a node could very reasonably 
>> be among the items noted in the messages of those protocols.  But DTN 
>> network management is a complex problem, and I think it makes more 
>> sense to leverage (and conform to) a general solution to that problem 
>> when it emerges than to try to invent a separate solution to a small 
>> subset of it in the CBHE spec.
> 
> What I'd like to see is something that *could* be applied in case the necessary communication happens. Here's the scenario:
> A sends to B.
> A doesn't know whether B can deal with CBHE or not. So A can't use it.
> B is not entirely unlikely to ever speak to A... and in a message, it could tell A "hey, I can do CBHE!"
> If, and when, that happens, A should be able to say "cool, so let's use it!".
> 
> The point is not to *require* the message from B to A, but to define it such that it can be used if B should send A a message, and A could then make a switch. Is that really out of scope? If we don't define such a message, B never has a chance to tell A about this capability.  
> Will DTN management protocols fill this exact gap in the right way?  
> Fine with me if you say they will.
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://maillists.intel-research.net/mailman/listinfo/dtn-interest

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Michael Welzl <[email-masked]>
Date: Mon, 24 Jan 2011 19:17:43 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Internet Research Steering Group <[email-masked]>, Elwyn Davies <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

Okay, I see your point.  I'm concerned, though, that if I add a definition of a new extension block or admin record in this spec then the change will be so significant that we'll have to open it up for another review cycle, and I'd like to avoid delaying publication of the spec if possible.

How about this?  Suppose I just add a line to the effect that reception of a bundle with zero-length dictionary -- that is, a CBHE-compressed bundle -- shall indicate that the sender of the bundle is able to do CBHE compression and decompression.  The decision on when to send such a bundle and exactly how to act on this information is left up to node administration policy, so it's not an elaborate full-fledged protocol and needn't generate a lot of controversy, but it does provide a simple mechanism by which node B could do as you propose.  Would that do the job?

Scott

-----Original Message-----
From: Michael Welzl [mailto:[email-masked]] 
Sent: Monday, January 24, 2011 6:30 PM
To: Burleigh, Scott C (313B)
Cc: Elwyn Davies; Internet Research Steering Group; DTN interest
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

Hi,

(on CBHE)

>> - section 3.1, par 2: the last sentence here, "The manner in which 
>> this determination is made is an implementation matter." made me stop 
>> and think. Isn't the point of standards to be interoperable? If you 
>> don't define how to determine whether CBHE is applied or not, doesn't 
>> this make this whole specification a bit pointless? I have a feeling 
>> that this is a key element which should be a part of this 
>> specification.
>
> I think this goes to a recurring dilemma in configuring DTNs - when to 
> define a discovery mechanism and when to rely on a management 
> procedure.  Discovery protocols reduce network administration workload 
> and ensure interoperability, but they typically rely on fairly prompt 
> round-trip message exchange, which we can't always count on in a DTN; 
> in some cases DTN transmission may even be strictly simplex, making 
> discovery impossible.
>
> That is, in the most general case I believe we have to be able to 
> support CBHE even on nodes that are on "fire and forget" devices that 
> can never tell us how they are configured.  This throws the 
> responsibility for this determination back on the source node, and in 
> the near term I think mandating any particular local node management 
> procedure for this purpose goes beyond the standardization that this 
> specification should be aiming for.
>
> The long-term answer may be different: there is ongoing work on 
> definition of DTN network management protocols, and eventually I think 
> information about the CBHE-readiness of a node could very reasonably 
> be among the items noted in the messages of those protocols.  But DTN 
> network management is a complex problem, and I think it makes more 
> sense to leverage (and conform to) a general solution to that problem 
> when it emerges than to try to invent a separate solution to a small 
> subset of it in the CBHE spec.

What I'd like to see is something that *could* be applied in case the necessary communication happens. Here's the scenario:
A sends to B.
A doesn't know whether B can deal with CBHE or not. So A can't use it.
B is not entirely unlikely to ever speak to A... and in a message, it could tell A "hey, I can do CBHE!"
If, and when, that happens, A should be able to say "cool, so let's use it!".

The point is not to *require* the message from B to A, but to define it such that it can be used if B should send A a message, and A could then make a switch. Is that really out of scope? If we don't define such a message, B never has a chance to tell A about this capability.  
Will DTN management protocols fill this exact gap in the right way?  
Fine with me if you say they will.

From: "Burleigh, Scott C (313B)" <[email-masked]>
To: Elwyn Davies <[email-masked]>, Michael Welzl <[email-masked]>
Date: Mon, 24 Jan 2011 17:15:38 -0800
Accept-Language: en-US
acceptlanguage: en-US
Cc: Internet Research Steering Group <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to	publish" mails...

Michael, thanks very much for your comments on CBHE.  Some responses in-line below.

Scott

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwyn Davies
Sent: Monday, January 24, 2011 11:37 AM
To: Michael Welzl
Cc: Internet Research Steering Group; DTN interest
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

...

On Mon, 2011-01-17 at 15:39 +1100, Michael Welzl wrote:
> Hi,
> 
> Below are my votes, and my (brief, because this is not my area of  
> expertise) comments on the ones that still needed votes. I'm fine with  
> all of them going forward, so my comments are rather minor, mostly  
> editorial things or nitpicking...

...

> > 3) draft-irtf-dtnrg-chbe
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/32
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
> > ready to publish:
> > 	"no objection" Juergen Scheoenwaelder, 2010-03-10
> > 		(note mail subject says "svhe" and not "cbhe" on irsg
> > 		list)
> 
> I vote "no objection" (instead of "ready to publish" due to lack of  
> confidence - I'd really have to be more of an expert on DTN to state  
> if this is really ready for publication or not) provided that you have  
> a good answer to this comment:
> 
> - section 3.1, par 2: the last sentence here, "The manner in which  
> this determination is made is an implementation matter." made me stop  
> and think. Isn't the point of standards to be interoperable? If you  
> don't define how to determine whether CBHE is applied or not, doesn't  
> this make this whole specification a bit pointless? I have a feeling  
> that this is a key element which should be a part of this specification.

I think this goes to a recurring dilemma in configuring DTNs - when to define a discovery mechanism and when to rely on a management procedure.  Discovery protocols reduce network administration workload and ensure interoperability, but they typically rely on fairly prompt round-trip message exchange, which we can't always count on in a DTN; in some cases DTN transmission may even be strictly simplex, making discovery impossible.

That is, in the most general case I believe we have to be able to support CBHE even on nodes that are on "fire and forget" devices that can never tell us how they are configured.  This throws the responsibility for this determination back on the source node, and in the near term I think mandating any particular local node management procedure for this purpose goes beyond the standardization that this specification should be aiming for.

The long-term answer may be different: there is ongoing work on definition of DTN network management protocols, and eventually I think information about the CBHE-readiness of a node could very reasonably be among the items noted in the messages of those protocols.  But DTN network management is a complex problem, and I think it makes more sense to leverage (and conform to) a general solution to that problem when it emerges than to try to invent a separate solution to a small subset of it in the CBHE spec. 
 
> other, minor, non-blocking comments:
> 
> - intro, par 2: you say here that the term SSP is historical - but  
> then, you keep using it throughout the document. This seems a bit  
> strange. Either you should use the new name, or you should rephrase  
> this here (e.g. "also called..." instead of "historically").

Or just remove the word "historically" from intro par.2?  I think that still preserves the sense of the sentence.

> - next par: I think there should be a comma after "eight" in: "...in  
> the dictionary may be less than eight and two or more of the scheme..."

I think that comma is optional in front of a coordinating conjunction, but I agree that it would improve the readability of the sentence.

> - section 2.1, par 1: fix "inSection" => "in Section".

Yes.

> - section 2.2: just a note, this list of constraints is one of the  
> things that made me feel less confident about this document - here, a  
> reviewer must really know the bundle spec very well to judge whether  
> this is ok or not...

Absolutely.  But I think it's unavoidable here.

> - security considerations: note that this appears as a heading within  
> IANA Considerations, and then later again, as a "proper" heading.  
> There is something wrong here, I think the second heading should be  
> removed, and the first one properly formatted.

Right, this looks like an error, but the first "security considerations" paragraph is actually part of the URI registration template I was trying to follow.  I think it's correct, but I will happily revise if someone knows of a more acceptable format.

> - in the bullet list after the first "security considerations" heading  
> (within section 4): "Rare IP address formats: not relevant, ..."   -  
> because this is not relevant, I think it should be removed.

This too was part of the URI registration template I was working from.  Again, I'm happy to remove it if IANA won't complain.

Scott

Date: Mon, 24 Jan 2011 21:26:10 +0000
From: Stephen Farrell <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: Internet Research Steering Group <[email-masked]>, Elwyn Davies <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

Excellent, many thanks.

I'll send a summary mail with the details. I think cbhe
also needs one more (Jeurgen say "no objection") but in
the meantime Aaron pointed out to me that I can vote on
this since I'm not an author on that, so I hereby vote
"ready to publish" for draft-irtf-dtnrg-cbhe.

Elwyn - when I've done that can you tidy up the tickets
and then ask Aaron to proceed to the IESG review stage
Thanks,
S.

On 24/01/11 20:51, Michael Welzl wrote:
>> Unfortunately that still leaves us needing 'ready to publish' votes for
>> items 3 (cbhe), 4 (metadata block) and 5 (previous hop block).  Any
>> other IRSG memebers willing to put their heads above the parapet
>> *please*?
> 
> Ah... I wasn't sure anymore. Well I'm willing to increase the level to
> "ready to publish" for these three documents then.
> It's just that I don't feel very confident because this is really not my
> field ... , but then again, they looked fine to me.
> 
> Sorry for that!
> 
> Cheers,
> Michael
> 
> 

From: Elwyn Davies <[email-masked]>
To: Michael Welzl <[email-masked]>
Date: Mon, 24 Jan 2011 19:37:06 +0000
Cc: Internet Research Steering Group <[email-masked]>, DTN interest <[email-masked]>
Subject: Re: [dtn-interest] [IRSG] DTNRG drafts need a few more "ready to publish" mails...

Hi, Michael.

Thanks very much for your comments.

I was planning a minor update of sdnv and will address your comments
along  with some from Lachlan Andrew.

I am forwarding this to the dtn interest list so that the various
authors can see your comments as well.

Unfortunately that still leaves us needing 'ready to publish' votes for
items 3 (cbhe), 4 (metadata block) and 5 (previous hop block).  Any
other IRSG memebers willing to put their heads above the parapet
*please*?

Regards,
Elwyn

On Mon, 2011-01-17 at 15:39 +1100, Michael Welzl wrote:
> Hi,
> 
> Below are my votes, and my (brief, because this is not my area of  
> expertise) comments on the ones that still needed votes. I'm fine with  
> all of them going forward, so my comments are rather minor, mostly  
> editorial things or nitpicking...
> 
> 
> > 1) draft-irtf-dtnrg-sdnv
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/30
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-sdnv
> > ready to publish:
> > 	Juergen Schoenwaelder, 2010-03-03
> 
> I also vote "ready to publish" here.
> 
> Comments:
> 
> I think this is a very useful document and even enjoyed reading it. A  
> few nits:
> - section 1.1 par 3 line 2: remove "0" before "IP header format"
> - second last line: might have to be "...to have _a_ visible impact  
> on..."   (don't know for sure, I'm not a native speaker)
> - 1.3 bullet list: I suggest to remove the last ("Etc.") bullet, this  
> is just a waste of space because you say "such as" anyway
> - section 4: as I read this, I became more and more curious what  
> SDNV-8 and SDNV-16 really look like. Given that it probably won't be  
> very complicated to explain them, you could make this an easier read  
> with a brief explanation of these formats.
> - paragraph just below table 1: this is a repetition of some earlier  
> text, and as such maybe unnecessary. If you think it adds value to  
> repeat this here, at least refer to the other text ("as initially  
> stated, .." or something like that).
> - Reference ASN1-BER: strange line break here
> 
> 
> > 3) draft-irtf-dtnrg-chbe
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/32
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-cbhe
> > ready to publish:
> > 	"no objection" Juergen Scheoenwaelder, 2010-03-10
> > 		(note mail subject says "svhe" and not "cbhe" on irsg
> > 		list)
> 
> I vote "no objection" (instead of "ready to publish" due to lack of  
> confidence - I'd really have to be more of an expert on DTN to state  
> if this is really ready for publication or not) provided that you have  
> a good answer to this comment:
> 
> - section 3.1, par 2: the last sentence here, "The manner in which  
> this determination is made is an implementation matter." made me stop  
> and think. Isn't the point of standards to be interoperable? If you  
> don't define how to determine whether CBHE is applied or not, doesn't  
> this make this whole specification a bit pointless? I have a feeling  
> that this is a key element which should be a part of this specification.
> 
> other, minor, non-blocking comments:
> 
> - intro, par 2: you say here that the term SSP is historical - but  
> then, you keep using it throughout the document. This seems a bit  
> strange. Either you should use the new name, or you should rephrase  
> this here (e.g. "also called..." instead of "historically").
> - next par: I think there should be a comma after "eight" in: "...in  
> the dictionary may be less than eight and two or more of the scheme..."
> - section 2.1, par 1: fix "inSection" => "in Section".
> - section 2.2: just a note, this list of constraints is one of the  
> things that made me feel less confident about this document - here, a  
> reviewer must really know the bundle spec very well to judge whether  
> this is ok or not...
> - security considerations: note that this appears as a heading within  
> IANA Considerations, and then later again, as a "proper" heading.  
> There is something wrong here, I think the second heading should be  
> removed, and the first one properly formatted.
> - in the bullet list after the first "security considerations" heading  
> (within section 4): "Rare IP address formats: not relevant, ..."   -  
> because this is not relevant, I think it should be removed.
> 
> 
> > 4) draft-irtf-dtnrg-bundle-metadata-block
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/33
> > draft:  http://tools.ietf.org/html/draft-irtf-dtnrg-metadata-block
> > ready to publish:
> > 	Juergen Schoenwaelder, 2010-11-29
> 
> Again I vote "no objection" just for confidence reasons. The document  
> looks fine to me. The only (non-blocking :-) ) comment I have on this  
> one is that I don't like its last three words (end of security cons.  
> section): "as currently written". I suggest to remove them.
> 
> 
> > 5) draft-irtf-dtnrg-bundle-previous-hop-block
> > ticket: http://trac.tools.ietf.org/group/irtf/trac/ticket/34
> > draft: http://tools.ietf.org/html/draft-irtf-dtnrg-previous-hop-block
> > ready to publish:
> > 	Juergen Schoenwaelder, 2010-11-29
> 
> Again, "no objection", for the same reasons.
> 
> Minor (non-blocking) comments:
> - remove " at the end of the abstract
> - section 3.3: about the statement "If ... the PHIB is not considered  
> to be well-formed." and the text after it: what's the point of  
> including this in the definition? According to the spec, such an ill- 
> formed PHIB MUST NOT be generated, right? In that case, describing how  
> to handle it is a bit like describing the case of when a buggy sender  
> writes "123123" in every field... or whatever... my point is, if we  
> consider buggy hosts, ANYTHING can happen, and incorporating this  
> assumption in the document here just seems like a waste of space to  
> me. But maybe I missed it, and an ill-formed PHIB may be generated  
> somehow in line with this spec.
> - section 4 par 5: same thing here, this looks to me as if you could  
> also add a paragraph saying "Note that a PHIB may also contain the  
> value 123123" no matter where it comes from if hosts are buggy and  
> hence always just stupidly write this number there." or: "Note that a  
> buggy host can write your system password into a packet, and then  
> anybody can see it."  That's taking security concerns too far IMO, and  
> seems like a waste of space (= reader's time!) to me.
> 
> Cheers,
> Michael
> 

Date: Thu, 20 Jan 2011 20:35:07 +0100
From: Frederic Guidec <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] CFP: International Workshop on Opportunistic and Delay/Disruption-Tolerant Networking (WODTN 2011)

Call for Papers : International Workshop on Opportunistic and 
Delay/Disruption-Tolerant Networking (WODTN 2011)

5 October 2011 (to be confirmed)

In conjunction with the 14th International Symposium on Wireless 
Personal Multimedia Communications (http://www.wpmc2011.org)

3-6 October, 2011
Brest, France

DESCRIPTION
Delay-tolerant and disruption-tolerant networking (DTN) have become 
active fields of research during the past decade. They address scenarios 
where traditional communication protocols fail because of very 
long-delayed transmissions, or because of the absence of continuous 
end-to-end connectivity in the network. In such conditions the DTN 
principle mainly allows some (or sometimes all) of the network nodes to 
store messages and forward these messages later when connectivity 
conditions permit. When some network nodes are mobile, they can 
additionally carry messages while moving physically in the network, thus 
serving as "data mules" and bridging the gap between otherwise 
non-connected parts of the network.
The term “opportunistic networking” is often used to refer to mobile 
DTNs in which radio contacts between mobiles devices are not planned in 
advance, and must thus be exploited opportunistically.
Possible application fields for DTN are interplanetary networks, 
vehicular networks, disaster-relief networks, sparse and/or mobile 
sensor networks, tactical networks, etc.

This workshop is meant to provide a forum for academic researchers and 
industry professionals to present and discuss their latest research 
results in all areas related to delay-tolerant, disruption-tolerant, 
and/or opportunistic networking. Original papers addressing both 
theoretical and practical issues are solicited, including papers 
describing prototype implementations and deployments.
SCOPE

Topics of interest include, but are not limited to:

• enabling technologies for DTN
• physical and data-link layer issues in DTN
• cross-layering in DTN
• routing and/or information dissemination in DTN
• resource management issues in DTN
• context awareness in DTN
• high-level paradigms and APIs for DTN
• security issues in DTN
• middleware platforms for DTN
• services and applications in DTN
• simulation and modeling of DTN
• DTN experimentation

PAPER SUBMISSION

Authors are invited to submit original papers in English (maximum 5 
pages) electronically in PDF format through the EDAS system. For all 
submissions, please use the templates available on the WPMC 2011 website 
(http://www.wpmc2011.org).

IMPORTANT DATES
Submission deadline: 31 March 2011
Notification of acceptance: 30 June 2011
Camera ready submission: 31 August 2011

Tentative date of the Workshop: 5 October 2011

-- 
Dr. Frederic GUIDEC -------------------------------------
Laboratoire VALORIA -- Université de Bretagne Sud
Université Européenne de Bretagne
Campus de Tohannic
BP 573 - F-56017 Vannes, France
mailto:Frederic.Guidec%AT%univ-ubs.fr
http://www-valoria.univ-ubs.fr/Frederic.Guidec
tel : +33 (0)2 97 01 72 16
fax : +33 (0)2 97 01 72 79
---------------------------------------------------------

From: Dirk Kutscher <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 20 Jan 2011 16:58:21 +0000
Accept-Language: de-DE, en-US
Cc: "[email-masked]" <[email-masked]>
Subject: [dtn-interest] Call for papers: ACM SIGCOMM Workshop on Information-Centric Networking (ICN-2011)

[Apologies if you receive this more than once]

======================================================================
                         ACM SIGCOMM Workshop on
                      Information-Centric Networking

                           August 15-19,2011
                          Toronto, ON, Canada

                      http://www.neclab.eu/icn-2011/
======================================================================

                            Call For Papers
                            ---------------

The development of Information-Centric Networking (ICN -- also
referred to as data centric networking, content centric networking,
networking of information, etc.) concepts is one of the significant
results of different international Future Internet research
activities. In such approaches, the principal paradigm is not
host-to-host communication as in the current Internet
architecture. Instead, an increasing demand for highly scalable and
efficient distribution of content has motivated the development of
architectures that focus on information objects, their properties, and
receiver interest in the network to achieve efficient and reliable
distribution of such objects. Corresponding network architectures can
leverage in-network storage, multiparty communication through
replication and interaction models such as publish-subscribe to
provide general platforms for communication services that are today
only available in dedicated systems such as peer-to-peer overlays and
proprietary content-distribution networks.

Important research topics for ICN include: naming and addressing (how
to name information objects, how to represent location information),
routing and resolution (deciding on how to forward "interest" in
information and actual information objects, whether and how to resolve
information object names to lower layer identifiers during that
process), resource management (implications of in-network caching and
paradigms such as receiver-orientation to resource sharing, congestion
control etc.) and security (privacy, data protection and key
distribution have to be adapted to the new communication models).
This workshop invites original contributions on Information-Centric
Networking architecture topics as well as on results from
implementations and experimentation. Topics of interest include, but
are not limited to:

* Naming and addressing in ICN
* Routing and name resolution in ICN
* Resource management (caching strategies, congestion control)
* Security, privacy and trust in ICN
* Testbeds and simulation frameworks
* Business and deployment aspects
* New application opportunities with ICN
* Design and definition of the basic ICN primitives
* Accountability in ICN (e.g. referrals, click-throughs, etc)
* Billing, costing and invoicing for ICN traffic
* Metadata and network extensions for ICN
* Real-time traffic over ICN (voice, video, etc)
* PDUs, fragmentation and Ã¢â‚¬Å“packet sizeÃ¢â‚¬Â implications on design
* Overlays and underlays with ICN
* ICNs in mobile networks
* Concurrency, locking and synchronization for ICN data
* Versioning, deletion, revocation and general ICN object management
* Monitoring, troubleshooting and management tools for ICNs

                         Submission instructions
                         ------------------------

Submissions must be no greater than 6 pages in length and must be a
pdf file. Reviews will be single-blind: authors name and affiliation
should be included in the submission. Submissions must follow the
formatting guidelines at http://www.sigcomm.org/sigcomm2011/. Authors
of accepted papers are expected to present their papers at the
workshop. Submissions must be original work not under review at any
other workshop, conference, or journal.

Submission website: http://www.neclab.eu/icn-2011/

                             Important Dates
                             ---------------

Paper submission: Friday, March 18, 2011 [23:59 PST] 

Acceptance notification: Friday, April 29, 2011  

Camera-ready: Friday, May 27, 2011

Date of the workshop: Friday, August 19, 2011

                         Technical Program Chairs
                         ------------------------
Dirk Kutscher, NEC Laboratories Europe - Germany
Giacomo Morabito, University of Catania - Italy
Ignacio Solis, PARC - USA

                          Steering Committee
                <[email-masked]>
                -------------------------------------------

Dirk Kutscher, NEC Laboratories Europe -  Germany
Giacomo Morabito, University of Catania - Italy
Boerje Ohlman, Ericsson - Sweden
George C. Polyzos, AUEB - Greece
Ignacio Solis, PARC - USA
Lixia Zhang, UCLA - USA

                       Technical program committee
                       ---------------------------

Tarek Abdelzaher, UIUC - USA
Bengt Ahlgren, SICS - Sweden
Tohru Asami, Univ. of Tokio - Japan
Jun Bi, Tsinghua Univ. - China
Nicola Blefari-Melazzi, Univ. of Rome  - Italy
Yanghee Choi, Seoul National Univ. - South Korea
Costas Courcoubetis, AUEB - Greece
Andrea Detti, Univ. of Rome  - Italy
Lars Eggert, Nokia, Finland 
Stephen Farrell, Trinity College - Ireland
Kenneth Guild, University of Essex - UK
Van Jacobson, PARC - USA
Jussi Kangasharju, Helsinki Univ. - Finland
Holger Karl, Univ. Paderborn - Germany
Wolfgang Kellerer, NTT Docomo - Germany
Teemu Koponen, Nicira - USA
Anders Lindgren, SICS - Sweden
Daniel Massey, Colorado State Univ. - USA
Pekka Nikkander, Ericsson - Finland
Joerg Ott, Aalto Univ. - Finland
Sara Oueslati, France Telecom - France
Christos Papadopoulos, Colorado State Univ. - USA
Jarno Rajahalme, NSN - Finland
Scott Shenker, ICSI - USA
Sasu Tarkoma, Aalto Univ. - Finland
Dirk Trossen, Cambridge Univ. - UK
Ryuji Wakikawa, Toyota ITC - Japan
Lan Wang, Univ. of Memphis - USA
Edmund Yeh, Yale Univ. - USA
Beichuan Zhang, Univ. of Arizona - USA

--
Dr. Dirk Kutscher
NEC Laboratories Europe
Kurfuerstenanlage 36
69115 Heidelberg, Germany
email: [email-masked]
Tel. +49 6221 4342 203
Fax. +49 6221 4342 155

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, 
London W3 6BL | Registered in England 2832014

From: Ioannis Komnios <[email-masked]>
Date: Wed, 19 Jan 2011 13:47:06 +0200
To: [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] CFP EXTENDED: [WWIC 2011] 9th International Conference on	Wired/Wireless Internet Communications

--Apple-Mail-5--697153667
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

-----------------------------------------------------------------------
-       Our apologies if you receive multiple copies of this CFP       -
------------------------------------------------------------------------

-------------------------DEADLINE EXTENSION-------------------------

                           CALL FOR PAPERS

                             WWIC 2011
                  9th International Conference on
               Wired/Wireless Internet Communications

                  http://www.craax.upc.edu/WWIC11

                         sponsored by IFIP

                          June 15-17, 2011
                Vilanova i la Geltr'u, Barcelona, Spain

------------------------------------------------------------------------

****    NEW SUBMISSION DEADLINE (EXTENDED): JANUARY 30, 2011     *******

------------------------------------------------------------------------

Next generation mobile networks will be based on Internet core =20
networks and wireless access networks. The need for efficient merging =20=

of the wired and wireless infrastructure as well as the new multimedia =20=

services and applications of next generation networks call for novel =20
network architectures, protocols and traffic-related mechanisms, =20
merging and assembling different network technologies features. WWIC =20
addresses research topics such as the design and evaluation of =20
protocols, the dynamics of the integration, the performance
tradeoffs, the need for new performance metrics, and cross-layer =
interactions.

The goal of the conference is to present high-quality results in the =20
field, and to provide a framework for research collaboration through =20
focused discussions that will designate future research efforts and =20
directions. In this context, the program committee will accept only a =20=

limited number of papers that meet the criteria of originality, =20
presentation quality and topic relevance. WWIC is a single-track =20
conference which has reached, within 8 years, the highest level of =20
quality, which is reflected both in the level of participation
as well as the acceptance ratio and the amount and quality of =20
submitted papers.

Accepted papers will appear in the conference proceedings published by =20=

Springer in the Lecture Notes of Computer Science (LNCS) Series. =20
Extended versions of conference selected papers will be considered for =20=

publication in an special issue of an international journal.

Following the conference tradition there will also be a Best Paper =
Award.

Topics of interest include, but are not limited to:

- AAA in mobile environments
- Ambient networks
- Ad-hoc mobile networks
- Blended network configurations
- Beyond 3G networks technologies
- Cross layer interactions
- Economical issues of wireless networks
 -End-to-end Quality of Service support
- Handover techniques
- Heterogeneous wireless access networks
- Hybrid wired / wireless environments
- Interaction wireless/optical networks
- Integration of wired and wireless networks
- Mobile service level agreements/spec.
- Mobility management
- Network design and network planning
- Network mobility
- Network coding in mobile networks
- Network security in mobile environments
- Performance evaluation of wireless systems
- Pricing, charging and accounting in wireless net.
- QoS routing in mobile networks
- QoS signalling in mobile environments
- Resource management and admission control
- Service creation and management for wireless
- Simulation for next generation mobile networks
- Traffic characterization and modeling
- Traffic engineering
- Transport protocols and congestion control
- Wireless mesh networks
- Wireless multi-hop networks
- Wireless multimedia systems
- Wireless network monitoring
- Wireless sensor networks
- Optical/Wireless integration
- Space internetworking
- Delay/disruptive tolerant networking
- Vehicular networks

PAPER SUBMISSION AND PUBLICATION
------------------------------------------------------------------------
All submissions must describe original research, not published or
currently under review for another workshop, conference, or journal.
Papers must be submitted electronically through EDAS.
You can find detailed submission instructions at
http://www.craax.upc.edu/WWIC11

*******************
Submission implies the willingness of at least one author to attend
the conference and present the paper. Accepted papers will appear
in the conference proceedings published by Springer in the
Lecture Notes of Computer Science (LNCS) Series.
*******************

IMPORTANT DATES
------------------------------------------------------------------------
- Manuscript submission deadline (EXTENDED): January 30, 2011.
- Manuscript acceptance notification:  March 4, 2011.

CONTACTS
------------------------------------------------------------------------
For further information, please visit the conference website at
http://www.craax.upc.edu/WWIC11 or contact the TPC-chairs
at [email-masked]

WORKSHOPS AND AFFILIATED EVENTS:
------------------------------------------------------------------------
Two workshops will be held in conjunction with the main conference.

5th ERCIM eMobility Workshop on June 14, 2011
4th IntelliCIS Workshop on June 13-14, 2011

Please visit the conference website for details.

ORGANIZING COMMITTEE
------------------------------------------------------------------------
GENERAL CO-CHAIRS
Xavier Masip-Bruin, Universitat Polit`ecnica de Catalunya, UPC, Spain
Dominique Verchere, Alcatel-Lucent Bell Labs, France

TPC CO-CHAIRS
Vassilis Tsaoussidis, Democritus University of Thrace, Greece
Marcelo Yannuzzi, Universitat Polit`ecnica de Catalunya, UPC, Spain

PUBLICATION CO-CHAIRS
Eva Mar'in-Tordera, Universitat Polit`ecnica de Catalunya, UPC, Spain

PUBLICITY CO-CHAIRS
Eduardo Cerqueira, UFPA, Brazil
Alex Sprintson, Texas A&M, USA

STEERING COMMITTEE
Torsten Barun, University of Bern, Switzerland
Georg Carle, TU M"unchen, Germany
Geert Heijenk, University of Twente, The Netherlands
Yevgeni Koucheryavy, Tampere University of Technology, Finland
Peter Langend"orfer, IHP Microelectronics, Germany
Ibrahim Matta, Boston University, USA
Vassilis Tsaoussidis, Democritus University of Thrace, Greece

SPONSORED BY:
Cisco
i2CAT
Spice project
COST Program
UPC
Neapolis=

--Apple-Mail-5--697153667
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><pre>-----------------------------------------------------------------------
-       Our apologies if you receive multiple copies of this CFP       -
------------------------------------------------------------------------

-------------------------DEADLINE EXTENSION-------------------------

                           CALL FOR PAPERS

                             WWIC 2011
                  9th International Conference on
               Wired/Wireless Internet Communications

                  <a class="moz-txt-link-freetext" href="http://www.craax.upc.edu/WWIC11">http://www.craax.upc.edu/WWIC11</a>

                         sponsored by IFIP

                          June 15-17, 2011
                Vilanova i la Geltr'u, Barcelona, Spain

------------------------------------------------------------------------

****    NEW SUBMISSION DEADLINE (EXTENDED): JANUARY 30, 2011     *******

------------------------------------------------------------------------

Next generation mobile networks will be based on Internet core  
networks and wireless access networks. The need for efficient merging  
of the wired and wireless infrastructure as well as the new multimedia  
services and applications of next generation networks call for novel  
network architectures, protocols and traffic-related mechanisms,  
merging and assembling different network technologies features. WWIC  
addresses research topics such as the design and evaluation of  
protocols, the dynamics of the integration, the performance
tradeoffs, the need for new performance metrics, and cross-layer interactions.

The goal of the conference is to present high-quality results in the  
field, and to provide a framework for research collaboration through  
focused discussions that will designate future research efforts and  
directions. In this context, the program committee will accept only a  
limited number of papers that meet the criteria of originality,  
presentation quality and topic relevance. WWIC is a single-track  
conference which has reached, within 8 years, the highest level of  
quality, which is reflected both in the level of participation
as well as the acceptance ratio and the amount and quality of  
submitted papers.

Accepted papers will appear in the conference proceedings published by  
Springer in the Lecture Notes of Computer Science (LNCS) Series.  
Extended versions of conference selected papers will be considered for  
publication in an special issue of an international journal.

Following the conference tradition there will also be a Best Paper Award.

Topics of interest include, but are not limited to:

- AAA in mobile environments
- Ambient networks
- Ad-hoc mobile networks
- Blended network configurations
- Beyond 3G networks technologies
- Cross layer interactions
- Economical issues of wireless networks
 -End-to-end Quality of Service support
- Handover techniques
- Heterogeneous wireless access networks
- Hybrid wired / wireless environments
- Interaction wireless/optical networks
- Integration of wired and wireless networks
- Mobile service level agreements/spec.
- Mobility management
- Network design and network planning
- Network mobility
- Network coding in mobile networks
- Network security in mobile environments
- Performance evaluation of wireless systems
- Pricing, charging and accounting in wireless net.
- QoS routing in mobile networks
- QoS signalling in mobile environments
- Resource management and admission control
- Service creation and management for wireless
- Simulation for next generation mobile networks
- Traffic characterization and modeling
- Traffic engineering
- Transport protocols and congestion control
- Wireless mesh networks
- Wireless multi-hop networks
- Wireless multimedia systems
- Wireless network monitoring
- Wireless sensor networks
- Optical/Wireless integration
- Space internetworking
- Delay/disruptive tolerant networking
- Vehicular networks

PAPER SUBMISSION AND PUBLICATION
------------------------------------------------------------------------
All submissions must describe original research, not published or
currently under review for another workshop, conference, or journal.
Papers must be submitted electronically through EDAS.
You can find detailed submission instructions at
<a class="moz-txt-link-freetext" href="http://www.craax.upc.edu/WWIC11">http://www.craax.upc.edu/WWIC11</a>

*******************
Submission implies the willingness of at least one author to attend
the conference and present the paper. Accepted papers will appear
in the conference proceedings published by Springer in the
Lecture Notes of Computer Science (LNCS) Series.
*******************

IMPORTANT DATES
------------------------------------------------------------------------
- Manuscript submission deadline (EXTENDED): January 30, 2011.
- Manuscript acceptance notification:  March 4, 2011.

CONTACTS
------------------------------------------------------------------------
For further information, please visit the conference website at
<a class="moz-txt-link-freetext" href="http://www.craax.upc.edu/WWIC11">http://www.craax.upc.edu/WWIC11</a> or contact the TPC-chairs
at <a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>

WORKSHOPS AND AFFILIATED EVENTS:
------------------------------------------------------------------------
Two workshops will be held in conjunction with the main conference.

5th ERCIM eMobility Workshop on June 14, 2011
4th IntelliCIS Workshop on June 13-14, 2011

Please visit the conference website for details.

ORGANIZING COMMITTEE
------------------------------------------------------------------------
GENERAL CO-CHAIRS
Xavier Masip-Bruin, Universitat Polit`ecnica de Catalunya, UPC, Spain
Dominique Verchere, Alcatel-Lucent Bell Labs, France

TPC CO-CHAIRS
Vassilis Tsaoussidis, Democritus University of Thrace, Greece
Marcelo Yannuzzi, Universitat Polit`ecnica de Catalunya, UPC, Spain

PUBLICATION CO-CHAIRS
Eva Mar'in-Tordera, Universitat Polit`ecnica de Catalunya, UPC, Spain

PUBLICITY CO-CHAIRS
Eduardo Cerqueira, UFPA, Brazil
Alex Sprintson, Texas A&amp;M, USA

STEERING COMMITTEE
Torsten Barun, University of Bern, Switzerland
Georg Carle, TU M"unchen, Germany
Geert Heijenk, University of Twente, The Netherlands
Yevgeni Koucheryavy, Tampere University of Technology, Finland
Peter Langend"orfer, IHP Microelectronics, Germany
Ibrahim Matta, Boston University, USA
Vassilis Tsaoussidis, Democritus University of Thrace, Greece

SPONSORED BY:
Cisco
i2CAT
Spice project
COST Program
UPC
Neapolis</pre></body></html>
--Apple-Mail-5--697153667--

From: Ioannis Komnios <[email-masked]>
Date: Wed, 19 Jan 2011 13:27:54 +0200
To: [email-masked]
Subject: [dtn-interest] Open position at Space Internetworking Center, Xanthi, Greece

--Apple-Mail-2--698305278
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

[We apologize in advance if you receive multiple copies of this message]

This call for interest is announced in the framework of the project =
=E2=80=9CSpace Internetworking Center=E2=80=9D with the acronym SPICE =
(Grant Agreement Number 264226) which is funded by =E2=80=9CCapacities=E2=80=
=9D of the Seventh Framework Programme. The project is approved as a =
=E2=80=9CCoordination and Support Action=E2=80=9D under the =E2=80=9CResea=
rch Potential=E2=80=9D Scheme and has a duration of three years =
(01/09/10-31/08/13).

A. BACKGROUND
Internetworked Systems Laboratory (InterSys Group) has made significant =
contributions to the architectural requirements, objectives =
standardization and prototyping of future Space Internetworking =
strategy. InterSys Group is a leading group in Europe in Space =
Internetworking, participates in the Consultive Committee for Space Data =
Systems and in several other European Bodies. The Internetworked Systems =
Laboratory has a total funding of around 4 million Euros. The Project =
Coordinator, Vassilis Tsaousidis, is a Professor in the Department of =
Electrical and Computer Engineering of Democritus University of Thrace, =
Greece and the Director of Internetworked Systems Laboratory.

SPICE relies on three major objectives: to broaden the group=E2=80=99s =
accomplished research innovation and engineering capacity both by =
mobilizing resources to visit first-class cooperating European =
institutions and hiring top class researchers from abroad; to support a =
revolutionary scientific agenda, as far as Delay Tolerant Networking is =
concerned, that boosts European competitiveness and supports a wide =
spectrum of applications; and to institutionalize and establish a =
permanent quality framework for innovative research activities in the =
convergence region of Thrace. Apart from the required infrastructure =
update, SPICE aims at promoting research through the publication of =
special issues in high-quality journals, the organisation of regular =
lectures and presentations from distinguished scientists, as well as the =
hosting of a panel session and two workshops on promising networking =
technologies, such as 4G communications.

B. JOB DESCRIPTION
In the framework of SPICE project we invite applications for a team of =
scientists as follows:

1. One senior researcher from abroad to work at the Space =
Internetworking Center (Xanthi, Greece) on the topic of =
=E2=80=9Cinternetworking and/or delay-tolerant networking=E2=80=9D.=20

Vacancies duration: the term of the appointment will be for one year =
starting March 2011 with an option for extension.

Job Requirements:=20
=E2=96=A0	Computer engineering or computer science degree=20
=E2=96=A0      Ph.D. Degree, preferably in the fields of computer =
networks, distributed computing, operating systems, computer =
architecture or telecommunications=20
=E2=96=A0	Excellent knowledge of English language (speak, read and =
write fluently).

Experience in delay tolerant networking and TCP/IP protocols is =
desirable. The evaluation of all candidates will be based on their =
experience, relevance of studies and research accomplishments.

C. CONTRACT
Salary depends on qualifications. Maximum gross annual salary is =
54.000=E2=82=AC. Accommodation cost in Xanthi is relatively low (for =
example typical two-bedroom apartment costs around 350=E2=82=AC).

D. EQUAL OPPORTUNITIES
Equal opportunities policy without distinctions (sex, origin, religion, =
disability, age etc) will be applied.

E. REQUIRED DOCUMENTATION
Interested applicants should send their curriculum vitae using the =
Europass standard including:
- An application letter=20
- A research statement
- A synopsis of research experience=20
- A list of publications=20
- The names of three referees
by e-mail to [email-masked].=20

Please use the following reference in the subject: =
SPICE_RESEARCHERS_2010. Please note that an acknowledgement e-mail will =
be sent upon receipt of each application within 3 working days.

An interview may be asked by the Project Coordinator, in case this is =
deemed necessary. Selected candidates should provide:
=EF=81=AE Original documents (or official translations) of Degrees
=EF=81=AE Original documents (or official translations) of working =
experience certificates=20
=EF=81=AE Three letters of reference.

F. DEADLINE OF SUBMISSION Initial deadline for receipt of e-mail: =
27/01/2011
However applications will be accepted until position is filled.
Candidates will be evaluated based on their qualification by a =
Scientific Committee.

--Apple-Mail-2--698305278
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 14px/normal Arial; ">[We =
apologize in advance if you receive multiple copies of this =
message]</div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
14px/normal Arial; "><br></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 14px/normal Arial; ">This call for interest is announced =
in the framework of the project =E2=80=9CSpace Internetworking Center=E2=80=
=9D with the acronym SPICE (Grant Agreement Number 264226) which is =
funded by =E2=80=9CCapacities=E2=80=9D of the Seventh Framework =
Programme. The project is approved as a =E2=80=9CCoordination and =
Support Action=E2=80=9D under the =E2=80=9CResearch Potential=E2=80=9D =
Scheme and has a duration of three years (01/09/10-31/08/13).</div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 14px/normal Arial; =
"><br></div><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal 'Times New Roman'; "><font class=3D"Apple-style-span" =
face=3D"Arial"><b><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">A. =
BACKGROUND</span></font></b></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Internetworked Systems Laboratory (InterSys Group) has made =
significant contributions to the architectural requirements, objectives =
standardization and prototyping of future Space Internetworking =
strategy. InterSys Group is a leading group in Europe in Space =
Internetworking, participates in the Consultive Committee for Space Data =
Systems and in several other European Bodies. The Internetworked Systems =
Laboratory has a total funding of around 4 million Euros. The Project =
Coordinator, Vassilis Tsaousidis, is a Professor in the Department of =
Electrical and Computer Engineering of Democritus University of Thrace, =
Greece and the Director of Internetworked Systems =
Laboratory.</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;"><br></span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">SPICE relies on three major objectives: to broaden the group=E2=80=99=
s accomplished research innovation and engineering capacity both by =
mobilizing resources to visit first-class cooperating European =
institutions and hiring top class researchers from abroad; to support a =
revolutionary scientific agenda, as far as Delay Tolerant Networking is =
concerned, that boosts European competitiveness and supports a wide =
spectrum of applications; and to institutionalize and establish a =
permanent quality framework for innovative research activities in the =
convergence region of Thrace. Apart from the required infrastructure =
update, SPICE aims at promoting research through the publication of =
special issues in high-quality journals, the organisation of regular =
lectures and presentations from distinguished scientists, as well as the =
hosting of a panel session and two workshops on promising networking =
technologies, such as 4G communications.</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;"><br></span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><div style=3D"margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; font: normal normal normal =
12px/normal 'Times New Roman'; "><font class=3D"Apple-style-span" =
face=3D"Arial"><b><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">B. JOB =
DESCRIPTION</span></font></b></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">In the framework of SPICE project we invite applications for a =
team of scientists as follows:</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;"><br></span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">1. One senior researcher from abroad to work =
at the Space Internetworking Center (Xanthi, Greece) on the topic of =
=E2=80=9Cinternetworking and/or delay-tolerant =
networking=E2=80=9D.&nbsp;</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;"><br></span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">Vacancies duration: the term of the =
appointment will be for one year starting March 2011 with an option for =
extension.</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;"><br></span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Job Requirements:&nbsp;</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;"><font =
class=3D"Apple-style-span" face=3D"Arial"></font></span></font><span =
style=3D"font: 9.0px 'Times New Roman'"><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
14px;">=E2=96=A0</span></font></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">	=
</span></font></font></span></span><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">Computer =
engineering or computer science =
degree&nbsp;</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;"><font class=3D"Apple-style-span" =
face=3D"Arial"></font></span></font><span style=3D"font: 9.0px 'Times =
New Roman'"><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">=E2=96=A0 &nbsp; &nbsp; =
&nbsp;</span></font></font></span><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">Ph.D. Degree, =
preferably in the fields of computer networks, =
distributed&nbsp;</span></font></font><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">computing, =
operating systems, computer architecture or =
telecommunications&nbsp;</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;"><font =
class=3D"Apple-style-span" face=3D"Arial"></font></span></font><span =
style=3D"font: 9.0px 'Times New Roman'"><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: =
14px;">=E2=96=A0</span></font></font><span class=3D"Apple-tab-span" =
style=3D"white-space:pre"><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">	=
</span></font></font></span></span><font class=3D"Apple-style-span" =
face=3D"Arial"><font class=3D"Apple-style-span" size=3D"4"><span =
class=3D"Apple-style-span" style=3D"font-size: 14px;">Excellent =
knowledge of English language (speak, read and write =
fluently).</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;"><br></span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Experience in delay tolerant networking and TCP/IP protocols is =
desirable. The evaluation of all candidates will be based on their =
experience, relevance of studies and research =
accomplishments.</span></font></font></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;"><br></span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><b><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">C. =
CONTRACT</span></font></b></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Salary depends on qualifications. Maximum gross annual salary is =
54.000=E2=82=AC. Accommodation cost in Xanthi is relatively low (for =
example typical two-bedroom apartment costs around =
350=E2=82=AC).</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;"><br></span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><b><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">D. EQUAL =
OPPORTUNITIES</span></font></b></font></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Equal opportunities policy without distinctions (sex, origin, =
religion, disability, age etc) will be =
applied.</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;"><br></span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><b><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">E. REQUIRED =
DOCUMENTATION</span></font></b></font></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Interested applicants should send their curriculum vitae using =
the Europass standard including:</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">- An application =
letter&nbsp;</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">- A research statement</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">- A synopsis of research =
experience&nbsp;</span></font></font></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">- A list of publications&nbsp;</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">- The names of three =
referees</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">by e-mail to </span></font></font><span style=3D"color: =
#0c00ff"><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;"><a =
href=3D"mailto:[email-masked]">[email-masked]</a></span></font><=
/font></span><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">.&nbsp;</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;"><br></span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">Please use the following reference in the =
subject: SPICE_RESEARCHERS_2010. Please note that an acknowledgement =
e-mail will be sent upon receipt of each application within 3 working =
days.</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;"><br></span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">An interview may be asked by the Project Coordinator, in case =
this is deemed necessary. Selected candidates should =
provide:</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><span style=3D"font: =
9.0px Wingdings"><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">=EF=81=AE </span></font></font></span><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Original documents (or official translations) of =
Degrees</span></font></font></div><div style=3D"margin-top: 0px; =
margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: normal =
normal normal 12px/normal 'Times New Roman'; "><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal 'Times New Roman'; "><span style=3D"font:=
 9.0px Wingdings"><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">=EF=81=AE </span></font></font></span><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Original documents (or official translations) of working =
experience certificates&nbsp;</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><span style=3D"font: 9.0px Wingdings"><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">=EF=81=AE </span></font></font></span><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Three letters of reference.</span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;"><br></span></font></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><b><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">F. DEADLINE OF =
SUBMISSION</span></font></b><font class=3D"Apple-style-span" =
size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 14px;"> =
Initial deadline for receipt of e-mail: </span></font><b><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">27/01/2011</span></font></b></font></div><div =
style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; font: normal normal normal 12px/normal 'Times New =
Roman'; "><font class=3D"Apple-style-span" face=3D"Arial"><font =
class=3D"Apple-style-span" size=3D"4"><span class=3D"Apple-style-span" =
style=3D"font-size: 14px;">However applications will be accepted until =
position is filled.</span></font></font></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" face=3D"Arial"><font class=3D"Apple-style-span"=
 size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: =
14px;">Candidates will be evaluated based on their qualification by a =
Scientific Committee.</span></font></font></div><div style=3D"margin-top: =
0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; font: =
normal normal normal 12px/normal 'Times New Roman'; "><font =
class=3D"Apple-style-span" =
face=3D"Arial"><br></font></div></div></div></body></html>=

--Apple-Mail-2--698305278--

Sender: [email-masked]
Date: Tue, 18 Jan 2011 13:31:11 -0500
From: Mostafa Ammar <[email-masked]>
To: [email-masked]
Subject: [dtn-interest] Paper on mobile network connectivity in SIGCOMM CCR

 We recently published a paper on "A Framework for Characterizing the
Wireless and Mobile Network Continuum" in SIGCOMM CCR.
The paper formalizes notions of connectivity in wireless and mobile
networks -- something that has been discussed on this list in the
past.

 You can find the paper at
http://ccr.sigcomm.org/online/?q=node/725

Mostafa
-- 
Mostafa Ammar
Regents' Professor
School of Computer Science
Georgia Institute of Technology

Date: Mon, 10 Jan 2011 15:02:59 +0100 (CET)
From: "Valerio Arnaboldi" <[email-masked]>
To: [email-masked]
Importance: Normal
Subject: [dtn-interest] [IEEE AOC 2011 - WoWMoM Workshop]: Call for Papers

--------------------------------------------------------------------------------
                               CALL FOR PAPERS
                        Fifth IEEE WoWMoM Workshop on
             Autonomic and Opportunistic Communications (AOC 2011)
                        June 20-24, 2011 - Lucca (Italy)
                        http://cnd.iit.cnr.it/aoc2011/

                           jointly supported by the

                             SOCIALNETS project
                  funded by the FET-IST Programme under the
           FET proactive initiative on Pervasive Adaptation (PerAda)
                         http://www.social-nets.eu

                                   and
                              SCAMPI project
                  funded by the FP7-ICT Programme under the
         Future Internet Research and Experimentation (FIRE) initiative
                         http://www.ict-scampi.eu/

                 Fast Track on Computer Communication Journal
                   http://www.elsevier.com/locate/comcom

             **** Submission Deadline --- January 31, 2011 ****
--------------------------------------------------------------------------------

The diffusion  of lightweight, powerful  portable devices, also enriched  with a
variety of sensing capabilities, is  enabling new ways for users to communicate,
and is  laying the  foundation for  the ubiquitous networking  idea to  become a
reality.  Risen from the ashes of  traditional MANETs, which failed to cope with
the variability  of a  network solely made  up from mobile  users, opportunistic
communications have recently  stood out and gained a  lot of research attention.
Opportunistic networking is the enabling strategy for communications in a mobile
network.  The  idea of  opportunistically exploiting extemporary  contacts among
the  users  of the  network  poses  new and  challenging  problems,  as well  as
providing  with novel and  promising opportunities,  to the  networking research
community.  The AOC 2011 workshop will  be a meeting point for people working in
the area  and it will constitute  a forum to exchange  ideas, discuss solutions,
and  share   experiences  among  researchers,   professionals,  and  application
developers, both from industry and academia.   The AOC 2011 workshop will have a
primary  interest   in  the  new  directions   of  opportunistic  communications
represented  by  mobile   social  networking,  content-centric  networking,  and
participatory  sensing.  More  in  general, papers  tackling  issues related  to
opportunistic networking and computing  are welcome.  Original papers addressing
both  theoretical   and  practical   aspects  of  autonomic   and  opportunistic
communications   are  solicited,   as  well   as  papers   describing  prototype
implementations and deployments.

Topics of interest include but are not limited to:

*  Architectures and models for autonomic and opportunistic communications
*  Advanced  technologies  for  enabling  autonomic  and  opportunistic
   communications
*  Tools and techniques for designing, analysing and building autonomic and
   opportunistic networks
*  Scaling laws and fundamental limits in autonomic and opportunistic
   communications
*  Performance modeling of autonomic and opportunistic communications
*  Autonomic and opportunistic communication testbeds and measurements
*  Algorithms, models, and architectures for opportunistic computing
*  Mechanisms, algorithms and testbeds for service provisioning in autonomic
   and opportunistic networks
*  Algorithms, models, and architectures for content centric autonomic and
   opportunistic networks
*  Mobile social networking in autonomic and opportunistic communications
*  Participatory and urban sensing in autonomic and opportunistic networks
*  Resource management techniques applied to autonomic and opportunistic
   communications
*  Context and social awareness in autonomic and opportunistic networks
*  Routing, transport, and reliability issues in autonomic and opportunistic
   communications
*  Techniques for data dissemination and replication in autonomic and
   opportunistic networks
*  Applications and middleware support for autonomic and opportunistic
   communications
*  Mobility models and statistical analysis of mobility traces
*  Trust, security, and reputation in autonomic and opportunistic
   communications
*  Socio-economic models for  autonomic and opportunistic communications

PAPER SUBMISSION AND PUBLICATION
--------------------------------

Papers should neither have been published elsewhere  nor being currently under
review  by another conference or journal.  Manuscripts are limited to 6 pages,
single  spacing,  double  column,  and  must  strictly  adhere to the template
format.  Guidelines  on  paper  submission  and  formatting  are available  at
http://cnd.iit.cnr.it/aoc2011/.

Accepted papers will appear in the symposium proceedings published by IEEE. At
least  one author of  each accepted paper  is required to register and present
his/her  work at  the workshop.  There  will be no  separate  registration for
workshop, but one single registration will cover both conference and workshops
participation.

Extended versions  of workshop selected papers will be considered for possible
fast  track publication  on  the  Computer Communications  Journal (Elsevier).

IMPORTANT DATES
---------------
Full papers due:   January 31, 2011
Notification:      March 28, 2011

ORGANIZING COMMITTEE
--------------------

WORKSHOP Chair
  Elena Pagani, Universita' degli Studi di Milano, Italy

WORKSHOP Vice-Chair
  Chiara Boldrini, IIT-CNR, Italy

STEERING Committee
  Marco Conti, IIT-CNR, Italy
  Silvia Giordano, SUPSI, Switzerland
  Ioannis Stavrakakis, University of Athens, Greece

PUBLICITY Chair
  Valerio Arnaboldi, IIT-CNR, Italy

PROGRAM COMMITTEE
-----------------------------

Gergely Acs, BUTE, Hungary
Giuseppe Bianchi, Universita' degli Studi di Roma Tor Vergata, Italy
Eleonora Borgia, IIT-CNR, Italy
Vania Conan, Thales, France
Igor Curcio, Nokia, Finland
Serge Fdida, UPCM Paris VI, France
Sabrina Gaito, Universita' degli Studi di Milano, Italy
Laura Galluccio, University of Catania, Italy
Mario Gerla, UCLA, USA
Philip Ginzboorg, Nokia, Finland
Stratis Ioannidis, Technicolor, France
Merkourios Karaliopoulos, University of Athens, Greece
Mohan Kumar, University of Texas at Arlington, USA
Frack Legendre, ETH Zurich, Switzerland
Daniele Miorandi, Create-net, Italy
Refik Molva, Eurecom, France
Giovanni Neglia, INRIA, France
Konstantinos Oikonomou, Ionian University, Greece
Joerg Ott, HUT, Finland
Andrea Passarella, IIT-CNR, Italy
Konstantinos Psounis, University of Southern California, USA
Daniele Puccinelli, SUPSI, Switzerland
Christian Rohner, Uppsala University, Sweden
Fabrizio Sestini, EU Commission
Abdullatif Shikfa, Alcatel Lucent Bell Labs, France
Thrasyvoulos Spyropoulos, EURECOM, France
Roger Whitaker, Cardiff University, UK
Hongyi Wu, University of Louisiana at Lafayette, USA
Eiko Yoneki, University of Cambridge, UK
Franco Zambonelli, University of Modena-Reggio, Italy
Xiaolan Zhang, Fordham University, USA

==============================================

Valerio Arnaboldi - AOC2011 Publicity Chair

Institute for Informatics and Telematics (IIT)
Italian National Research Council (CNR)
Via G. Moruzzi, 1 - 56124 Pisa, Italy
phone: +39 050 315 2195
email: [email-masked]

From: Elwyn Davies <[email-masked]>
To: Lachlan Andrew <[email-masked]>
Organization: Folly Consulting
Date: Thu, 06 Jan 2011 17:06:26 +0000
Cc: DTN interest <[email-masked]>
Subject: [dtn-interest] [Fwd: Re: IRSG poll for draft-irttf-dtnrg-sdnv: special request]

-------- Forwarded Message --------
> From: Lachlan Andrew <[email-masked]>
> To: Elwyn Davies <[email-masked]>
> Subject: Re: IRSG poll for draft-irttf-dtnrg-sdnv: special request
> Date: Thu, 23 Dec 2010 11:45:11 +1100
> 
> Thanks Elwyn.  I would like to respond to your responses.  Should we
> have this discussion on-list, for the archive?
> 
> Lachlan
> 
> On 23 December 2010 11:39, Elwyn Davies <[email-masked]> wrote:
> > Hi, Lachlan.
> >
> > Thanks for the response.
> >
> > I have had a look at your comments and made various responses below.  I
> > think Wes needs to take a view of whether we should make further
> > changes, but in any case I don't think we need to do a great deal to
> > address your comments.
> >
> > Wes:  what is your view?
> >
> > Happy Christmas.
> >
> > Elwyn
> >
> > On Wed, 2010-12-22 at 15:17 +1100, Lachlan Andrew wrote:
> >> Greetings Elwyn,
> >>
> >> Some comments are attached.  None are major, and if you really want I
> >> can vote "yes" even if you don't address them, but I think they would
> >> improve the RFC.
> >>
> >> Let me know if you don't want to address them.
> >>
> >> Cheers,
> >> Lachlan
> >>
> >> On 15 December 2010 04:35, Elwyn Davies <[email-masked]> wrote:
> >> > Hi, Lachlan.
> >> >
> >> > A long time ago you may remember that you reviewed this document as part
> >> > of the IRTF publication process.  We are still trying to get these DTN
> >> > drafts through the IRSG processes.  I need another formal 'yes' vote in
> >> > the IRSG poll to satisfy the process.. If I understand correctly you
> >> > were happy with the document after various changes were made.  Since
> >> > that time we have added a little more explanation of using SDNVs for bit
> >> > fields to tie in with the IANA registries draft that had to be created
> >> > to deal with various comments we had for other drafts.
> >> >
> >> > So, could I please ask you to send an email with a formal 'yes' to
> >> > publication to the IRSG and dtn-interest lists if you are happy for this
> >> > draft to become an RFC.
> >> >
> >> > Best wishes for the festive season.
> >> >
> >> > Elwyn Davies
> >> > Sheep wrangler and cat herder.
> >> >
> >> >
> >>
> >>
> >>
> >
> >>
> >> In the last paragraph of page 6, it says:
> >>   "The best use of SDNVs may often be to define the
> >>    Length field of a TLV structure to be an SDNV whose value is the
> >>    length of the TLV's Value field.  In this way, one can avoid
> >> forcing
> >>    large numbers from being directly encoded as an SDNV, yet retain
> >> the
> >>    extensibility that using SDNVs grants."
> >> This also incurs overhead, and should only be used when the fields are
> >> expected to be long.  I'd say
> >>   "If the value to be encoded is expected to be large, then it is
> >>    desirable to avoid the overhead of directly coding a large number,
> >>    but to retain the extensibility of using SDNVs.  One possibility is
> >>    to define the Length field of a TLV structure to be an SDNV whose
> >>    value is the length of the TLV's Value field."
> >
> > I believe that the first sentence of the paragraph (before the quoted
> > piece) effectively says that one is talking about large number cases.  I
> > don't think this change adds any value.
> >
> >> Note that this point is also made on page 13.  Is it redundant to say
> >> it
> >> twice.
> > True, but I am relaxed about this - since it is commentary rather than
> > definition I don't think it does any harm to say it twice.
> >
> >>
> >> I'm still uncomfortable with the comment on arbitrary bit-fields,
> >> since
> >> leading zeros cannot be safely encoded.  You might want to say that an
> >> arbitrary bit-field can be encoded by prepending a 1 and then applying
> >> SDNV.
> >
> > I don't follow how it is 'safer' to have the leading zeroes explicitly
> > in the transmitted data rather than implicitly (I assume that is what
> > you are implying).  If you have two interoperating instances of a
> > protocol, they (implicitly) know what the size of the bit field that is
> > SDNV encoded actually is.  If you put an extra delimiting bit into the
> > SDNV you seem to be potentially throwing away any (probably small)
> > efficiency gains from using an SDNV.  Combining these two points and
> > assuming that the transmission is over a transmission medium that
> > detects bit corruptions, I am think this suggestion doesn't help. (one
> > has to say that for production protocols (as opposed to experimental
> > ones where adding new flags might be useful) the gains from using SDNVs
> > seem fairly minimal - but we have them in DTN.
> >>
> >> In the last paragraph of page 6, perhaps change "the current SDNV"
> >> to "the SDNV described in this document".  Since it is a criticism of
> >> the current scheme, it sounds like it is the prior state of the art,
> >> which this RFC tries to improve on.
> >
> > OK
> >
> >>
> >> In "floor(log n)" and "(8/7 log n)", I'd keep your old wording:
> >>    "floor(log_2 n)" and "(8/7 log_2 n)".
> >> It is only inside the "O(...)" that the base should be omitted.
> >
> > That seems sensible.
> >
> >>
> >> Sections 3.1 and 3.2 seem to suggest an asymmetry between the problem
> >> of
> >> not knowing the output length when encoding and decoding.  In both
> >> cases,
> >> the size of the output is not known until the entire input has been
> >> read
> >> in (unless you assume the input to encoding is stored in a format like
> >> TLV), but in both cases, it a single pass of the input can tell you
> >> the
> >> size of the output.
> >
> > In general you do know the size of the item you are encoding - you
> > aren't usually deserializing it.  The point that is being made is that
> > you can preallocate the output buffer in the encoding case and dump the
> > output direct into the target octets, so no shifting is needed.  In the
> > decoding case you generally would be deserializing and (particularly if
> > you were hoping for hardware assistance) you would have to do a
> > multi-octet shift as the octets came off the wire in the general case
> > which is not very efficient.  So yes there *is* generally an asymmetry
> > between the two cases.  I think it is clear what is meant and doesn't
> > need any improvement.
> >>
> >>
> >> I'm still surprised that there is no mention of Elias coding, which is
> >> extremely similar.
> >
> > I would beg to differ.  The various forms of Elias coding make rather
> > different assumptions about the distribution of the values to be
> > encoded.  SDNVs are actually an incarnation of Variable Byte Coding or
> > Comma Coding.  I think that bringing Elias Coding into the document
> > would be distracting.
> >>
> >>
> >
> >
> 
> 
> 

Date: Wed, 5 Jan 2011 17:54:08 +0100
From: Anders Lindgren <[email-masked]>
To: dtn-interest <[email-masked]>
Cc: Pan Hui <[email-masked]>
Subject: [dtn-interest] =?windows-1252?q?CCR_paper=3A_=22ExtremeCom_=96_To?= =?windows-1252?q?_Boldly_Go_Where_No_One_Has_Gone_Before=22?=

Hi all,

For those of you interested, there is now a paper available in the
latest issue of CCR talking about the ExtremeCom series of workshops,
the background and motivation behind the workshop, and the lessons
learned from it.
It is available online at http://ccr.sigcomm.org/online/?q=node/718

Cheers,

/Anders and Ben