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

From: Wesley Eddy <[email-masked]>
Date: Fri, 15 Feb 2013 19:42:26 -0500

On 2/15/2013 2:56 PM, Joe Touch wrote:
> 
> Here's what we need to know:
> 
> 1. do you agree with change (A)?
> 
> 2. do you agree with change (B)?
> 
> 3. do you agree with change (C)?
> 

A) YES

B) YES (but should be clear that requesters can "suggest" a value)

C) YES (prefer option i)

-- 
Wes Eddy
MTI Systems

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 15 Feb 2013 17:03:57 -0800

> B) YES (but should be clear that requesters can "suggest" a value)

same votes as Wes and Joe.

>
>
> --
> Wes Eddy
> MTI Systems
>
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: [email-masked]
Date: Sat, 16 Feb 2013 10:25:59 -0000

I've thought about this and also think the proposed approach is simple and
sufficient.

+1

- If a specific value is requested value and this has already been
assigned, I think it could be wise for IANA to confirm that the value will
be shared with the other entries.

Gorry

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 22 Feb 2013 09:23:01 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Wesley Eddy
> Sent: Saturday, February 16, 2013 1:42 AM
> To: [email-masked]
> Subject: Re: [tcpm] request for feedback - proposed update to 
> draft-touch-tcpm-experimental-options
> 

As individual TCPM contributor, I agree with Joe and Wes.

As co-chair, I would really appreciate further opinions, most notably regarding change (C).

Michael

---

From: John Leslie <[email-masked]>
Date: Fri, 22 Feb 2013 13:36:17 -0500

> As co-chair, I would really appreciate further opinions, most notably

   I was too confused by the original request to comment.

   Since you ask, I traced down the actual issue, which is on
draft-ietf-tcpm-experimental-options, not draft-touch...

   The plain fact is that the IESG state is three Yes vs. five Abstain.
Abstain is the way the IESG "votes" "No".

   The remaining ballot positions are two Discuss vs. five No-Objection.
No-Objection is the way the IESG "votes" "don't care".

   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.

   My personal opinion is that variable-length is a terrible idea; and
that if we can't agree on a single length we should just give up.

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

   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.

   You asked for other opinions: that's mine.
====
   To Joe's specific questions:

A) I don't care what it's called
B) OK, but "unassigned values" needs a definition
C) only (i) is acceptable; (16 bits is fine)

   (I would expect we'd reserve the first 16-bits of known uses: any
further length they use is their problem, not ours.)

   If we ever exhaust 16-bits, I consider that sufficient justification
for allocating another TCP Option Number reserved for experimental use.

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Fri, 22 Feb 2013 10:45:20 -0800

> 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. Nothing happens until 
a discuss is resolved, though, so that's the only vote that blocks 
things if there are enough 'yes' positions.

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

> pretty stiff barrier (though I have seen more).

Some of those positions might be changed based on this update.

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

Joe

---

From: John Leslie <[email-masked]>
Date: Fri, 22 Feb 2013 14:21:35 -0500

Joe deserves a response:

Joe Touch <[email-masked]> wrote:
> 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

> This note posted a solution that addresses IESG concerns to see what the 

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

> Some of those positions might be changed based on this update.

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

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

---

From: Wesley Eddy <[email-masked]>
Date: Sun, 24 Feb 2013 21:45:36 -0500

> Some of those positions might be changed based on this update.

As I understand them, those ballots *should* be able to change
based on some of the modifications Joe proposed.

Some of them were, in my opinion, based on a misunderstanding of
what the goals were, and AD's envisioning their own personal
criteria that wasn't consistent with what the WG originally shot
for.

I think these changes will bring it within expectations.

-- 
Wes Eddy
MTI Systems