Subject: [apps-discuss] Applicability Statements

From: Pete Resnick <[email-masked]>
Date: Wed, 11 May 2011 12:05:15 -0500

At the IESG Retreat, we had a discussion on how we publish 
implementation advice, conformance specifications, protocol profiles, 
and the like. Right now, we often put these sorts of things in BCP or 
Informational documents. Unfortunately, these are both second class 
citizens in our document series: They don't get published as "standards" 
and they can't be reviewed and progressed along the standards track even 
though they often have information that we want to review for success.

There is a way to deal with these sorts of documents that we haven't 
tried in a very long time: RFC 2026 defines two kinds of standards track 
documents: Technical Specifications (TS), which we publish all of the 
time, and Applicability Statements (AS), which we haven't. According to 
2026, an AS can be any of the following:

     "identifies the relevant TSs and the specific way in which they are 
to be combined"
     "specify particular values or ranges of TS parameters or 
subfunctions of a TS protocol that must be implemented"
     "specifies the circumstances in which the use of a particular TS is 
required, recommended, or elective"
     "describe particular methods of using a TS in a restricted 'domain 
of applicability'"
     "comprehensive conformance specification"

That sounds to me like exactly what we're trying to do. And an AS can be 
standards track, so long as it is at the same or lower maturity level 
than any of the TSs it references, so it can get full standards track 
treatment.

So, here's my proposal, which I've already gotten some positive feedback 
from the chairs of WGs that I cover in the apps area, and which the IESG 
has agreed to go along with: For my WGs in the apps area, we're going to 
try an informal experiment and submit documents like the above to the 
IESG for Proposed Standard AS. (I already have two such documents in 
mind: The potential MARF "BCP" and the the Malformed Header document.) 
Other ADs may join in, but I'll at least start the ball rolling. I'll 
try to get some early feedback from IESG folks as we get some I-Ds 
together to sanity check, and with any luck we'll get a few of these 
published as Proposed Standard. Then the IESG can talk about the 
criteria for advancement. However it works out, the worst case will be 
that we back off and publish these things as BCP or Informational 
instead, but I'm hopeful. After we get some experience, we'll see where 
else the use of AS might make sense.

What do folks think?

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: John C Klensin <[email-masked]>
Date: Wed, 11 May 2011 13:16:01 -0400

--On Wednesday, May 11, 2011 12:05 -0500 Pete Resnick
<[email-masked]> wrote:

> implementation advice, conformance specifications, protocol
> profiles, and the like. Right now, we often put these sorts of
> things in BCP or Informational documents. Unfortunately, these
> are both second class citizens in our document series: They
> don't get published as "standards" and they can't be reviewed
> and progressed along the standards track even though they
> often have information that we want to review for success.
>
> There is a way to deal with these sorts of documents that we
> haven't tried in a very long time: RFC 2026 defines two kinds
> of standards track documents: Technical Specifications (TS),
> which we publish all of the time, and Applicability Statements
> (AS), which we haven't. According to 2026, an AS can be any of
> the following:
>...
 > So, here's my proposal, which I've already gotten some
> positive feedback from the chairs of WGs that I cover in the
> apps area, and which the IESG has agreed to go along with: For
> my WGs in the apps area, we're going to try an informal
> experiment and submit documents like the above to the IESG for
> Proposed Standard AS. (I already have two such documents in
> mind: The potential MARF "BCP" and the the Malformed Header
> document.) Other ADs may join in, but I'll at least start the
> ball rolling. I'll try to get some early feedback from IESG
> folks as we get some I-Ds together to sanity check, and with
> any luck we'll get a few of these published as Proposed
> Standard. Then the IESG can talk about the criteria for
> advancement. However it works out, the worst case will be that
> we back off and publish these things as BCP or Informational
> instead, but I'm hopeful. After we get some experience, we'll
> see where else the use of AS might make sense.
> 
> What do folks think?

Pete,

I think this is entirely sensible.  I've felt for some time that
we have underutilized the AS option.  Sometimes we incorporate
AS elements into a TS, but it has been a long time since they
have been done standalone.  You didn't mention it explicitly,
but use of AS documents eliminates another issue that has
annoyed lots of people about some BCPs: An AS is entirely
appropriate for recommendations about what we think is the least
bad thing to do under some set of circumstances.  When we make
that sort of recommendation in a BCP, we expose ourselves to the
criticism that the recommendation is neither best (as distinct
from a bad compromise), nor current (as distinct from a
recommendation about future behavior), nor actively practiced.

So, from my point of view, go for it.   And my thanks to you and
the IESG for being willing to try this out.

    john

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 May 2011 14:04:30 -0400

> recommendation about future behavior), nor actively practiced.

This is exactly what I'd have said if John hadn't said it.  Or, put
another way, "I support the publi...."  No, wait.  Um.

Yes, let's go ahead with it.

Barry

---

