Subject: RE: draft-phillips-langtags-08, process, sp ecifications, "stability", and extensions

From: "Peter Constable" <[email-masked]>
Date: Thu, 6 Jan 2005 07:42:33 -0800

> From: [email-masked] [mailto:ietf-languages-
> [email-masked]] On Behalf Of [email-masked]

> Again, your pejorative dismissal of other people's concerns does not
> mean your position is valid...

> Parsing almost never is. But simply parsing these tag is not, and
never
> has
> been, the issue.

I think you guys are in violent agreement over country codes within a
tag, and that the debate over intrepreting the wording of RFC 3066
serves no purpose.

I think the intent of Mark's dismissal has been to refute
perceived-invalid objections, in which case we need to consider that the
line between perceived-invalid and truly-invalid has been blurred simply
by the volume of discussion (the noise factor). There have been some
invalid objections that bear some similarity to comments Ned has made as
he has tried to make his point. (E.g. Bruce Lilly has claimed invalid
back-compat problems on the incorrect premises that RFC 3066 does not
permit ISO 3166 country codes except as second subtags or does not
permit second subtags that are not country codes (at the moment I forget
if it was one or the other or both).)

But Ned's concerns are legitimate, I think. I'd say they are not
necessarily blocking issues for this draft, because I think a possible
outcome of discussion is to characterize them as concerns about
outstanding issues that need to be solved rather than as concerns over
the draft itself; but I do think they are valid concerns that deserve
attention.

In a nutshell, Ned was elaborating on a comment from Dave Singer that,
once we have parsed a pair of tags and identified all the pieces, it's
not a trivial matter to decide in every case how the two tags compare,
and that there are factors that would exist if the draft were approved
that didn't exist under RFC 3066.

Again, I think this is a question that deserves discussion. In relation
to the proposed draft, I don't see it as a particular problem with the
draft. It is a problem that doesn't exist in RFC 3066, but that is only
because RFC 3066 left us with bigger problems: it doesn't give us any
way to identify pieces that we would be encountering in registered tags
(apart from hard-coded tables compiled from versions of the registry
that pre-exist a given implementation).

RFC 3066 permits tags that have all kinds of internal structures. That
is a problem as it will never allow us to derive much useful information
from a tag with any confidence -- only the ISO 639 language category and
in some cases a country category. I predict that in the future we will
be seeing a significant number of tags (whether sanctioned without
registration by a successor to RFC 3066 or as tags registered under RFC
3066) that go beyond the patterns 'll(-CC)" and "lll(-CC)". If we stick
with RFC 3066, we will have no way of writing forward-compatible
processors that will be able to do very useful matching.

What this draft does is impose some order to all the other patterns
within  tags that are permitted, and tell us what the different pieces
must be. As a result, we have more named pieces to deal with, and we are
presented with the question that Ned raised: "Now we have more named
pieces than we did before; what do we do with them?" That is a problem
that will need to be addressed. But I don't think it's a reason to
oppose the draft, since opposing the draft (or at least opposing any
revision that introduces a richer internal structure) leaves us in a
situation that must be characterized either as a worse problem or as
turning our backs on increased functionality to meet real user needs.

Peter Constable

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jan 2005 11:04:54 -0500

--On Thursday, 06 January, 2005 07:42 -0800 Peter Constable
<[email-masked]> wrote:

>...
> But Ned's concerns are legitimate, I think. I'd say they are
> not necessarily blocking issues for this draft, because I
> think a possible outcome of discussion is to characterize them
> as concerns about outstanding issues that need to be solved
> rather than as concerns over the draft itself; but I do think
> they are valid concerns that deserve attention.

Peter, as soon as we get to "valid concerns that deserve
attention", we remove the proposed document, I believe, as a
candidate for BCP.  We don't have any provision in the BCP rules
for pushing a document forward that identifies valid concerns
and other loose ends rather than having those issues resolved
sufficiently that we can talk about a "practice".  So it means
that either

		* The document needs to be withdrawn, these (and other)
		concerns sorted out, and a new document produced that
		addresses them.
		
		or
		
		* The document needs to be recast into Proposed Standard
		or Experimental form, because we do have ways, there, to
		say "these are known outstanding issues that deserve
		attention"

That, of course, doesn't solve some other strategic/ positioning
issues with it; see my recent other note.

    john

---

From: Dave Crocker <[email-masked]>
Date: Thu, 6 Jan 2005 09:02:10 -0800

On Thu, 06 Jan 2005 11:04:54 -0500, John C Klensin wrote:
>  candidate for BCP.

That pretty much applies to all specifications.  A Last Call that produces any sort of serious "concern" that folks feel should be taken seriously means that the document is not yet ready for approval.

It occurs to me that a Last Call for an independent submission has an added requirement to satisfy, namely that the community supports adoption of the work.  We take a working group as a demonstration of community support.  (However we used to pressure for explicit statements during Last Call.)  My feeling is that an independent submission MUST show significant support during Last Call.

In other words, a working group document getting IETF Last Call has something of a Default Yes. And independent submission needs to be Default No.

And, indeed, I haven't seen much support for the document under discussion.

d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker  a t ...
WE'VE MOVED to:  www.bbiw.net

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 6 Jan 2005 09:02:58 -0800

I want to reinforce what Peter has said. In RFC 3066 we have already
registered language tags like zh-Hans, and zh-Hant. Nobody can parse out the
script in the language tag because RFC 3066 does not provide for
identification of the pieces. During the development of 3066bis, we have
been holding off on registering all of the country variants of these,
because we didn't want them to be redundant with the generated codes in
3066bis. If we don't get 3066bis, then we will end up needing to register
the combinations zh-Hans-CN, zh-Hant-CN, zh-Hans-HK, zh-Hant-HK, zh-Hans-MO,
zh-Hant-MO, zh-Hans-SG, zh-Hant-SG, zh-Hans-TW, zh-Hant-TW. And zh is just
one example. There are many languages that can be written in different
scripts, where it is important as a matter of practice to be able to
distinguish the script as well as the country.

