Subject: Re: [Autoconf] Input to the IESG on draft-templin-autoconf-dhcp

From: Shubhranshu <[email-masked]>
Date: Tue, 21 Oct 2008 17:32:50 +0530

Hello Thomas,

Thanks for your detail comments. My input is not to permanently block
the document but to postpone for a while. Apart from overlap of work,
the reasoning was, using the language of 3932bis, "Publication of the
document will give the publishing party an RFC number before the WG is
finished. It seems better to have the WG product published first, and
have the non-adopted document published later". I agree, AFAIK, there
is no vendor desperately waiting for the output of this group to ship
product however I worry that having an already published RFC with
certain architectural assumptions and solutions might confuse,
influence and help further lose interest/effort in design and
agreement of wg's architecture/solutions.

I agree, the reason for my input to delay the publication of this
document is not as strong as in the case of Photuris that you
mentioned but then I do not find any strong reason supporting its
immediate publication.

To answer your other question, there are different ways to contribute
at this point. One could directly provide inputs to the members
involved in the ongoing effort, propose text on the architectural
issues raised and help discussion towards conclusion and accelerate
the work.

- Shubhranshu

----- Original Message -----
From: "Thomas Narten" <[email-masked]>
To: "Shubhranshu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Monday, October 20, 2008 7:27 PM
Subject: Re: [Autoconf] Input to the IESG on draft-templin-autoconf-dhcp

> Shubhranshu <[email-masked]> writes:
>
>> Currently the group is working on the architecture document and IMO,
>> at this point publishing draft-templin-autoconf-dhcp, which makes
>> specific architectural assumptions would likely influence and
>> undermine the WG effort.
>
> Please explain how or why this is so. Especially "undermine".
>
> IMO, having the topic of an ID overlap with the work (or potential
> work) in a chartered WG is not (by itself) sufficient justification to
> block or delay publication. The IETF has a long history of publishing
> work that is related to a WG effort, so long as doing so doesn't cause
> any obvious or significant harm.
>
> I very much do think it is valid to block publication of a document if
> (say) the market is going to be confused about the RFC and somehow
> implement it rather than waiting for the IETF effort -- and in a way
> that significantly harms interoperability. For the classic example of
> where this was done, publication of the Photuris documents was blocked
> until the original IPsec documents set was finished. But there was a
> real concern about confusion and fragmentation of a very important
> market (i.e., security), and the Photuris documents had been discussed
> (and rejected) by the WG.
>
> In the case of autoconf, my take is:
>
> There is no vendor or industry segment desperately waiting for the
> output of this group in order to ship product. Thus, having a document
> appear is not likely to "confuse the market" and cause anyone to
> implement the other effort rather than wait for this WG to finish.
>
> (If there is a vendor or industry segement that is waiting for a
> document, please educate me... )
>
> Also, I suspect (but don't know for sure) that the author has simply
> given up on waiting for the WG to actually do anything. Certainly,
> such a view would be justified.
>
>> Considering this and noting that the draft-templin-autoconf-dhcp
>> overlaps with the Autoconf work, my input to the IESG is to delay the
>> publication of draft-templin-autoconf-dhcp for, say six months. During
>> this time I'd strongly encourage authors of
>> draft-templin-autoconf-dhcp and other members of the group to
>> contribute to the wg MANET architecture document.
>
> Um, to speak frankly/bluntly, this WG has been dysfunctional for the
> last year. (Just look at what it has actually done and how much
> progress it has made.) Suggesting that the authors need to participate
> in the WG effort more is a Red Herring. Exactly what should the
> authors (or anyone else for that matter?) be doing that they haven't
> been?
>
> In summary, for the IESG (or this WG) to recommend blocking a
> document, it needs to be clear about why such a step is
> appropriate. There needs to be some clear potential harm resulting
> from publication.
>
> Consider draft-housley-iesg-rfc3932bis-04.txt:
>
> Section 3 lists the conditions under which publication can be
> blocked. The two categories that seem relevant to the present
> discussion are:
>
>   The IESG review of these Independent Stream and IRTF Stream documents
>   reach one of the following five types of conclusions.
>
>   2. The IESG finds that this work is related to IETF work done in WG
>      <X>, but this relationship does not prevent publishing.
>
>   3. The IESG finds that publication is harmful to the IETF work done
>      in WG <X> and recommends not publishing the document at this time.
>
> For us, the question is which of case 2 or 3 applies. For 3), we
> need to articulate the "harm". IMO, it is not sufficient to just say
> "the work is related" (and indeed, if that were sufficient, there
> would be no need for 2).
>
> Section 4 gives some examples where publication delay or denial may be
> appropriate. Do any of the examples cited there apply to this case?
>
> Thomas
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: Thomas Narten <[email-masked]>
Date: Tue, 21 Oct 2008 08:30:08 -0400

> Thanks for your detail comments. My input is not to permanently
> block the document but to postpone for a while. Apart from overlap
> of work, the reasoning was, using the language of 3932bis,
> "Publication of the document will give the publishing party an RFC
> number before the WG is finished.  It seems better to have the WG
> product published first, and have the non-adopted document published
> later".

This sounds like a generic argument for NEVER allowing related work to
be published if there is an ongoing chartered WG. But from what I can
tell, the IETF has strongly disagreed with this as a starting point
(there have been long discussions about this on the ietf list, leading
to RFC 3932 and its successor
draft-housley-iesg-rfc3932bis-04.txt). The default starting point
should be to allow publication, unless there is a good reason not to.

