Subject: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 22 Oct 2009 01:49:30 +0200

All,

It appeared to the chairs that the comments raised at the Stockholm  
IETF, as well as on the list subsequently, concerning the document:

		http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model

had been addressed fully by the editors, and to the WGs satisfaction -  
at least, there were no issue raised to the latter/latest version  
hereof. The chairs therefore found it a good idea to move the document  
forward as a WG document, and progress this document as such. We  
therefore approved for publication:

		http://tools.ietf.org/html/draft-ietf-autoconf-adhoc-addr-model

We (the chairs)  still believe that this is the proper approach in  
order to make progress for the WG.

Do note that the WG is 7 months past the milestone for initial  
document submission, and 1 month past the milestone for having  
progressed the document to the IESG and/or closed up shop!  And, there  
has been no discussions (in meetings or on this list) on alternative  
candidate documents for the work item which [autoconf] is chartered to  
accomplish.

To put it bluntly, this WG is far far behind schedule and this  
document seemed, and still seems, by virtue of having been widely  
discussed and agreed upon, as the best shot at making progress for  
this WG.

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!!

Cheers,

Ryuji & Thomas

---

From: sratliff <[email-masked]>
Date: Wed, 21 Oct 2009 20:24:49 -0400

Thomas, 

I think the document is fine, and that we should proceed. I have no problems
with the change from ³draft-bacelli² to ³draft-ietf-autoconf² -- from what I
remember, the WG had expressed interest in pursuing the issue, and I don¹t
think I¹ve seen any alternatives offered in a while.

As you eloquently state, this working group is (yet again) behind schedule,
on the one-and-only deliverable. Frankly, if we¹re going to engage in a
protracted discussion of the minutiae of whether or not this should be
³draft-bacelli² vs. ³draft-ietf-autoconf², it¹s time to pull the plug on
this WG, and put all of us out of our misery.

Regards,
Stan

On 10/21/09 7:49 PM, "Thomas Heide Clausen" <[email-masked]> wrote:

> All,
> 
> It appeared to the chairs that the comments raised at the Stockholm IETF, as
> well as on the list subsequently, concerning the document:
> 
>  <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model>
> <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model>
> had been addressed fully by the editors, and to the WGs satisfaction - at
> least, there were no issue raised to the latter/latest version hereof. The
> chairs therefore found it a good idea to move the document forward as a WG
> document, and progress this document as such. We therefore approved for
> publication:
> 
> We (the chairs)  still believe that this is the proper approach in order to
> make progress for the WG.
> 
> Do note that the WG is 7 months past the milestone for initial document
> submission, and 1 month past the milestone for having progressed the document
> to the IESG and/or closed up shop!  And, there has been no discussions (in
> meetings or on this list) on alternative candidate documents for the work item
> which [autoconf] is chartered to accomplish.
> 
> To put it bluntly, this WG is far far behind schedule and this document
> seemed, and still seems, by virtue of having been widely discussed and agreed
> upon, as the best shot at making progress for this WG.
> 
> 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
> 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 --
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 21 Oct 2009 21:00:41 -0700

Hello folks,

I think that the WG should proceed 
with draft-ietf-autoconf-adhoc-addr-model as a baseline.

Regards,
Charlie P.

Thomas Heide Clausen wrote:
> o if you think that the WG should proceed 
> with draft-ietf-autoconf-adhoc-addr-model
> as a baseline, say so! 
>
> ------------------------------------------------------------------------
>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 22 Oct 2009 10:21:42 +0200

On Thu, Oct 22, 2009 at 6:00 AM, Charles E. Perkins <
[email-masked]> wrote:

> I think that the WG should proceed with
> draft-ietf-autoconf-adhoc-addr-model as a baseline.
>

Me too.

Ulrich

>> It appeared to the chairs that the comments raised at the Stockholm IETF,
>> as well as on the list subsequently, concerning the document:
>>
>> We (the chairs)  still believe that this is the proper approach in order
>> to make progress for the WG.
>>
>> submission, and 1 month past the milestone for having progressed the
>> document to the IESG and/or closed up shop!  And, there has been no
>> discussions (in meetings or on this list) on alternative candidate documents
>> for the work item which [autoconf] is chartered to accomplish.
>> seemed, and still seems, by virtue of having been widely discussed and
>> agreed upon, as the best shot at making progress for this WG.
>>
>> 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 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.
>>
>> let the WG know explicitly how you suggest that we progress  at this point
>> --  considering the current timeline!!
>>
>> Cheers,
>>
>> Ryuji & Thomas

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 22 Oct 2009 18:03:16 +0200

Hi Thomas,

	My individual and personal opinion -- also biased, since I'm
