Re: [tcpm] request for feedback - proposed update to draft-touch-tcpm-experimental-options

[John Leslie <[e-mail]>]

   Joe deserves a response:

Joe Touch <[e-mail]> wrote:
> On 2/22/2013 10:36 AM, John Leslie wrote:
>>
>> The plain fact is that the IESG state is three Yes vs. five Abstain.
>> Abstain is the way the IESG "votes" "No".
> 
> AFAICT, 'discuss' is how they vote "no", since a position can pass with 
> abstains so long as there are enough "yes" votes.

   While an I-D may pass with Abstains, it is the intent of IESG process
that the IESG isn't allowed to stop something just because a minority
doesn't like it. Usually more than one Abstain means the others will
try to understand _why_ the AD Abstained.

> Nothing happens until a discuss is resolved, though,

   Indeed: a Discuss is blocking; but it's common for an AD to move from
Discuss to Abstain if others don't agree his Discuss has merit. There is
a process (seldom invoked) for removing the block if the AD can't find
another AD to agree the Discuss is worth resolving. I'll not attempt to
describe that process here: see
www.ietf.org/iesg/voting-procedures.html

> so that's the only vote that blocks things if there are enough 'yes'
> positions.

   It's better to avoid the word "vote" -- these are "ballot positions."

   Also, the rules for number of Yes positions are a bit complex; see
www.ietf.org/iesg/voting-procedures.html

>> I recommend perusing the Narrative Minutes at
>> www.ietf.org/iesg/minutes/2012/narrative-minutes-2012-12-20.html
>> in which I heard a serious concern about variable-length nonces and
>> an opinion that the WG might not be able to agree on a length.
> 
> This note posted a solution that addresses IESG concerns to see what the 
> WG feedback would be.

   Indeed. Alas, I may not have been the only person confused by it...

>> Frankly, I'm not sure the IESG is ready to approve this, even with
>> a fixed-length nonce. Wes has been supportive of this I-D; but Wes will
>> be off the IESG by the time this could return. Five Abstains is a
>> pretty stiff barrier (though I have seen more).
> 
> Some of those positions might be changed based on this update.

   when it goes back to the IESG, yes... or they might not...

>> I think the discussion in the Narrative Minutes is a good one; and
>> I agree with several IESG members who said we should look to an IANA
>> registry, strictly first-come-first-served, where _any_ individual
>> (even one with no connection to the group wanting to experiment) can
>> request a number, with no requirement to document the purpose of the
>> experiment, and be assured of a unique number.
> 
> The IESG lives in a fantasy world where IANA registry assures users of 
> assignment; we live in the real world where that doesn't happen.

   We _all_ live in a fantasy world! ;^)

   I'm not sure what you consider "assured" "assignment". IANA clearly
cannot stop unfriendly users from forging TCP Option values. Nor can
anyone else. :^(

> So we can update this doc to encourage people to register, but the
> solution MUST be robust to the squatting that
> a) has already happened and
> b) will continue to happen, either out of malice or ignorance.

   Believe it or not, IANA tries to avoid squatting damage, and the IESG
is very supportive of these efforts. But it is pointless to try to "be
robust" against all possible squatting.

   In a document like this, we can almost certainly list a few values
where we believe already are used. Alternatively, we could propose a
_new_ Experimental TCP Option number where IANA believes _no_ squatting
exists; but there are IESG members I know would resist that -- YMMV.

   It is a bit silly to talk of "squatting" in the Experimental Option
space -- these have always been "Use at your own risk."

--
John Leslie <[e-mail]>