From: SM <[email-masked]>
Date: Wed, 11 May 2011 12:32:01 -0700

Hi Pete,
At 10:05 11-05-2011, Pete Resnick wrote:
>tried in a very long time: RFC 2026 defines two kinds of standards 
>track documents: Technical Specifications (TS), which we publish all 
>of the time, and Applicability Statements (AS), which we haven't. 
>According to 2026, an AS can be any of the following:
>
>     "identifies the relevant TSs and the specific way in which they 
> are to be combined"
>     "specifies the circumstances in which the use of a particular 
> TS is required, recommended, or elective"
>     "describe particular methods of using a TS in a restricted 
> 'domain of applicability'"
>That sounds to me like exactly what we're trying to do. And an AS 
>can be standards track, so long as it is at the same or lower 
>maturity level than any of the TSs it references, so it can get full 
>standards track treatment.
>
>So, here's my proposal, which I've already gotten some positive 
>feedback from the chairs of WGs that I cover in the apps area, and 
>which the IESG has agreed to go along with: For my WGs in the apps 
>area, we're going to try an informal experiment and submit documents 
>like the above to the IESG for Proposed Standard AS. (I already have 
>two such documents in mind: The potential MARF "BCP" and the the 
>Malformed Header document.) Other ADs may join in, but I'll at least 
>start the ball rolling. I'll try to get some early feedback from 
>IESG folks as we get some I-Ds together to sanity check, and with 
>any luck we'll get a few of these published as Proposed Standard. 
>Then the IESG can talk about the criteria for advancement. However 
>it works out, the worst case will be that we back off and publish 
>these things as BCP or Informational instead, but I'm hopeful. After 
>we get some experience, we'll see where else the use of AS might make sense.

This is like two ADs and a lamb voting on what to have for lunch. :-)

I like the idea on the grounds that BCP has more value if it 
documents best (existing) current practices instead of what we 
believe should be best practice.  RFC 4130 is an example of what is 
discussed above.

Regards,
-sm

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 May 2011 08:43:51 +1200

> Yes, let's go ahead with it.

+1. I would recommend it to all Areas in fact, but it's good for
somebody to start.

   Brian

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 11 May 2011 14:47:02 -0600

> +1. I would recommend it to all Areas in fact, but it's good for

Pete dreamed this up as something we could try in the Applications Area,
and I'm on board with it. Once we have some practical results to show to
other area directors, we might convince them to try it, too.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Pete Resnick <[email-masked]>
Date: Wed, 11 May 2011 15:48:31 -0500

> This is like two ADs and a lamb voting on what to have for lunch. :-)

Smiley face understood but:

We have no lambs in this organization. Or wolves. Or kings. Or better 
yet, we are *all* all of those things.

I asked for thoughts. I take them seriously. What makes the IETF a good 
place to work is that it's full of people much smarter than me.

pr

---

From: SM <[email-masked]>
Date: Wed, 11 May 2011 14:39:09 -0700

Hi Pete,
At 13:48 11-05-2011, Pete Resnick wrote:
>We have no lambs in this organization. Or wolves. Or kings. Or 
>better yet, we are *all* all of those things.
>
>I asked for thoughts. I take them seriously. What makes the IETF a 
>good place to work is that it's full of people much smarter than me.

That's how I read the threads that you opened.  It would be good if a 
broader audience throws in their two cents.  In plain English, read 
the thoughts as coming from Pete, the individual who does not have 
any IETF track record, and tell him what you think.  The IETF does 
not work when people remain silent.

At 13:37 11-05-2011, John C Klensin wrote:
>So, I wouldn't have said "useless".  I might have said "of very
>limited value in helping the IESG with its determination of
>consensus about technical quality and adequacy of review".

That is the politically correct way of stating it.  It may help some 
people understand what the IESG would like.  However, sentences like 
that are against IETF best practices. :-)

Pete has taken a rather unusual approach.  I would qualify it as 
open.  It is to encourage discussion on an equal footing.

Regards,
-sm

---

From: Barry Leiba <[email-masked]>
Date: Wed, 11 May 2011 18:43:42 -0400

Hm.  I thought I wouldn't comment on this, but I think I will, because
I want to make something clear about how I think about this.

On Wed, May 11, 2011 at 5:39 PM, SM <[email-masked]> wrote:
> That is the politically correct way of stating it.  It may help some people
> understand what the IESG would like.  However, sentences like that are
> against IETF best practices. :-)
>
> Pete has taken a rather unusual approach.  I would qualify it as open.  It
> is to encourage discussion on an equal footing.

Here's why I think being "politically correct" is important:
If it's someone's manner to be blunt, and to expect that we won't take
him *too* much at his exact words, that's fine, and we learn that.
And if someone is wont to say "Eff all y'all.  I'm going to ignore any
comments I choose to," well, again, we consider who's saying it and to
what extent we think he really means that... and everyone has a right
not to pay attention to anyone in particular.  Except....