co-authoring draft-bernardos-autoconf-addressing-model-00 (btw, we plan
to submit a  -01 before the cutoff deadline) -- is that since we now
have one alternative candidate document for the work item which
[autoconf] is chartered to accomplish (when we were working on it we
didn't know there was already a WG document on this charter item), we
may consider as WG our document as input as well. Then, we may have at
least some discussion (on the ML -- please wait until we release -01 if
you don't mind) and in Hiroshima (if we can present our draft) and then
make a similar call as you did below, potentially considering somehow
also the input that draft-bernardos-autoconf-addressing-model may bring
(if the WG considers there is any).

	I know that we are late, we have been unfortunately always late in this
WG (I participated in the BOF in 2005 and kept on contributing somehow
since then, and still we haven't achieved any milestone, more than 4
years later). But still, I don't see this as a valid reason for taking
decisions in a hurry (such as adopting WG documents without asking the
WG), and I honestly think it would be good for the WG to have the chance
to have some discussion on our draft and then come up with the best
possible input that the WG can produce.

	Just my -- unavoidable (although I fought not to be) biased -- opinion
on this.

	Thanks,

	Carlos

On Thu, 2009-10-22 at 01:49 +0200, Thomas Heide Clausen wrote:
> with 
-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 23 Oct 2009 12:45:05 +0200

Hi Ryuji, Thomas,

>	as a baseline, say so! 

I am neutral on this.

I think my comments on earlier versions are not well incorporated and the 
document misses essential elements for a practical addressing scheme for 
MANETs, such as global addresses and usage of ULAs. I think the recently 
published "bernardos alternative" is more complete and also better specifies
LL usage. 

I prefer not extending useless discussions on LLs, but careful wording for
it.

with 
>	will certainly do their best to address the issues.

I posted this already. 
http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html
http://www.ietf.org/mail-archive/web/autoconf/current/msg01830.html
I do not understand why text is not corrected yet.

hope, 
> 	considering the current timeline!!

After 3 months, we have a new version with only small updates (enhancements
or 
wrong text, make your choice). I think this progress is extremely
disappointing. 
Or "beyond hope".

A question on procedure: can we decide to swap the content of 
draft-ietf-autoconf-adhoc-addr-model, e.g. a new version with content of 
draft-bernardos-autoconf-addressing-model or a merger of those?

Anyway, we have more progress than listed on the Autoconf page: we have
completed our fourth goal: there is a initial draft on addressing model 
in ad hoc networks. And we might not be that far away from our last
milestone. 

Regards, Teco

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 23 Oct 2009 12:51:17 +0200

> draft-bernardos-autoconf-addressing-model or a merger of those?

This is something I tend to agree to.  I am suggesting the same thing: 
copy relevant things from draft-bernardos and paste on the WG item document.

Of course, it depends how this is done, but it is a good direction IMHO.

Alex

---

From: HyungJin Lim <[email-masked]>
Date: Fri, 23 Oct 2009 22:56:55 +0900

Hi,

This is Hyung-Jin Lim.
I am still reading AUTOCONF mailing lists.

I also agree to Teco's suggestion totally.
Thanks.
2009/10/23 Alexandru Petrescu <[email-masked]>

>>> wrong
>>>        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.
>>>
>>
>> I posted this already.
>>> this
>> point --
>> or wrong text, make your choice). I think this progress is extremely
>> disappointing. Or "beyond hope".
>>
>>
> This is something I tend to agree to.  I am suggesting the same thing: copy
> relevant things from draft-bernardos and paste on the WG item document.
>
>> completed our fourth goal: there is a initial draft on addressing model in
>> ad hoc networks. And we might not be that far away from our last
>> milestone.
>>
>> Regards, Teco
>>
>>
>>
>>
>>
>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 23 Oct 2009 16:10:15 +0200

<SNIP>

> draft-bernardos-autoconf-addressing-model or a merger of those?

Constructive proposals for improvement to documents should *always* be  
very welcome, especially if they're concrete such as proposed text.

I can only encourage that you [the plural version of "you"] propose  
such text on the list, and that we all discuss it -- then decide how  
to progress with it?

I know that you [ Teco ]  have made proposals in the past. I must  
admit that I do not recall to which extend exactly these were  
reflected in the text. Would you be able to restate your proposals as  
"text to insert into the I-D at a specific place, possibly replacing  
something existing", in a separate thread on the list? We can then all  
discuss them and, if the outcome is that we agree on inclusion,  
together whip the editors to incorporate them?

Thanks,

Thomas

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 02:23:29 -0700

Hi Carlos,

Thanks for the draft and your suggestion. we haven't seen your draft  
before publishing draft-ietf doc.
Anyway, you can discuss your draft on the list, but let us postpone  
the decision.
I want to complete this consensus call first.
We still have dates to Hiroshima and want to see more opinions from WG.
I saw Alex, Teco supporting your document.

My concern is that we finished consensus call for LL address treatment  
and agreed the texts.
We should not step back and bring new discussion on this thread.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 24 Oct 2009 11:35:00 +0200

Ryuji Wakikawa a écrit :
> Anyway, you can discuss your draft on the list, but let us postpone the 
> decision.

There is also HyungJin having expressed support.

Alex

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 24 Oct 2009 02:36:50 -0700

> There is also HyungJin having expressed support.

I missed his email. Yes, we now have 4 people including Carlos.

regards,
ryuji

>
> Alex
>
>>
>> My concern is that we finished consensus call for LL address treatment and
>> agreed the texts.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 27 Oct 2009 23:38:32 -0700

Hi all,

Reminder, we currently solicit your opinion.
The deadline is Thursday. We only have few reply from WG.

thanks
ryuji

On 2009/10/21, at 16:49, Thomas Heide Clausen wrote:

> had been addressed fully by the editors, and to the WGs satisfaction  
> - at least, there were no issue raised to the latter/latest version  
> hereof. The chairs therefore found it a good idea to move the  
> document forward as a WG document, and progress this document as  
> such. We therefore approved for publication:
>
> progressed the document to the IESG and/or closed up shop!  And,  
> there has been no discussions (in meetings or on this list) on  
> alternative candidate documents for the work item which [autoconf]  
> is chartered to accomplish.
>
> 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:
>

---

From: mase <[email-masked]>
Date: Wed, 28 Oct 2009 15:50:06 +0900

Fine with me.

Regards.
Kenichi

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 28 Oct 2009 08:09:20 +0100

I guess it's hardly a surprise that I also support this document as  
baseline..

Thomas

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 28 Oct 2009 09:23:41 +0100

I suppose I should also mention I support draft-ietf-autoconf-
adhoc-addr-model as baseline.
Emmanuel

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 09:59:17 +0100

> The deadline is Thursday. We only have few reply from WG.

Ryuji - how can you ask opinion on something you've already done?

This draft _is_ a WG item.

It's called draft-ietf-autoconf-adhoc-addr-model

I propose you first retire it.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 02:23:08 -0700

Hello Alex,

> I propose you first retire it.

There is no procedure for "retiring" a draft.

This seems like obstructionism to me.

The chairs thought there was enough consensus to adopt the
draft and get moving.  There were objections.  The chairs now,
it seems to me, are asking to verify whether there is enough
consensus to confirm the adoption of the draft.

What's so hard about that?

Regards,
Charlie P.

---

From: Hajime Tazaki<[email-masked]>
Date: Wed, 28 Oct 2009 10:11:59 +0000

Hi Chairs,

I also support this draft as a baseline.

regards,
hajime

At Tue, 27 Oct 2009 23:38:32 -0700,

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 11:12:34 +0100

> There is no procedure for "retiring" a draft.

Yes, I believe so.  I think we may need to propose one.

Our Chairs and DT have brought us to a situation unseen before: ask for 
consensus _after_ having supposed that consensus existed, and _after_ 
having acted as if that consensus existed - they submitted and approved 
submission of a WG item.

If we realize that was wrong, then we need a procedure to deal with 
that.  Ideas feel free to  express how to deal with it.

Maybe a new option at tools.ietf.org?

> This seems like obstructionism to me.

No, not obstructionism - realism.

I can also call your action of submitting without WG approval as 
non-legitimacy, but I won't go that far.

> What's so hard about that?

Charles - that is your interpretation.

I have never seen any other time where people submit WG items before 
having consensus on the WG.

Have you seen?

Alex

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Oct 2009 13:20:56 +0200

I would also like to see the document adopted by the WG.

I have read the document today and I'm quite happy with the contents.

Jari

Emmanuel Baccelli wrote:
> On Wed, Oct 28, 2009 at 8:09 AM, Thomas Heide Clausen 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I guess it's hardly a surprise that I also support this document
>     as baseline..
>
>     Thomas
>
>
>             draft-ietf-autoconf- adhoc-addr-model
>                                   as a baseline, say so!
>
>
>
>
>     [email-masked] <mailto:[email-masked]>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 28 Oct 2009 12:37:00 +0100

Hi Jari,

	did you have the chance to take a look at
draft-bernardos-autoconf-addressing-model-01.txt? Your feedback would be
highly appreciated.

	Thanks,

	Carlos

---

From: Juan Antonio Cordero Fuertes <[email-masked]>
Date: Wed, 28 Oct 2009 12:40:04 +0100

Having read the draft and tried to follow (with partial success...) the
whole discussion, it seems to me that the proposed document is a quite
reasonable approach to begin with, in particular considering the need of
abstraction and the huge diversity of MANET-like situations to deal with; so
I also support the adoption as WG document.

Regards,

Juan Antonio Cordero

2009/10/28 Jari Arkko <[email-masked]>

>> adhoc-addr-model as baseline. Emmanuel
>>
>> [email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Cedric Adjih <[email-masked]>
Date: Wed, 28 Oct 2009 13:11:44 +0100

My opinion is that the WG should proceed with
draft-ietf-autoconf-adhoc-addr-model as a baseline.

-- Cedric

---

From: Jari Arkko <[email-masked]>
Date: Wed, 28 Oct 2009 14:13:55 +0200

Carlos,

> draft-bernardos-autoconf-addressing-model-01.txt? Your feedback would be

I had not read it before, but I did read (quickly) now.

Its well written and I saw no major problems. If I compare your draft to 
the DT draft, yours is attempting to cover a more general case, allowing 
for different prefix lengths, etc. For what it is worth, my goals for 
the working group document were that it would be very specific, provide 
a concrete and workable configuration model and avoid saying something 
that might be ripped to pieces on closer analysis by some non-AUTOCONF 
folk. For these goals, the DT document is a pretty perfect match. I 
still prefer to adopt the DT document for the WG document.

Jari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 28 Oct 2009 13:29:28 +0100

Hi Jari,

> still prefer to adopt the DT document for the WG document.

Thanks for your feedback. My fear/concerns with draft-baccelli is that
exactly that, it is too much specific, IMHO. We can risk ending up with
a practical model that is impractical because restricts too much the
things that can be done (no LLs -- this might avoid many protocols to be
run in MANETs -- only /128s and /32s, etc).

Thanks,

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 13:49:46 +0100

Jari Arkko a écrit :
>> draft-bernardos-autoconf-addressing-model-01.txt? Your feedback
>> would be highly appreciated.
>> 
> 
> Its well written and I saw no major problems. If I compare your draft
> to the DT draft, yours is attempting to cover a more general case,
> allowing for different prefix lengths, etc. For what it is worth, my
> goals for the working group document were that it would be very
> specific,

Let me assure you that it is not specific at all - it deals with unknown
  network environments.

> provide a concrete and workable configuration model and avoid saying
> something that might be ripped to pieces on closer analysis by some
> non-AUTOCONF folk. For these goals, the DT document is a pretty
> perfect match. I still prefer to adopt the DT document for the WG
> document.

Jari - I fully disagree with that preference.

The bernardos document is more inline with what I think about link-local
addresses.  I prefer the bernardos document.

Alex

> 
> Jari
> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 08:51:22 -0700

Hello Alex,

> Yes, I believe so.  I think we may need to propose one.

That would be in a different group, concerned with
process details.

>
> Our Chairs and DT have brought us to a situation unseen before: ask 
> for consensus _after_ having supposed that consensus existed, and 
> _after_ having acted as if that consensus existed - they submitted and 
> approved submission of a WG item.

Or, more likely, they gauged consensus based on their
reading of the megabytes of discussion on the list.

> that.  Ideas feel free to  express how to deal with it.

My suggestion would be to ask your contacts on the IESG
about which working group would be appropriate for this
work.

> No, not obstructionism - realism.

I'm a realist.  I don't perceive your characterizations
as realistic.

> non-legitimacy, but I won't go that far.

You can call my action anything you want, but I had
no role in the decision to accept that document as
a WG item.

> Charles - that is your interpretation.

To use your words, my description is realism.

> having consensus on the WG.

You might want to check on that.

The process for adopting WG items has by no means
always been so nitpicky as you seem to suggest.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 17:21:23 +0100

Hi Charles,

I think you're right about new processes being discussed elsewhere in 
other WGs.

Existing process could be discussed here though, I believe.

[...]
> My suggestion would be to ask your contacts on the IESG about which
> working group would be appropriate for this work.

Hmmm... let me think... who do I know in IESG...

Otherwise, let's see what we can do process-wise here in AUTOCONF.

How about asking the Chairs to ask the Group to send their requests for
agenda items soon?

This is also a sort of process, or ways I see happening already in
many WGs, and not in AUTOCONF :-(

If we do that agenda stuff now, then there'll be less surprise later 
during the meeting.

Or you prefer to be surprised?

[...]

>> I have never seen any other time where people submit WG items
>> before having consensus on the WG.
> 

Well I checked recently 6MAN, NETEXT, MEXT, ROLL, 6LoWPAN - the 5 had 
calls for WG item adoption.  Often there was call for adoption of the DT 
output too.

> The process for adopting WG items has by no means always been so
> nitpicky as you seem to suggest.

Hmmm... I am curious about the WGs where WG item adoption isn't usually 
happening with a call - please enlighten.

I am not nitpickying sorry.  I have already discussed twice offline with 
somebody else surprised how we don't see agenda, no item adoption call, 
on this WG.

Let alone the non-use of the issue tracker.

You might find all those to be obstacles to finishing the DT draft, I 
know - ok.  I personally can not go any further without such processes.

Let us finish here about process and say we don't agree.  I will read 
your post about this, but not reply unless you ask me explicitely to reply.

Alex

> Regards, Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 09:29:22 -0700

Hello Alex,

> Hmmm... let me think... who do I know in IESG...

They have colorful dots and love to spend time on process
details :-)

> Otherwise, let's see what we can do process-wise here in AUTOCONF.

Indeed.  I'd suggest promulgating the draft after verifying
consensus.

> How about asking the Chairs to ask the Group to send their requests for

I thought that was already done, at your instigation.

> many WGs, and not in AUTOCONF :-(

Yes, I see many working groups making progress.

> Or you prefer to be surprised?

I'm already surprised, but of course setting the agenda
soon would be a good idea.  And in other emails I see
that some agenda topics were identified.

> calls for WG item adoption.  Often there was call for adoption of the 
> DT output too.

I think Jari Arkko had email relevant to this topic.

>
>
> I am not nitpickying sorry.  I have already discussed twice offline 
> with somebody else surprised how we don't see agenda, no item adoption 
> call, on this WG.
>

This is a good point.  The issue tracker is terribly underutilized
in most working groups, as I found out to my surprise when I
was trying to learn to use it.

Regards,
Charlie P.

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 28 Oct 2009 11:59:28 -0700

Hi Alex,

There is a case to adapt a DT document in WG without adaption call.
Did you remember we had an adaption call for NEMO-BS?
The PMIP IPv4 support doc was published as a WG doc from the  
beginning, because the NETLMM WG formed DT.

In AUTOCONF WG, we have decided to publish the first DT doc as an  
individual document.
After 6 months, authors reflects WG agreement to the document (well  
maybe not your opinion though).
I am not repeating the same reasons why we adapt this doc here again.  
You can refer to other mails from us.

anyway, the adaption call is still open.
We cannot retire the WG doc, but we can replace it if that is the WG  
consensus.

regards,
ryuji

On 2009/10/28, at 3:12, Alexandru Petrescu wrote:

> _after_ having acted as if that consensus existed - they submitted  
> and approved submission of a WG item.
>
> I can also call your action of submitting without WG approval as non- 
> legitimacy, but I won't go that far.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 21:04:58 +0100

> We cannot retire the WG doc, but we can replace it if that is the WG

There are number of issues which have been discussed recently about each
document.

I know for my own point, but not sure how to re-make it.  If I make it
again and gets lost then it's a waste of time.

http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-03

1.  I think Charles had text proposal to me and onlist about replacing
"undetermined properties" and that proposal sounded better to me, except
that he assumed that an LL address is derived from link-layer
characteristics (the MAC adddress), and thus he discarded LLs; at which
point I disagreed saying that not discard LL, because LL can be like
fe80::1.  I think he got tired of me at that point so we
left it there.  LAter Charles repeatedly said he had nothing particular 
against LLs.  In retrospective I think it was a good direction, overall.

2.  Also - I strongly oppose "discouraging LL IPv4" which the current
baccelli draft says.  Just type ifconfig or ipconfig on your offtheshelf
machine with wireless interfaces and see the IPv4 LL in action.  I think 
that's support enough.

3.  I also oppose in draft-baccelli the exclusive use of /128 prefixes,
it makes no sense, I could explain further if listened, or noted in an
issue tracker.

For draft-bernardos addressing model I still have to read it fully, 
other than LLs.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 21:15:42 +0100

> Did you remember we had an adaption call for NEMO-BS?

I think we did, if I remember correctly (you correct me).

I do remember though that there was a call about whether or not a NEMO 
DT had to be formed or not.

That was long ago.  Nowadays one goes through call after call.

There is also this thing that sometimes people take votes in the WG
meeting and sometimes avoid (or forget?) to confirm on the list - it 
sometimes sounds ok.  But here this time it was like no call neither 
f2f, neither on the list - nowhere, just a pressure to go fast.

> beginning, because the NETLMM WG formed DT.

There was a call on PMIPv6 DT output though (the most important output
of the group), I am not sure about the PMIP IPv4 support.

Long ago I considered even NETLMM to be badly run - I got kicked off it :-)

> In AUTOCONF WG, we have decided to publish the first DT doc as an 

That was good.

>  You can refer to other mails from us. anyway, the adaption call is
> still open. We cannot retire the WG doc, but we can replace it if
> that is the WG consensus.

Ok, let's wait (until which date?) to see how much support is for one
draft and for another.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 13:21:33 -0700

Hello Alex,

Some comments and corrections below...

Alexandru Petrescu wrote:
> characteristics (the MAC adddress),
I did not assume this.
> and thus he discarded LLs
I did not discard LLs
> ; at which
> fe80::1.
I pointed out that this was totally irrelevant.

> I think he got tired of me at that point so we
> left it there.
If I stopped discussing when I was tired, you might
not have heard from me for many many months.

>   LAter Charles repeatedly said he had nothing particular against LLs.
Later, and earlier, and even earlier, and ...
> machine with wireless interfaces and see the IPv4 LL in action.  I 
> think that's support enough.

Is that a valid metric for utility in a wireless ad hoc network?

> it makes no sense, I could explain further if listened, or noted in an

It makes a lot of sense.  In fact it makes enough sense so that
the multiplicity of early proposed solutions to the problem could
be developed into standards.

If only.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 21:55:48 +0100

> Later, and earlier, and even earlier, and ...

You have nothing against IPv6 LLs or nothing against IPv4 LLs or both?

BEcause current draft still says "discourage IPv4 LL".

Or when you have nothing against something it means that you actually 
discourage it?

> Is that a valid metric for utility in a wireless ad hoc network?

It's wireless links for adhoc networks - yes.  It's 169.254. yes.  It's 
widely spread on your off-the-shelf machines - yes.

> be developed into standards.

Do we make 3 issues out of these or should I consider that you convinced 
me and I give up?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 14:20:57 -0700

Hello Alex,

> Or when you have nothing against something it means that you actually 

I am fine if the draft discourages LL.  I am fine if the draft does
not discourage LL.

I only expect that the draft should make it clear that solutions are
acceptable if they do not use nor assign link-local addresses.

Why do I have to say this so many times?

> It's wireless links for adhoc networks - yes.  It's 169.254. yes.  
> It's widely spread on your off-the-shelf machines - yes.

It generally works in nonspecialized ad hoc networks - no.

> Do we make 3 issues out of these or should I consider that you 
> convinced me and I give up?

It's not a matter of convincing.  It's a matter of exploring
the facts.  The only person who could possibly convince
you is you yourself.  I do not see that happening for a
very long time.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Oct 2009 22:26:07 +0100

> acceptable if they do not use nor assign link-local addresses.

Are solutions acceptable if they do use LL addresses? (and are 
guaranteed unique on their respective links.)

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Oct 2009 16:06:29 -0700

> guaranteed unique on their respective links.)

Of course!  They may apply only to a restricted subset of the
wireless space of interest, and thus not solve the whole problem,
but why wouldn't they be acceptable for the realm of their
applicability?

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 29 Oct 2009 09:12:46 +0100

Well, since it seems that the obvious should be said (i.e. authors
supporting their own documents :-) ), I think we should not proceed --
at this stage -- with draft-baccelli, and consider first all the
candidate documents that are on the table (i.e., draft-bernardos, which
is surprisingly more aligned with my opinion).