There are very good reasons to have the script code before the country code,
because differences by script swamp differences by country. Suppose that you
are composing a web page by pulling together different pieces of data, and
your target is Chinese simplified for Hong Kong. For one of those data
sources, there is not an exact match. Given a choice between a data source
in Chinese simplified, or a data source in Chinese Hong Kong (but
traditional), you really want to pick the Chinese simplified. That is
reflected in the use of the script value second (zh-Hant-HK), so that the
common process of truncation will get the right result.

This is similar to the reason why the language code comes before the country
code. If we had the order CH-fr, then we could end up mixing French and
German in the same page, because we would fall back (for one of the data
sources) from CH-fr to CH, which could be German.

‎Mark

----- Original Message ----- 
From: "Peter Constable" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, January 06, 2005 07:42
Subject: RE: draft-phillips-langtags-08, process, sp
ecifications,"stability", and extensions

never

Peter Constable
_______________________________________________
Ietf-languages mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/ietf-languages

---

From: Scott W Brim <[email-masked]>
Date: Thu, 06 Jan 2005 13:04:49 -0500

>In other words, a working group document getting IETF Last Call has something of a Default Yes. And independent submission needs to be Default No.
Pretty close.  Certainly the default can't be "Yes".  However the reason 
why many things come in as individual submissions is that the community 
doesn't care much.  So if the IESG is satisfied enough to put out a last 
call, and nobody responds -- it doesn't have community support -- the 
default community position shouldn't be "no" but "no objection". 

(In this specific case it appears to me, as an outsider, that there has 
been significant objection, and not all of it dismissable.)

swb

---

From: John C Klensin <[email-masked]>
Date: Thu, 06 Jan 2005 13:48:18 -0500

Dave,

While we are pretty much in agreement, three observations, one
based on Scott's "default no objection" observation.

(1) I think you are right that there are two issues with an
independent submission, one of which is the notion of support
that doing something is a good idea.  And I agree that, for WG
efforts, we pretty much sort that issue out at charter time so
it would take strong evidence at Last Call time to be persuasive
that the community is not interested.  For that part, I agree
with you on the "default no" part -- either the community cares
enough that the document should be part of our corpus of
standards-track materials, or it doesn't and "no objection"
doesn't seem to be a good option (even though the appropriate
threshold for "cares enough" might be debated).  But there is
also the set of issues associated with "given that we are
interested, it is technically adequate, does it solve the stated
(or implied) problems, and similar questions".  And, for that
piece, I think Scott's default "no objection" is about the right
target: it is reasonable for the community, as it figures out
how to allocate resources, to say "this is worth doing, looks
close enough, and we trust the people who have done the work
sufficiently".

(2) It is orthogonal to the issues you have raised, but I
believe that barriers to approval to something that is intended
to replace something that is deployed and working should be
higher than the barrier for a new piece of work in a new area of
application with no potential for screwing things up.  One could
try to further grade that (or not) based on degree of backward
compatibility in applications and use.   I think that treating
"replacement of different protocol or procedure or model" as
needing a higher degree of certainty than "new work" is what the
IETF has done all along without ever being explicit about it as
a principle.  But it seems important to flag in this case.

(3) Finally, there is apparently a procedural oddity with this
document.  The people who put it together apparently held
extended discussions on the ietf-languages mailing list, a list
that was established largely or completely to review
registrations under 3066 and its predecessors.    My
understanding at this point is that their good-faith impression
was that the discussions on that list were essentially
equivalent to those of a WG.  As a result, they came into this
Last Call process believing that their document ought to be
treated very much like a WG one with the presumption that all of
the relevant people were aware of their efforts and on their
list and hence that their consensus on the document should
create a "default yes" to both of the key questions that you
identify.  I think that conclusion is wrong, precisely because
they didn't have the benefit of the struggles about scope and
charter details, and the announcements that the effort was going
on, that invariably accompany a WG formation process.  And I
know of at least a case or two of IETF participants who would
have felt obligated to carefully track a WG chartered to replace
3066 who were not sufficiently aware of this effort to track it
except as an evolving individual submission draft.   The
question of how that process confusion arose, and whether we are
doing the right things in cases like this,  might be something
the community should examine at some point, but it is largely
independent of how this document should be treated going forward.

regards and best new year's wishes,
    john

--On Thursday, 06 January, 2005 09:02 -0800 Dave Crocker
<[email-masked]> wrote:

> That pretty much applies to all specifications.  A Last Call
> that produces any sort of serious "concern" that folks feel
> should be taken seriously means that the document is not yet
> ready for approval.
> 
> It occurs to me that a Last Call for an independent submission
> has an added requirement to satisfy, namely that the community
> supports adoption of the work.  We take a working group as a
> demonstration of community support.  (However we used to
> pressure for explicit statements during Last Call.)  My
> feeling is that an independent submission MUST show
> significant support during Last Call.
> 
> In other words, a working group document getting IETF Last
> Call has something of a Default Yes. And independent
> submission needs to be Default No.
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 6 Jan 2005 10:48:26 -0800

>   However the reason
>  doesn't care much.  

I sure hope you are very, very wrong.

If the community does not care much, then I do not see the purpose in making it an IETF standard.

A standards process is primarily about gaining community support for a common way of doing something.  

So if the IESG is satisfied enough to put out a last
>  default community position shouldn't be "no" but "no objection".

That's a default 'yes'.  

We already have a problem with producing specifications that no one uses.  A default 'yes' on outside submissions makes it likely we will get lots more.

d/

---

From: Dave Singer <[email-masked]>
Date: Thu, 6 Jan 2005 10:58:25 -0800

>sources) from CH-fr to CH, which could be German.