When someone accepts a position on the IESG, the IAB, or the IAOC --
I*, as we collectively call them -- s/he no longer gets to be the
gruff "eff all y'all" person s/he once may have been.  S/he has to
support the open system we have, and not be closed to input.  That's
why someone on I* saying "I won't listen unless you say it the way I
want to hear it," bothers me.  That's why I think it's important to
put it more the way John did -- so people understand that you're not
just brushing people off, but see what you need and why.

So I don't really look at it as being "politically correct", but as
being clear without being exclusive.

That's all.  I don't think we need to belabour this any more, so I'll
leave it here.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 May 2011 23:51:47 +0100

On 11/05/11 23:43, Barry Leiba wrote:
> gruff "eff all y'all" person s/he once may have been...

Sheesh, guess I better sign up for that Swiss finishing school I never
made it to first time 'round ;-)

S.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 12 May 2011 19:34:11 +0900

> other area directors, we might convince them to try it, too.

The *Applica*tion area is all about *Applica*bility :-).

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 May 2011 10:20:00 -0400

(I think these last few messages slipped into the wrong thread.
Restoring...)

--On Wednesday, May 11, 2011 14:39 -0700 SM <[email-masked]>
wrote:

>> So, I wouldn't have said "useless".  I might have said "of
>> very limited value in helping the IESG with its determination
>> of consensus about technical quality and adequacy of review".
> 
> That is the politically correct way of stating it.  It may
> help some people understand what the IESG would like.
> However, sentences like that are against IETF best practices.
> :-)

I think you may have missed my point, although the style I adopt
in the IETF rarely results in my being accused of saying things
to be politically correct.  :-)

The determination the IESG needs to make is multidimensional.
There is no agreed-upon statement of the dimensions, but I would
try the following as components.  They should require different
levels of certainty at different maturity levels, e.g., for
Proposed Standard, "no known technical defects" is supposed to
be adequate while, for higher levels, there should be some
conviction that no such defects exist, not merely that no one
has noticed.

(1) Is the document technically adequate?

(2) Is the document clear enough to be implemented in a
consistent and interoperable way?

(3) Are there interactions between the protocol specified in the
document that would have negative effects on the Internet or on
specific existing protocols?

(4) Do enough people in the community care about this spec that
the IETF should put its stamp of approval on it?

A "I think this is ok and should be published" statement may be
very useful for (4), especially for non-WG documents.   One
important characteristic of (4) is that the IESG actually does
have to count, even if the counting process doesn't correspond
to normal arithmetic.  For (1)-(3) high-information-content
technical arguments are important, especially if they take a
"don't publish" or "don't publish without..." position.  And, at
least in theory, there is no counting at all -- it doesn't make
any difference if a particular technical position is stated by
one person or by five (whether explicitly or by "+1"
endorsement): the issue should be the contents of that position.

Of course, it would reasonable for the IESG to take the position
that one reported problem is a bug that needs fixing but that
two dozen independent reported problems suggest that the spec
needs more fundamental work, but that ought to mean two dozen
comments of the type that I think Pete was asking for, not two
dozen endorsements of one such comment.

> Pete has taken a rather unusual approach.  I would qualify it
> as open.  It is to encourage discussion on an equal footing.

I think the only thing that is unusual about Pete's approach is
that he is trying to be explicit about the criteria he is going
to use to evaluate and weight comments.  I think that is A Good
Thing, but I don't think the criteria he suggests are in any way
new or unusual.

    john

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 12 May 2011 17:31:29 +0300

Hi Pete, 

I do not find this effort useful and see it as a waste of time. Sorry to say that. 
I believe you should let the application area spend more time with relevant technical work rather than letting them spend time with process aspects. 

Ciao
Hannes

On May 11, 2011, at 8:05 PM, Pete Resnick wrote:

> At the IESG Retreat, we had a discussion on how we publish implementation advice, conformance specifications, protocol profiles, and the like. Right now, we often put these sorts of things in BCP or Informational documents. Unfortunately, these are both second class citizens in our document series: They don't get published as "standards" and they can't be reviewed and progressed along the standards track even though they often have information that we want to review for success.
> 
> There is a way to deal with these sorts of documents that we haven't tried in a very long time: RFC 2026 defines two kinds of standards track documents: Technical Specifications (TS), which we publish all of the time, and Applicability Statements (AS), which we haven't. According to 2026, an AS can be any of the following:
> 
>    "identifies the relevant TSs and the specific way in which they are to be combined"
>    "specify particular values or ranges of TS parameters or subfunctions of a TS protocol that must be implemented"
>    "specifies the circumstances in which the use of a particular TS is required, recommended, or elective"
>    "describe particular methods of using a TS in a restricted 'domain of applicability'"
> That sounds to me like exactly what we're trying to do. And an AS can be standards track, so long as it is at the same or lower maturity level than any of the TSs it references, so it can get full standards track treatment.
> 
> So, here's my proposal, which I've already gotten some positive feedback from the chairs of WGs that I cover in the apps area, and which the IESG has agreed to go along with: For my WGs in the apps area, we're going to try an informal experiment and submit documents like the above to the IESG for Proposed Standard AS. (I already have two such documents in mind: The potential MARF "BCP" and the the Malformed Header document.) Other ADs may join in, but I'll at least start the ball rolling. I'll try to get some early feedback from IESG folks as we get some I-Ds together to sanity check, and with any luck we'll get a few of these published as Proposed Standard. Then the IESG can talk about the criteria for advancement. However it works out, the worst case will be that we back off and publish these things as BCP or Informational instead, but I'm hopeful. After we get some experience, we'll see where else the use of AS might make sense.
> 
> What do folks think?
> 
> pr
> 
> -- 
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 May 2011 10:47:56 -0400