Thanks,

Carlos

On Wed, 2009-10-28 at 09:23 +0100, Emmanuel Baccelli wrote:
> <[email-masked]> wrote:
>         I guess it's hardly a surprise that I also support this
>         document as baseline..
>         
>         Thomas
>         
>         
>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Oct 2009 09:44:28 +0100

On Thu, Oct 29, 2009 at 12:06 AM, Charles E. Perkins
<[email-masked]> wrote:
> [..]

I fully agree with Charlie. For a subset of deployment scenarios, we
can very well use LLs (for example, if they guarantee unique MACs, or
if we guarantee a good source of entropy). And this is said in the DT
draft:

"When more specific assumptions can be made regarding the connectivity
between interfaces, these SHOULD be considered when configuring subnet
prefixes."

So for _specific_ settings (like Alex's testbed), using LL will work
fine. However, the address model of the DT tries to be as _general_ as
possible and NOT to focus on a subset with specific assumptions.

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 29 Oct 2009 10:46:16 +0100

Not agreed with suggested usage of LLs.
See my proposal for correction of the baccelli draft.
It specifies when to use LLs and when not, and applies 
to IPv6 in general. And hopefully, it stops the LL 
discussion, because everybody may agree on the text.

Regards, Teco

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Ulrich Herberg
>Verzonden: donderdag 29 oktober 2009 9:44
>Aan: Charles E. Perkins
>CC: [email-masked]
>Onderwerp: Re: [Autoconf] issues with draft-baccelli address model
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 10:51:33 +0100

Ulrich Herberg a écrit :
>> [..] Of course!  They may apply only to a restricted subset of the 
>  if we guarantee a good source of entropy). And this is said in the
> DT draft:
> 
> "When more specific assumptions can be made regarding the
> connectivity between interfaces, these SHOULD be considered when
> configuring subnet prefixes."
> 
> fine. However, the address model of the DT tries to be as _general_
> as possible and NOT to focus on a subset with specific assumptions.

My question is whether or not this type of use LL addresses working fine
in _some_ applications (in a restricted subset of deployment scenarios
in the wireless space of interest) is a valid case for AUTOCONF or not.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Oct 2009 11:01:45 +0100

Alex,

> in the wireless space of interest) is a valid case for AUTOCONF or not.

I think it is definitely interesting for AUTOCONF to solve after we
have been rechartered; but not at this time. We want to produce an
addressing model that covers a general case, and is not specific to
certain subsets of scenarios. After finishing work on the general
address model, I am not against thinking about more specific models
with more assumptions (i.e. unique MAC etc.)

Ulrich

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 29 Oct 2009 11:42:42 +0100

Ulrich,

Again and again and again. Can you check what "practical"
means? We are chartered for it. Not for "all" or "general".

It happens to be that I try to get MANETs deployed. 
All what I have around me and venders offer have no problem
with address uniqueness. To name a few problems: no standard
for prefix delegation, no MANET standard protocol with
link metrics, problems with scalability, multicast issues,
multi-homing, security and on and on.

See also Jari his last posting. This motivated me keep telling
what I am doing and what the problems are. This also makes very 
clear we shall stop boil the ocean.

Regards, Teco

>Verzonden: donderdag 29 oktober 2009 11:02
>Aan: Alexandru Petrescu
>CC: [email-masked]

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Thu, 29 Oct 2009 11:57:07 +0100

Thomas, Ryuji, WG members,
 
My vote below:

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Thomas Heide Clausen
	Sent: donderdag 22 oktober 2009 1:50
	To: [email-masked]
	Subject: [Autoconf] On WG progress and
draft-ietf-autoconf-adhoc-addr-model

	All,

	It appeared to the chairs that the comments raised at the
Stockholm IETF, as well as on the list subsequently, concerning the
document:

	had been addressed fully by the editors, and to the WGs
satisfaction - at least, there were no issue raised to the latter/latest
version hereof. The chairs therefore found it a good idea to move the
document forward as a WG document, and progress this document as such.
We therefore approved for publication:

	We (the chairs)  still believe that this is the proper approach
in order to make progress for the WG.

	To put it bluntly, this WG is far far behind schedule and this
document seemed, and still seems, by virtue of having been widely
discussed and agreed upon, as the best shot at making progress for this
WG.

	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:

Editors 

Yes, I think there are serious, but fixable issues with
draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote
draft-bernardos-autoconf-addressing-model to offer a different
perspective on these issues. Let me briefly summarize here our (or at
least: my) main objections:
 
1.  Section 1, Introduction and section 3, Applicability Statement:
Nowhere in these sections is there any mention of the assumed
host/router model, i.e. whether applications (including management
clients) can run on routers and if they can, make use of the interfaces
/ addresses that are the subject of this draft OR whether applications
are assumed to always separated by at least one hop from these
interfaces. However, the ghost of
draft-clausen-manet-autoconf-recommendations-00 seems to be hovering
over this draft, so the latter is sort of implied. I would prefer that
this is spelled out, as it impacts the type of addresses that need to be
configured, I might not necessarily agree, but al least it would be
clearer.
 
2. Section 4, IP Subnet Prefix Configuration:
 
- "Subnet prefix configuration on such interfaces must thus not make any
promises in terms of direct (one hop) IP connectivity to IP addresses
other than that of the interface itself." I find this unconvincing. What
promise would there be, really? Imagine a wired Ethernet, with several
nodes on it sharing a prefix.It would be rare for the subnet to be fully
populated, even on an IPv4 /24. So if I dream up a host part / Interface
ID, append it to the subnet prefix and use that as a destination
address, what would be my chances of reaching another node? To be clear,
I *agree* on the unique / non-overlapping subnet prefix principle stated
here, but find the motivation lacking. 
- It should say "non-overlapping", because "not the same" is not
sufficient.
 
3. Section 6, Addressing Model
 
- 6.1, IPv4 Model: Disagree that the prefix length should be /32. For
subnet prefixes to be unique / non-overlapping (see definition in
draft-bernardos-autoconf-addressing-model), is a necessary, but also
sufficient condition. I ran a MANET with 192.168.x.1/24 on the MANET
interfaces for many months. I fail to see what's wrong with that. (Agree
on what is said here about IPv LL's, by the way)
 
- 6.2, IPv6 Model: Strongly disagree that the prefix length should be
/128. Why paint ourselves into a corner like that? I would urge the
draft authors to have a look at RFC 5375, "IPv6 Unicast Address
Assignment Considerations". While this is "only" an informational RFC, I
think it is worth reading. When in a hurry, you can skip Appendix A, but
do not skip Appendix B! Besides, there was discussion at the IETF-75
Autoconf session, see the minutes of that meeting:
 
Dave Thaler
- Consistency with RFC 4291 (in particular section 2.5.1).
- Do you believe you have 64-bit interface identifiers that 
  are unique within the subnet prefix? (the 64-bit part being 
  a requirement for all unicast addresses that do not begin
              with binary '000').
- If the answer to previous question is 'no', do you require
  prefixes to start with binary '000'?
- If that is not the case either, shouldn't the document say
  that the addressing model will not be compliant with RFC4291?
 
and:
 
Dave Thaler
- If you believe that you ARE compliant with RFC4291, the way to
  phrase it is, that you have a /64 subnet prefix, but it is only
  assigned to a single host.

and later Thomas Narten wrote:
 
Thomas Narten (Jabber)
- IMO, /128 does not conflict with existing specs. We are blurring and
confusing
  various issues. You can have a /128 for on-link prefixes and still
have a 
  64-bit Interface IDs.
 
but he did not explain this any further. So who is right: Thaler or
Narten? And what ithe prefix length of a ULA assigned to an interface?
/64 as far as I was able to figure out.
 
