Subject: Re: [rrg] Proposal for recommendation language

From: [email-masked] (Noel Chiappa)
Date: Fri, 23 Apr 2010 14:41:37 -0400 (EDT)

> From: "George, Wes E [NTK]" <[email-masked]>

    > those who came up with proposals were so convinced that their idea was
    > the right one ... in the belief that someone is only against the idea
    > because they don't understand it well enough, or were simply unwilling
    > to compromise

No, there are other explanations, such as 'what spoken or unspoken
assumptions about the environment, both current and future, are people
making'. The thing is that one probably can't say a priori, or necessarily
even provide emperical evidence a priori, that people's views on such
important factors are correct or incorrect.

E.g. Ran and I have different models of how easy it will be to upgrade hosts,
and probably also how necessary it is for initial deployers to get some bang
for their buck (especially when interacting with entities on the other end
have not yet deployed the upgrade). Peoples views on things like that might
bias them, say, towards a solution which is uglier (architecturally), but
more tuned to the existence of lots of unmodified devices.

    > Option 2/3 is a no-op, because not only would there be a Tony/Lixia doc,
    > there would be an IVIP doc, and there would be a [LISP] doc, and an
    > IRON-RANGER doc, etc, etc.
    > ...
    > the solution to the lack of consensus problem isn't to write MORE reams
    > of text in support of individual proposals as in option 2/3 above

No, that is not the intention of option 3. The intention of 3 is that there be
_two_ documents: the first being an RRG 'proposals overview' document which is
the existing overview/criticism/rebuttal groups for each of the proposals, and
the second being an individual document which is the co-chairs recommendation
document.

This would not involve the writing of _any_ extra text (OK, maybe a tiny bit
of header boilerplate for the second document). But none of the proposers would
be writing anything extra.

	Noel

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Fri, 23 Apr 2010 14:43:58 -0500

-----Original Message-----
From: Noel Chiappa [mailto:[email-masked]]
Sent: Friday, April 23, 2010 2:42 PM

E.g. Ran and I have different models ... Peoples views on things like that might
bias them, say, towards a solution which is uglier (architecturally), but
more tuned to the existence of lots of unmodified devices.

[[WEG]] Fair enough, I was oversimplifying. However, the net result is largely the same. Whatever the underlying reasoning, and no matter how sound it may appear, we still have fundamental disagreement that is leading to an unwillingness to compromise to move towards consensus.
IOW, if we can't all be right, and we can't prove that the other person is wrong, then it is time to pick a direction and make it work, hopefully with the best information we have at the time reducing our chances of being totally and utterly wrong.
If there are still fundamental disagreements about certain things, like changing vs not changing hosts, etc, then that means the risk is high that we might be choosing wrong. So rather than there being 2 or 3 different complete solutions because of a difference in a few key areas, these would ideally be variants on one implementation to give it flexibility. I admit that this is not always going to be possible, but I think it would have at least reduced the amount of discrete proposals a bit.

The closest analogy I can give is that this is becoming like denominations or sects in religion. We follow the same deity and rough moral code, but you and I disagree on one specific point of interpretation, and instead of agreeing that there's probably more than one valid interpretation and having the flexibility to manage both interpretations, I go off and start a whole new sect and we argue endlessly over who is right.

[[WEG]] Ok, that's better than what I was thinking you were suggesting, but I still fail to see the value in doing so vs. leaving the recommendation within the current draft if it's to be the only one. IMO the only reason to separate it would be to treat the chairs as no one special and open the door for what would end up being multiple individual contributions for recommendations. Even if we have some self-imposed criterion like "you must have at least X other people who support your proposal in order to write a draft-irtf-rrg-* recommendation draft" so that there isn't necessarily an RRG recommendation for each proposal, it still ends up being very fragmented. If we're separating the recommendation because it's just an individual (or minority group) recommendation, and we can't even get to enough consensus to recommend one proposal of each type, we'd be better off just dispensing with the recommendation altogether.

Wes

This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.

---

From: Vince Fuller <[email-masked]>
Date: Fri, 23 Apr 2010 15:21:58 -0700

>> [from Noel]
>> No, that is not the intention of option 3. The intention of 3 is
>> that there be _two_ documents: the first being an RRG 'proposals
>> overview' document which is the existing overview/criticism/rebuttal
>> groups for each of the proposals, and the second being an individual
>> document which is the co-chairs recommendation document.
> 
> [[WEG]] Ok, that's better than what I was thinking you were
> suggesting, but I still fail to see the value in doing so
> vs. leaving the recommendation within the current draft if it's to
> be the only one.

As Noel pointed out in a separate message, I am the person making the
suggestion of splitting the current document. My intent was to clearly
distinguish between what was discussed in the RRG during the past three
years (the first document, to be published as an RRG document) and what
is being recommended by the two individuals who are the co-chairs of the RRG
(the second document, to be published as their individual submission).

I have participated in all and presented at some of the RRG meetings during
these deliberations, have been a member of the mailing list and followed the
discussions there, and have been working on the Internet routing scalability
problem since the arly 1990s. I'm should think that makes me a "member" of
the RRG. As such, I am extremely uncomfortable with the a document being
published in the name of that group that makes a set of recommendations
with which I do not agree and for which we all acknowledge there exists
no semblence of even rough consensus.

