Subject: [Autoconf] Conclusion: draft-ietf-autoconf-adhoc-addr-model-02.txt

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 16 Feb 2010 11:59:44 -0800

Dear All,

We have concluded the WGLC of
draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a -02
document issued, following up on this.

Thanks to all for all the reviews and comments to this document!

After Thomas and I (Chairs) carefully reviewed discussions on the
mailing list, we do find that there is rough consensus for the current
document.

There was an individual objection to the description of the use of
link-local address, but we did not detect wide support within the
working group. This objection will, of course, be reflected in the PROTO
write-up that will be sent to the IESG and the ADs, and reflected in the
tracker.

As a conclusion, we have established rough consensus to the new document.

The WG chairs will start preparing the PROTO writeup for forwarding the
document.

Thanks,

WG chairs

---

From: Jari Arkko <[email-masked]>
Date: Tue, 16 Feb 2010 22:01:15 +0200

Great. Lets move this doc forward!

Jari

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 16 Feb 2010 12:03:10 -0800

We will send you the PROTO document shortly.

thanks for waiting!
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Feb 2010 21:18:34 +0100

Le 16/02/2010 20:59, Ryuji Wakikawa a écrit :
> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and have a
> -02 document issued, following up on this.
>
> mailing list, we do find that there is rough consensus for the
> current document.
>
> working group.

Please make that count 2 not 1.

I already sent a few days ago a public mail response to ThomasC.  I said
"well I believe it should [treat multicast]".

Me too I object to the lack of treatment of multicast in this draft.
Multicast is the very first thing happening when booting up.  It's the
only thing that can help autoconf.  This draft ignoring multicast shows
signs autoconf can't happen.

Multicast is what helps DHCP happen, which is a kind of what autoconf
tries to achieve.  Multicast helps many other protocols trying to do
things as autoconf tries.

Multicast is what an RFC MANET document reserves in its IANA section.

> This objection will, of course, be reflected in the PROTO write-up
> that will be sent to the IESG and the ADs, and reflected in the
> tracker.

Please add the multicast objection too thank you.

Alex

> The WG chairs will start preparing the PROTO writeup for forwarding
> the document.
>
> Thanks,
>
> WG chairs
>
> _______________________________________________ Autoconf mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Feb 2010 21:20:30 +0100

> Great. Lets move this doc forward!

YEs, let's move this forward and add multicast discussion to it without 
which autoconf can't fly.  Multicast is what typical autoconfiguration 
protocols use today without which they'd never work.

Multicast is what IPv6 got builtin precisely for the reason of autoconfing.

This draft being silent about multicast spells it's not autoconf, IMHO.

Alex

> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Feb 2010 21:21:13 +0100

> We will send you the PROTO document shortly.

YEs, please the PROTO document shortly and add multicast discussion to 
it too, thank you.

No more waiting,

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 16 Feb 2010 21:23:26 +0100

Dear Alex,

Autoconf is about configuring addresses on interfaces, not on  
allocating addresses in a registry, not sending IP packets to  
multicast destinations.

Sincerely,

Thomas

On Feb 16, 2010, at 21:20 PM, Alexandru Petrescu wrote:

> YEs, let's move this forward and add multicast discussion to it  
> without which autoconf can't fly.  Multicast is what typical  
> autoconfiguration protocols use today without which they'd never work.
>
>>> current

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Feb 2010 21:29:00 +0100

> allocating addresses in a registry, not sending IP packets to

Thomas, thank you for the reply.

Link-layer multicast mechanisms are used in any autoconfing (DHCPv6,
SLAAC, probably more) mechanism.

A stack booting up sends packets to multicast destinations.

MANET already allocates a multicast address for this.

Suffices it to mention it.

Otherwise leave place for non-understanding: will the IPv6 autoconf
stack use the MANET multicast address?  Or the other non-MANET multicast
address?

I mostly agree with you.

And there are two different people here (Teco, myself) saying
approximately the same thing about multicast.  The autoconf group is not
large.  Are two opinions worth ignoring?

Alex