- IPv6 link-locals: (Too?) Much has been said about this already. My
opinion: LL's are there, and they may be pretty hard to get rid of. I'm
more concerned about existing platforms than about these new
ultra-resource-starved devices that have been subject of discusion on
the ML recently. You can choose to not use them for routing purposes (in
the narrow definition of routing as discovering network topology and
populating the RIB / FIB), but you may not be able to influence whether
they are used for forwarding. I've seen neighbor solicitations being
sent with LL source addresses from MANET interfaces, that also had
global IPv6 addresses configured.
 
- 3rd bullet under "known limitations": routing protocol packets are
sent hop-by-hop. They are intercepted. processed and possibly
regenerated at each router, so limitation does not apply.
 
Oops, getting too close to deadline. This will have to do.
 
Regards,
Ronald

	
	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!!

	Cheers,

	Ryuji & Thomas

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: "Holtzer, A.C.G. (Arjen)" <[email-masked]>
Date: Thu, 29 Oct 2009 11:59:46 +0100

Hi all,
 
Ronald told me to say: "Me too". :)
 
Regards,
Arjen

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Velt, R. (Ronald) in 't
	Sent: donderdag 29 oktober 2009 11:57
	To: Thomas Heide Clausen; [email-masked]
	Subject: Re: [Autoconf] On WG progress
anddraft-ietf-autoconf-adhoc-addr-model

	My vote below:

		All,

		It appeared to the chairs that the comments raised at
the Stockholm IETF, as well as on the list subsequently, concerning the
document:

		We (the chairs)  still believe that this is the proper
approach in order to make progress for the WG.

		Do note that the WG is 7 months past the milestone for
initial document submission, and 1 month past the milestone for having
progressed the document to the IESG and/or closed up shop!  And, there
has been no discussions (in meetings or on this list) on alternative
candidate documents for the work item which [autoconf] is chartered to
accomplish. 

		To put it bluntly, this WG is far far behind schedule
and this document seemed, and still seems, by virtue of having been
widely discussed and agreed upon, as the best shot at making progress
for this WG.

		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 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. 

	1.  Section 1, Introduction and section 3, Applicability
Statement: Nowhere in these sections is there any mention of the assumed

	- "Subnet prefix configuration on such interfaces must thus not
make any promises in terms of direct (one hop) IP connectivity to IP
addresses other than that of the interface itself." I find this
unconvincing. What promise would there be, really? Imagine a wired
Ethernet, with several nodes on it sharing a prefix.It would be rare for
the subnet to be fully populated, even on an IPv4 /24. So if I dream up
a host part / Interface ID, append it to the subnet prefix and use that
as a destination address, what would be my chances of reaching another
node? To be clear, I *agree* on the unique / non-overlapping subnet
prefix principle stated here, but find the motivation lacking. 
	- It should say "non-overlapping", because "not the same" is not
sufficient.

	- 6.1, IPv4 Model: Disagree that the prefix length should be
/32. For subnet prefixes to be unique / non-overlapping (see definition
in draft-bernardos-autoconf-addressing-model), is a necessary, but also
sufficient condition. I ran a MANET with 192.168.x.1/24 on the MANET
interfaces for many months. I fail to see what's wrong with that. (Agree
on what is said here about IPv LL's, by the way)
	 
	- 6.2, IPv6 Model: Strongly disagree that the prefix length
should be /128. Why paint ourselves into a corner like that? I would
urge the draft authors to have a look at RFC 5375, "IPv6 Unicast Address
Assignment Considerations". While this is "only" an informational RFC, I
think it is worth reading. When in a hurry, you can skip Appendix A, but
do not skip Appendix B! Besides, there was discussion at the IETF-75
Autoconf session, see the minutes of that meeting:
	 
	Dave Thaler
	 
	and:
	 
	Dave Thaler
	- If you believe that you ARE compliant with RFC4291, the way to
	  phrase it is, that you have a /64 subnet prefix, but it is
only
	  assigned to a single host.

	Thomas Narten (Jabber)
	- IMO, /128 does not conflict with existing specs. We are
blurring and confusing
	  various issues. You can have a /128 for on-link prefixes and
still have a 
	  64-bit Interface IDs.
	 
	but he did not explain this any further. So who is right: Thaler
or Narten? And what ithe prefix length of a ULA assigned to an
interface? /64 as far as I was able to figure out.
	 
	- IPv6 link-locals: (Too?) Much has been said about this
already. My opinion: LL's are there, and they may be pretty hard to get
rid of. I'm more concerned about existing platforms than about these new
ultra-resource-starved devices that have been subject of discusion on
the ML recently. You can choose to not use them for routing purposes (in
the narrow definition of routing as discovering network topology and
populating the RIB / FIB), but you may not be able to influence whether
they are used for forwarding. I've seen neighbor solicitations being
sent with LL source addresses from MANET interfaces, that also had
global IPv6 addresses configured.
	 
	- 3rd bullet under "known limitations": routing protocol packets
are sent hop-by-hop. They are intercepted. processed and possibly
regenerated at each router, so limitation does not apply.

	Regards,
	Ronald

		 
		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!!

		Cheers,

		Ryuji & Thomas

	This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 12:57:00 +0100

Hi,

Me too I agree with what Ronald says below, especially the risk of 
painting self in a corner using /128 and /32.

I hope Chairs can count this too.

Alex

Holtzer, A.C.G. (Arjen) a écrit :
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Velt, R. (Ronald) in 't
>     *Sent:* donderdag 29 oktober 2009 11:57
>     *To:* Thomas Heide Clausen; [email-masked]
>     *Subject:* Re: [Autoconf] On WG progress
>         *From:* [email-masked]
>         [mailto:[email-masked]] *On Behalf Of *Thomas Heide
>         Clausen
>         *Sent:* donderdag 22 oktober 2009 1:50
>         *To:* [email-masked]
>         *Subject:* [Autoconf] On WG progress and
>         Stockholm IETF, as well as on the list subsequently, concerning
>         the document:
> 
>         <http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model>http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model
> 
>         satisfaction - at least, there were no issue raised to the
>         latter/latest version hereof. The chairs therefore found it a
>         good idea to move the document forward as a WG document, and
>         progress this document as such. We therefore approved for
>         publication:
> 
>         alternative candidate documents for the work item which
>         [autoconf] is chartered to accomplish. 
> 
>         document seemed, and still seems, by virtue of having been
>         widely discussed and agreed upon, as the best shot at making
>         progress for this WG.
> 
>         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:
> 
>     Yes, I think there are serious, but fixable issues
>     with draft-ietf-autoconf-adhoc-addr-model. Carlos and I wrote
>     perspective on these issues. Let me briefly summarize here our (or
>     at least: my) main objections:
>      
>     clients) can run on routers and if they can, make use of the
>     interfaces / addresses that are the subject of this draft OR whether
>     applications are assumed to always separated by at least one hop
>     from these interfaces. However, the ghost of
>     over this draft, so the latter is sort of implied. I would prefer
>     that this is spelled out, as it impacts the type of addresses that
>     need to be configured, I might not necessarily agree, but al least
>     it would be clearer.
>      
>     - "Subnet prefix configuration on such interfaces must thus not make
>     any promises in terms of direct (one hop) IP connectivity to IP
>     Ethernet, with several nodes on it sharing a prefix.It would be rare
>     for the subnet to be fully populated, even on an IPv4 /24. So if I
>     dream up a host part / Interface ID, append it to the subnet prefix
>     and use that as a destination address, what would be my chances of
>     reaching another node? To be clear, I *agree* on the unique /
>     non-overlapping subnet prefix principle stated here, but find the
>     motivation lacking.
>     - 6.1, IPv4 Model: Disagree that the prefix length should be /32.
>     For subnet prefixes to be unique / non-overlapping (see definition
>     in draft-bernardos-autoconf-addressing-model), is a necessary, but
>     also sufficient condition. I ran a MANET with 192.168.x.1/24 on the
>     MANET interfaces for many months. I fail to see what's wrong with
>     that. (Agree on what is said here about IPv LL's, by the way)
>      
>     - 6.2, IPv6 Model: Strongly disagree that the prefix length should
>     be /128. Why paint ourselves into a corner like that? I would urge
>     the draft authors to have a look at RFC 5375, "IPv6 Unicast Address
>     Assignment Considerations". While this is "only" an informational
>     RFC, I think it is worth reading. When in a hurry, you can skip
>     Appendix A, but do not skip Appendix B! Besides, there was
>     discussion at the IETF-75 Autoconf session, see the minutes of that
>     meeting:
>      
>     Dave Thaler
>     - IMO, /128 does not conflict with existing specs. We are blurring
>     and confusing
>     Narten? And what ithe prefix length of a ULA assigned to an
>     opinion: LL's are there, and they may be pretty hard to get rid of.
>     I'm more concerned about existing platforms than about these new
>     ultra-resource-starved devices that have been subject of discusion
>     on the ML recently. You can choose to not use them for routing
>     purposes (in the narrow definition of routing as discovering network
>     topology and populating the RIB / FIB), but you may not be able to
>     influence whether they are used for forwarding. I've seen neighbor
>     solicitations being sent with LL source addresses from MANET
>     interfaces, that also had global IPv6 addresses configured.
>

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Oct 2009 13:13:50 +0100

Arjen, Ronald,

I hope that Ronald did not really ask you to say "me too" but rather
to state your own opinion on the list (whether that be "pro" or
"against") :-)

Please read draft-clausen-manet-autoconf-recommendations-00 if you did
not yet. This explains the rationale for using /32 and /128 prefixes.
It also explains what can go wrong when using shorter prefixes and the
symptoms thereof (ICMP redirects...)

Ulrich