--On Thursday, May 12, 2011 17:31 +0300 Hannes Tschofenig
<[email-masked]> wrote:

> Hi Pete, 
> 
> I do not find this effort useful and see it as a waste of
> time. Sorry to say that.  I believe you should let the
> application area spend more time with relevant technical work
> rather than letting them spend time with process aspects. 

Hi Hannes,

I guess I don't understand your comment.  I didn't understand
Pete to be suggesting the creation of a single new document or
piece of work, only that we stop trying to disguise materials
that some readings of 2026 would classify as Applicability
Statements as BCPs or Information documents, but instead publish
them as AS documents.     If no work is done, then there are no
documents to be published in any category.  If someone says
"publish this as a BCP" and the content is essentially that of
an AS, Pete intends to push back and say "AS instead".  That
isn't extra work or "process aspects".  If something were
published and someone decides it needs updating, revision, or
confirmation, then the effort needs to be made to generate an
updated version: that doesn't change whether the document is a
BCP or an AS either.. the only thing that changes is being clear
to all concerned about what is being done and, as I pointed out
in an earlier note, we get away from the notion than an untried
idea to address a practical, often operational, problem with a
protocol is a "best current practice".

   best,
    john

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 12 May 2011 08:59:57 -0700

On 5/11/2011 10:05 AM, Pete Resnick wrote:
> There is a way to deal with these sorts of documents that we haven't tried in a
> very long time:
...
>   For my WGs in the apps area, we're going to try an informal
> experiment and submit documents like the above to the IESG for Proposed Standard
> AS.

AS is a failed experiment.  The failure was complete and not a matter of opinion.

If you want to repeat it, you need to change the conditions, and explain how 
those changes are likely to make it succeed this time.

I'm not stating an opinion about whether I think the construct is good or bad, 
or whether it's worth conducting the experiment, but of the need to specify the 
details that give sufficient guidance and make it (more) likely that the label 
will be useful this time.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 12:34:30 -0500

> AS is a failed experiment.  The failure was complete and not a matter of

Given that we never issue any anymore, I agree.  Heck, I was never
even aware of ASes as a document type.

Are there any RFCs that are ASes?  Why did AS fail?

> those changes are likely to make it succeed this time.

Sure, but a little more background as to why AS failed might help.

Right now I have no opinion on this subject.

Nico
--

---

From: SM <[email-masked]>
Date: Thu, 12 May 2011 10:08:05 -0700

Hi John,
>to be politically correct.  :-)

I was commenting on the two different angles.  I should not have used 
"politically correct" as it is an incorrect description.

>conviction that no such defects exist, not merely that no one

Agreed.

[snip]

>endorsement): the issue should be the contents of that position.

I'll say yes to the above without going into the details.  As a 
comment on the "+1", I'll refer to Ted Hardie's comment about "context" [1].

[snip]

>Thing, but I don't think the criteria he suggests are in any way

My comment was not about the criteria; it was more about posting a 
message about the thinking.  It is not always an easy decision for 
the individual making the determination.  Should the person be open 
about how he or she will make the decision?  There are two choices:

  (i)  Stick to text from BCPs when making public statements and not voicing
       out any thoughts that might be misconstrued as bias.

  (ii) Be candid about likes and dislikes while being able to overcome the
       dislikes to avoid being biased.

The first option leaves people to second guess what the person might 
decide.  It is the favored option and it leaves less room for people 
to object to the decision.  The second option is interesting; people 
can come up and say "excuse me, you may have overlooked the '+1' 
posted by person X who is not a well-known suspect.  Person X is 
working on this specification".

If the community prefers to have ADs who have made it through Swiss 
finishing school, it won't see statements of support such as the 
"Walled Garden Standard" [2].

Regards,
-sm

1. http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02580.html
2. http://www.ietf.org/mail-archive/web/ietf/current/msg50789.html

---

From: Pete Resnick <[email-masked]>
Date: Thu, 12 May 2011 13:02:23 -0500