So, what specific harm or downside is there to publishing a document
now?

> I agree, AFAIK, there is no vendor desperately waiting for the
> output of this group to ship product however I worry that having an
> already published RFC with certain architectural assumptions and
> solutions might confuse, influence and help further lose
> interest/effort in design and agreement of wg's
> architecture/solutions.

>From what I can tell (by the lack of progress in this WG over the last
3 years), nobody really needs this work. If they did, they would be
screaming within the WG to get its act together and make
progress. This alone, suggests to me that nobody is going to be silly
enough to look at an RFC and be "confused" by it.

Also, all RFC editor submissions that get published include the
standard disclaimer making clear that the work is not the output of an
IETF WG. And, they frequently (and could in this case) point people to
the autoconf WG as a place where related work is being done.

> mentioned but then I do not find any strong reason supporting its

Again, the default starting point is "allow publication unless doing
so causes harm" not "you need to convince me there is a good reason to
publish this document".

> issues raised and help discussion towards conclusion and accelerate

Again, these are all high-level, generic suggestions on what to
do. They do not seem to take into account that there has been no
substantive discussion on anything on this mailing list in months, it
didn't meeting in Dubin, and I don't recall the chairs having made any
call to the WG for help on resolving any outstanding issues.

Sorry to be blunt, but I'm very frustrated/disappointed by the lack of
progress of this WG, and given that lack of progress, I think the WG
has absolutely no legitimacy in trying to block publication of a
document just because it "overlaps" with the subject matter of the WG.

Again, I'm open to delaying publication, but I have yet to hear a
compelling argument there is a real harm/drawback to doing so.

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 21 Oct 2008 23:10:37 +0200

Hi Thomas,

> enough to look at an RFC and be "confused" by it.

SCREAM LOUDLY.

I think nobody is satisfied with progress of Autoconf.
Please explain "nobody really needs this work".

IMHO the reason for slow progress / no progress at all is a road block. We
(members of IETF interested in Autoconf) are waiting on Autoconf chairs,
Manet_Arch authors and IESG end a debate that is far out of our sight.

> They do not seem to take into account that there has been no

We had an informal meeting in Dublin, discussed the Manet_Arch debate topic
and some of us have action points.
I offered help
(http://www.ietf.org/mail-archive/web/autoconf/current/msg01084.html), but I
did not receive any response.

I think we need fresh blood in Autoconf for getting work done.

Regards, Teco

---

From: Thomas Narten <[email-masked]>
Date: Wed, 22 Oct 2008 08:32:17 -0400

Hi Teco.

> SCREAM LOUDLY.

Indeed! But where are the screams?

> I think nobody is satisfied with progress of Autoconf.

To be clear, I didn't mean to imply this.

> Please explain "nobody really needs this work".

In my experience, when something is really needed by the market, there
are either multiple vendors with proprietary implementations already
and/or there are vendors that want to implement something (because
customers want it), but they would rather implement a proper standard
than pick one of the proprietary implementations.

In such cases, people are usually screaming rather loudly if the WG is
being too slow and or not delivering.

I simply do not sense that happening with this WG.  (Again, if I am
wrong, please enlighten me.)

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 22 Oct 2008 15:53:57 +0200

Hi Thomas,

OK, now we are in the discussion on whether or not there is an urgent need
for an Autoconf solution. My opinion on this:

 - Fred Templin has a track record on putting a lot of effort on this. His
attempt to get an RFC out there is some evidence. Fred is not the only one
worked hard on Autoconf.

 - Personally I am involved in designing a very large MANET (we could need a
new term for a MANET larger than 10000 nodes, this is missing in
Manet_Arch). I don't see solutions using "flat" MANET routing protocols
supporting this scalability, so I am interested in using hierarchy and
backbone infrastructures for that. Backbones can scale to almost infinity. I
see IPv6 auto address configuration as a nice facility for ad hoc networks,
so therefore I propose using IPv6. In short: Autoconf is important for me.

 - Many military organizations have plans to upgrade their tactical
networks. At least one country takes this extremely serious (lucky guy I am,
as I have a sponsor for my efforts!). Others are also working on it, but not
that active in IETF.

- There is a reason that ISP (and vendors with strong relation to them) are
not that interested in MANETs. Mostly the usage of an ad hoc network is free
of charge. ISPs / Wireless Network Operators cannot live from that, and they
put lots of effort on providing "infrastructure mode" to anybody that can
afford it. I have nothing against this, but sometimes it is not applicable.
The problem here is that some customers need a hybrid mode (ad hoc and
infrastructure), but providers dislike this for business reasons. I think
this will change.

 - For those outside the military that need ad hoc networks, the
organizations are mostly small and do not have the resources to design their
infrastructures. Side remark: the term -ad hoc- is somewhat in contradiction
with -design-. I have contacts outside the military, the problem that I see
there is that the organizations are mostly de-centralized and they have just
started looking at solutions for their data communication needs. Disasters
in the last decade provided evidence that there is a need for ad hoc voice
and data networks (they use other terms also, such as hasty formed
networks). Most pilots are small in size, and the problems with addressing,
routing and multi-homing does not appear yet. But when looking at what they
are doing, the need for solutions like scalable MANETs and auto address
configuration is evident. 

- Many researchers are interested in MANET. Autoconf is not that interested
for them, we just have to define some tricks and we are done. Maybe we have
lack of engineering experience in MANET and Autoconf WGs.

Others:
Please post opinions on this, focused on whether Autoconf work is important
or not.

Kind regards, Teco