On Thu, Oct 29, 2009 at 11:59 AM, Holtzer, A.C.G. (Arjen)
<[email-masked]> wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Velt, R. (Ronald) in 't
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Thomas Heide Clausen
> Subject: [Autoconf] On WG progress and draft-ietf-autoconf-adhoc-addr-model
>
> All,
> 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:
> draft-bernardos-autoconf-addressing-model to offer a different perspective
> on these issues. Let me briefly summarize here our (or at least: my) main
> objections:
>
> 1.  Section 1, Introduction and section 3, Applicability Statement: Nowhere
> in these sections is there any mention of the assumed host/router model,
> i.e. whether applications (including management clients) can run on routers
> and if they can, make use of the interfaces / addresses that are the subject
> of this draft OR whether applications are assumed to always separated by at
> least one hop from these interfaces. However, the ghost of
> draft-clausen-manet-autoconf-recommendations-00 seems to be hovering over
> this draft, so the latter is sort of implied. I would prefer that this is
> spelled out, as it impacts the type of addresses that need to be configured,
> I might not necessarily agree, but al least it would be clearer.
>
> promises in terms of direct (one hop) IP connectivity to IP addresses other
> than that of the interface itself." I find this unconvincing. What promise
> would there be, really? Imagine a wired Ethernet, with several nodes on it
> sharing a prefix.It would be rare for the subnet to be fully populated, even
> on an IPv4 /24. So if I dream up a host part / Interface ID, append it to
> the subnet prefix and use that as a destination address, what would be my
> chances of reaching another node? To be clear, I *agree* on the unique /
> non-overlapping subnet prefix principle stated here, but find the motivation
> lacking.
> - It should say "non-overlapping", because "not the same" is not sufficient.
>
> - 6.1, IPv4 Model: Disagree that the prefix length should be /32. For subnet
> prefixes to be unique / non-overlapping (see definition in
> interfaces for many months. I fail to see what's wrong with that. (Agree on
> what is said here about IPv LL's, by the way)
>
> - 6.2, IPv6 Model: Strongly disagree that the prefix length should be /128.
> Why paint ourselves into a corner like that? I would urge the draft authors
> to have a look at RFC 5375, "IPv6 Unicast Address Assignment
> Considerations". While this is "only" an informational RFC, I think it is
> worth reading. When in a hurry, you can skip Appendix A, but do not skip
> Appendix B! Besides, there was discussion at the IETF-75 Autoconf session,
> see the minutes of that meeting:
>
> Dave Thaler
>   various issues. You can have a /128 for on-link prefixes and still have a
>   64-bit Interface IDs.
>
> but he did not explain this any further. So who is right: Thaler or Narten?
> And what ithe prefix length of a ULA assigned to an interface? /64 as far as
> I was able to figure out.
>
> opinion: LL's are there, and they may be pretty hard to get rid of. I'm more
> concerned about existing platforms than about these new
> ultra-resource-starved devices that have been subject of discusion on the ML
> recently. You can choose to not use them for routing purposes (in the narrow
> definition of routing as discovering network topology and populating the RIB
> / FIB), but you may not be able to influence whether they are used for
> forwarding. I've seen neighbor solicitations being sent with LL source
> addresses from MANET interfaces, that also had global IPv6 addresses
> configured.
>
> - 3rd bullet under "known limitations": routing protocol packets are sent
> hop-by-hop. They are intercepted. processed and possibly regenerated at each
> router, so limitation does not apply.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 13:57:55 +0100

> to state your own opinion on the list (whether that be "pro" or

I think it may be right to ask somebody to express an expression on the 
list if that somebody already thinks that way.

I can tell you that there are some people around me who think the way I 
do with respect to AUTOCONF stuff, yet they don't post on the list.  If 
I tell them to post, they will.  They have already made up their mind.

There are often cases when we see somebody vote on the list yet rarely 
if ever having posted previously on the list.  There's one recently on 
your camp too.  Did you tell him the same?

I hope Chairs count all this in a fair manner.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Oct 2009 14:05:17 +0100

Alex,

On Thu, Oct 29, 2009 at 1:57 PM, Alexandru Petrescu
<[email-masked]> wrote:
[..]
> I think it may be right to ask somebody to express an expression on the list
> if that somebody already thinks that way.

Everybody has the right to express his opinion (and more importantly,
technical arguments) on the mailing list.

>
> I can tell you that there are some people around me who think the way I do
> with respect to AUTOCONF stuff, yet they don't post on the list.  If I tell
> them to post, they will.  They have already made up their mind.
>
> There are often cases when we see somebody vote on the list yet rarely if
> ever having posted previously on the list.  There's one recently on your
> camp too.  Did you tell him the same?

I asked my colleague to express his own opinion on this matter. I did
not tell him "Please vote in favor of the DT draft".  (and I am not
accusing anyone of not expressing his own opinion, but the opinion of
the supervisor/colleague etc.) But please, let's close this
discussion. I am sorry if that diverged from the main, technical
issue.

> I hope Chairs count all this in a fair manner.

I am sure they will count every opinion.

Ulrich

---

From: "Holtzer, A.C.G. (Arjen)" <[email-masked]>
Date: Thu, 29 Oct 2009 14:29:14 +0100

Hi Ulrich, Ronald, Alex,

Actually, to be more specific, I agree with the text in draft-bernardos-autoconf-addressing-model-01 which states in section 3.2:

"The use of /32 (in the IPv4 case) or /128 (in the IPv6 case)
   prefix lengths can be an effective way to ensure that prefixes are
   non-overlapping.  However, it would be needlessly restrictive to
   mandate the use of only these prefix lengths."

As far as section 4.2 of draft-clausen-manet-autoconf-recommendations-00 is concerned: this addresses the issue with ICMP redirect messages when the addresses of the nodes in the "hidden-terminal"-scenario of Figure 9 are using the same subnet prefix. I agree this is an issue and it can be solved by using non-overlapping prefixes, not exclusively by using /32 IPv4 and /128 IPv6 prefixes. This seems unnecessarily restrictive to me.

And about my opinion on the WG document: I think draft-ietf-autoconf-adhoc-addr-model is a good point for continuation, but I think Ronald has several good points. In general, I am, like everyone in the WG, in favour of fast progress with the addressing model, since I am waiting for the moment to go into solution space.

Best regards,
Arjen

> -----Original Message-----
> From: Ulrich Herberg [mailto:[email-masked]] 
> Sent: donderdag 29 oktober 2009 13:14
> To: Holtzer, A.C.G. (Arjen)
> Cc: Velt, R. (Ronald) in 't; [email-masked]
> I hope that Ronald did not really ask you to say "me too" but 
> rather to state your own opinion on the list (whether that be "pro" or
> "against") :-)
> 
> Please read draft-clausen-manet-autoconf-recommendations-00 
> if you did not yet. This explains the rationale for using /32 
> and /128 prefixes.
> It also explains what can go wrong when using shorter 
> prefixes and the symptoms thereof (ICMP redirects...)
> 
> Ulrich
> 
> 
> satisfaction - 
> > candidate documents for the work item which [autoconf] is 
> chartered to accomplish.
> > discussed and agreed upon, as the best shot at making 
> progress for this WG.
> 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 
> > applications are assumed to always separated by at least 
> one hop from 
> > these interfaces. However, the ghost of 
> > this is spelled out, as it impacts the type of addresses 
> that need to be configured, I might not necessarily agree, 
> but al least it would be clearer.
> >
> > non-overlapping subnet prefix principle stated here, but 
> find the motivation lacking.
> > interfaces for many months. I fail to see what's wrong with that. 
> > (Agree on what is said here about IPv LL's, by the way)
> >
> should be /128.
> > Why paint ourselves into a corner like that? I would urge the draft 
> > authors to have a look at RFC 5375, "IPv6 Unicast Address 
> Assignment 
> > Considerations". While this is "only" an informational RFC, 
> I think it 
> > is worth reading. When in a hurry, you can skip Appendix A, 
> but do not 
> > skip Appendix B! Besides, there was discussion at the 
> IETF-75 Autoconf 
> > session, see the minutes of that meeting:
> >
> > Dave Thaler
> blurring and 
> > And what ithe prefix length of a ULA assigned to an 
> interface? /64 as 
> > the ML recently. You can choose to not use them for routing 
> purposes 
> > (in the narrow definition of routing as discovering network 
> topology 
> > and populating the RIB / FIB), but you may not be able to influence 
> > whether they are used for forwarding. I've seen neighbor 
> solicitations 
> > being sent with LL source addresses from MANET interfaces, 
> that also 
> > had global IPv6 addresses configured.
> >
> > hope, let the WG know explicitly how you suggest that we 
> progress  at 
> > this point
> > --

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 09:55:27 -0700

Hello Teco,

> means? We are chartered for it. Not for "all" or "general".

Since a good number of solutions have been proposed that
do resolve the "general" network problem, your argument loses
all of its force.  If there were some indication that the general
case was too hard, then you might have a complaint.

So far the only hard problem seems to be how to avoid
squabbling over whether link-locals are needed.  I am not
sure why the proponents of necessity are so adept at
ignoring the solutions that do not need link-locals.  It is
not explainable by the existence of solutions that use
link-locals, because such solutions are universally
acknowledged to be useful in their realm of applicability.

So why do link-locals insist on "their way come hell
or high water"?

> clear we shall stop boil the ocean.

I agree with that.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 10:44:19 -0700

Hello Ronald,

As I understand, you and several other people feel that the
current document is too negative regarding the use of link-local
addresses.  I have tried to create some text for the document
which is a little more specific about the situations when
link-local addresses can be useful, which are (tautologically)
the same situations when leaf-level subnets can be useful.

If this text is more acceptable, maybe the document authors
can use it to replace Section 4:

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

4.  IP Subnet Prefix Configuration

   Some network interfaces obey certain configuration directives which
   enable useful assumptions about address uniqueness, or otherwise
   enable communications onto physical media which exhibit certain
   useful characteristics enabling address aggregation.  Links connecting
   computers with such network interfaces are likely to support
   link-local communications reaching multiple computers whose
   addresses can be aggregated into subnet ranges.  For such links,
   the known characteristics of the link SHOULD be considered when
   configuring IP subnet prefixes, and the corresponding interfaces
   configured with the same subnet prefix.  Such subnet prefix assignment
   is outside the scope of this document, since it depends on the
   specific characteristics of the physical links and network interfaces.

   If, on the other hand, the link to which an interface connects
   enables no such assumptions of connectivity to other interfaces,
   the only addresses which can be assumed "on link", are the address(es)
   of that interface itself.

   Subnet prefix configuration on such interfaces, SHOULD NOT make any
   promises in terms of direct (one hop) IP connectivity to IP addresses
   other than that of the interface itself.  This suggests the following
   principle:

   o  two distinct such interfaces in the network SHOULD NOT be configured
      with the same subnet prefix.

   In all cases, when L2 communication is enabled between a pair of 
interfaces,
   IP packet exchange is enabled regardless of the IP subnet configuration
   on each of these interfaces.

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

I'd also be willing to go through the rest of the document text
making similar revisions.

Another alternative would be to strip link-locals out of the
document entirely, or put all such discussion in an Appendix.
This would, however, make the document seem more mysterious
and arbitrary, since the fundamental reasoning and understanding
leading to the recommendations would be absent.

I also used "SHOULD" and "SHOULD NOT" instead of
"MUSTs", since it seems to me that systems can clearly be
built that do not adhere to the recommendations.  Nevertheless,
in the absence of system-specific assumptions, the general
recommendations are expected to be followed.  This last
sentence is merely a regurgitation of the definition of "SHOULD".

Regards,
Charlie P.

Velt, R. (Ronald) in 't wrote:
>     [mailto:[email-masked]] *On Behalf Of *Thomas Heide Clausen
>     latter/latest version hereof. The chairs therefore found it a good
>     idea to move the document forward as a WG document, and progress
>     this document as such. We therefore approved for publication:
>
>     list) before 29/10/09 (i.e. Thursday next week) at noon
>     o
>     if you think there're cardinal (but fixable) issues missing or
>     wrong with 
> perspective on
> these issues. Let me briefly summarize here our (or at least: my) main
> objections:
>  
> 1.  Section
> 1, Introduction and section 3, Applicability Statement: Nowhere in these
> sections is there any mention of the assumed host/router model, i.e. 
> whether
> applications (including management clients) can run on routers and if 
> they
> can, make use of the interfaces / addresses that are the subject of 
> this draft
> OR whether applications are assumed to always separated by at least 
> one hop from
> draft-clausen-manet-autoconf-recommendations-00 seems to
> be hovering over this draft, so the latter is
> sort of implied. I would prefer that this is spelled out, as it 
> impacts the type
> of addresses that need to be configured, I might not necessarily 
> agree, but al
> least it would be clearer.
>  
> 2. Section 4, IP
> - "Subnet prefix
> configuration on such interfaces must thus not make any promises in 
> terms of
> direct (one hop) IP connectivity to IP addresses other than that of the
> interface itself." I find this unconvincing. What promise would there be,
> really? Imagine a wired Ethernet, with several nodes on it sharing a 
> prefix.It
> would be rare for the subnet to be fully populated, even on an IPv4 
> /24. So if I
> and use that
> node? To
> be clear, I *agree* on the unique / non-overlapping subnet prefix 
> principle
> stated here, but find the motivation lacking.
> - It should say
> "non-overlapping", because "not the same" is not
> sufficient.
>  
> 3. Section 6,
> Addressing Model
>  
> - 6.1, IPv4
> Model: Disagree that the prefix length should be /32. For subnet 
> prefixes to be
> unique / non-overlapping (see definition in
> sufficient
> condition. I ran a MANET with 192.168.x.1/24 on the MANET interfaces 
> for many
> months. I fail to see what's wrong with that. (Agree on what is said 
> here about
> IPv LL's, by the way)
>  
> - 6.2, IPv6
> Model: Strongly disagree that the prefix length should be /128. Why paint
> ourselves into a corner like that? I would urge the draft authors to 
> have a look
> at RFC 5375, "IPv6 Unicast Address Assignment Considerations". While 
> this is
> "only" an informational RFC, I think it is worth reading. When in a 
> hurry,
> you can skip Appendix A, but do not skip Appendix B! Besides, there was
> - Consistency
> with RFC 4291 (in particular section 2.5.1).
>   a requirement for all unicast
> addresses that do not
> begin
>              
> with binary '000').
> - If that is not
> the case either, shouldn't the document say
>   that the addressing
> model will not be compliant with RFC4291?
>  
> and:
>  
> Dave Thaler
> - If you
> believe that you ARE compliant with RFC4291, the way to
>   phrase it
> is, that you have a /64 subnet prefix, but it is only
>   assigned to a
> single host.
> and later
> Thomas Narten wrote:
>  
> Thomas Narten
> (Jabber)
>   64-bit Interface
> IDs.
> but he did
> not explain this any further. So who is right: Thaler or Narten? And 
> what ithe
> prefix length of a ULA assigned to an interface? /64 as far as I was 
> able to
> figure out.
>  
> - IPv6
> link-locals: (Too?) Much has been said about this already. My opinion: 
> LL's are
> there, and they may be pretty hard to get rid of. I'm more concerned 
> about
> existing platforms than about these new ultra-resource-starved devices 
> that have
> been subject of discusion on the ML recently. You can choose to not 
> use them for
> routing purposes (in the narrow definition of routing as discovering 
> network
> influence
> whether they are used for forwarding. I've seen neighbor solicitations
> being sent with LL source addresses from MANET interfaces, that also 
> had global
> - 3rd bullet
> under "known limitations": routing protocol packets are sent 
> hop-by-hop. They
> are intercepted. processed and possibly regenerated at each router, so
> limitation does not apply.
>  
> Oops, getting too
>     o
>     if you think that draft-ietf-autoconf-adhoc-addr-model is beyond
>     hope,

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 18:58:32 +0100

> So far the only hard problem seems to be how to avoid squabbling over
>  whether link-locals are needed.
> 
> I am not sure why the proponents of necessity are so adept at 
> ignoring the solutions that do not need link-locals.

It's very simple why: I have a prototype which involves protocol
extensions (RA) only on the parts of the System which use exclusively
link-locals addresses.  You forbidding link-local addresses equates with
forbidding my protocol extensions on the core of my prototype, makes all 
break.

(the parts of the System which use global addresses are not affected by
my prototype.  They are also essential and core, but to some other people.)

> It is not explainable by the existence of solutions that use
> link-locals, because such solutions are universally acknowledged to
> be useful in their realm of applicability.

Is this formulation ok, or an "only" missing somewhere?

If you keep that formulation as is - I agree with it!

> So why do link-locals insist on "their way come hell or high water"?

BEcause I don't want my prototype discarded by an illogical sense of 
forbidding LLs.

Alex

> 
>> 
>> See also Jari his last posting. This motivated me keep telling what
>>  I am doing and what the problems are. This also makes very clear
>> we shall stop boil the ocean.
>> 
> 
> I agree with that.
> 
> Regards, Charlie P.
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 11:07:12 -0700

Hello Alex,

I don't mind discussing with you.  But I really don't
like having to point out your false statements so
often.

Alexandru Petrescu wrote:
> forbidding my protocol extensions on the core of my prototype, makes 
> all break.

I _do not_ forbid link-local addresses.  I'm not even one of the
document authors, and I didn't create that language.

But the document does not forbid link-locals either.

So how many times do you persist in making this false
statement, and, worse, basing your repeated, iterated,
verbose, relentless, and seemingly misguided objections
based on the false notion that link-locals are forbidden?

> Is this formulation ok, or an "only" missing somewhere?

...???...

> BEcause I don't want my prototype discarded by an illogical sense of 

And in what universe does that prohibition reside?

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 19:21:51 +0100

> But the document does not forbid link-locals either.

Well it does, here is how:

draft-baccelli says:
>   Note that while link-local addresses are assumed to be "on link", the
>    utility of link-local addresses is limited as described in Section 6.

The word "limited" strikes.

draft-baccelli says:
>    o  A subnet prefix configured on this interface should be of length
>       /128.

The link-local prefix of IPv6 LLs is fe80::/10, and not /128.

draft-baccelli says:
>    o  Any [IPv4] subnet prefix configured on this interface should be of length
>       /32.

Yet the prefix of the IPv4 LL is 169.254/16, and not a /32.

draft-baccelli says:
>    Note that the use of IPv4 link-local addresses [RFC3927] in this
>    context should be discouraged for most applications

"Discouraged" means discouraged.  And which "context"?  The word 
"context" appears precisely once in the draft.

These 4 things make me think the draft-baccelli co-authors and Editors 
want to forbid the LLs.

How do we fix these 4 things such that I don't misunderstand them again?

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 11:24:09 -0700

Hello Alex,

What do you think about my
suggestion for revising Section 4?

I'll wait to answer your points below
until I hear back on that.

Regards,
Charlie P.

---

From: sratliff <[email-masked]>
Date: Thu, 29 Oct 2009 14:25:18 -0400

Charlie, 

Absolutely correct. I agree 100%. And this is why I see this whole
discussion as a tempest in a teapot.

"discourage" != "cannot"

No one supporting the Bacelli-Townsley draft has said you can't use
link-local addresses. I support the Bacelli-Townsley draft, and most of my
deployments use link-local addresses. My deployments will continue to use
link-local addresses. But I do see that there are deployments where use of
link-local addresses is either problematic, or impossible. So I understand
the draft's language concerning "discouraging" their use.

But the draft DOES NOT say they CANNOT be used. That's one of the reasons I
support the draft.

Regards,
Stan

---

From: sratliff <[email-masked]>
Date: Thu, 29 Oct 2009 14:30:55 -0400

> The word "limited" strikes.

Nonsense. "utility.. is limited" is not the same as "must not be used".
> The link-local prefix of IPv6 LLs is fe80::/10, and not /128.

The key word in that sentence is SHOULD. It does not say MUST.

> Yet the prefix of the IPv4 LL is 169.254/16, and not a /32.

Again, the sentence says SHOULD. Not MUST.

> "context" appears precisely once in the draft.

Precisely. "Discouraged" means discouraged. It doesn't mean "cannot". And
again, the sentence contains the word SHOULD. It does not say MUST.

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 20:23:26 +0100

sratliff a écrit :
[...]
>> draft-baccelli says:
>>> Note that while link-local addresses are assumed to be "on link",
>>> the utility of link-local addresses is limited as described in
>>> Section 6.

Would you agree to say "the utility of /128 prefixes is limited"?

>> draft-baccelli says:
>>> o  A subnet prefix configured on this interface should be of
>>> length /128.

Well, LLs are a SHOULD on many interfaces.  A SHOULD and and a SHOULD
NOT could give a "MAY":  "a /128 prefix on this interface MAY be /128".
(and I invite implementers to do it and report back problems thank you).

>> draft-baccelli says:
>>> o  Any [IPv4] subnet prefix configured on this interface should
>>> be of length /32.

Again, a MAY would be a better fit.

> Precisely. "Discouraged" means discouraged. It doesn't mean "cannot".
> And again, the sentence contains the word SHOULD. It does not say
> MUST.

I believe that "dicouraged" fits better the use of host-based routes
(the "/128" prefix recommendation) for a variety of reasons, making them 
limited use too: (1) it doesn't scale to large domain, (2) can't connect 
to the Internet, (3) consumes more ressources than /64-or-shorter 
prefixes (cycles: instead of average 64 bit comparisons you use a sure 
128 bit comparisons, memory: instead of one entry covering several 
destinations you use an entry for each destination in each router).

It sounds as we have it completely reverse, and "MAY" may solve it.

Alex

---

From: sratliff <[email-masked]>
Date: Thu, 29 Oct 2009 15:49:46 -0400

> (and I invite implementers to do it and report back problems thank you).

"a SHOULD and a SHOULD NOT could give a MAY"....... I don't even know how to
begin to address this.

I'm comfortable with the current state of "SHOULD/MAY/MUST" that's in the
current document. As I said earlier, I think all of this is a tempest in a
teapot. 

Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 20:58:19 +0100

Charles E. Perkins a écrit :
> 
> Hello Ronald,
> 
> As I understand, you and several other people feel that the current 
> document is too negative regarding the use of link-local addresses. I
> have tried to create some text for the document which is a little 
> more specific about the situations when link-local addresses can be 
> useful, which are (tautologically) the same situations when 
> leaf-level subnets can be useful.
> 
> If this text is more acceptable, maybe the document authors can use 
> it to replace Section 4:
> 
> useful characteristics enabling address aggregation.  Links 
> connecting computers with such network interfaces are likely to 
> support link-local communications reaching multiple computers whose 
> addresses can be aggregated into subnet ranges.  For such links, the 
> known characteristics of the link SHOULD be considered when 
> configured with the same subnet prefix.

I agree.  This section starts now with the right thing.

> Such subnet prefix assignment is outside the scope of this document, 
> since it depends on the specific characteristics of the physical 
> links and network interfaces.

That sounds as if you are going to be concerned (inscope of this
document) with prefix assignment which does not depend on the specific
characteristics of the physical links and network interfaces.  DO you
think it is possible to even send a message on a physical link and
network interface without knowing its MTU, for example?

> enables no such assumptions of connectivity to other interfaces, the 
> only addresses which can be assumed "on link", are the address(es) of
>  that interface itself.

You are mixing interface scope with link scope.  This should be kept
disambiguated, scopes 2 and 1.

An address "on link" assumes there is a real link out there.

An address "off link" is an address absent from the node and from all
the nodes on that link.

An address on-interface (not sure the terminology exists) can't go on
the link on which that interface attaches, because its scope is solely
that interface (scope 2 in rfc4291, which does exist).

It sounds as a need to define undefinable links.

Let's copypaste here some relevant and recent definitions of link, if 
you wish.  I could help.

> promises in terms of direct (one hop) IP connectivity to IP addresses
I believe it's 0th hop.

> other than that of the interface itself.  This suggests the following

Yes, the principle is that you want to define an on-interface scope. 
The problem with it is that it doesn't go out on a link.

> o  two distinct such interfaces in the network SHOULD NOT be 
> configured with the same subnet prefix.
> 
> interfaces, IP packet exchange is enabled regardless of the IP subnet
>  configuration on each of these interfaces.

This sounds ok to me, it is very well said.  Moreover, IP can run on 
links which have no MAC at all.

> Another alternative would be to strip link-locals out of the document
>  entirely, or put all such discussion in an Appendix.

Entirely out of the document - I would agree with that.  Don't
mention the word link-local or link-local address anywhere throughout -
I agree.

> This would, however, make the document seem more mysterious and
> arbitrary, since the fundamental reasoning and understanding leading
> to the recommendations would be absent.

I don't believe there is a coherent understanding of the link-local 
addresses.  You simply use them to say that because most of them rely on 
probably-not-unique MAC, and because they are not forwarded across links 
  - then use /128... it's completely illogic.

BEtter don't mention them at all.  I would agree with such a direction.

> I also used "SHOULD" and "SHOULD NOT" instead of "MUSTs", since it 
> seems to me that systems can clearly be built that do not adhere to 
> the recommendations.  Nevertheless, in the absence of system-specific
>  assumptions, the general recommendations are expected to be
> followed. This last sentence is merely a regurgitation of the
> definition of "SHOULD".

I agree with this direction in general, when things are to be explored. 
  In the case of LLs things are widely used already, tested, 
demonstrated, in a different way that you suggest.  Thus I would suggest 
"MAY" in many places where you say link-local address, and "MAY" where 
you say "/128 prefix".

IMHO,

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 29 Oct 2009 21:02:59 +0100

Hi,

> discussion as a tempest in a teapot.

Absolutely! I also think that a large confusion comes from wording: I
assist Charlie and Stan that you _are NOT prohibited_ to continue
using your setting with LLs. Nowhere in the draft this is prohibited.
Nevertheless, I hope that the revised section by Charlie can help to
make that clearer. Are there any other opinions on that revised
section?

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 21:04:28 +0100

> make that clearer. Are there any other opinions on that revised

Ulrich, call this draft "discourage!=cannot" and you'll have many 
eyebrows raised...

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 14:45:52 -0700

Hello Alex,

> network interface without knowing its MTU, for example?

Yes, I do.  There are minimal sizes involved as well
as maximal sizes.

And, I think the document should focus on prefix assignment which
does not depend on the specific characteristics of the physical links
and network interfaces.  And, since this is very general, it would
work for all links.

Prefix assignment for specific link classes ought to be in a separate
document.  Those techniques would not work for all links.

> It sounds as a need to define undefinable links.
Good luck with that!  On balance, the abovementioned text
is quite clear.  I didn't write it, by the way.

>> promises in terms of direct (one hop) IP connectivity to IP addresses
0th hop doesn't leave the node.  I think the statement above
is correct.

> The problem with it is that it doesn't go out on a link.
Your second statement is not correct.  The transmission
occurs on the link to the neighbor.

> mention the word link-local or link-local address anywhere throughout -

I think it is not the best choice, but better than dawdling for even one
more month on these link-local details.

> addresses.

Maybe, but I personally feel that my understanding is crystal clear.

>   You simply use them to say that because most of them rely on 
> probably-not-unique MAC, and because they are not forwarded across 
> links  - then use /128... it's completely illogic.

This statement is wrong in more than one way:
- I didn't use them
- That is not why they are used in the document
- The proportion of them depending on probably-not-unique MAC
    is not evaluated
- The reason for /128 is not as you suggest
- The reason for /128 is not completely illogic
-  illogic is syntactically incorrect (I do not fault you for this one).

That's a pretty impressive score for a single sentence.

> BEtter don't mention them at all.  I would agree with such a direction.

In my opinion it should the the last resort, and a recognition
that the working group insists on making progress as slowly
as possible.  But still better than zero progress, so I support
it as a last resort.

> I agree with this direction in general, when things are to be 
> explored.  In the case of LLs things are widely used already, tested, 
> demonstrated, in a different way that you suggest.  Thus I would 
> suggest "MAY" in many places where you say link-local address, and 
> "MAY" where you say "/128 prefix".

I think you and others should form a design team to
formulate an addressing model for the subnets you
want.  Be sure to explain why you need for the work
you identify to be done within the [autoconf] working
group.  Maybe you will be happy with DHCP and DAD
and won't need to do anything more.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 15:26:22 -0700

Hello Alex,

Since you CC:'d me, I feel that it should be O.K.
for me to supply a response.

> Would you agree to say "the utility of /128 prefixes is limited"?

The utility of /128 prefixes is that using them enables
solutions in all circumstances.

Is that limited?

> (and I invite implementers to do it and report back problems thank you).

You seem to have already dismissed the experience of
many implementors on this list.  Moreover, as has been
noted before, MAY != ("SHOULD"+"SHOULD NOT").
In fact it is not helpful at all to understand what is at issue.

> Again, a MAY would be a better fit.

MAY is completely worthless in this context.
It adds almost no information, and absolutely
no practical information.

> (the "/128" prefix recommendation) for a variety of reasons, making 
> them limited use too:

> (1) it doesn't scale to large domain, 

How large do you need?

> (2) can't connect to the Internet,

Wrong.

> (3) consumes more ressources than /64-or-shorter prefixes (cycles: 
> instead of average 64 bit comparisons you use a sure 128 bit 
> comparisons, memory: instead of one entry covering several 

Here, I agree.  Perhaps you might evaluate the
cost of the memory.  Compare it to the cost of
imposing more DAD or NUD cycles over the air.

> It sounds as we have it completely reverse, and "MAY" may solve it.

I don't think so.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 23:32:24 +0100

Charles E. Perkins a écrit :
>>> Such subnet prefix assignment is outside the scope of this
>>> document, since it depends on the specific characteristics of the
>>> physical links and network interfaces.
>> 
>> document) with prefix assignment which does not depend on the
>> specific characteristics of the physical links and network
>> interfaces.  DO you think it is possible to even send a message on
>> a physical link and network interface without knowing its MTU, for
>> example?
> 
> Yes, I do.  There are minimal sizes involved as well as maximal
> sizes.

Charles, this is in an interesting point that I just stumbled across in
ROLL too.  I think the minimum sized packet isn't standardized.  One may
think 40bytes but that's no payload at all.  One may think 41bytes but
there's no Protocol number for a payload of only 1 bute.  ETc.

So what would be the minimum packet sized for IPv6?

But that's not the most important point here.

The important point is that the stack must know the MTU before sending a
packet otherwise it may be tempted in sending huge packets, payload
after payload.

If the AUTOCONF link is such undefined such that even the MTU is unknown
then the stack has much problems sending packets on it.

>  and network interfaces.  And, since this is very general, it would 

:-)

>  document.  Those techniques would not work for all links.

:-)