>>>> draft-ietf-autoconf-adhoc-addr-model-01.txt on Dec/23/09, and
>>>> have a -02 document issued, following up on this.
>>>>
>>>> After Thomas and I (Chairs) carefully reviewed discussions on
>>>> the mailing list, we do find that there is rough consensus for
>>>> the current document.
>>>>
>>>> There was an individual objection to the description of the
>>>> use of link-local address, but we did not detect wide support
>>>> within the working group. This objection will, of course, be
>>>> reflected in the PROTO write-up that will be sent to the IESG
>>>> and the ADs, and reflected in the tracker.
>>>>
>>>> The WG chairs will start preparing the PROTO writeup for
>>>> forwarding the document.
>>>>
>>>> Thanks,
>>>>
>>>> WG chairs
>>>>
>>>>
>>>
>>> _______________________________________________ Autoconf mailing
>>> list [email-masked]
>> _______________________________________________ Autoconf mailing
>> list [email-masked]

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 16 Feb 2010 21:35:34 +0100

Dear Alex,

> Suffices it to mention it.

These reflections belong properly in the problem-statement/scoping and  
solution-space discussions -- hopefully, we will be able to get to  
those (the fun part: building protocols) soon. So hold that thought  
until later.

> stack use the MANET multicast address?  Or the other non-MANET  

If I configure my addresses manually, as is one viable option, I can  
follow the recommendations in draft-ietf-autoconf-adhoc-addr- 
model-02.txt and have a valid configuration. In that case, the  
"configuration mechanism" needs no multicast. I note that this may  
apply more to IPv4 than IPv6, and that the document covers both.

If a MANET autoconfiguration protocol needs to exchange information  
for proper functioning - which it may well do - then that protocol  
will have to decide on which addresses, messages and algorithms to use  
for that. So again, these reflections belong properly in the problem- 
statement/scoping and solution-space discussions.

Sincerely,

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 16 Feb 2010 21:41:08 +0100

ThomasC, oh sorry, so the problem statement document is going to happen 
later?  We're not yet at that stage?

And in this "IP Addressing Model in Ad Hoc Networks" we don't even 
mention multicast addresses, as if the multicast address were not an 
address?

Sorry for disturbing but my remark was really gentle, I thought the 
draft could easily mention multicast address.

I sometimes feel that the more I ask a thing the less it gets accepted. 
  IT must be because it comes from me :-)

I will shut up maybe things will happen better :-)

Alex

Le 16/02/2010 21:35, Thomas Heide Clausen a écrit :
> solution-space discussions -- hopefully, we will be able to get to those
> (the fun part: building protocols) soon. So hold that thought until later.
>
> follow the recommendations in
> draft-ietf-autoconf-adhoc-addr-model-02.txt and have a valid
> configuration. In that case, the "configuration mechanism" needs no
> multicast. I note that this may apply more to IPv4 than IPv6, and that
> the document covers both.
>
> If a MANET autoconfiguration protocol needs to exchange information for
> proper functioning - which it may well do - then that protocol will have
> to decide on which addresses, messages and algorithms to use for that.
> So again, these reflections belong properly in the
> problem-statement/scoping and solution-space discussions.
>
> Sincerely,
>
> Thomas
>
>> I mostly agree with you.
>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 16 Feb 2010 15:59:23 -0800

Hi Alex,

On 2010/02/16, at 12:41, Alexandru Petrescu wrote:

> ThomasC, oh sorry, so the problem statement document is going to happen later?  We're not yet at that stage?

Thomas means a problem statement document for the future solution space, since you start explaining solution spaces.
The addr-model document is not a solution. There is no need to have a problem statement at this stage.

> And in this "IP Addressing Model in Ad Hoc Networks" we don't even mention multicast addresses, as if the multicast address were not an address?
> 
> Sorry for disturbing but my remark was really gentle, I thought the draft could easily mention multicast address.
> 
> I sometimes feel that the more I ask a thing the less it gets accepted.  IT must be because it comes from me :-)

Not at all. We cannot adapt comments only when there is less supporter. 
We have to move forward based on the consensus. 

> I will shut up maybe things will happen better :-)

