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

From: Shubhranshu <[email-masked]>
Date: Mon, 20 Oct 2008 19:00:25 +0530

Below are some of my observations, followed by my input to the IESG:

The Autoconf wg charter says "The main purpose of the AUTOCONF WG is
to standardize mechanisms to be used by ad hoc nodes for configuring
unique local and/or globally routable IPv6 addresses."

One of the goals of the WG is (taken from the charter) "Develop an
IPv6 address autoconfiguration mechanism to be used by ad hoc nodes
for configuring unique local addresses as well as, in cases where
Internet connectivity exists, globally routable unique addresses."

The document, draft-templin-autoconf-dhcp says  (introduction section)
"The different types of interfaces are defined, and the
autoconfiguration mechanisms used for each type are specified. "
Section 4 then specifies autoconfiguration of EIR, EBR,  EBG.

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

- Shubhranshu

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Cc: "Ross Callon" <[email-masked]>
Sent: Wednesday, October 15, 2008 5:09 PM
Subject: [Autoconf] Input to the IESG on draft-templin-autoconf-dhcp

> Dear all,
>
> There are several ways to publish RFCs. One method is to take the
> document through a working group and the IETF process, and publish it as
> an RFC when last call and IESG review have been completed.
>
> Another method is called the Independent Submission method, and it
> allows people to submit documents to the RFC Editor directly, without
> any IETF review. Given the lack of review at the IETF, these are not
> standards of any sort. However, they can still be valuable contributions
> and they are often used, for instance, to document vendor specific
> protocols or someone's thoughts on some topic. These documents do get
> some review from the IESG, however, to ensure, for instance, that they
> do not make IANA allocations that would require taking the document
> through the IETF process. Where there is some overlap with work in an
> IETF WG, the IESG has a variety of steps that it can recommend to the
> RFC editor, such as delaying publication so that the WG can first
> complete its work, and/or adding an IESG note to clarify the status of
> the document.
>
> Fred Templin has submitted a document through the Independent
> Submissions process on his views about on MANET architecture,
> autoconfiguration, and use of DHCP. The IESG needs to make a decision on
> what to do about this document. Fred's document does not define a
> protocol or allocate any new IANA values, so from that perspective there
> is no reason for the IESG to recommend that it be delayed or not
> published. However, it does have overlap with the chartered work of
> AUTOCONF, namely with the architecture document. In these cases, the
> IESG can use its judgment to determine whether publishing the work will
> be harmful to the WGs progress, or to the industry. We'd like to collect
> input from the WG on this matter. If there are no objections we are
> inclined to recommend that the RFC Editor publish Fred's document.
>
> Please respond by Tuesday, Oct 21st. Note that we are not asking for
> technical feedback on Fred's document, or whether you believe its
> contents are correct or incorrect. If you have that type of input,
> please send it to Fred directly.
>
> Finally, and more importantly we would also like the AUTOCONF WG to
> deliver its own architecture document as soon as possible. We know that
> Thomas and others are working on a new version, but the ADs want to
> stress that progress on this document is crucial for the continued
> existence of the WG. When the new version appears, we need substantial
> help from the WG to review and progress it.
>
> Jari Arkko and Ross Callon
>
_______________________________________________
Autoconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/autoconf

---

From: Thomas Narten <[email-masked]>
Date: Mon, 20 Oct 2008 09:57:36 -0400

> specific architectural assumptions would likely influence and

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.

> 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