Charles, I gave a long list of links.  That is not specific.  That list
is very heterogeneous.

On one hand I read your text as ideal, which I share (IP runs over
everything), on another hand the programmer has often real links at
hand, not some undefined link.

>>> the only addresses which can be assumed "on link", are the
>>> address(es) of that interface itself.

Let's try this ^ text again.

What does it mean?  I can accept for a while MANET link being a link
with no assumption of connectivity.

But then, what does it mean "the only address assumed "on link" is the
address of that interface"?  Do you mean there is nobody else on that
link?  If there is nobody else on that link then it is an "off link",
per rfc4861 def of "off link".

Do you mean that all addresses in MANET link are off-link?

Really, however I struggle to read that phrase I can't parse.

>> You are mixing interface scope with link scope.  This should be
>> kept disambiguated, scopes 2 and 1.
>> 
>> An address "off link" is an address absent from the node and from
>> all the nodes on that link.
>> 
>> An address on-interface (not sure the terminology exists) can't go
>> on the link on which that interface attaches, because its scope is
>> solely that interface (scope 2 in rfc4291, which does exist).
>> 
> Good luck with that!  On balance, the abovementioned text is quite
> clear.  I didn't write it, by the way.

Sorry for saying 'you'.

I meant to say that that text says something I can't parse.