It has to be application-specific which fallback happens.  If the 
user says he's swiss french, and the the content has alternative 
offers for swiss german or french french, which do you present?  If 
the content actually differs for legal or geographic reasons ('the 
legal representative in your country is', 'for copyright reasons this 
edition differs in material ways from other countries'), then the 
correct country but wrong language is the best answer.  If the desire 
is simply for maximum intelligibility, then the reverse is true.
-- 
David Singer
Apple Computer/QuickTime

---

From: [email-masked]
Date: Thu, 06 Jan 2005 10:48:41 -0800

I notice two main types of arguments going on in this thread, where it seems to me that there is frustration
and "talking past each other" occurring due to fundamentally different concerns and assumptions between
different constituencies. 

One type of conflict seems to me between what I will term, for convenience (and please, I don't want to get
side-tracked on my choice of terms -- I just want convenient words) "implementors" vs. "linguists".

By "implementors", I mean those whose concern is primarily on how to interpret (act on) received language tags
-- consumers of language tags, where falling back to a "general" or "compatible" match may be desirable when an
exact match is not available.  From their point of view, the most important aspect of language tags is being able to
parse and match them -- exact linguistic purity and accuracy is a secondary issue.  From their point of view, the 
addition of new tags, regardless of whether the new tags improve language tagging "accuracy", may be actively
harmful unless accompanied by improved matching rules.  To the extent that the adding of tags moves beyond
simple registration of new tags, and instead into new forms of tags and new rules for interpreting tags, that is, that
the new tags bring up fundamental matching algorithm questions, that becomes the main concern for this group.

There are what I will refer to as "linguistic purists", whose concern is primarily on having precise, accurate tags
availabel for languages.  (These may be people whose orientation is on generating content, and labelling it 
accurately.)  For this group, the most important aspect of language tags is having them be accurate and precise.
Any matching issue (and in particular issues of trying to fall back to a more "generic" match when an exact match
is not available) are secondary.

The opinion on whether a tag is "useful" then varies: "it's useful if I know how to match it" vs. "it's useful if it's accurate".

An example where the difference in orientation shows up is with the position of script vs. country in tags.  From the
linguistic point of view, there are arguments for having script come first.  But from the implementation point of view,
that is less backwards-compatible with 3066, hence more problematic.

The process question of whether this is appropriately a BCP, or whether it is at least implicitly  bringing up
algorithmic implementation issues and hence instead ought to be perhaps a Proposed Standard or an Experimental 
Standard, also has something to do with this difference in orientation.
 
A second type of argument, (which I should mention I have largely tuned out so this is my superficial and not very
informed take on it), seems to me to be more linguistic/political in nature, which is what is the "correct" (linguistically 
correct? politically correct?) way to name the tags: what sort of naming scheme corresponds to linguistic reality,
or what sort of naming scheme is politically acceptable, and is there a conflict there.  This does get back to the
algorithmic matching issue in a sense though, which is that if one wants some sort of hierarchical structure to
the tags (to allow easier matching), or indeed define any sort of matching rules (as an implementor wants), you're
probably getting right into some political questions about how matching "should work".   So for those who wanted
to stick just to linguistic accuracy and try to avoid political issues, trying to avoid discussion of algorithmic matching
may have seemed appealing (but then provides no help to what I've termed the "implementors").

If we can keep in mind that there are different constituencies interested in language tags, with different main concerns,
then I would hope for less frustration and irritation with others "missing the main point", so that constructive 
discussions can occur, leading to some compromise useful to everyone. 

Regards,

Kristin

---

From: John Cowan <[email-masked]>
Date: Thu, 6 Jan 2005 14:18:58 -0500

> is simply for maximum intelligibility, then the reverse is true.

Absolutely, which is why the fallback rule isn't and can't be a
protocol-level transaction or (a fortiori) an interop issue.  It's
simply a useful default in many circumstances.

-- 
All Norstrilians knew what laughter was:        John Cowan
it was "pleasurable corrigible malfunction".    http://www.reutershealth.com
        --Cordwainer Smith, Norstrilia          [email-masked]

---

From: [email-masked]
Date: Thu, 06 Jan 2005 16:50:08 -0800 (PST)

> that didn't exist under RFC 3066.

Finally! Thank you! This is exactly what I have been trying to say.

> that pre-exist a given implementation).

With, as you point out below, one important exception: It did have a way to
reliably identify a country code in most cases (but not all). And this ability
to say "2 character subtag in the second position, most be a country code" was
quite useful even though it might miss other occurences of country codes in
some cases.

3066bis provides a reliable way to locate country codes in all cases, but the
algorithm is different. And this is a non-backwards-compatible change.

Of course there's the option Dave Singer has raised: Reverse the positions of
script and country codes in 3066bis. I see two problems with this:

(1) Script codes are in general more important than country codes, and
    therefore really should come first so that simple truncation matches
    work "better". (There are probably exceptions to this assertion lurking
    out there somewhere, but I believe it is mostly true.)

(2) I believe it increases the number of grandfathered codes that won't conform
    to the new format.

Now, it may be that, after full consideration of all the issues, especially
given that the 3066 algorithm could not locate country codes in all cases, the
right way forward is to make this non-backwards-compatible change, fully
document the change and its consequences (although I will again point out that
assessing the true impact on the installed base is a practical impossibility),
and move on. But as you say, it does deserve discussion.

> processors that will be able to do very useful matching.

A very good point.

> turning our backs on increased functionality to meet real user needs.

What would be really nice is to specify a parameterized matching algorithm (or
more precisely, an algorithm family) along the lines of the stringprep family
of string normalization algorithms. But I'm unsure if there's sufficient time
and interest available to do this. But it is nice to dream...

				Ned

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 07 Jan 2005 10:46:41 +0100

[note - this note does NOT talk about the language tags document]
Recent standards-track/BCP RFCs that came in as individual submisssions 
(you can tell this from the draft name in the rfc-editor.xml file):

RFC 3936 - draft-kompella-rsvp-change
RFC 3935 - draft-alvestrand-ietf-mission
RFC 3934 - draft-wasserman-rfc2418-ml-update
RFC 3915 - draft-hollenbeck-epp-rgp
RFC 3912 - draft-daigle-rfc954bis

Apart from draft-alvestrand, I don't remember any of these causing much of 
a stir at Last Call. Still, I think the decision to advance them was 
appropriate.
The usual case for an individual submission is, I think:

- there are a number of people who see a need for it
- there are a (usually far lower) number of people who are willing to work 
on it
- someone thinks that this isn't controversial enough for a WG, isn't work 
enough that the extra effort of setting up a WG is worth it, is too 
urgently needed to wait for a WG to get up to speed, or other version of 
"doesn't fit with our WG process
- nobody's significantly opposed to getting the work done

A "default no" doesn't seem like a correct procedure here.

              Harald

--On 6. januar 2005 10:48 -0800 Dave Crocker <[email-masked]> wrote:

> We already have a problem with producing specifications that no one uses.
> A default 'yes' on outside submissions makes it likely we will get lots
> more.
>
>
>
> d/
> --
> Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Fri, 07 Jan 2005 06:59:19 -0500

Harald,

Using these --and my recent experience with
draft-klensin-ip-service-terms, which is still in the RFC
Editor's queue-- as examples, let me suggest that advancing all
of them is still consistent with what I took Dave to be
suggesting.   In each case, there was evidence of a problem that
"some people" felt was worth solving.  There was no indication
that there was controversy in the community about whether they
were right on the problem (again, independent of whether they
were right on the solution).  

For the IESG to look at a completely quiet last call (or at
least quiet on the problem statement) and say "looks like there
is interest, like the problem is real, and there is no sign of
lack of consensus" seems to me to be a reasonable position.
But, if the Last Call produces an argument about whether the
problem being solved is reasonable or relevant to the
community, _then_ I think the burden shifts to the advocates to
demonstrate that there really is adequate community support for
the idea _and_ for their solution.  And, if there isn't
relatively clear consensus on the answers, the default had best
be either "no" or "if there is really enough interest, it is
time to start thinking about WGs or equivalent mechanisms"
(which is a different form of "no" where approval as an
individual submission is involved).

I don't know if that is what Dave intended, but it is how I
interpreted his "default no" condition.

It does bother me that we can approve a something as a
standards-track document about which everyone but the authors
and the IESG are sound asleep, but the solution to that problem
is for the community to wake up and start taking responsibility.

     john

--On Friday, 07 January, 2005 10:46 +0100 Harald Tveit
Alvestrand <[email-masked]> wrote:

> Recent standards-track/BCP RFCs that came in as individual
> submisssions (you can tell this from the draft name in the
> rfc-editor.xml file):
> 
> Apart from draft-alvestrand, I don't remember any of these
> causing much of a stir at Last Call. Still, I think the
> decision to advance them was appropriate.
> - there are a (usually far lower) number of people who are
> willing to work on it
> - someone thinks that this isn't controversial enough for a
> WG, isn't work enough that the extra effort of setting up a WG
> is worth it, is too urgently needed to wait for a WG to get up
> to speed, or other version of "doesn't fit with our WG process

---

From: John Cowan <[email-masked]>
Date: Fri, 7 Jan 2005 08:26:29 -0500

[email-masked] scripsit:

> What would be really nice is to specify a parameterized matching
> algorithm (or more precisely, an algorithm family) along the lines
> of the stringprep family of string normalization algorithms. But
> I'm unsure if there's sufficient time and interest available to do
> this. But it is nice to dream...

That would be a Good Thing indeed.  However, it is definitely out of
scope for this draft, as it would stretch the definition of BCP well
beyond the breaking point.  If there's any defending the presence of an
*algorithm* in a BCP at all, it's because we are not making the algorithm
normative, but just saying "The most commonly used algorithm is".

-- 
[W]hen I wrote it I was more than a little              John Cowan
febrile with foodpoisoning from an antique carrot       [email-masked]
that I foolishly ate out of an illjudged faith          www.ccil.org/~cowan
in the benignancy of vegetables.  --And Rosta           www.reutershealth.com

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Jan 2005 08:13:27 -0800

On Fri, 07 Jan 2005 06:59:19 -0500, John C Klensin wrote:
>  In each case, there was evidence of a problem that
>  "some people" felt was worth solving.

My comments were in response to an explicit statement that "the community doesn't care much" and my comments included the statement "A standards process is primarily about gaining community support for a common way of doing something."

Thanks for noticing that there is a difference between having no indication of community support, versus "there are a number of people who see a need for it".

d/

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 07 Jan 2005 18:20:42 +0100

Harald,
This does not discuss the language tags comment. This case however provides 
some experience. The real problem I see is the increased need of Practice 
Documentation. RFC 3066 is a BCP yet it introduces issues (and the proposed 
RFC 3066bis does more) which are not established but proposed or even 
modified practices, without the proper debate with other areas some 
consider as concerned (IDN, OPES, Web Services, architecture, etc.) what an 
IAB approved charter would have warranted. In this case there is also the 
oddity of a private list bearing responsibilities on the IANA.

You say this may happen when the matter has not been considered being worth 
a WG. I have nothing to object to that. But I can document that in this 
particular case I sent you a private mail a few months ago asking guidance 
on the way to organize a WG. You did not signaled me your "ietf" list. I 
can also only note this is a consistent position with the IAB/IESG, since 
RFC 3869 does not even allude to the matter. That some's positions are more 
equal than other is a feature of 1st generation networks, so I will not 
object. But I suggest this calls for a better WG proposition track. In this 
case a WG would have saved time and harassment (I am used to be insulted 
and I have no problem with it, should it help).

IRT the need of PB documentation. This case shows that there would have 
been no problem and full consensus if the "BEST" as documented in RFC 
2026.5.1 could have been replaced by a "DOCUMENTED" or by a "SUGGESTED". 
This made me a supposed "main" and "odious" and "gerrymandering" etc... 
"opponent" of the draft. Should the author have been able to present a DCP 
for what is already in use, and an SCP for what he proposes, we would now 
considered how to continue further, may be along the working protocol I 
documented.

I can quote many other areas where such a SCP/DCP use could lead to a 
progressive practice aggregation or transition and innovation.
Regards.
jfc

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 7 Jan 2005 18:07:13 +0100

Looking at the recent announcements of I-Ds, I think we will get a
substantial number of URI/URL related drafts in the coming months which
will also test this procedure.  Their revision numbers are clocking up
so they are being discussed but not AFAICS on any IETF-related list. And
these seem to be standards track.

I am in the 'default no' camp.

Tom Petch

----- Original Message -----
From: "Harald Tveit Alvestrand" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; <[email-masked]>
Sent: Friday, January 07, 2005 10:46 AM
Subject: Re: individual submission Last Call -- default yes/no.

Apart from draft-alvestrand, I don't remember any of these causing much
of
a stir at Last Call. Still, I think the decision to advance them was
appropriate.
The usual case for an individual submission is, I think:

- there are a number of people who see a need for it
- there are a (usually far lower) number of people who are willing to
work
on it
- someone thinks that this isn't controversial enough for a WG, isn't
work
enough that the extra effort of setting up a WG is worth it, is too
urgently needed to wait for a WG to get up to speed, or other version of
"doesn't fit with our WG process
- nobody's significantly opposed to getting the work done

              Harald

.ietf.org/mailman/listinfo/ietf

---

From: Ted Hardie <[email-masked]>
Date: Fri, 7 Jan 2005 10:43:32 -0800

>these seem to be standards track.

URI-related drafts are discussed on the [email-masked] list.  This was
the list of the IETF URI working group, when it was active, and it is
still used by the URI community to discuss URI schemes and updates
to the URI standards.  With the publication of the core URI spec
as a standard (RFC 2396bis), there are several efforts under way to
clean up the related standards.  One of those efforts is to move
the existing scheme definitions in RFC 1738 into separate documents,
so that RFC 1738 can be declared obsolete.  A second effort is
to move the registration procedures for URI schemes onto a
new basis, since the existing basis has resulted in organizations
minting unregistered schemes.  Lastly, there is the usual traffic
of documents for new schemes, like the SNMP URI scheme
recently discussed; these last may not be individual submissions,
since the working group chartered for the protocol tends to
develop the documents for its URI scheme.  The URI mailing
list acts there only as a useful source of reviewers.

As much as we might like the handy "default yes"/"default no"
terminology, the reality is that individual submissions for the
standards track have varying levels of support and interest
when they reach the point of IETF Last Call.  Defaulting all
proposals to "no" that have no working group behind them
collapses that too far, in my personal opinion.

The important point to me is that the Last Call gives an opportunity
for the IETF community as a whole to give a cross-area review of a
proposal.  Feedback at this stage is crucial to determining whether
a proposal will have positive, negative, or no effect on the parts
of the Internet infrastructure which are not the core competence
of the draft's authors.  Working groups tend to have broader sets
of competence than individual authors or design teams, but it is
this same benefit that we seek with each Last Call.

			regards,
				Ted Hardie

---

From: Dave Crocker <[email-masked]>
Date: Fri, 7 Jan 2005 13:43:57 -0800

>  - there are a (usually far lower) number of people who are willing to work
....

Harald,

Given that we are talking about an individual submission, two points from your list are curious:

1.  The last point is at least confusing, since the submission comes *after* the work has been done; otherwise it would be a working group effort; so I do not know what additional work you are envisioning.

2.  Since there is no track record for the work -- given that it has not been done in an IETF working group -- then what is the basis for assessing its community support, abssent Last Call comments?

If one has no concern for the IETF's producing useless and unsupported specifications, then it does not much matter whether marginal specifications are passed.  However the IESG's diligence at seeking perfection in working group output submitted for approval suggests that, indeed, there is concern both for efficacy and safety.

How are either of these assessed for an individual submission, if not by requiring a Last Call to elicit substantial and serious commentary of support?

d/

ps.  The IESG used to be very forceful in requiring explicit statements (demonstrations) of community support; . I suspect we have moved, instead, towards delegating the assessment almost entirely to our representatives and their subjective preferences for work that is submitted.

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 07 Jan 2005 23:21:08 +0100

Dear Ted,
the experience of this Last Call shown the problem comes from the diversity 
of the internet. You may feel that a proposed solution is minor in your 
area and not realize that it has a big impact in others areas. This is why 
WGs are important: their Charters are the only place for some kind of 
coordination of the internet architecture. Otherwise the only time for 
concerned areas to exchange is the Last Call. Too late.
jfc

---

From: Eliot Lear <[email-masked]>
Date: Sun, 09 Jan 2005 10:15:46 +0100

Dave,

You make an assumption here that there is some relationship between the 
usefulness of a standard done from a working group and those individual 
submissions.  Is that assumption borne out in truth?

Just asking.  I haven't checked too much.

Eliot

---

From: Sam Hartman <[email-masked]>
Date: Sun, 09 Jan 2005 14:54:39 -0500

Dave, I think that the requirements for a successful last call depend
on how much review and interest have been demonstrated before the last
call.

For example, I recently last called draft-housley-cms-fw-wrap.  It
received no last call comments.  What should I do with the draft?

Well, in that case, I knew the draft had been reviewed (and changed
based on comments) by several people in the S/MIME and security
community.  I also knew there was work on implementations and specific
customers who plan to use the standard if approved.

In my judgement as an AD, that was sufficient to justify bringing the
document to the IESG even given no support in last call.

There might very well be cases wher I'd bring a document to last call
wher I was skeptical of the utility of the standard.  I'd actually
suspect that other tools for judging sufficient support before
bringing a document to last call might be better, but last call is
certainly a tool for judging support.  In such a case, I might
conclude that no comments were insufficient support.

In conclusion, it seems like the ADs sponsoring documents have
significant latitude in this area and that is a reasonable way for
things to work.  The community can complain that a standard is useless
during last call; you can even say things like "I don't see the point;
if others don't chime in and say they would use this, please do not
publish."  In addition, the community has multiple ways of giving
feedback if they believe that there are systemic problems in the
criteria ADs are using.

--Sam

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Jan 2005 12:21:17 +0100

--On 7. januar 2005 13:43 -0800 Dave Crocker <[email-masked]> wrote:

> 1.  The last point is at least confusing, since the submission comes
> *after* the work has been done; otherwise it would be a working group
> effort; so I do not know what additional work you are envisioning.

Generally, someone who sees a problem and considers writing a draft to 
address it will at least briefly wonder whether a working group should be 
chartered for it or not. I was not talking about only the stuff that 
happens around Last Call time.

> 2.  Since there is no track record for the work -- given that it has not
> been done in an IETF working group -- then what is the basis for
> assessing its community support, absent Last Call comments?
>
....
> How are either of these assessed for an individual submission, if not by
> requiring a Last Call to elicit substantial and serious commentary of
> support?

Following the IETF's tradition of personal responsibility, the AD is 
responsible for having ascertained that there is reasonable reason to 
believe that there are good reasons to think that the document should be 
published before issuing the Last Call.

How that is done varies.

(for instance, in the case of the updated WHOIS specification, there were 
about five people who were groaning about the stupidity of having an IETF 
standards-track specification that people read as if it said that WHOIS 
records have to include a phone number - then Leslie said "OK, I'll draft 
it", and all of the people on the chain of approval were aware of the 
issues that the draft was trying to address, and thought that it was 
obviously a good idea to address them. The relative lack of Last Call 
comments was then interpreted as "the community seems to have found no 
fault with our judgment that this makes sense to do". And I think that was 
the right outcome for that particular case.)

                            Harald

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jan 2005 09:00:58 -0800

On Fri, 7 Jan 2005 10:43:32 -0800, Ted Hardie wrote:
>  s much as we might like the handy "default yes"/"default no"

If one believes that the IETF has no problem with publishing useless, wasteful specifications and no problem with excessive concentration of authority and responsibility in the IESG, then by all means, the model you, Harald and Sam espouse should remain.

Unfortunately, the IETF community has repeatedly, and even formally, expressed concern about both of these issues, so I was merely noting a pretty straightforward means of dealing with both of them, in regards individual submissions seeking IETF approval.

Rather than be mystical assessors of vague sources of support, the IESG needs to make major decisions more transparent.  With respect to approval of IETF documents, that is one of the reasons for Last Call.  And as I noted, it used to be used for that quite pointedly.

The way to make it obvious that there is serious community support for adopting an individual submission is to require that the support be demonstrated ON THE RECORD.

d/

---

From: John C Klensin <[email-masked]>
Date: Mon, 10 Jan 2005 12:57:32 -0500

Hi.

In the hope of making part of this discussion concrete and
moving it a step forward, rather than (or in addition to)
debates about philosophy, let me make two suggestions:

(1) Last Calls for independent submission and similar
standards-track (and BCP) documents should include, explicitly,

	(i) An indication that it is not a WG submission.
	
	(ii) An explicit request for comments on whether the
	material is appropriate for IETF standardization
	(independent of the correctness/ appropriateness of its
	technical content), as well as
	
	(iii) The usual request for comment on technical content.

(2) Any explanations of why the document is relevant, what
problems it solves, what individuals or groups are and are not
supporting it, etc., that might help the community reach a
conclusion about the second point above should be either part of
the document itself or part of a supplemental informational
document that is included in the Last Call. 

These suggestions are independent of discussions about defaults,
etc., and would, I think, be helpful for all non-WG submissions,
even though they will obviously be more important for some than
for others.   And, since the IESG decides what is Last Called
and what is not, and about the content of Last Call
announcements, I think it is something you can just do if you or
the community think it would be helpful.

    john

---

From: Ted Hardie <[email-masked]>
Date: Mon, 10 Jan 2005 10:06:40 -0800

At 9:00 AM -0800 1/10/05, Dave Crocker wrote:
>
>The way to make it obvious that there is serious community support 
>for adopting an individual submission is to require that the support 
>be demonstrated ON THE RECORD.
>
>d/

And the point I'm trying to make is that there are multiple records. 
When we have
a mailing list like "ietf-types" or "ietf-languages" where there is a long term
community of interest around a specific issue, should a discussion there
be taken into account when assessing an individual submission?  I think
the answer is "it depends" and certainly may be "yes".  It should not over-ride
other discussion or be given extraordinary weight, but I do think that the
evidence there of interest, support, and consideration of issues raised should
be taken into account.  That's why I believe saying "default yes" or 
"default no"
at Last Call is too black and white.

I suggest that we try to include pointers to these discussions in
the Last Call text, so that the community has the transparency it needs
to assess these previous discussions.  That will require a change in
behavior, though, as I've been told by several senior folk that they
don't read the Last Call additional text at all if the draft name alone
convinces them they need to read the document; this was in the context
of the considerable additional explanatory text included with the
langtags "New Last Call".  Other suggestions on how to highlight this
to the community reviewing a document at Last Call are more than
welcome.
		regards,
			Ted Hardie

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Jan 2005 12:52:36 -0700 (MST)

> From: Ted Hardie <[email-masked]>

>the answer is "it depends" and certainly may be "yes".  It should not over-ride

I'm bothered by the talk of "community of interest" and "support" as if
they were fungible, as if every community of interest is the same as the
IETF.  That is a potentially catastrophic slippery slope.  There are
very good reasons for IEEE PARs.  Turf is the most fought over commodity
of standards organizations.  Turf is more highly valued than any single
document.  Letting random groups of people call themselves "communities"
and so automagically give themselves the IETF imprimatur is a very bad
thing.  Whether the random group has a mailing list that includes the
string "ietf" in its private part should be obviously irrelevant, but
judging from recent cases, isn't.  Whether the group's mailing list
happens to use an ietf.org domain name is close to irrelevant.  Whether
the supposed "community" includes leaders of other standards organizations
should also obviously be irrelevant, but evidently isn't.

Instead of a "default no" for BCPs or standards track RFC from individual
submissions, it would be better to make it a simple "no."  If the IETF
does not feel like investing the substantial effort and delays to form
a WG and the rest of the tiresome, formal IETF dance, then that in
itself is proof that the issue is unworthy of the IETF's official seal.

Previous efforts to borrow the IETF's printing press and official
seal have involved "Informational."  Evidently the many forces that
want to borrow the IETF's seal have figured out that "Informational"
is not valuable enough and are trying a new tactic.

Giving BCP or standards track to individual submissions is evil on
more than one front.  It's not just that it risks blessing non-standards
and deluting the value of BCP and the standards track.  It is evidence
that the IETF as an organization is getting lazy about its real work.
If every I-D were worth publishing, there would never have been a need
for WGs, Last Calls, and the rest.  The whole "community consensus"
thing is absolutely required for anything that deserves the word
"standard."  You can't have a worthwhile standards publisher without
the work of editing.  Other standards bodies use voting.  Book publishers
use editors.  The IETF uses "consensus".  Letting the editors off the
hook for jobs will have results as bad in their own way as results we
saw from letting the directors of Enron and MCI sleep on their jobs.

The IESG, IAB, and ADs are not the IETF and do not define the IETF
consensus.  They might gauge it, but if it does not exist outside
them, then it does not exist.

It is definitely not good that the IETF is spending so much time
writing a job description and paying so little attention to ostensibly
important Internet standards like language tags.

It's not only true that "A [standards committee's] gotta know [its]
limitations," but it must also know what it doesn't care about enough
to work on.  If the IETF doesn't want to work on language tags by
having a WG and the rest of those delays and work, then so be it.  Let
the standards body that evidently does care do it...unless the incredible
"I'm gona tell the Liason on you" threat was the vacuous, standards
committee politicing as usual that it sounded like.