:-)

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Feb 2010 15:51:37 +0100

HEllo AUTOCONFers,

About a non-technical matter of draft-ietf-autoconf-adhoc-addr-model.

Its boilerplate currently says "Code Components extracted from this
document must include Simplified BSD License...".

I disagree with it for three reasons.  First and foremost I do not want
Code Components extracted from this document to include that license,
but another one.  E.g. if linux kernel implements it then GPL is more
suitable.  Second, if there are no Code Components then it would be
useless to talk about Code Components.

Also I disagree with it because the implementation experience which has
been shared on this list often has been about linux, and which is often
GPL and rarely BSD license.

I also have to say I understand fully that the boilerplate is there from
the IETF Trust to which I am bound to abide, by the fact that I am
subscribed to this list.

Respectfully,

Alex
(this is about a series of I-Ds I am following in several WGs)

Le 16/02/2010 20:59, Ryuji Wakikawa a écrit :
> working group. This objection will, of course, be reflected in the
> PROTO write-up that will be sent to the IESG and the ADs, and
> reflected in the tracker.
>

---

From: Zach Shelby <[email-masked]>
Date: Wed, 17 Feb 2010 17:01:02 +0200

Alex,

There is no code in this I-D, therefore this is pointless. And as this is the IETF trust boilerplate, it is also useless to discuss it here as you pointed out yourself. 

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Feb 2010 16:04:10 +0100

> useless to talk about Code Components.
You can get from "simplified BSD" (2-clause BSD) to GPL. The other way around 
is not possible.

See http://tinyurl.com/ykwyud4 (Link to wikipedia).

Forcing GPL would mean that the code fragments cannot be included into 
commercial software, which contradicts the purpose of the IETF RFCs.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 17 Feb 2010 16:11:03 +0100

Alex,

I second Zach. This I-D does not contain any code. And as you have been
indicated in the ROLL WG, this mailing list is the wrong place to discuss
the boilerplate.

Ulrich

On Wed, Feb 17, 2010 at 4:01 PM, Zach Shelby <[email-masked]> wrote:

> Alex,
>
> There is no code in this I-D, therefore this is pointless. And as this is
> the IETF trust boilerplate, it is also useless to discuss it here as you
> pointed out yourself.
>
> Zach
>
> This e-mail and all attached material are confidential and may contain
> legally privileged information. If you are not the intended recipient,
> please contact the sender and delete the e-mail from your system without
> producing, distributing or retaining copies thereof.
>
>
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 17 Feb 2010 16:16:41 +0100

Dear Alex,

<wg-chair-hat-on>

As has been pointed out to you by Adrian Farrel (RTG AD) on [email-masked] 
, when you raised the exact same issue there, discussions concerning  
the I-D boilerplate and licensing are appropriate on the tlp-interest  
mailing list -- and NOT on WG mailing lists.

I would therefore kindly ask that you move this discussion to the  
appropriate mailing list -- and that you cease discussion on this  
particular matter on [email-masked].

I entered "tlp-interest mailing list" in a well-known web-search  
engine, which as first result returned this URL -- which I believe  
would be a more appropriate venue, should you want to continue  
discussing this:

	https://www.ietf.org/mailman/listinfo/tlp-interest

Thanks in advance for your kind cooperation on this matter,

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Feb 2010 18:24:55 +0100

ThomasC, members of WG autoconf - don't overeact.

FYI I started a discussion on the tlp-interest cc'ing trustees; first
about the procedure (should we always cc trustees, as the trustees
request, even if it bounces back?).  Later I will mention boilerplate.

My statement about the licensing scheme is not intended for discussion.
  It is a public statement showing my personal opinion on the licensing
scheme of this draft.  It discharges me personally from any legal bind I
may have with what may happen later with this draft (from a legal
standpoint).

(I am trying to do the same with every draft I have been following or
  commented on recently, because I just discovered the new strict BSD
  licensing in the boilerplate.)

Yours,

Alex