Let's have the definitions of "link", "on link", "off link", "link
scope", "interface scope".  These are widely used and implemented and
have their meanings understood as per rfc4861 and addr architecture and
other docs.

>> Let's copypaste here some relevant and recent definitions of link,
>> if you wish.  I could help.

Any interest in that ^ ?

>>> Subnet prefix configuration on such interfaces, SHOULD NOT make
>>> addresses
> 0th hop doesn't leave the node.  I think the statement above is
> correct.

Yes, I think I actually agree with you on that.  I often stumble
between 0 and 1...

>>> other than that of the interface itself.  This suggests the
>>> following principle:
>> 
>> Yes, the principle is that you want to define an on-interface
>> scope. The problem with it is that it doesn't go out on a link.
> 
> Your second statement is not correct.  The transmission occurs on the
> link to the neighbor.

Well, clearly an "interface-local scope" means it stays on that
interface, not go on link, as per arch doc.  A "link scope" - it stays
on that link, not global, etc.  That "interface-local" scope is for
multicast addresses.

I have never seen an address in that interface-local scope.

When reading the draft-baccelli draft it makes me think of such an
address, because it says it is "on link", it is on interface, there's
nobody else on that link, yet it's not "off link".

Your use of neighbor... is it on purpose(?)... ND?  NHDP?

>>>  interfaces, IP packet exchange is enabled regardless of the IP
>>> subnet configuration on each of these interfaces.
>> 
>> This sounds ok to me, it is very well said.  Moreover, IP can run
>> on links which have no MAC at all.
>> 
>> mention the word link-local or link-local address anywhere
>> throughout - I agree.
> 
> I think it is not the best choice, but better than dawdling for even
> one more month on these link-local details.

I agree with you on this.

>>> arbitrary, since the fundamental reasoning and understanding

Ok let's say there's no common crystal clear understanding of what the
draft says about link-local addresses.

> This statement is wrong in more than one way: - I didn't use them -
> That is not why they are used in the document - The proportion of
> them depending on probably-not-unique MAC is not evaluated - The
> reason for /128 is not as you suggest - The reason for /128 is not
> completely illogic -  illogic is syntactically incorrect (I do not
> fault you for this one).
> 

Ha :-)  let's agree that saying "/128" is not saying "/10" - we can
agree on that, right?  I.e. saying "/128" excludes saying "/10".

> In my opinion it should the the last resort, and a recognition that
> the working group insists on making progress as slowly as possible.
> But still better than zero progress, so I support it as a last
> resort.

I support it too not only as last resort - if Chairs want to decide that 
now - I am all for it - LLs out of the doc, completely, now.

As for the /128 recommendation we can discuss separately, one thread is
not enough.

>>> I also used "SHOULD" and "SHOULD NOT" instead of "MUSTs", since
>>> it seems to me that systems can clearly be built that do not
>>> adhere to the recommendations.  Nevertheless, in the absence of
>>> system-specific assumptions, the general recommendations are
>>> expected to be followed. This last sentence is merely a
>>> regurgitation of the definition of "SHOULD".
>> 
>> explored.  In the case of LLs things are widely used already,
>> tested, demonstrated, in a different way that you suggest.  Thus I
>> would suggest "MAY" in many places where you say link-local
>> address, and "MAY" where you say "/128 prefix".
> 
> 
> I think you and others should form a design team to formulate an
> addressing model for the subnets you want.  Be sure to explain why
> you need for the work you identify to be done within the [autoconf]
> working group.  Maybe you will be happy with DHCP and DAD and won't
> need to do anything more.