IMHO, the best and only truly fair way to achieve the goal of documenting
what the RRG has been doing, including points of agreement (such as a
recognition that the current routing system architecture can't scale and
maybe even that identifier/locator separation is a desirable property of a
new architecture) while at the same time fulfilling the need of the chairs
to make a recommendation to the IETF is by publishing two documents. As
Noel pointed-out, little new writing is required.

> IMO the only reason to separate it would be to treat the chairs as no
> one special and open the door for what would end up being multiple
> individual contributions for recommendations. Even if we have some
> self-imposed criterion like "you must have at least X other people who
> support your proposal in order to write a draft-irtf-rrg-* recommendation
> draft" so that there isn't necessarily an RRG recommendation for each
> proposal, it still ends up being very fragmented. If we're separating the

There are no rules forbidding individual contribution Internet Drafts. I
am in no way whatsoever encouraging that. All I am suggesting is that the
parts of the current document that describe what happened in the RRG be
clearly and cleanly separated from the opinions and recommendations of the
co-chairs.

I would expect that the separate recommendation document, despite being an
individual submission, would by its nature refer to the RRG document. I
would also expect that the authors of the recommendation would state they
co-chaired the RRG during the deliberations that resulted in the definitions
and proposals contained in the first document. The consumer of that
recommendation, the IETF, would see all of this. But by creating two
separate documents, it would be much more clear that the recommendation
is that of the co-chairs and does not speak for the members of the RRG.

> recommendation because it's just an individual (or minority group)
> recommendation, and we can't even get to enough consensus to
> recommend one proposal of each type, we'd be better off just
> dispensing with the recommendation altogether.

To quote from my original message:

  1. publish the document as-is as an RRG recommendation to the IETF
  2. remove RRG references and publish as an individual contribution
  3. split the document as described above
  4. none of the above (please describe an alternative)

what you described in the text above was option #2.

My preference is clearly for option #3.

I strongly oppose option #1.

	--Vince

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 23 Apr 2010 18:32:06 -0400

Personally, the only value I see in the part of the current document 
before the chair's recommendation is as context for that recommendation.
The document is not a complete survey of what was discussed.  It is not 
even a complete critique of any one of the ideas.  It is however a set 
of pieces which give a reader some idea of what went one, what the range 
of ideas is, and where to look for more ideas.  As a separate document, 
I doubt it is worth publishing as an RFC.  Coupled to the chair's 
recommendation, it at least has the property of bringing this phase of 
the work to a clear state.

Put another way, in order for the chair's recommendation to be a 
meaningful document without the rest of the text, you are asking them to 
do a LOT more work.  Given that they are trying to complete the task 
that the IRTF chair directed, making this significantly more burdensome 
is not helpful.

lets be clear.  Splitting it, or adding more text, or more critiques, is 
not going to improve the impact on the IETF.  It is not going to improve 
the impact on the research community.

If we can actually get acreement to add a few words that ID / Locator 
split is a good idea, I would love to see that.  I rather expect that as 
soon as we try to wordsmith that, the same debates that have occurred 
every other time will recur, and I am rather tired of repeating the process.

Yours,
Joel

Vince Fuller wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: "George, Wes E [NTK]" <[email-masked]>
Date: Fri, 23 Apr 2010 20:25:07 -0500

-----Original Message-----
From: Vince Fuller [mailto:[email-masked]]
Sent: Friday, April 23, 2010 6:22 PM
To: George, Wes E [NTK]
Cc: Noel Chiappa; [email-masked]
Subject: Re: [rrg] Proposal for recommendation language

As Noel pointed out in a separate message, I am the person making the
suggestion of splitting the current document.
[[WEG]] yes, my apologies. I used an incorrect pronoun because I was responding to a clarification that Noel made to your recommendation.

[[WEG]] I don't think anyone is calling into question your membership, nor your contribution. Ultimately I think you should write a rebuttal to the recommendation if you feel that strongly. I agree that we should definitely highlight the things that there is consensus on, but I really don't think that how the document is formatted/separated changes the situation.

[[WEG]] I was not implying that there were rules forbidding IC drafts. I was actually recommending that we use that sort of a distinguisher to separate draft-irtf-rrg-* from draft-irtf-[name] (or draft-name-rrg-recommendation) so that if each of the folks responsible for the 15 different proposals feel the need to publish an IC rebuttal to the chairs' recommendation, it at least will be possible to determine which has some semblance of minority consensus support vs essentially no support beyond the authors. I think that's a worthwhile distinction, as it helps to cut the signal to noise ratio for those trying to review the final output of RRG.

...But by creating two separate documents, it would be much more clear that the recommendation
is that of the co-chairs and does not speak for the members of the RRG.
[[WEG]] I don't know how this would be more clear than the language already in the current recommendation draft.

---

From: John E Drake <[email-masked]>
Date: Sun, 25 Apr 2010 03:58:28 -0700

+1

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel
> M. Halpern
> Sent: Friday, April 23, 2010 3:32 PM
> To: Vince Fuller
> Cc: [email-masked]