On 5/12/11 12:34 PM, Nico Williams wrote:
> On Thu, May 12, 2011 at 10:59 AM, Dave CROCKER<[email-masked]>  wrote:
>    

So I would not characterize this as a "failed" experiment. I would 
characterize it as an "unimplemented" experiment. To wit: If I say, 
"Gee, it think it would be very beneficial if we substituted broccoli 
for the cookies during IETF meeting breaks; I propose that we run an 
experiment to put out broccoli and see if it is beneficial" and the 
secretariat (because they are wise folks) don't ever try putting out 
broccoli instead of cookies, I would not say that the broccoli 
experiment "failed". It was never tried. Who knows...it might have been 
successful if tried.

Nobody ever really tried what was described in 2026. For whatever reason 
(I think mostly because 2026 was ambiguous), people started publishing 
the types of documents we are talking about as BCPs instead of 
standards-track BCPs. I am simply suggesting that we actually *start* 
the experiment that 2026 envisions: Separate out certain kinds of 
documents we've to date been labeling as BCPs and make put them into the 
standards-track as AS.

> Are there any RFCs that are ASes?

There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as 
BCPs. The experiment is really not introducing ASs per se. The 
experiment is to put them on the standards track and call them out as 
2026 AS documents.

There is no evidence whatsoever that the experiment failed. That's not a 
matter of opinion.

pr

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 13:05:57 -0500

On Thu, May 12, 2011 at 1:02 PM, Pete Resnick <[email-masked]> wrote:
> BCPs. The experiment is really not introducing ASs per se. The experiment is
> to put them on the standards track and call them out as 2026 AS documents.

Let me rephrase: are there Standards-Track BCPs?  The RFC-Editor RFC
Search tool does not allow me to search for RFCs that are both, BCPs
and on the Standards-Track, thus making a search for such a thing
difficult.

Nico
--

---

From: Pete Resnick <[email-masked]>
Date: Thu, 12 May 2011 13:09:20 -0500

On 5/12/11 1:05 PM, Nico Williams wrote:
> On Thu, May 12, 2011 at 1:02 PM, Pete Resnick<[email-masked]>  wrote:
>    

Ah. No, in 2026, BCPs cannot be Standards-Track and Standards-Track 
documents cannot be BCPs. They are mutually exclusive categories.

The problem is that there are some things that we've been making BCPs 
(i.e., AS documents) that I think would be better served by being 
Standards-Track. The experiment is (for future documents of this sort) 
that we try Standards-Track instead of BCP for ASs.

pr

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 13:34:14 -0500

On Thu, May 12, 2011 at 1:09 PM, Pete Resnick <[email-masked]> wrote:
>>> BCPs. [...]
>> Let me rephrase: are there Standards-Track BCPs?  [...]
>

Let me go back to my original phrasing then: are there any existing
ASes?  I'm not asking if there's BCPs that should have been ASes.

I note that the RFC-Editor has an index of BCPs, STDs, FYIs, and RFCs,
but no index of ASes.  I take this to mean that there are no ASes.

Another question: if there are indeed no ASes as such, have there ever
been any attempts to publish any such?  My guess is the answer is
"no", in which case the "experiment" hasn't failed -- it hasn't been
attempted.

Nico
--

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 May 2011 11:42:14 -0700

Pete Resnick <[email-masked]> wrote:

>>> AS is a failed experiment.  The failure was complete and not a
>matter of
>>> opinion.
 ...
>BCPs. 

That is facile, but it lacks rough consensus.  It eve lacks a clear statement of basis.

>The experiment is really not introducing ASs per se. The 
>There is no evidence whatsoever that the experiment failed. That's not
>a. matter of opinion.

how long do we have to wait for a spec to be unused, before being able to calling it a failure?

failure to garner interest is a failure.

while it might be quibbling about versions, AS docs HAVE been tried,  The community never got comfonrtable with their purpose or form.

d/
--
Dave Crocker
bbiw.net

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 13:46:49 -0500

> while it might be quibbling about versions, AS docs HAVE been tried,  The community never got comfonrtable with their purpose or form.

Out of curiosity, if nothing else, can you point me an some examples?

---

From: Dave Crocker <[email-masked]>
Date: Thu, 12 May 2011 11:55:20 -0700

Nico Williams <[email-masked]> wrote:

>> while it might be quibbling about versions, AS docs HAVE been tried,
> The community never got comfonrtable with their purpose or form.
>

google ietf applicability statement

d/

d/
--
Dave Crocker
bbiw.net

---

From: Nico Williams <[email-masked]>
Date: Thu, 12 May 2011 14:05:32 -0500

> google ietf applicability statement

Actually, this is better: ietf "applicability statement" "Intended
status: standards".

Also: ietf "applicability statement" "category: standards"

So there are standards-track ASes, and there have been I-Ds with
intended status of standards track and with "applicability statement"
in the title.

How has this "experiment" failed then?

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 May 2011 15:11:25 -0400