Le 17/02/2010 16:16, Thomas Heide Clausen a écrit :
> Dear Alex,
>
> <wg-chair-hat-on>
>
> As has been pointed out to you by Adrian Farrel (RTG AD) on
> [email-masked], when you raised the exact same issue there,
> discussions concerning the I-D boilerplate and licensing are
> appropriate on the tlp-interest mailing list -- and NOT on WG
> mailing lists.
>
>> I disagree with it for three reasons. First and foremost I do not
>> want Code Components extracted from this document to include that
>> license, but another one. E.g. if linux kernel implements it then
>> GPL is more suitable. Second, if there are no Code Components then
>> it would be useless to talk about Code Components.
>>
>> Also I disagree with it because the implementation experience
>> which has been shared on this list often has been about linux, and
>> which is often GPL and rarely BSD license.
>>
>> I also have to say I understand fully that the boilerplate is
>> there from the IETF Trust to which I am bound to abide, by the fact
>> that I am subscribed to this list.
>>
>> Respectfully,
>>
>> Alex (this is about a series of I-Ds I am following in several
>> WGs)
>>
>>> There was an individual objection to the description of the use
>>> of link-local address, but we did not detect wide support within
>>> the working group. This objection will, of course, be reflected
>>> in the PROTO write-up that will be sent to the IESG and the ADs,
>>> and reflected in the tracker.
>>>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 17 Feb 2010 10:23:48 -0800

Hello Alex,

On 2/16/2010 12:20 PM, Alexandru Petrescu wrote:
> which autoconf can't fly.

What if we find that the requirements for a
mobile ad hoc network do not enable us to
rely on a typical autoconfiguration  protocol?

>  Multicast is what typical autoconfiguration

This isn't true.  In every case I am aware of, we could
have designed for pure broadcast operation.

But of course you might just say that broadcast is a
special case of multicast.  In that case, your
argument completely loses its apparent force anyway.

> Multicast is what IPv6 got builtin precisely for the reason of autoconfing.

Nothing wrong with using the tools available to
perform the function for which they were built
in the systems where they can be expected to work.

> This draft being silent about multicast spells it's not autoconf, IMHO.

Well, I strongly disagree, especially since your
arguments as I understand them are fatally flawed.

However, I'd be happy to have a non-tree-based
local multicast group consisting of all members
within range of a node.  There's absolutely zero
multicast protocol required to maintain membership
in this group, conveniently.

I would not insist to have that group definition
appear in the addr-model draft.

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 17 Feb 2010 19:35:37 +0100

> in the systems where they can be expected to work.
I think most "autoconf protocols" just use a linklocal multicast, which is the 
same as a broadcast without retransmission.
 
> in this group, conveniently.
Do current IP stacks even have something like "linklocal membership" ?

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 17 Feb 2010 19:41:33 +0100

Charles - I must say thank you for the reply about motivating the
absence of multicast in the autoconf addressing model because of its
ressemblance to broadcast, lack of tools to build trees and dedicated
suitability to non-MANET environments.

I will excuse myself for not replying.  I don't because this group is
not friendly.

Later, when we wonder who owes an answer to whom - it'll be simpler :-)

Alex

Le 17/02/2010 19:23, Charles E. Perkins a écrit :
>> without which autoconf can't fly.
>
> What if we find that the requirements for a mobile ad hoc network do
>  not enable us to rely on a typical autoconfiguration protocol?
>
>
>> Multicast is what typical autoconfiguration protocols use today
>> without which they'd never work.
>
> This isn't true. In every case I am aware of, we could have designed
>  for pure broadcast operation.
>
> But of course you might just say that broadcast is a special case of
>  multicast. In that case, your argument completely loses its apparent
>  force anyway.
>
>
> Nothing wrong with using the tools available to perform the function
>  for which they were built in the systems where they can be expected
>  to work.
>
> Well, I strongly disagree, especially since your arguments as I
> understand them are fatally flawed.
>
> However, I'd be happy to have a non-tree-based local multicast group
>  consisting of all members within range of a node. There's absolutely
>  zero multicast protocol required to maintain membership in this
> group, conveniently.
>
> I would not insist to have that group definition appear in the
> addr-model draft.
>
>
> Regards, Charlie P.
>
>