Re: [Hipsec] Overlay work: status and request for input

Miika Komu wrote:

Hi,

sorry, I missed one. +1 for hiccups too.

> Gonzalo Camarillo wrote:
> 
> Hi,
> 
>> Folks,
>>
>> here you have a summary of the status of the overlay work.
>> Additionally, we have some questions for the WG related to our
>> milestones and their related charter items. Your input on those
>> questions is very welcome.
>>
>> 1) We have the following milestone:
>>
>> "Specify a framework to build HIP-based overlays. This framework will
>> describe how HIP can perform some of the tasks needed to build an
>> overlay and how technologies developed somewhere else (e.g., a peer
>> protocol developed in the P2PSIP WG) can complement HIP by performing
>> the tasks HIP was not designed to perform."
>>
>> The WG item for this milestone is the following draft, which should be
>> ready for WGLC:
>>
>> http://tools.ietf.org/id/draft-ietf-hip-bone-02.txt
>>
>> This draft defines a high-level framework to build HIP-based overlays.
>> Additionally, its previous version defined how to build a HIP-based
>> overlay using RELOAD. The authors have chosen to move this definition to
>> a separate document because while the high-level framework is
>> informational in nature, the definition makes use of normative language.
>> The resulting document is the draft below. We would like to ask the WG
>> if it is OK to split our current milestone in two so that they cover the
>> high-level framework and the definition in separate documents.
>>
>> http://tools.ietf.org/internet-drafts/draft-keranen-hip-reload-instance-00.txt 
>>
>>
>> Additionally, we would like to ask the WG if we should take the draft
>> above as the WG item associated to the milestone for the definition.
> 
> +1
> 
>> 2) We have the following milestone:
>>
>> "Specify how to carry upper-layer data over specified HIP
>> packets. These include some of the existing HIP packets and possibly
>> new HIP packets (e.g., a HIP packet that occurs outside a HIP base
>> exchange)."
>>
>> We still do not have a WG item for it but the following draft has been
>> around for some time. We would like to ask the WG if we should adopt the
>> following draft as the WG item for this milestone.
>>
>> http://tools.ietf.org/internet-drafts/draft-nikander-hip-hiccups-02.txt
>>
>> Revision 02 of the draft above is identical to 01 (the only changes are
>> the date and the new copyright). The authors intend to address the
>> comments received on the list shortly.
>>
>> 3) In order to be able to support the functionality provided by RELOAD,
>> HIP needs to support multi-hop routing. Instead of specifying it in the
>> HIP BONE draft, having a separate draft seem to make more sense given
>> that this functionality has a more general applicability than overlays.
>> We would like to ask the WG if we should spin off a new milestone from
>> our original milestone for overlays that covers multihop routing in HIP.
>>
>> The following draft takes a stab at specifying multihop routing in HIP.
>> We would like to ask the WG if we should adopt it as a WG item for the
>> milestone above (assuming we decide to create the milestone).
>>
>> http://tools.ietf.org/internet-drafts/draft-camarillo-hip-via-00.txt
> 
> +1
> 
>> 4) We have the following milestone:
>>
>> "Specify how to generate ORCHIDs from other node identifiers
>> including both cryptographic ones (leading to cryptographic
>> delegation) and non-cryptographic ones (e.g., identifiers defined by a
>> peer protocol)."
>>
>> When we created that milestone, we expected to have a generic mechanism
>> to transform node IDs into ORCHIDs. However, at this point, it seems
>> that such transformation will be done in different ways depending on the
>> peer protocol used in a particular overlay. For example, the instance
>> specification for RELOAD draft defines such transformation for RELOAD
>> peer identifiers. The fact that nobody has submitted a draft for that
>> milestone seems to confirm the previous impression. We would like to ask
>> the WG if we should remove that milestone from our charter.
> 
> Fine by me.
> _______________________________________________
> Hipsec mailing list
> Hipsec@ietf.org
> https://www.ietf.org/mailman/listinfo/hipsec