--On Thursday, May 12, 2011 13:46 -0500 Nico Williams
<[email-masked]> wrote:

>> while it might be quibbling about versions, AS docs HAVE been
>> tried,  The community never got comfonrtable with their
>> purpose or form.
> 
> Out of curiosity, if nothing else, can you point me an some
> examples? ___

RFCs 1122 and 1123 (or at least large fractions of them)?

Many other documents contain both TS and AS components.  As far
as I know, no one has ever tried to interpret "fall into one of
two categories" (RFC 2026 Section 3) as implying a requirement
for two separate documents unless they were trying to kill a
specification procedurally without addressing its content.  The
language of 2026 seems to make any text that specifies
requirements or conformance part of the AS domain.

   john

---

From: Pete Resnick <[email-masked]>
Date: Thu, 12 May 2011 15:24:07 -0500

On 5/12/11 1:42 PM, Dave Crocker wrote:

> Pete Resnick<[email-masked]>  wrote:
>
>    
>> There are oodles of RFCs that are ASs. They are all (AFAICT) labeled as BCPs.
>>      

If you are talking about the first sentence, your statement is clearly 
false. As I said in my first message, there are a list of things that 
2026 envisions as ASs:

I'm happy to point out many of the above types of documents ("oodles" if 
you prefer) that are currently published as BCPs.

If you're complaint is with the second sentence (that as far as I can 
tell all of these ASs are labeled as BCPs), well, I concede the point. 
I'm sure there are Informational documents that are of the above 
categories. And parts of standards track documents. But there are an 
awful lot of these that are published as BCPs, and it is docs of that 
type (AS intended status: BCP) that I wish to put on the standards track.

>> a matter of opinion.

Well, now you've changed horses. Are we talking about the experiment 
failing or are we talking about a spec being a failure? Again, I'm happy 
to concede that section 3.2 and 3.3 of 2026 have not been implemented. 
The reasons it hasn't been implemented are debatable. I've mentioned 
ambiguity. There are actually a couple of weird contradictions in 2026 
around this topic. But I'm not sure what that has to do with whether or 
not it's a good idea to try to put certain kinds of documents on the 
standards track.

> failure to garner interest is a failure.

Well, if that is one of the criteria, then I'd say that a half dozen 
people on this list actually *expressing* "interest" (with reasons) and 
the IESG being "interested" is a good initial sign. But the failure of 
one document to garner interest is not itself evidence that the idea is 
of interest. Now I've got a little prima facia evidence that there is 
some interest in my expression of this idea. I'm happy enough with that.

> while it might be quibbling about versions, AS docs HAVE been tried,  The community never got comfonrtable with their purpose or form.

Uh, now who's making statements without a clear basis?

There is no doubt that there were AS documents prior to 2026 (1122 and 
1123 being good examples). There is no doubt that there are plenty of 
documents that fit the definitions of a 2026 AS that I quoted above 
(with many of them being published as BCP). You can't be arguing that 
the community never got comfortable with the purpose or form of ASs, as 
they demonstrably have, unless you're arguing that they never got 
comfortable with the purpose or form of standards track ASs. I'd like to 
hear some evidence for that conclusion, because I've seen scant few 
examples of the latter. Otherwise, you're simply saying that the 
community never got comfortable with broccoli instead of cookies at 
meeting breaks, and that's either equivocation or false.

(For the record, so far, I have Dave "in the rough" on this topic.)

pr

---

From: Pete Resnick <[email-masked]>
Date: Thu, 12 May 2011 16:23:34 -0500

Let me say up front that I think this entire conversation is great, and 
I think we are all getting a great deal out of having it. I know I am. 
And I do agree with Barry on some of the more specific points, but I 
suspect that we will end up simply agreeing to disagree on the broader 
issue. And I do think it is worth having this conversation, because I 
hope it will lead to some understanding of not just my style, but my 
motives.

On 5/11/11 5:43 PM, Barry Leiba wrote:
> On Wed, May 11, 2011 at 5:39 PM, SM<[email-masked]>  wrote:
>    

First, I don't think you'll find anywhere in my original note on the 
"support publication" thread that I said I would absolutely ignore or be 
closed to the input. I did say that I "find these 
statements...well...useless." I did say that such commentary on the 
publication itself is "really, truly, not important." And I did joke 
(smiley face included) that I would have to assume that the reason for 
such a statement is "because you have a wager on how soon we will get to 
RFC 10000. :-)" But I never did say I'd ignore them. I did say later (in 
reference to Ted's comments) that I "*might* ignore comments that come 
without context because there really is no way to evaluate what they 
mean", but that's just to say that if I can't figure out the meaning of 
a statement, it's simply not going to impact my thinking on a particular 

> just brushing people off, but see what you need and why.

As I said above, I don't think that anything I said means that "I won't 
listen". However, let's talk for a moment about style:

There is a circumstance in which I think one really does have to take 
care to act and sound as open to all input and impartial as possible: 
when you are in a position of power in a truly hierarchical 
organization. In that case, the fact that you have power over other 
people requires that you not only have be open, but you have to act more 
open than you normally would. A position of power means that the less 
powerful folks will be reluctant to confront you, so you have to be 
exceedingly careful to listen for quieter voices and coax people into 
expressing their views frankly and honestly. And my real concern here is 
the inverse effect of the above: When someone starts acting measured in 
their statements and Solomon-like in their judgments and pronouncements, 
it creates an air of authority. It puts people in mind that you are, by 
virtue of your position, in power.

Call me naïve, but the IETF is not supposed to be a hierarchical 
organization like that (behavior of some folks and some adopted 
procedures notwithstanding). We're supposed to be a consensus 
organization, where we all listen to well-reasoned technical arguments, 
even if they come from someone new; where the mere fact of having grey 
hairs (on the face, head, legs, or otherwise shaved off of any of those) 
does not entitle you to say, "It must be this way and I don't have to 
explain why"; where the people in "leadership" are just other passengers 
on the bus, not kings, to whom one can say, "You're wrong, and here's 
why, and that makes you, Mr./Ms. Leader, in the 'rough' part of the 
rough consensus"; and where the participants in the IETF are the ones 
who take responsibility for the documents being of good quality, not the 
leadership.

Some of that is happening now. Some is definitely not. Not being 
hierarchical and having everyone be responsible makes lots of folks 
(leadership and regular participants alike) very uncomfortable. Being in 
a hierarchy means that there is normally someone above you who can 
direct you to the right path if you need, or take the heat when you make 
a mistake. Being in leadership in a hierarchy means you can make a 
decision and not be pushed back on by people under you. These are all 
very comforting thoughts and not having that backstop is worrisome. And 
many of us now come out of corporate culture (as against academia), 
where hierarchy is what we know. But I'm doing my best to push back on that.

So, when I say that "I support the publication of this document" is 
useless, what I'm saying is: Sure, you can choose to assume that I, or 
other ADs, or the rest of participants, "know who you are" and therefore 
must take such contextless statements seriously. But really, I don't 
think you should say things that way. I think you should state the 
technical (or other) grounds that you think this document is useful or 
important or implementable (or not). Or you might choose to assume that 
such statements count as a vote for the document. But really, this is a 
consensus organization, and you don't get to "count" just because you 
grunted "yes". New folks shouldn't think that "silence followed by 
voting" is a reasonable modus operandi, and you shouldn't act that way 
either. You might count, if I happen to have enough context, but if 
another AD or another participant comes up to me and says, "Who is this 
bozo? I don't believe he ever even read the document", it would be 
rather nice to be able to point back to something more concrete than "+1".

Yes, I definitely want people to feel that I am open to their input. (I 
want people to feel that everyone is open to their input.) On the flip 
side, I also want people to feel responsibility for the output of the 
IETF. And I don't want people thinking that I am some oracle from on 
high that has any particular power over them. I take my role to be (a) 
judging the consensus of the community and (b) inputting my experience 
and expertise when I can, and I take them in that order.

So it comes down to my style to get that ethos instilled. I'm inclined 
to say to people (new and old alike), "You'd better explain your 
reasoning or you're not going to get heard". Now, I take your point that 
such talk might put off some people. And that means that I also have a 
responsibility to mentor new folks (or even not-so-new folks who are 
disinclined to challenge authority) to understand that nobody gets to 
rely on their station to justify their statements, and that anyone can 
push back on anyone else, myself included. But I am taking a risk that 
people will think I'm not going to listen to them. However, I prefer 
that risk to the one where I act "exalted" and speak in such ways and 
end up where people think I'm "in charge". I am not (as a friend of all 
of ours said to me recently) "the Last Defender of Camelot". I'm not 
going to talk like that, and I don't want you to talk to me like that.

You may all feel free to decide that I'm completely full of it. That's 
what this organization is supposed to allow. In fact, if 20 of you think 
that I am sufficiently full of it at any point, we have a procedure to 
deal with that. But I do hope that I am setting up the world in such a 
way that anybody feels they can yell at me first and convince me that I 
am "in the rough."

> being clear without being exclusive.

As do I.

pr

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 12 May 2011 15:33:38 -0600

On 5/12/11 3:23 PM, Pete Resnick wrote:

> where the people in "leadership" are just other passengers

Yep. And I mentally replace "the leadership" with "those individuals who
are currently serving, temporarily and at the pleasure of the community,
in leadership roles"...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Barry Leiba <[email-masked]>
Date: Thu, 12 May 2011 18:30:05 -0400

> Let me say up front that I think this entire conversation is great

And let me say up front that I do, too.  Also:

> You may all feel free to decide that I'm completely full of it. That's what
> this organization is supposed to allow. In fact, if 20 of you think that I
> am sufficiently full of it at any point, we have a procedure to deal with

