Subject: Re: [apps-discuss] I-D Action: draft-ietf-appsawg-xdash-02.txt

From: Dave CROCKER <[email-masked]>
Date: Mon, 14 Nov 2011 13:56:20 +0800

On 11/14/2011 10:00 AM, Randall Gellens wrote:
> To me, this text points out that sometimes people slap together an ad-hoc "x-"
> parameter, and later go for a standard version, which after wider review is
> modified to address security or other issues; the text notes that if this

I think the essence of what you've cited is that the later process produces a 
revised specification.  Hence, what is produced is not the same thing as was 
getting used.  Unfortunately the implication is a practise of re-using the name 
without any version indication, which is generally frowned upon, protocol 
technique-wise...

> I can't help but think that we'd be better off with a middle ground, similar to
> "vnd." namespace, for ad-hoc parameters that might or might not be standardized,
> but that clearly have not been through IETF consensus.

Yuch.

 > One advantage is that it
> provides some impetus (however slight) to develop a standard version if it's
> useful. Another advantage is that it might provide better clues as to the source
> of and change control over the ad-hoc parameter.

At base, this would continue the core model that has proved problematic.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Randall Gellens <[email-masked]>
Date: Mon, 14 Nov 2011 00:11:36 -0800

At 1:56 PM +0800 11/14/11, Dave CROCKER wrote:

>  I think the essence of what you've cited is that the later process 
> produces a revised specification.  Hence, what is produced is not 
> the same thing as was getting used.  Unfortunately the implication 
> is a practise of re-using the name without any version indication, 
> which is generally frowned upon, protocol technique-wise...

Right, but the answer, I think, is to use a different name for the 
standardized version, not to do away with wider review.

We saw this in the past few years with IMAP extensions, where a 
proposal used a capability name for the I-D versions, and a new 
capability name for the RFC.

>>  but that clearly have not been through IETF consensus.

Why?  There are a number of situations where it would be helpful to 
have some namespace distinguisher, including where other SDOs specify 
a set of parameters (as well as case of some implementation wanting 
to use a parameter value for its own purposes).

>  At base, this would continue the core model that has proved problematic.

But it would improve some of the problems of that model, and avoid 
some of the problems with just abandoning the model entirely.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Never look at the trombones, it only encourages them.
                                   --Richard Strauss

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 14 Nov 2011 16:45:11 +0800

On 11/14/2011 4:11 PM, Randall Gellens wrote:
> Right, but the answer, I think, is to use a different name for the standardized
> version, not to do away with wider review.

+1

(but for clarity:  I, for one, hadn't called for doing away with wider review.)

> Why?

because it really is perpetuated essentially the same model that we are trying 
to do away with.

> But it would improve some of the problems of that model, and avoid some of the
> problems with just abandoning the model entirely.

or it wouldn't.

d/

-- 

   Dave Crocker

---

From: Randall Gellens <[email-masked]>
Date: Mon, 14 Nov 2011 01:42:42 -0800

At 4:45 PM +0800 11/14/11, Dave CROCKER wrote:

>> standardized

The current model, with all its flaws, does try to distinguish 
between ad-hoc parameters that anyone can just start using, with no 
review, and standard ones, that have been through wider review.  To 
move to a model that does away with this distinction seems to 
encourage more use of ad-hoc parameters that have not been through 
wide review.

-------------- Randomly selected tag: ---------------
Sorry, no obscene fortunes.  Don't want to offend anyone.
(Now that's obscene!)

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 14 Nov 2011 18:46:19 +0800

On 11/14/2011 5:42 PM, Randall Gellens wrote:
> The current model, with all its flaws, does try to distinguish between ad-hoc
> parameters that anyone can just start using, with no review, and standard ones,

Yes, it tries.  It was an entirely reasonable and well-intentioned, idea.  But 
in making its attempt, it created a problem.

You aren't solving that demonstrated problem.

Note that a strategically isomorphic problem is distinguishing which RFCs are 
standards.  Folks get very upset that some people think all RFCs are standards, 
but it does not actually cause serious real-world problems.  It's just 
unaesthetic.

Rather than split the structure of RFC "names" between standard and 
non-standard, we create a separate attribute for labeling some RFCs as standards.

That's the sort of thing to do in the current case.  Keep status separate from name.

d/
-- 

   Dave Crocker

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Nov 2011 18:48:07 +0800

On 11/14/11 6:46 PM, Dave CROCKER wrote:

> Keep status separate from name.

Exactly!

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 14 Nov 2011 14:23:33 +0100

> Exactly!

Good idea, maybe "status" can be inherited from the status of the spec.

-Frank

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 14 Nov 2011 09:32:02 -0600

+1

--
Mark Nottingham
http://www.mnot.net/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Nov 2011 05:53:47 +0800

>>> Keep status separate from name.

The same principle has emerged from discussions on the "Happy IANA" list 
(i.e., registration of parameters does not imply advancement along a 
standardization path). I sense a theme...

/psa

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Nov 2011 06:05:30 +0800

On 11/15/2011 5:53 AM, Peter Saint-Andre wrote:

> The same principle has emerged from discussions on the "Happy IANA" list (i.e.,
> registration of parameters does not imply advancement along a standardization
> path). I sense a theme...

It's actually closer to a principle.

It is extremely natural to want names to carry deep semantics.  It's an easy 
place to put parametric information.  Unfortunately it seems to always create 
problems, most notably when there is a change in state, which is exactly the 
concern we are dealing with in the draft.

d/

-- 

   Dave Crocker

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 18 Nov 2011 17:34:24 -0800

Perhaps this could be communicated to ICANN.

/me ducks

On 14/11/2011, at 2:05 PM, Dave CROCKER wrote:

> It is extremely natural to want names to carry deep semantics.  It's an easy place to put parametric information.  Unfortunately it seems to always create problems, most notably when there is a change in state, which is exactly the concern we are dealing with in the draft.
> 
> d/
> 
> 
> -- 
> 
>  Dave Crocker
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham
http://www.mnot.net/

---

From: Dave CROCKER <[email-masked]>
Date: Sat, 19 Nov 2011 11:10:14 +0800

With apologies, I'm going to try to follow a serious path in spite of that not
being what you intended:

    Note that the problem is not with ICANN but with the population of folk
making registrations.  THEY provide the initiative for the misguided model(s) of
name use..

    That fact can be an important lesson for anyone else doing work involving
name/string registration.

d/

On 11/19/2011 9:34 AM, Mark Nottingham wrote:
>> It is extremely natural to want names to carry deep semantics.  It's an
>> easy place to put parametric information.  Unfortunately it seems to
>> always create problems, most notably when there is a change in state, which
>> is exactly the concern we are dealing with in the draft.

-- 

   Dave Crocker