[Autoconf] Consensus Call Summary & Plan Forward

[Thomas Heide Clausen <[e-mail]>]

All,

On October 22 we asked the WG, via [e-mail], 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