Vernon Schryver    [email-masked]

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 10 Jan 2005 19:47:43 +0100

Mmmmm

My take is that by the time we get to last call, we may be trying to
do - are IMHO in the case of the I-D that kicked this off - things that
were better done earlier.

I can track I-Ds courtesy of the IETF mauling list (whoops Freudian
slip:-) and can take it upon myself to read them but may still have no
idea where - if anywhere - a discussion is taking place by whom and I
may be prevented from taking part in that discussion anyway; and for me
that is the lack of openness that is at the heart of the problem

I believe any individual submission should have a publicly identified,
publicly accessible mailing list, perhaps listed in the I-D
announcement, so that we can raise issues, hopefully resolve them,
before last call.  Then a default yes could make sense.

Tom Petch

----- Original Message -----
From: "Ted Hardie" <[email-masked]>
To: "Dave Crocker" <[email-masked]>; "Harald Tveit Alvestrand"
<[email-masked]>; <[email-masked]>
Sent: Monday, January 10, 2005 7:06 PM
Subject: Re: individual submission Last Call -- default yes/no.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 10 Jan 2005 15:41:45 -0500

>>>>> "Tom" == Tom Petch <[email-masked]> writes:

    Tom> I believe any individual submission should have a publicly
    Tom> identified, publicly accessible mailing list, perhaps listed
    Tom> in the I-D announcement, so that we can raise issues,
    Tom> hopefully resolve them, before last call.  