In no sense did I mean to imply that you're "full of it", completely
or partially.  And, of course, it goes without saying that no
procedures are forthcoming.  This is mostly an academic exercise, to
make sure that everyone's considering the same sorts of things.

> listen".

This is part of what I was getting at:
"Such input is useless," which, when it's my input turns into, "Your
input is useless," is -- at least to some people -- another way of
saying, "so I won't be paying it any mind."  One response to that
could be -- and is likely to be, for some people -- "Well, geez, then
I might as well go away."

On the other hand, focusing on what you *do* need in order to do your
job is an angle that's more likely to prompt people to give that,
and... be heard.  That's really the core of what I was trying to get
across.

But now you've brought up something else entirely, so let's pursue this:

> organization like that (behavior of some folks and some adopted procedures
> notwithstanding). We're supposed to be a consensus organization, where we
> all listen to well-reasoned technical arguments

I don't think for a moment that you're naïve, but you're speaking
naïvely here, if you really think that there's no hierarchy as things
are perceived by many participants.  *Lots* of people here -- probably
not those participating in this thread, but lots who are less active,
and certainly a great many of the newer participants -- hold the I*
folks up, consider them to be on pedestals, in ivory towers, or
whatever.  There certainly *is* a very strong perception of hierarchy,
and you certainly *do* have to make a special point of being open and
making it clear that you are.  Not to me, not to John Klensin... but
to, oh, say, at least half of the attendees at a face-to-face meeting,
and to a much higher percentage of those on the mailing lists.

You also have more control than you're letting on, here, and more than
many would like you to have, in using DISCUSS positions, in
controlling charters, in controlling BoF scheduling, in appointing
chairs, and so on.  You can have a significant effect on the
documents, and we can all think of our favourite stories of ADs doing
what we consider to be nasty things to our work.

Don't downplay that, and what it means to the responsibility that you
have in light of it.

Barry

---

From: "John Levine" <[email-masked]>
Date: 13 May 2011 01:00:25 -0000

>and on the Standards-Track, thus making a search for such a thing

RFC 3677 is a standards track BCP.

Since it's the only one, perhaps that was a mistake.

R's,
John

PS: the web may seem cool, but nothing beats rsync'ing the whole
set of RFCs and using grep

---

From: "t.petch" <[email-masked]>
Date: Fri, 13 May 2011 09:03:25 +0200

----- Original Message -----
From: "Nico Williams" <[email-masked]>
To: "Pete Resnick" <[email-masked]>
Cc: <[email-masked]>; "Apps Discuss" <[email-masked]>
Sent: Thursday, May 12, 2011 8:34 PM
Subject: Re: [apps-discuss] Applicability Statements

Nico

My vade mecum is the RFC-INDEX which lists some 30 Applicability Statements, the
most recent being October 2010.  As has been pointed out, there are many more
appearing as sections of Technical RFC.  There are also areas where an AS is
sadly lacking - MPLS-TP springs to mind.

I find them a commonplace in Routing and Operations, perhaps reflecting
an underlying technical difference, or perhaps reflecting a penchant on the part
of the
ADs and WG chairs.  I think that they are needed early on, when the scope of a
technical solution is expanding rapidly, exploding even, and some bounds are
needed.

Tom Petch

---

From: Scott Brim <[email-masked]>
Date: Fri, 13 May 2011 10:08:01 -0400

We have always done the equivalent of applicability statements where
we thought they were necessary.  We are not stupid, and we do produce
what we think people need to be able to use our products effectively.
Sometimes they are in separate documents, sometimes part of "framework
documents", sometimes included in the protocol specs themselves, and
sometimes split across multiple documents with different focus issues.

We have always done applicability "statements", but rarely standalone
application statement documents.  That's okay ... but the problem is
when WGs don't get around to documenting applicability, or do a
haphazard job of it.  Then you get disagreements and incompatibility,
and the IETF hasn't done its job.  So, while we don't usually need
separate applicability documents, we do need to document any
applicability issues for those who weren't in the meeting room.

I believe we should put "deal with applicability questions" on the
shepherding checklist.  The WG decides what the most appropriate way
to document applicability is, but they make an explicit decision about
how to do it.

Scott

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 May 2011 10:17:49 -0500

On 5/13/11 2:03 AM, t.petch wrote:
> appearing as sections of Technical RFC.

Do note that 2026's definition of AS is broader than what we usually 
call "applicability statements". It includes conformance documents, 
protocol profiles, and implementation instructions. There are actually 
plenty of those sorts of documents that are published as BCP that never 
use the words "applicability statement" in their title. And it's 
actually those kinds of documents that I'm most interested in getting on 
the standards track.

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 13 May 2011 10:21:27 -0500

> Since it's the only one, perhaps that was a mistake.

Oh, that's pretty funny. It's gotta just be a typo. I'll mention that to 
the RFC Editor.

pr