Hi, Petri Jokela wrote:
On 20.7.2009, at 12.33, Gonzalo Camarillo wrote:Folks, 1) We have the following milestone: "Specify a framework to build HIP-based overlays. This framework will...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.txtAdditionally, 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.The proposal sounds reasonable, taking also into account the discussion that has been going on in another thread.
+1
2) We have the following milestone:...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.txtFor me, this sounds good. As in the previous case, taking into account also the ongoing discussion on the related thread.
+1 and the concerns raised before IETF 75 are addressed in the -03 draft and some new that came up during IETF 75 will be addressed in -04
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.txtThis sounds ok.
+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.While there is no activity, it seems reasonable to remove it now.
Ok! Jan