I believe sending such comments to [email-masked] is a reasonable thing
for you to do.  Certainly that is what I would do if I had a public
comment about a pre-last-call individual draft for which I didn't
explicitly know of a better place.  I recommend copying authors on
such comments.

--Sam

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 10 Jan 2005 22:16:09 +0100

On Mon, Jan 10, 2005 at 12:52:36PM -0700, Vernon Schryver wrote:
 
> [...]  The whole "community consensus"
> "standard." [...]

I would like to recall that new documents enter the "standards-track" 
as Proposed Standards and there are various ways to proceed from there 
(one of them is direct transition to Historic) and a long way to go for
becoming Standard. So even if the IESG (a group of people we should
trust - at least someone should be there you should trust ;-) made a 
bad decision and nobody recognized the IETF last call, then there are
still several ways and mechanisms to fix the decision before something
becomes a "standard". (And mind you: a standards-track document which 
is not deployed is just a sequence of bits in a storage device.)

[I do understand what people are concerned about here but I also find 
 it important to remind myself from time to time how we are all working
 towards raising the bar, and once raised, someone will speak up to
 raise it even further. Why are we not trusting the system that has 
 worked remarkable well most of the time so far? Perhaps thats human
 nature - if I look what it takes to release a new Linux kernel these
 days or how difficult it is to make the next Debian release, I may
 conclude that raising the bar is a normal part of such societies.]

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 10 Jan 2005 22:17:28 +0100

