 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
| All, On October 22 we asked the WG, via autoconf at ietf.org, on advice on how to best make progress. Specifically, the question was: That said, we (and, this we is also the chairs) will take this opportunity to ask the WGs opinion on how to progress. If you have any opinion, please let it be known to the WG (via this mailing list) before 29/10/09 (i.e. Thursday next week) at noon CET. Please be specific and constructive, i.e., pick one of: o if you think that the WG should proceed with draft-ietf-autoconf-adhoc-addr-model as a baseline, say so! o if you think there're cardinal (but fixable) issues missing or wrong with draft-ietf-autoconf-adhoc-addr-model, then let the WG know what these issues are, and propose a solution before the deadline. The Editors will certainly do their best to address the issues. o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond hope, let the WG know explicitly how you suggest that we progress at this point -- considering the current timeline!! About 20 or so responded to this question, with roughly 70% of the respondents supporting proceeding with draft-ietf-autoconf-adhoc-addr-model as baseline for future progress. We therefore observe that: o There's CONSENSUS for continuing with draft-ietf-autoconf-adhoc-addr-model as a BASELINE for future progress. The key word in the above is "BASELINE". During the discussions on the list in the past 3 weeks or so, a couple of issues were raised that need to be duly addressed, by inclusion in the document or by discussion and consensus to not include. We're trying to summarize those issues below: o Link Local Addresses - As a reminder, after Stockholm, consensus was established to NOT have [autoconf] configure Link Local Addresses, and to encourage that other addresses, which [autoconf] should develop methods for obtaining and ensure properties of, be used. In draft-ietf-autoconf-adhoc-addr-model, this is reflected by stating that in MANETs, Link Local Addresses are "discouraged". This phrasing has on the list been suggested inappropriate, we should consider alternatives. Below, an extract of that which was the essence of that discussion in Stockholm. The objective was to state that as [autoconf] does not do anything to generate and preserve properties of Link Local addresses, for the network parts where [autoconf] is applicable, it is recommended to in these parts of the network use addresses which [autoconf] *does* generate and ensure properties of. In other words: "no guarantees are made by [autoconf] for LL addresses, so using those may break stuff. Use at your own risk. We RECOMMEND using other addresses with properties ensured by [autoconf]" - Issues which were brought up include (i) if LL addresses generated from MAC addresses are "unique enough", (ii) compatibility with other protocols which stipulate the use of LL address. and (iii) the definition of DAD as given in RFC4862 o Interface Definition / Description - As a reminder, prior to our past rechartering, we went through a large effort in trying to describe "MANET Interfaces", and fell short of the goal of doing so satisfactory. The rechartering was, in part, done with a recognition of this fact, and re-scoped [autoconf] to consider *a* addressing model for which there's an existence proof that it works. In draft-ietf-autoconf-adhoc-addr-model, this is reflected by stating "undefined connectivity properties". This phrasing has on the list been suggested insufficient. We should therefore consider alternatives/expansion of the phrasing hereof - but, we insist, avoid going back down the rathole of trying to produce an "interface model" or "link model". We're not chartered to do that, and past efforts have shown that to be a difficult task to do (especially on a short timescale) The authors of the (now expired) I-D, draft-baccelli-multi-hop-wireless-communication have kindly accepted to launch these discussions by a presentation in Hiroshima. o Prefix lengths on the interfaces that [autoconf] is concerned with - As a reminder, there has (long ago, even before the rechartering) been consensus on the use of /32 and /128 prefix lengths for *these* interfaces. There are ways of using shorter prefixes, but again, the re-chartering had as premiss to scope [autoconf] to consider *a* addressing model for which there is an existence proof that it works. In draft-ietf-autoconf-adhoc-addr-model, this is reflected in section 4 (the justification) and in section 6 (the recommendation - a "should" for /32 and /128). We should therefore consider if there's a need for further explanation (section 4) for this recommendation, as well as verify and handle any potential conflicts with RFC4291 (if any). We plan to discuss these in Hiroshima, and to issue consensus calls shortly after the [autoconf] session in Hiroshima has concluded and minutes have been posted. The objective is closing these issues quickly. We will want to establish consensus on these issues such that draft-ietf-autoconf-adhoc-addr-model can be considered "done", come early December. The meeting agenda is online at http://www.ietf.org/proceedings/09nov/agenda/autoconf.txt See y'all in the land of Sake and Sushi, Ryuji & Thomas |