Well, not for the moment.  For the moment let's do this document.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 29 Oct 2009 23:46:19 +0100

Charles E. Perkins a écrit :
> 
> Hello Alex,
> 
> Since you CC:'d me, I feel that it should be O.K. for me to supply a 
> response.
> 
> 
> The utility of /128 prefixes is that using them enables solutions in 
> all circumstances.
> 
> Is that limited?

Yes, limited by its trade-offs (memory and search time you agree below).

>> Well, LLs are a SHOULD on many interfaces.  A SHOULD and and a 
>> SHOULD NOT could give a "MAY":  "a /128 prefix on this interface 
>> MAY be /128". (and I invite implementers to do it and report back 
>> problems thank you).
> 
> You seem to have already dismissed the experience of many 
> implementors on this list.

Yes, we have an issue here.

Many implementers on this list have often disregarded the fact that the
LL address was there.  Because of that, let us continue this complete
disregard and not say MAY LL, neither SHOULD LL, nor MUST NOT LL.  Just
don't say LL - because they have always been completely disregarded -
let us have this draft reflect that particular implementer situation.
Disregarded in implementation, disregarded in the draft.

But don't say wrong things about them.

> Moreover, as has been noted before, MAY != ("SHOULD"+"SHOULD NOT").

I tend to agree too.

>>>> draft-baccelli says:
>>>>> o  Any [IPv4] subnet prefix configured on this interface 
>>>>> should be of length /32.
> MAY is completely worthless in this context. It adds almost no 
> information, and absolutely no practical information.

Hmmm, I tend to agree... I often believe that seeing "MAY" is seeing
lack of consensus.  It is a big problem when trying to implement.

[...]
>> I believe that "dicouraged" fits better the use of host-based 
>> routes (the "/128" prefix recommendation) for a variety of reasons,
>>  making them limited use too:
> 

Hmmm, it can't become as big as the Internet is now.

>> (2) can't connect to the Internet,

Can we talk about it without going solution space?

I think we should talk about it in an addressing model draft which does
not disturb the non adhoc aware nodes (i.e. Internet nodes).

> Here, I agree.  Perhaps you might evaluate the cost of the memory. 
> Compare it to the cost of imposing more DAD or NUD cycles over the 
> air.

Hmm... I do like the distributed manner of DAD+SLAAC, instead of
req-resp messages between someone trying to obtain an address and
someone delivering it one.  This latter has its own problems.

>> It sounds as we have it completely reverse, and "MAY" may solve it.

Now that you say it, I think too so, a bit.

I think better get rid of them (LLs) entirely rather than talk in an
unconsensual way of them.

Then we'll see the /128s recommendation separately.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 16:00:51 -0700

Hello Alex,

> So what would be the minimum packet sized for IPv6?
You already know the answer to that, and you probably already
know that some device drivers have to run adaptation software
in order to manage transmission over media not supporting
large packets.  And you certainly already know that it is possible
to transmit IPv6 packets with size far less than the minimum MTU.

> But that's not the most important point here.

I thoroughly agree with that.

> packet otherwise it may be tempted in sending huge packets, payload

I doubt this, for any sane operating system.

Not everything runs over TCP.

> then the stack has much problems sending packets on it.

Not in my experience.

> Charles, I gave a long list of links.  That is not specific.  That list

This so thoroughly misses the point I am not sure
just how to respond.

> hand, not some undefined link.

Well at least I have finally received a very high compliment.
I rarely suspect that my text might be ideal.

For the rest of your comment, I invite you to consider the
implications of having device drivers with well-defined
interface routines.

> per rfc4861 def of "off link".
It means that you don't automatically know the layer-3 addresses
of nodes reachable by that link.

Really, Alex, couldn't you figure this out?

> Do you mean that all addresses in MANET link are off-link?
No.

> Really, however I struggle to read that phrase I can't parse.

Try harder.

> I meant to say that that text says something I can't parse.

Try!

Don't try to imagine ways that it might be questionable and
argued to infinity in an alternate universe.  Try instead to
understand what it might mean.

That's what I do.

> have their meanings understood as per rfc4861 and addr architecture and

Good luck with dancing on that mattress of nails.

>>> if you wish.  I could help.

No.

> Your use of neighbor... is it on purpose(?)... ND?  NHDP?
You ought to know.  If not, then read the previously cited
Baccelli/Perkins document.

> draft says about link-local addresses.

That is certainly true.

> agree on that, right?  I.e. saying "/128" excludes saying "/10".

I'm not concerned with this, and don't care to
state a position.

> Well, not for the moment.  For the moment let's do this document.

I really think you ought to get with your colleagues into a
task force.  You are not helping with this document, in my
opinion.

Regards,
Charlie P.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 30 Oct 2009 00:07:15 +0100

Alex,

You must understand, that the things which you are trying hard to  
deconstruct are things which this WG has spent ~5 years reaching an  
understanding of as a viable approach -- an understanding based on  
"running code" and real networks.....real AD HOC networks, even.

Real ad hoc networks, connected to the Internet and with real and  
regular applications running and in operation with real users (i.e.  
outside a limited lab environment).

I would appreciate if you would try to understand the reasons for why  
the Townsley/Baccelli recommends as it does -- rather than blindly  
picking out issues and declaring open war on those. You have been  
given numerous references to documents which could help further your  
understanding.

We have existence proof that the recommendations in the Townsley/ 
Baccelli document work....in real ad hoc networks, connected to the  
internet, and with hosts running regular applications and protocols.

Thanks,

Thomas

On Oct 29, 2009, at 11:46 PM, Alexandru Petrescu wrote:

>> Since you CC:'d me, I feel that it should be O.K. for me to supply  
>> a response.
>> The utility of /128 prefixes is that using them enables solutions  
>> in all circumstances.
>> Is that limited?
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 16:08:11 -0700

\Hello Alex,

> Disregarded in implementation, disregarded in the draft.
This is not responsive to the need.

> But don't say wrong things about them.

This is good advice, as always.

> Hmmm, it can't become as big as the Internet is now.

Is that your test for utility?

> Can we talk about it without going solution space?

It's mathematically proven that your statement is wrong,
by the mere existence of a counterexample.

> not disturb the non adhoc aware nodes (i.e. Internet nodes).
We already did.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Oct 2009 00:20:49 +0100

Thomas Heide Clausen a écrit :
> picking out issues and declaring open war on those. You have been given 
> numerous references to documents which could help further your 
> understanding.
> 
> We have existence proof that the recommendations in the 
> Townsley/Baccelli document work....in real ad hoc networks, connected to 
> the internet, and with hosts running regular applications and protocols.

How do these networks use the link-local addresses?  If somehow - please 
state how.

If not at all - then please don't talk about them.

About the /128 let's talk separately.

Alex

>>>> SHOULD NOT could give a "MAY":  "a /128 prefix on this interface MAY 
>>>> be /128". (and I invite implementers to do it and report back 
>>>> problems thank you).
>>>> (the "/128" prefix recommendation) for a variety of reasons,
>>> Compare it to the cost of imposing more DAD or NUD cycles over the air.
>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 30 Oct 2009 00:22:51 +0100

On Oct 30, 2009, at 12:20 AM, Alexandru Petrescu wrote:

>> I would appreciate if you would try to understand the reasons for  
>> why the Townsley/Baccelli recommends as it does -- rather than  
>> blindly picking out issues and declaring open war on those. You  
>> have been given numerous references to documents which could help  
>> further your understanding.
> How do these networks use the link-local addresses?  If somehow -  
> please state how.
>

As described in the Townsley/Baccelli document and in the many other  
documents that have been handed to you.

> About the /128 let's talk separately.

No. They are an integral part of the addressing model that has an  
existence proof.

Thomas

>>>> Since you CC:'d me, I feel that it should be O.K. for me to  
>>>> supply a response.
>>>>> MAY be /128". (and I invite implementers to do it and report  
>>>>> back problems thank you).
>>>>> (3) consumes more ressources than /64-or-shorter prefixes  
>>>>> (cycles: instead of average 64 bit comparisons you use a sure  
>>>>> 128 bit comparisons, memory: instead of one entry covering  
>>>>> several destinations you use an entry for each destination in  
>>>>> each router).
>>>> Here, I agree.  Perhaps you might evaluate the cost of the  
>>>> memory. Compare it to the cost of imposing more DAD or NUD cycles  
>>>> over the air.
>>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Oct 2009 00:22:57 +0100

> This is good advice, as always.

No, it is not good advice to talk about things one doesn't know, sorry. 
  I agree, myself I don't know many things - but then I don't talk about 
them in my drafts.

It's wrong to say that because Clausen adhoc network does not use LLs 
then I should not use them.  Sorry about that and please get rid of them 
(LLs).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Oct 2009 00:36:54 +0100

> to transmit IPv6 packets with size far less than the minimum MTU.

YEs yes, I'll give separately the context elsewhere when needed.

[...]
>> then the stack has much problems sending packets on it.

Did you experience receiving an RA with an MTU in it?  Did you 
discourage that to, because it depends on the link characteristics? 
(you==one)

[...]
> of nodes reachable by that link.

Nobody said one would automatically know the L3 address of node on that 
link.  If having their MAC addresses, Inverse Neighbor Discovery may help.

What's the problem with that?

> Really, Alex, couldn't you figure this out?

No, really, I am completely lost.

That paragraph is completely un-parsable to me.

You refuse to have a common definition of a link, and this is not right.

>> Do you mean that all addresses in MANET link are off-link?

They're "on link", and they are the only ones assumed (by whom? by 
thesmelves?  by the authors?) to be on link.

What is this talking about?  IT's really unclear.

>> Really, however I struggle to read that phrase I can't parse.

No, I stop here.  You try to explain that to whomever will ask you about 
it.  I no longer care.

[...]
> Baccelli/Perkins document.

No, I am fed up, really.  No negative intention but I am fed up.

> I'm not concerned with this, and don't care to

Well try to - saying that you use _only_ /128 means you don't use /10 
(LL) that's as clear as it gets.

> task force.  You are not helping with this document, in my

No, I will get from your way without needing to get into a Task Force. 
I am completely fed up.

Yours,

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Oct 2009 16:38:27 -0700

Hello Alex,

Alexandru Petrescu wrote:
>
> No, it is not good advice to talk about things one doesn't know, 
> sorry.  I agree, myself I don't know many things - but then I don't 
> talk about them in my drafts.

This doesn't seem to be responsive to the
thread of discussion -- or at least I don't
see the connection.

> then I should not use them.  Sorry about that and please get rid of 
> them (LLs).

Nobody said that you should not use them.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Oct 2009 00:41:08 +0100

Thomas Heide Clausen a écrit :
>>> Townsley/Baccelli document work....in real ad hoc networks, connected 
>>> to the internet, and with hosts running regular applications and 
>>> protocols.
>>

YEs - they discourage it.  That was  your way of using LLs? 
Discouraging them?  How did you discourage their use other than not 
using them?  Did you add some timers aging them slowly out?

> No. They are an integral part of the addressing model that has an 

Ok, no then.

I am fed up anyways.

Alex