> before last call.  Then a default yes could make sense.

So do I. It's one of the pieces of advice I always give to I-D writers.
It is, unfortunately, not often followed.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Jan 2005 14:01:51 -0800

On Sun, 09 Jan 2005 10:15:46 +0100, Eliot Lear wrote:
>  submissions.

Actually, i was not intending to indicate such a relationship, nor do i believe it exists.  Good and lousy work come from both sources...

I was indicating that the IETF standardization requires indication of community support.  We take the working group record as strong input to that indication, but that individual submissions lack any equivalent record.  

I am intrigued that IESG leadership apparently feels it acceptable to take the activity of random mailing lists, that have no IETF process standing and no IETF oversight, as sufficient indication of community support.  Ultimately, taking such input as sufficient calls to question the need for ever forming a working group.

But, then, even for established working groups, we seem to be ready to standardize things that show active support by literally only a few people.  

If there were a recent track record of successful, widespread, large-scale adoption for IETF standards, then that sort of random, subjective, opaque assessment process might be acceptable.  Alas, there isn't, so it isn't. 

To repeat my response to John K:
>  My comments were in response to an explicit statement that "the community
>  doesn't care much" and my comments included the statement "A standards
>  process is primarily about gaining community support for a common way of
>  doing something."
>
>  Thanks for noticing that there is a difference between having no
>  indication of community support, versus "there are a number of people who
>  see a need for it".

On Mon, 10 Jan 2005 10:06:40 -0800, Ted Hardie wrote:
>   suggest that we try to include pointers to these discussions in
>  to assess these previous discussions.  

ahh, now.  that certainly seems like a good idea,

however, one needs to be careful that this does not turn into statements like "there are x years of discussion on the foo mailing list; go read it all".  ultimately, that's not very helpful for making an assessment.

On Mon, 10 Jan 2005 12:52:36 -0700 (MST), Vernon Schryver wrote:
>  itself is proof that the issue is unworthy of the IETF's official seal

I do not agree with this recommendation.  I think individual submissions are a good alternative in some cases.

However I think Vernon's posting does point to a very good set of questions.  Namely, what is the purpose of IETF standardization, as distinct from IETF specification development?  What is the incremental value of that going through IETF-wide approval?

Here are my own answers:

1.  There is an independent technical community assessment of efficacy and safety for the specification

2.  The is hand-off of the specification's "ownership" to the IETF.

I see these both as extremely valuable.  The question that follows is whether we are conducting the IETF individual submission process that ensures a reality for both of these?

d/

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 10 Jan 2005 15:28:01 -0700 (MST)

> From: Juergen Schoenwaelder <[email-masked]>

>  conclude that raising the bar is a normal part of such societies.]

That is seriously wrong.  The issue does not involve rising bars, but
falling bars that need to be caught or at least seen to be falling.
The IETF is, as it has been for 10 or 15 years, under attack from those
who use it for ends not consciously chosen by the IETF.

15 years ago there would have been blank looks of incredulity to
the suggestion that an outside, sometimes ostensibly ad hoc and
other times supposedly offical standards organization should push
through a document with as official a designation as "BCP" without
the let, leave, or hindrance of IETF consensus.  However, that is
the case today.

10 years ago no one would have considered the notion that individual
submissions should become official standards (of course I include
"Proposed" as an offical IETF standard) of the IETF with a yes vote
assumed from everyone outside the IESG.

Of course, 20 years or 25 years ago, things were nominally different.
In practical terms, the bar was higher still.

---

From: "Tom Petch" <[email-masked]>
Date: Mon, 10 Jan 2005 22:32:24 +0100

In principle, the process for moving in stages from I-D to Full Standard
is a good one, but only for those who know and respect the different
categories.  Increasingly, I get the impression that those not au fait
with the workings of the IETF see an I-D as a considered piece of work,
to be referenced as if was almost a standard; which is sometimes true,
sometimes not.  We can tell the difference, in lots of ways, others may
not, so I would like more indication from the first that an I-D,
particularly an individual submission, is an idea on the table, for
discussion, with a mailing list attached where the discussion can
happen.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Vernon Schryver" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, January 10, 2005 10:16 PM
Subject: Re: individual submission Last Call -- default yes/no.

> is not deployed is just a sequence of bits in a storage device.)
<snip>

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Tue, 11 Jan 2005 01:53:36 +0100

At 19:06 10/01/2005, Ted Hardie wrote:
>>The way to make it obvious that there is serious community support for 
>>adopting an individual submission is to require that the support be 
>>demonstrated ON THE RECORD.
>

Dear Ted,
I suppose you want to say there are multiple types of records, not that 
there could be different records at the same time. There is only one single 
record: the one published by the IESG. Usually it is a WG, but obviously 
there might be a procedure to have a private list published, when a formal 
WG is not deemed worth being created.

Otherwise, concerned people cannot know which one is _the_ record. Also, 
the first community support is demonstrated by the IAB approval of the WG 
charter. There are already too many lists to follow. The IAB charter 
approval is what makes the difference between work and lobbying.
Best regards.
jfc

---

From: wayne <[email-masked]>
Date: Mon, 10 Jan 2005 23:54:52 -0600

> It is, unfortunately, not often followed.

Well, that may well depend on how far along the I-D is, but in the ID
checklist section 3.8 found on the rfc-editor's website (see: 
http://www.ietf.org/ID-Checklist.html#anchor6 ), it explicitly says:

   Avoid text that will become outdated after RFC is published.

   Examples include non-permanent URLs, mentions of specific mailing
   lists as places to send comments on a document, or referring to
   specific WGs as a place to perform specific future actions (e.g.,
   reviewing followup documents).

So, even if an I-D starts out with information about where to discuss
the draft, it needs to be removed once it gets close to being final.
Also, even if the I-D has this information, it isn't in the
announcement.

Maybe it would be a good idea to have a manditory section in all I-Ds
that lists this information, and *only* this information.  Then that
info could be "easily" put into the announcement and the RFC-editor
could remove that section before publication.

-wayne

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Jan 2005 10:01:18 +0100

What John says below is good sense and IMHO should put the
discussion of this subject to bed (ignoring subthreads where
people have gone off on to other topics without changing
the subject field).

The phrase "Last Call" has built-in semantics. If something is
sufficiently straightforward that the overhead of creating a WG
is pointless, and if the last call message carries the sort of
text John suggests, I don't see an issue.

    Brian