Re: ORCID - unique identifiers for contributors

[Riccardo Bernardini]

On Wed, Sep 18, 2013 at 3:14 AM, George Michaelson  wrote:
> Currently, IETF standards activity carries little or no weight for an
> academic career profile. It doesn't appear to have a weighting compared to
> peer review publication. I think this is a shame, because the contribution
> is as substantive, if not more so. And, since time is limited and choices
> have to be made, I believe good students/postdocs don't come into our space
> because the payback isn't there compared to submission into the peer-review
> process.
>
> (happy to be corrected. this is a belief, not a proven theory)

I can confirm your theory, at least regarding me.
I come from academia. I came with some enthusiasm, happy to try to get
involved in IETF activities; I subscribed to few WG mailing list, but
after some time I discovered that (unfortunately) the payback for unit
of work was much less than just publishing  scientific paper.  So, I
unhappily unsubscribed from most of the ML and I stay here, lurking in
the background, waiting for some interesting subject...

Too bad.


>
> On that basis, things we do which make it easier for academic and research
> assessment processes for STEM careers to consider our work as 'worthy' are
> good and useful, because they help to direct skilled new brains into our
> zombie pool.
>
> I think ORCID would be the kind of thing which helps.
>
> -G
>
>
> On Wed, Sep 18, 2013 at 11:08 AM, John Levine  wrote:
>>
>> >Having an IETF identity is OK if all you ever publish is in the IETF.
>> > Some of our
>> >participants also publish at other SDOs such as IEEE, W3C, ITU, and quite
>> > a few publish
>> >Academic papers. Using the same identifier for all these places would be
>> > useful, and
>> >that single identifier is not going to be an @ietf.org email address.
>>
>> If you want Yahoo mail or gmail or pobox.com, you know where to find it.
>>
>> Or people here are, I expect, mostly able to arrange for their own
>> vanity domains.
>>
>> R's,
>> John, ab...@no.sp.am
>
>

Re: ORCID - unique identifiers for contributors

[Andrew G. Malis]

Checking out the ORCID site, I noticed that when manually adding a
work, one of the possible external IDs is "Request for Comments". So
they certainly seem to be aware of the RFC series. The site already
has the ability to search various external databases to automate the
process of adding works, but doesn't have the ability to search the
RFC database for works. It would be a great addition to the site if it
could.

Cheers,
Andy

On Mon, Sep 16, 2013 at 10:39 AM, Andy Mabbett
 wrote:
> [First post here]
>
> Hello,
>
> I'm a contributor to RFC 6350 - but I'm listed there by name only, and
> there is nothing to differentiate me from some other Andy Mabbett (the
> problem is no doubt worse for people with less unusual family names).
> Like many such contributors, I don't want to publish my email address
> as an identifier, in case I get spammed, and if I give an affiliation
> or even the URL of my website, that may change over time.
>
> This problem is addressed by "Open Research Contributor Identifiers"
> (ORCID; ),  UIDs (and URIs) for scientific and other
> academic authors. Mine is below.
>
> As the website says: "ORCID is an open, non-profit, community-driven
> effort to create and maintain a registry of unique researcher
> identifiers and a transparent method of linking research activities
> and outputs to these identifiers".
>
> Individuals can sign up for an ORCID at  and then
> include it in their attribution in RfCs, in their research papers, and
> in other publications.
>
> I'd like to propose that we strongly encourage, or even mandate, this
> for future RfCs.
>
> How should I proceed? Is this list the best place for discussion of
> this topic? Does it need an RfC? If so, would someone care to assist
> me, please?
>
> --
> Andy Mabbett
> @pigsonthewing
> Website: http://pigsonthewing.org.uk
> ORCID: http://orcid.org/-0001-5882-6823

Re: ORCID - unique identifiers for contributors

[George Michaelson]

Currently, IETF standards activity carries little or no weight for an
academic career profile. It doesn't appear to have a weighting compared to
peer review publication. I think this is a shame, because the contribution
is as substantive, if not more so. And, since time is limited and choices
have to be made, I believe good students/postdocs don't come into our space
because the payback isn't there compared to submission into the peer-review
process.

(happy to be corrected. this is a belief, not a proven theory)

On that basis, things we do which make it easier for academic and research
assessment processes for STEM careers to consider our work as 'worthy' are
good and useful, because they help to direct skilled new brains into our
zombie pool.

I think ORCID would be the kind of thing which helps.

-G


On Wed, Sep 18, 2013 at 11:08 AM, John Levine  wrote:

> >Having an IETF identity is OK if all you ever publish is in the IETF.
> Some of our
> >participants also publish at other SDOs such as IEEE, W3C, ITU, and quite
> a few publish
> >Academic papers. Using the same identifier for all these places would be
> useful, and
> >that single identifier is not going to be an @ietf.org email address.
>
> If you want Yahoo mail or gmail or pobox.com, you know where to find it.
>
> Or people here are, I expect, mostly able to arrange for their own
> vanity domains.
>
> R's,
> John, ab...@no.sp.am
>

Re: [IETF] Re: ORCID - unique identifiers for contributors

[John Levine]

>It's practically essential for academics whose career depends on
>attribution of publications and on citation counts (and for the
>people who hire or promote them).

Gee, several of the other John Levines have published way more than I
have.  If what we want is citation counts, confuse away.

R's,
John

PS: If you think I think this topic has been beaten to death and back,
you wouldn't be mistaken.

Re: ORCID - unique identifiers for contributors

[John Levine]

>Having an IETF identity is OK if all you ever publish is in the IETF. Some of 
>our
>participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a 
>few publish
>Academic papers. Using the same identifier for all these places would be 
>useful, and
>that single identifier is not going to be an @ietf.org email address.

If you want Yahoo mail or gmail or pobox.com, you know where to find it.

Or people here are, I expect, mostly able to arrange for their own
vanity domains.

R's,
John, ab...@no.sp.am

Re: PS Characterization Clarified

[John C Klensin]

Pete,

I generally agree with your changes and consider them important
-- the IESG should be seen in our procedural documents as
evaluating and reflecting the consensus of the IETF, not acting
independently of it.

Of the various places in the document in which "IESG" now
appears, only one of them should, IMO, even be controversial.
It is tied up with what I think is going on in your exchange
with Scott:

--On Tuesday, September 17, 2013 18:10 -0500 Pete Resnick
 wrote:

>>> Section 2:
>...
>>> "the IESG strengthened its review"
>...
>>> The IETF as a whole, through directorate reviews, area
>>> reviews, doctor reviews, *and* IESG reviews, has evolved,
>>> strengthened, ensured, etc., its reviews.
>>>  
>> I believe that change would be factually incorrect
> 
> Which part of the above do you think is factually incorrect?

The issue here --about which I mostly agree with Scott but still
believe your fix is worth making-- is that the impetus for the
increased and more intense review, including imposing a number
of requirements that go well beyond those of 2026, did not
originate in the community but entirely within the IESG.  It
didn't necessarily originate with explicit decisions.  In many
cases, it started with an AD taking the position that, unless
certain changes were made or things explained to his (or
occasionally her) satisfaction, the document would rot in the
approval process.  Later IESG moves to enable overrides and
clarify conditions for "discuss" positions can be seen as
attempts to remedy those abuses but, by then, it was too late
for Proposed Standard.  And, fwiw, those changes originated
within the IESG and were not really subject to a community
consensus process either.

However, because the document will be read externally, I prefer
that it be "IETF" in all of the places you identify.  If we have
to hold our noses and claim that the community authorized the
IESG actions by failing to appeal or to recall the entire IESG,
that would be true if unfortunate.  I would not like to see
anything in this document that appears to authorize IESG actions
or process changes in the future that are not clearly authorized
by community consensus regardless of how we interpret what
happened in the past.

john

Re: [IETF] Re: ORCID - unique identifiers for contributors

[Brian E Carpenter]

On 18/09/2013 09:11, Melinda Shore wrote:
> On 9/17/13 1:08 PM, Warren Kumari wrote:
>> On Sep 17, 2013, at 4:52 PM, Yoav Nir  wrote:
>>> Having an IETF identity is OK if all you ever publish is in the
>>> IETF. Some of our participants also publish at other SDOs such as
>>> IEEE, W3C, ITU, and quite a few publish Academic papers. Using the
>>> same identifier for all these places would be useful,
>> Would it? Why?
> 
> It's useful to librarians/archivists/people who organize things.

It's very useful to people who maintain citation databases, where
uniquely identifying authors is necessary.

It's practically essential for academics whose career depends on
attribution of publications and on citation counts (and for the
people who hire or promote them).

At first sight, it doesn't seem to matter too much for the IETF itself,
until the day we have two authors with the same name, or one author
with two names. I think we have several instances of the latter, and
I can't really tell you easily if the following set of RFC authors
contains 10 people or more:

A. Li, C. Li, D. Li, H. Li, J. Li, K. Li, T. Li, X. Li, Y. Li, Z. Li.

A. Li, who authored RFC 2363, is an especially interesting case.
Probably the same person as A. Lin, who authored RFC 2764, but
worked for a different company.

I see that R.T. Braden, R. Braden and B. Braden have all authored
RFCs. One person or three?

In other words, objective identification would actually help sometimes.

   Brian

Re: PS Characterization Clarified

[Pete Resnick]

On 9/17/13 5:52 PM, Scott O. Bradner wrote:

On Sep 17, 2013, at 6:48 PM, Pete Resnick  wrote:

   

I would like to change "IESG" to "IETF" in five places:

Section 1:

"the IESG has evolved its review processes"

Section 2:

"IESG Reveiew of Proposed Standards"
"the IESG strengthened its review"
"last chance for the IESG to ensure the quality"
"cross-area technical review performed by the IESG"

The IETF as a whole, through directorate reviews, area reviews, doctor reviews, 
*and* IESG reviews, has evolved, strengthened, ensured, etc., its reviews.
 

I believe that change would be factually incorrect


Which part of the above do you think is factually incorrect?

pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

Re: PS Characterization Clarified

[Scott O. Bradner]

1/ I believe that change would be factually incorrect

2/ I do not see that being factually correct about what happened says anything 
about
the community opinion about any future IESG decision to change processes.

Scott

On Sep 17, 2013, at 6:48 PM, Pete Resnick  wrote:

> On 9/17/13 11:27 AM, Olaf Kolkman wrote:
>> I just posted the third version of the draft at:
>> http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02
> 
> I would like to change "IESG" to "IETF" in five places:
> 
> Section 1:
> 
> "the IESG has evolved its review processes"
> 
> Section 2:
> 
> "IESG Reveiew of Proposed Standards"
> "the IESG strengthened its review"
> "last chance for the IESG to ensure the quality"
> "cross-area technical review performed by the IESG"
> 
> The IETF as a whole, through directorate reviews, area reviews, doctor 
> reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., its 
> reviews.
> 
> Saying "the IESG" in these places implies precedent setting that I think 
> would be bad. If the IETF capitulated to the IESG changing the rules on its 
> own in the past, so be it, but I think it would be bad to indicate in a BCP 
> that we think it's OK for the IESG to do so unilaterally.
> 
> pr
> 
> -- 
> Pete Resnick
> Qualcomm Technologies, Inc. - +1 (858)651-4478
> 

Re: Why we don't want to actually replace 2026

[Brian E Carpenter]

On 17/09/2013 17:49, S Moonesamy wrote:
> Hi John,
> At 08:31 16-09-2013, John C Klensin wrote:
>> By the way, while I understand all of the reasons why we don't
>> want to actually replace 2026 (and agree with most of them),
>> things are getting to the point that it takes far too much
>> energy to actually figure out what the rules are.  Perhaps it is
>> time for someone to create an unofficial redlined version of
>> 2026 that incorporates all of the changes and put it up on the
>> web somewhere.   I think we would want a clear introduction and
> 
> I posted draft-moonesamy-stds-process-00 (expired) [1] in 2010.  I have
> to update the draft as it does not take into account the two-track
> change.  I would not post a revision on the web as the IETF Trust might
> not like it.  In my opinion it might be related to the original
> negotiating position of CNRI.

For some years I've maintained http://www.ietf.org/about/process-docs.html
"to assist IETF participants in navigating the labyrinth." It
does carefully avoid red-lining or commentary, and I think it also
shows the complexity that we have created.

   Brian

> 
> Regards,
> S. Moonesamy
> 
> 1. http://tools.ietf.org/html/draft-moonesamy-stds-process-00 
> 

Re: PS Characterization Clarified

[Pete Resnick]

On 9/17/13 11:27 AM, Olaf Kolkman wrote:

I just posted the third version of the draft at:
http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02


I would like to change "IESG" to "IETF" in five places:

Section 1:

"the IESG has evolved its review processes"

Section 2:

"IESG Reveiew of Proposed Standards"
"the IESG strengthened its review"
"last chance for the IESG to ensure the quality"
"cross-area technical review performed by the IESG"

The IETF as a whole, through directorate reviews, area reviews, doctor 
reviews, *and* IESG reviews, has evolved, strengthened, ensured, etc., 
its reviews.


Saying "the IESG" in these places implies precedent setting that I think 
would be bad. If the IETF capitulated to the IESG changing the rules on 
its own in the past, so be it, but I think it would be bad to indicate 
in a BCP that we think it's OK for the IESG to do so unilaterally.


pr

--
Pete Resnick
Qualcomm Technologies, Inc. - +1 (858)651-4478

Re: ORCID - unique identifiers for contributors

[Yoav Nir]

On Sep 17, 2013, at 10:44 PM, Hector Santos 
 wrote:

> On 9/17/2013 1:55 PM, Michael Tuexen wrote:
>> On Sep 17, 2013, at 7:48 PM, Scott Brim  wrote:
>> 
>>> On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
>>>  wrote:
 I was always wondering the authors can't get an @ietf.org address, which 
 is listed
 in the RFC and is used to forward e-mail to another account.
> 
> Me too!  I would even suggest that all I-D authors, at the very least, should 
> need to register with the IETF to submit documents.  Optional @ietf.org 
> offered.

Having an IETF identity is OK if all you ever publish is in the IETF. Some of 
our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a 
few publish Academic papers. Using the same identifier for all these places 
would be useful, and that single identifier is not going to be an @ietf.org 
email address.

Re: ORCID - unique identifiers for contributors

[Hector Santos]

On 9/17/2013 4:52 PM, Yoav Nir wrote:


Having an IETF identity is OK if all you ever publish is in the IETF. Some of 
our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite a 
few publish Academic papers. Using the same identifier for all these places 
would be useful, and that single identifier is not going to be an @ietf.org 
email address.



Then for these unique individuals, a single source id is useful for 
them and should be recommended to consolidate contact consistent and 
persistent information.  People are increasingly doing that now with 
what was once alias junk domains, i.e. gmail.com, google+, even 
facebook, twitter, etc. I know I have move away from a using a 
corporate id in public that are now protected (in spirit) by ADSP and 
DKIM.  But as a total, don't you think the ietf.org will benefit in 
the long run maintaining its own registry?


--
HLS

Re: ORCID - unique identifiers for contributors

[Hector Santos]

On 9/17/2013 3:24 PM, Melinda Shore wrote:

On 9/17/13 11:14 AM, Michael Tuexen wrote:

For example
http://www.ietf.org/rfc/rfc3237.txt
has 7 authors. I know that at least 4 affiliations have changed
and at least you can't reach me anymore via the given e-mail
address or telephone number.


This is not the problem ORCID addresses, except indirectly.
It's a way to establish that the author Melinda Shore who
worked at Cisco is the same author Melinda Shore who worked
at the Center for Research Libraries.  It is NOT a contact
mechanism, a personal tracking mechanism, etc.


But how much of a problem is that?  Why not advocate gmail.com, 
google+, facebook.com, linked-in?  I registered at ORCID and it found 
a similar named registrant.  It only wanted to know if it was me, if 
not then continue.  But all the newsletter spam potential and privacy 
issues and even more in there, well, scared me.  It had multiple 
levels of privacy to select and too much reading required to follow 
it.  So I punted on that.


Why can't the IETF offers its own signup requirement for I-D 
submissions where a contact id can be provided?   The focus should be 
within the @IETF.ORG, not try to steer folks to use some 3rd party 
contact id where the IETF has no legal hold or control of any kind, in 
case, well, of the many things that can happen.


Thanks

--
HLS

Re: ORCID - unique identifiers for contributors

[Hector Santos]

On 9/17/2013 1:55 PM, Michael Tuexen wrote:

On Sep 17, 2013, at 7:48 PM, Scott Brim  wrote:


On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
 wrote:

I was always wondering the authors can't get an @ietf.org address, which is 
listed
in the RFC and is used to forward e-mail to another account.


Me too!  I would even suggest that all I-D authors, at the very least, 
should need to register with the IETF to submit documents.  Optional 
@ietf.org offered.



The email address associated with the draft, for example
draft-kutscher-icnrg-netinf-pr...@tools.ietf.org, apparently stays
with the RFC.  If you go to tracker for any RFC you can click "email
authors".  I don't think there's a way to update the authors' current
addresses.

... and that is my point. One level of indirection might be useful here.

I would prefer to update only one mapping and not go through a list
of RFCs and change the mapping for each document.


If there are other purposes for ORCID, then what are those?  These are 
things the IETF can do in general to improve its electronic 
participant and network of world wide contributors.


The idea is great.  By why use ORCID?  Why not Facebook? linked-in? 
etc. So many issues when its 3rd party.  While ORCID does offer an API 
(another conflict issue when API changes), I think the IETF should 
offer its own registry database of contributors.


--
HLS

Re: ORCID - unique identifiers for contributors

[Juliao Braga]

Yes, you can do this using RDFa [1] into HTML tags. If Dr. Krafft had
used RDFa so his page:

a. Will be a entry point and used as SPARQL[2] queries. This entry point
will be found in his contribuition to, or participation in the IETF
(e.g. in the Attendance List of the IETF meetings).
b. Could be subjected to a destiller[3] to obtain a RDF / RDFS / OWL file.
c. This file will be part of an (upper) ontology for the IETF, with
specific vocabulary (or metadata) as DCMI[4].
d. And so on...

Julião
A simple example: http://www.braga.eti.br/People/Juliao_Braga/. Get the
source of this page. You will see the vocabulary used into the HTML tags.

[1] http://www.w3.org/TR/xhtml-rdfa-primer
[2] http://www.w3.org/TR/rdf-sparql-query/
[3] http://www.w3.org/2012/pyRdfa/
[4] http://dublincore.org/

Em 16/09/2013 13:49, Scott Brim escreveu:
> It's a good idea but I would generalize it.  Why have a system just for
> I*?  I would allow people to provide a pointer to their public
> information in one (or more?) of many places.  For example,
> http://vivo.cornell.edu/display/individual8772 and if necessary we can
> explore federated identity.
> 
> Scott

Re: [IETF] Re: ORCID - unique identifiers for contributors

[Warren Kumari]

On Sep 17, 2013, at 4:52 PM, Yoav Nir  wrote:

> 
> On Sep 17, 2013, at 10:44 PM, Hector Santos 
> wrote:
> 
>> On 9/17/2013 1:55 PM, Michael Tuexen wrote:
>>> On Sep 17, 2013, at 7:48 PM, Scott Brim  wrote:
>>> 
 On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
  wrote:
> I was always wondering the authors can't get an @ietf.org address, which 
> is listed
> in the RFC and is used to forward e-mail to another account.
>> 
>> Me too!  I would even suggest that all I-D authors, at the very least, 
>> should need to register with the IETF to submit documents.  Optional 
>> @ietf.org offered.
> 
> Having an IETF identity is OK if all you ever publish is in the IETF. Some of 
> our participants also publish at other SDOs such as IEEE, W3C, ITU, and quite 
> a few publish Academic papers. Using the same identifier for all these places 
> would be useful,

Would it? Why?

I publish some papers in other places. I wear substantially different hats in 
other areas -- drafts published in the IETF reflect (in theory) IETF consensus, 
so they are not really *my* views, they are the views of a group of folk.

So, it is not that folk can read a document in another context and then say 
"Wow, that's interesting, let me see what Warren's views on IETF subjects is" 
and then go find *my* IETF views (if they wanted that, looking at mailing lists 
is probably a better option :-))

I guess a universal identifier could be useful so that future employers / 
people in bars could look me up, see that I've contributed to N documents in M 
SDOs and then be all impressed. 

This does not seem very useful to me.

W

> and that single identifier is not going to be an @ietf.org email address.

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk 
but choose not to do so in case humans put them to work, possibly in the 
television industry. In fact they can talk. It's just that they talk in 
Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett

Re: [IETF] Re: ORCID - unique identifiers for contributors

[Melinda Shore]

On 9/17/13 1:08 PM, Warren Kumari wrote:
> On Sep 17, 2013, at 4:52 PM, Yoav Nir  wrote:
>> Having an IETF identity is OK if all you ever publish is in the
>> IETF. Some of our participants also publish at other SDOs such as
>> IEEE, W3C, ITU, and quite a few publish Academic papers. Using the
>> same identifier for all these places would be useful,
> 
> Would it? Why?

It's useful to librarians/archivists/people who organize things.

Melinda

Re: ORCID - unique identifiers for contributors

[Tony Hansen]

On 9/17/2013 8:07 AM, Melinda Shore wrote:
> I'm not sure much needs to be done other than talking with Heather
> Flanagan (the RFC Editor), getting her sign-off, and then getting
> it into the xml2rfc schema and noting its existence.

What would the ORCID reference look like? My understanding is that it
would look like this: http://orcid.org/-0003-0437-

Very few people use the uri element in the author block. (I count zero
in the currently extant internet-drafts XML files.) Its intended use
really is for the author to put in whatever URI they care to that helps
identify them. Its usage is directly parallel to a person's postal, fax
and email addresse. So plugging an ORCID into the URI element seems to
fit that usage perfectly.

Tony Hansen

Re: I-D Action: draft-kolkman-proposed-standards-clarified-02.txt

[Brian E Carpenter]

Is it just me, or does this sentence now seem like hubris?

>  In fact, the IETF review
>  is more extensive than that done in other SDOs owing to the cross-
>  area technical review performed by the IESG, a position that is
>  further strengthened by the common presence of interoperable running
>  code and implementation before publication as a Proposed Standard.

At the least, I would prefer to see it start thus:

   The IETF review is possibly more extensive than ...

Regards
   Brian

Re: ORCID - unique identifiers for contributors

[Michael Tuexen]

On Sep 17, 2013, at 9:24 PM, Melinda Shore  wrote:

> On 9/17/13 11:14 AM, Michael Tuexen wrote:
>> For example
>> http://www.ietf.org/rfc/rfc3237.txt
>> has 7 authors. I know that at least 4 affiliations have changed
>> and at least you can't reach me anymore via the given e-mail
>> address or telephone number.
> 
> This is not the problem ORCID addresses, except indirectly.
> It's a way to establish that the author Melinda Shore who
> worked at Cisco is the same author Melinda Shore who worked
> at the Center for Research Libraries.  It is NOT a contact
> mechanism, a personal tracking mechanism, etc.
Agreed. Maybe the wrong thread... I replied to a statement
that the authors e-mail addresses went stale...

Best regards
Michael
> 
> Melinda
> 
> 

Re: ORCID - unique identifiers for contributors

[Melinda Shore]

On 9/17/13 11:14 AM, Michael Tuexen wrote:
> For example
> http://www.ietf.org/rfc/rfc3237.txt
> has 7 authors. I know that at least 4 affiliations have changed
> and at least you can't reach me anymore via the given e-mail
> address or telephone number.

This is not the problem ORCID addresses, except indirectly.
It's a way to establish that the author Melinda Shore who
worked at Cisco is the same author Melinda Shore who worked
at the Center for Research Libraries.  It is NOT a contact
mechanism, a personal tracking mechanism, etc.

Melinda

Re: ORCID - unique identifiers for contributors

[Michael Tuexen]

On Sep 17, 2013, at 8:19 PM, Melinda Shore  wrote:

> On 9/17/13 9:55 AM, Michael Tuexen wrote:
>> ... and that is my point. One level of indirection might be useful here.
>> I would prefer to update only one mapping and not go through a list
>> of RFCs and change the mapping for each document.
> 
> I really think that you all are completely over-engineering
> this.  But that's what I think.  What I *know* is that you're
Really?
Each RFC lists the addresses of the authors. My understanding is
that this information might be used to contact the authors in
case of questions, errata, ... At least this happened in the past.

For example
http://www.ietf.org/rfc/rfc3237.txt
has 7 authors. I know that at least 4 affiliations have changed
and at least you can't reach me anymore via the given e-mail
address or telephone number.

Best regards
Michael
> looking at this from the perspective of IETF contributors.
> Librarians have a problem, too, and the ORCID stuff primarily
> addresses that problem, not ours.
> 
> There's been a long history of difficulty in name usage on
> documents and that's confounded librarians, who for some
> reason (<- sarcasm) feel the need to be able to group works by the same
> author.  This has been dealt with through authority control
> mechanisms, where the cataloger tries to ascertain if
> a given "Scott Smith" is the same person as one of the
> many other Scott Smiths already in the catalog, and if not,
> creates a new authority record.  Discrimination is encoded
> in the authority records in the form of middle names/initials,
> dates of birth and death, etc.  Again, this is something the
> *cataloger* does, and it's actually rather difficult.  So,
> in a cataloging record the contents of the author field are
> normalized under authority control and the author name as it
> appears on the title page is carried in the body of the
> cataloging record, and not indexed.
> 
> There's a quite good discussion of this here:
> http://kcoyle.blogspot.com/2007/09/name-authority-control-aka-name.html
> 
> What ORCID does is allow the author to help catalogers out
> by providing a unifying identifier.  It's not intended to
> be authenticative or provide identity information - it just
> helps group documents (which is why I think it belongs in a
> separate piece of metadata).  I don't think this is a huge
> deal and i don't think it requires community consensus.  I
> imagine most IETF authors, who for the most part are not
> academics, will bother with it, and that's just fine.
> 
> Melinda
> 
> 

Re: ORCID - unique identifiers for contributors

[Michael Tuexen]

On Sep 17, 2013, at 7:48 PM, Scott Brim  wrote:

> On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
>  wrote:
>> I was always wondering the authors can't get an @ietf.org address, which is 
>> listed
>> in the RFC and is used to forward e-mail to another account.
> 
> The email address associated with the draft, for example
> draft-kutscher-icnrg-netinf-pr...@tools.ietf.org, apparently stays
> with the RFC.  If you go to tracker for any RFC you can click "email
> authors".  I don't think there's a way to update the authors' current
> addresses.
... and that is my point. One level of indirection might be useful here.
I would prefer to update only one mapping and not go through a list
of RFCs and change the mapping for each document.

Best regards
Michael
> 

Re: ORCID - unique identifiers for contributors

[Michael Tuexen]

On Sep 17, 2013, at 6:36 PM, Steve Crocker  wrote:

> I'm in agreement.
> 
> We have not had any standards so far regarding maintenance of the validity of 
> contact information.  For example, my contact information for the April 1, 
> 1995 RFC 1776 is:
> 
>> Steve Crocker
>>   CyberCash, Inc.
>>   2086 Hunters Crest Way
>>   Vienna, VA 22181
>> 
>>   Phone: +1 703 620 1222
>>   EMail: croc...@cybercash.com
>> 
> The email address, phone number and postal address became stale a long time 
> ago.  If ORCID is
I was always wondering the authors can't get an @ietf.org address, which is 
listed
in the RFC and is used to forward e-mail to another account.

Best regards
Michael
> introduced, it's likely to be at least as good as email addresses, etc.  
> Let's avoid or at least defer trying to endow them with additional properties 
> such as permanence until there is some experience.
> 
> Steve
> 
> 
> 
> 
> On Sep 17, 2013, at 12:16 PM, John C Klensin  wrote:
> 
>> 
>> 
>> --On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson
>>  wrote:
>> 
>>> 
>>> I did not know about ORCID before this thread.
>>> I think it is brilliant, and what I've read about the mandate
>>> of orcid.org, and how it is managed, I am enthusiastic.
>>> 
>>> I agree with what Joel wrote:
>>> 
>>> Asking for ORCID support in the tool set and asking for IETF
>>> endorsement are two very different things.
>>> 
>>> Having tool support for it is a necessary first step to
>>> permitting IETF contributors to gain experience with it.   We
>>> need that experience before we can talk about consensus.
>>> 
>>> So, permit ORCID, but not enforce.
>> 
>> The more I think about it, the more I think that Andy or someone
>> else who understands ORCIDs and the relevant organizations,
>> etc., should be working on a URN embedding of the things.  Since
>> we already have provisions for URIs in contact information, an
>> ORCID namespace would permit the above without additional
>> tooling or special RFC Editor decision making.  It would also
>> avoid entanglement with and controversies about the rather long
>> RFC Editor [re]tooling queue.
>> 
>> Doing the write-up would require a bit of effort but, in
>> principle,
>>   URN:ORICD:
>> is pretty close to trivially obvious.
>> 
>> Comments about dogfood-eating and not inventing new mechanisms
>> when we have existing ones might be inserted by reference here.
>> 
>>> An interesting second (or third) conversation might be about
>>> how I could insert ORCIDs into the meta-data for already
>>> published documents. 
>> 
>> With a URN embedding that question would turn into the much more
>> general one about how URIs in contact metadata could be
>> retroactively inserted and updated. In some ways, that is
>> actually an easier question.
>> 
>> best,
>>  john
>> 
>> 
>> 
>> 
>> 
> 
> 

Re: ORCID - unique identifiers for contributors

[Scott Brim]

On Tue, Sep 17, 2013 at 1:37 PM, Michael Tuexen
 wrote:
> I was always wondering the authors can't get an @ietf.org address, which is 
> listed
> in the RFC and is used to forward e-mail to another account.

The email address associated with the draft, for example
draft-kutscher-icnrg-netinf-pr...@tools.ietf.org, apparently stays
with the RFC.  If you go to tracker for any RFC you can click "email
authors".  I don't think there's a way to update the authors' current
addresses.

Re: ORCID - unique identifiers for contributors

[Carsten Bormann]

On Sep 17, 2013, at 19:37, Michael Tuexen  
wrote:

> I was always wondering the authors can't get an @ietf.org address, which is 
> listed
> in the RFC and is used to forward e-mail to another account.

+1.

(Remarkably, all the RFCs I co-authored show the same email address.  Not so 
for the ones I only contributed to, even though all of those addresses still 
work.  But even for the co-authored ones that seems to be the exception.)

Grüße, Carsten

Re: Fwd: Gen-ART LC Review of draft-ietf-karp-ops-model-07

[Sam Hartman]

Hi.
I somehow missed the genart review and Stewart kindly forwarded me a
copy

I will shortly be publishing a new version that includes fixes discussed
below.

> "genart" == Stewart Bryant  writes:


genart> Major issues:

genart> None.


genart> Minor issues:

genart> -- This abstract claims that this draft is a discussion of
genart> issues. From that per spective, I don't think the use of
genart> 2119 language is appropriate. There are some specific areas
genart> (mentioned below) where 2119 language is used in imprecise
genart> ways, and may do harm to the reader's understanding. There
genart> are other uses that may be more reasonable. But I think the
genart> draft would be better off dispensing with 2119 language
genart> altogether.

We disagree.
I think that the draft provides requirements that if followed will make
management of the security aspects of routers easier to depend on.
I believe 2119 language is useful in that.

I think this is well within an area where there is no IETF-wide
consessus and the judgment of the individual WGs and to a lesser extent
editors should control.

genart> -- Section 3, paragraph 4:

genart> This seems like a place where descriptive language would be
genart> better than 2119 lan guage. In particular, "and so on"
genart> leaves things too open ended and imprecise. Al so, the use
genart> of 2119 language in an example seems a bit off.

So, the requirement is stated in the first clause using 2119 language:

   Operational Requirements: implementations of this model MUST support
   configuration of keys at the most general scope for the underlying
   protocol; 

The sentence goes on to apply that requirement to some common cases:
   protocols supporting per-peer keys MUST permit
   configuration of per-peer keys, protocols supporting per-interface
   keys MUST support configuration of per-interface keys, and so on.

You might prefer different style rules; you might prefer  that the
restatements of the general requirement to specific situations not use
2119 language.
I think the right approach for that is to try and build community
consensus on those style rules and not to apply those rules until such a
consensus is achieved.
I do agree that care should be used when using 2119 in a restatement,
but in this instance believe it is OK.

I've removed the 2119 language from the example, although I think it was
harmless.

genart> -- section 3.1, last paragraph:

genart> I'm not sure what guidance is intended in this paragraph. It
genart> offers an example, then refutes it. Are there better
genart> examples to offer? Is the point that one shoul dn't make
genart> such checks?

The point is that we're not recommending such checks here; added text to
clarify.  Thanks.

genart> -- section 3.2, paragraph 2:

genart> What distinguishes SHOULD from "desirable" in this context?
genart> That is, why use 211 9 language for one and not the other?

The sentences including desirable are giving motivation for the
sentences including SHOULD.
That is the SHOULDS are the take-aways, the desirables are
expansions/explanations of why the SHOULDS make sense.

genart> -- section 3.2, last paragraph: "Implementations SHOULD
genart> permit a configuration i n which if no unexpired key is
genart> available, existing security associations continu e using
genart> the expired key with which they were established."

genart> This may need further guidance. For example, it seems risky
genart> to do this silently.

I think this was explicitly discussed in the WG and is where we got in
our discussions.
There's discussion of alerts for security events elsewhere.
However I think the current text represents a fairly informed WG
consensus.

genart> -- section 3.3, last paragraph: "... then there is
genart> complexity in key management protocols."

genart> Can you elaborate? Too much complexity? Are there key
genart> management systems that ar e not complex?

Clarified to indicate that there's complexity that can be avoided if you
don't need key IDs to be globally unique.

genart> -- section 4, 2nd to last paragraph:

genart> Seems like other disadvantages are worth mentioning. For
genart> example, the potential impact of a compromised CA.

I spent a few minutes trying to come up with an argument whether CA
compromise was better or worse than other systems compromise profile,
particularly focusing on central management system compromise in the
preshared key case.
I think it's difficult to come up with an argument about whether that's
actually a disadvantage of CAs in this case and I think getting
consensus would be non-trivial.
I also think that managing CA compromise can either be handled on the
cost axis (secure offline CA) or the complexity axis (push out new CA
certs and end-entity certs on compromise).
So, I think the current text is accurate.
If there are sp

Re: ORCID - unique identifiers for contributors

[Melinda Shore]

On 9/17/13 9:55 AM, Michael Tuexen wrote:
> ... and that is my point. One level of indirection might be useful here.
> I would prefer to update only one mapping and not go through a list
> of RFCs and change the mapping for each document.

I really think that you all are completely over-engineering
this.  But that's what I think.  What I *know* is that you're
looking at this from the perspective of IETF contributors.
Librarians have a problem, too, and the ORCID stuff primarily
addresses that problem, not ours.

There's been a long history of difficulty in name usage on
documents and that's confounded librarians, who for some
reason (<- sarcasm) feel the need to be able to group works by the same
author.  This has been dealt with through authority control
mechanisms, where the cataloger tries to ascertain if
a given "Scott Smith" is the same person as one of the
many other Scott Smiths already in the catalog, and if not,
creates a new authority record.  Discrimination is encoded
in the authority records in the form of middle names/initials,
dates of birth and death, etc.  Again, this is something the
*cataloger* does, and it's actually rather difficult.  So,
in a cataloging record the contents of the author field are
normalized under authority control and the author name as it
appears on the title page is carried in the body of the
cataloging record, and not indexed.

There's a quite good discussion of this here:
http://kcoyle.blogspot.com/2007/09/name-authority-control-aka-name.html

What ORCID does is allow the author to help catalogers out
by providing a unifying identifier.  It's not intended to
be authenticative or provide identity information - it just
helps group documents (which is why I think it belongs in a
separate piece of metadata).  I don't think this is a huge
deal and i don't think it requires community consensus.  I
imagine most IETF authors, who for the most part are not
academics, will bother with it, and that's just fine.

Melinda

Re: ORCID - unique identifiers for contributors

[Melinda Shore]

On 9/17/13 9:22 AM, Pat Thaler wrote:
> Given this comment in John Levin's post: " PS: Now that I think about
> it, you can already put in a personal URL in rfc2xml, so if someone
> wants to use an ORCID URL, they can do so right now." it seems like
> there isn't any need to change the schema.

I'd agree that there isn't a *need* but I would agree
that for it to be valuable as metadata it ought to (the
word "should" is forever tainted) be a new child
element of the name element.

Melinda

Re: ORCID - unique identifiers for contributors

[Scott Brim]

On Tue, Sep 17, 2013 at 1:22 PM, Pat Thaler  wrote:
> Given this comment in John Levin's post: " PS: Now that I think about it, you 
> can already put in a personal URL
> in rfc2xml, so if someone wants to use an ORCID URL, they can do so
> right now." it seems like there isn't any need to change the schema.

+1.  Those who are concerned about name collisions can add a pointer
to any sort of additional information.

RE: ORCID - unique identifiers for contributors

[Pat Thaler]

Given this comment in John Levin's post: " PS: Now that I think about it, you 
can already put in a personal URL
in rfc2xml, so if someone wants to use an ORCID URL, they can do so
right now." it seems like there isn't any need to change the schema.

-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Joel M. 
Halpern
Sent: Tuesday, September 17, 2013 5:57 AM
To: Andy Mabbett
Cc: ietf@ietf.org
Subject: Re: ORCID - unique identifiers for contributors

Heather Flanagan can be most easily reached at
rfc-edi...@rfc-editor.org, the specified email address for reaching the 
rfc-editor.
Note however that you need to be clear as to what you are asking her. 
If you are asking that she arrange for the tools to include provision 
for using ORCHIDs, that is a reasonable request.  SUch a request would 
presumably be prioritized along with the other tooling improvement that 
are under consideration.

On the other hand, if youa re asking that the IETF endorse or encourage 
such uses, there are two problems.  First, the RFC Editor does not speak 
for the IETF.  You need to actually get a determination of IETF rough 
consensus on the ietf email list.  That consensus would need to be based 
on a more specific question than "do we want to allow ORCHIDs", and then 
would be judged on that question by the IETF chair.

Yours,
Joel M. Halpern

On 9/17/13 8:26 AM, Andy Mabbett wrote:
> On 17 September 2013 13:07, Melinda Shore  wrote:
>> I'm not sure much needs to be done other than talking with Heather
>> Flanagan (the RFC Editor), getting her sign-off, and then getting
>> it into the xml2rfc schema and noting its existence.
>
> Thank you. Is Heather on this list?
>
>> I hope that what's going on here is *not* that there's been
>> little uptake and you're trying to promote its use.
>
> On the contrary; the uptake from both individuals, and organisations
> incorporating ORCID into their publishing workflows - is impressive,
> as you can see form reading the ORCID website & blog.
>

Re: ORCID - unique identifiers for contributors

[Steve Crocker]

I'm in agreement.

We have not had any standards so far regarding maintenance of the validity of 
contact information.  For example, my contact information for the April 1, 1995 
RFC 1776 is:

> Steve Crocker
>CyberCash, Inc.
>2086 Hunters Crest Way
>Vienna, VA 22181
> 
>Phone: +1 703 620 1222
>EMail: croc...@cybercash.com
> 
The email address, phone number and postal address became stale a long time 
ago.  If ORCID is introduced, it's likely to be at least as good as email 
addresses, etc.  Let's avoid or at least defer trying to endow them with 
additional properties such as permanence until there is some experience.

Steve




On Sep 17, 2013, at 12:16 PM, John C Klensin  wrote:

> 
> 
> --On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson
>  wrote:
> 
>> 
>> I did not know about ORCID before this thread.
>> I think it is brilliant, and what I've read about the mandate
>> of orcid.org, and how it is managed, I am enthusiastic.
>> 
>> I agree with what Joel wrote:
>> 
>> Asking for ORCID support in the tool set and asking for IETF
>> endorsement are two very different things.
>> 
>> Having tool support for it is a necessary first step to
>> permitting IETF contributors to gain experience with it.   We
>> need that experience before we can talk about consensus.
>> 
>> So, permit ORCID, but not enforce.
> 
> The more I think about it, the more I think that Andy or someone
> else who understands ORCIDs and the relevant organizations,
> etc., should be working on a URN embedding of the things.  Since
> we already have provisions for URIs in contact information, an
> ORCID namespace would permit the above without additional
> tooling or special RFC Editor decision making.  It would also
> avoid entanglement with and controversies about the rather long
> RFC Editor [re]tooling queue.
> 
> Doing the write-up would require a bit of effort but, in
> principle,
>URN:ORICD:
> is pretty close to trivially obvious.
> 
> Comments about dogfood-eating and not inventing new mechanisms
> when we have existing ones might be inserted by reference here.
> 
>> An interesting second (or third) conversation might be about
>> how I could insert ORCIDs into the meta-data for already
>> published documents. 
> 
> With a URN embedding that question would turn into the much more
> general one about how URIs in contact metadata could be
> retroactively inserted and updated. In some ways, that is
> actually an easier question.
> 
> best,
>   john
> 
> 
> 
> 
> 

Re: [IETF] Re: ORCID - unique identifiers for contributors

[Warren Kumari]

On Sep 17, 2013, at 11:20 AM, Michael Richardson  wrote:

> 
> I did not know about ORCID before this thread.
> I think it is brilliant, and what I've read about the mandate of
> orcid.org, and how it is managed, I am enthusiastic.
> 
> I agree with what Joel wrote:
> 
> Asking for ORCID support in the tool set and asking for IETF endorsement
> are two very different things.
> 

I must admit that I'm still somewhat confused by what exact problem we are 
trying to solve here.

Things that I write in an IETF context are fundamentally different to things 
that I write on other contexts, so I don't really see a need for a *global* 
identifier (If folk think that I wrote a particularly funny anecdote about fish 
they are not likely to be looking for drafts that I have co-authored. Anyway, 
what I author in the IEFT context should reflect WG consensus, so who the 
actual author is is somewhat irrelevant).

So, all I really need is to disambiguate myself in the IETF context.
This seems simple -- when I arrived here, no-one mistook me for some other 
Warren Kumari, so I have stuck with that identifier.
If there was already a Warren Kumari participating I would simply have used my 
middle name (embarrassingly enough, "Kim") and been Warren Kim Kumari.
Had there already been a Warren Kim Kumari, I could refer to myself as Warren 
"Monkey" Kumari, Warren "Ace" Kumari, Warren "Dumbass" Kumari, etc. 

If there were multiple Warren Kumari's participating folk are more likely to 
remember me as "Dumbass Warren" than "that Warren guy with the ORCID 
-0002-2404-6244".

If the purpose it to try prevent folk intentionally passing themselves off as 
someone else, well, putting in an ORCID doesn't really accomplish that either.

I guess I see no harm in this, I just don't really get the point. 

W



> Having tool support for it is a necessary first step to permitting IETF
> contributors to gain experience with it.   We need that experience before we
> can talk about consensus.
> 
> So, permit ORCID, but not enforce.
> An interesting second (or third) conversation might be about how I could
> insert ORCIDs into the meta-data for already published documents.
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> 

-- 
There are only 10 types of people in this world -- those who understand binary 
arithmetic and those who don't.




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: PS Characterization Clarified

[Olaf Kolkman]

FYI.

I just posted the third version of the draft at:
http://tools.ietf.org/html/draft-kolkman-proposed-standards-clarified-02

Diff with the previous document:
http://tools.ietf.org/rfcdiff?url2=draft-kolkman-proposed-standards-clarified-02.txt

I will let Jari know that I believe we converged and that as far as I am 
concerned its last call time.

--Olaf


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ORCID - unique identifiers for contributors

[John Levine]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>Asking for ORCID support in the tool set and asking for IETF endorsement
>are two very different things.
>
>Having tool support for it is a necessary first step to permitting IETF
>contributors to gain experience with it.   We need that experience before we
>can talk about consensus.

The toolset already lets you put in URIs.  What else do you think it needs?

R's,
John
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)

iEYEARECAAYFAlI4gwcACgkQkEiFRdeC/kXqJQCfRBk5uNBf+EEMHlj6BWSRvQCL
YsUAnA6ynSuwlRSigpjw/dhQgQNZltmy
=1xR4
-END PGP SIGNATURE-

Re: ORCID - unique identifiers for contributors

[John C Klensin]

--On Tuesday, September 17, 2013 11:20 -0400 Michael Richardson
 wrote:

> 
> I did not know about ORCID before this thread.
> I think it is brilliant, and what I've read about the mandate
> of orcid.org, and how it is managed, I am enthusiastic.
> 
> I agree with what Joel wrote:
> 
> Asking for ORCID support in the tool set and asking for IETF
> endorsement are two very different things.
> 
> Having tool support for it is a necessary first step to
> permitting IETF contributors to gain experience with it.   We
> need that experience before we can talk about consensus.
> 
> So, permit ORCID, but not enforce.

The more I think about it, the more I think that Andy or someone
else who understands ORCIDs and the relevant organizations,
etc., should be working on a URN embedding of the things.  Since
we already have provisions for URIs in contact information, an
ORCID namespace would permit the above without additional
tooling or special RFC Editor decision making.  It would also
avoid entanglement with and controversies about the rather long
RFC Editor [re]tooling queue.

Doing the write-up would require a bit of effort but, in
principle,
URN:ORICD:
is pretty close to trivially obvious.

Comments about dogfood-eating and not inventing new mechanisms
when we have existing ones might be inserted by reference here.

> An interesting second (or third) conversation might be about
> how I could insert ORCIDs into the meta-data for already
> published documents. 

With a URN embedding that question would turn into the much more
general one about how URIs in contact metadata could be
retroactively inserted and updated. In some ways, that is
actually an easier question.

best,
   john

RE: Gen-ART IETF LC review of draft-allen-dispatch-imei-urn-as-instanceid-10

[Andrew Allen]

Roni
Thank you for the review
My responses below prepended with [AA]
Andrew

From: Roni Even [mailto:ron.even@gmail.com]
Sent: Monday, August 05, 2013 8:35 AM
To: draft-allen-dispatch-imei-urn-as-instanceid@tools.ietf.org
Cc: ietf@ietf.org; gen-...@ietf.org
Subject: Gen-ART IETF LC review of 
draft-allen-dispatch-imei-urn-as-instanceid-10

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at .
Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-allen-dispatch-imei-urn-as-instanceid-10

Reviewer: Roni Even

Review Date:2013-8-5

IETF LC End Date: 2013-8-16

IESG Telechat date:



Summary: This draft is almost ready for publication as an Informational RFC.





Major issues:



Minor issues:



Why is it going to be an Informational RFC, considering that there is a lot of 
normative language in the document.



[AA] I think there are many other informational RFCs that contain normative 
language (e.g. RFC 3325 is informative and full of MUST statements). There is 
no intention to make this an IETF standard so therefore it cannot be standards 
track. This is being specified for 3GPP usage to meet the requirements of RFC 
5626 that require publication of an RFC for specifying URNs that are used as 
instance-IDs.


Nits/editorial comments:

According to RFC editor guidelines 
(http://www.rfc-editor.org/policy.html#policy.abstract) the abstract section 
should not contain citations unless they are completely defined within the 
Abstract.
[AA]  This specification defines how the Uniform Resource Name namespace
   reserved for the GSMA (GSM Association) identities and its sub-
   namespace for the IMEI (International Mobile station Equipment
   Identity) can be used as an instance-id as specified in RFC 5626 [1]
   and also as used by RFC 5627 [2].  Its purpose is to fulfil the
   requirements in RFC 5626 [1] that state "If a URN scheme other than
   UUID is used, the UA MUST only use URNs for which an RFC (from the
   IETF stream) defines how the specific URN needs to be constructed and
   used in the "+sip.instance" Contact header field parameter for
   outbound behavior."

[AA] I think I can remove the as specified in RFC 5626 [1] and also as used by 
RFC 5627 [2] from the first sentence however I think the second sentence 
contains the relevant statement from the RFC so this is OK.

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.

Fwd: FW: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04

[Mary Barnes]

Hi Ben,

I apologize for the delay in responding.  I had initially missed this
review - it either got cached directly with gen-art reviews or the tools
alias burped.  I'm not on the main IETF list with this email address.

Anyways, thank you very much for your thorough review.  Our responses are
below [MB].

We have an update underway that addresses your's and other's LC comments.
 We can forward that to you to preview if you would like.

Regards,
Mary.


-Original Message-
From: Ben Campbell [mailto:b...@nostrum.com]
Sent: Tuesday, July 16, 2013 6:52 PM
To: draft-yusef-dispatch-ccmp-indication@tools.ietf.org
Cc:  Team; IETF-Discussion list
Subject: Gen-ART LC Review of draft-yusef-dispatch-ccmp-indication-04

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:  draft-yusef-dispatch-ccmp-indication-04
Reviewer: Ben Campbell
Review Date: 2013-07-16
IETF LC End Date: 2013-07-16

Summary: This draft is almost ready for publication as a proposed standard,
but I think there are some clarifications needed first.

Major issues:

-- None

Minor issues:

-- Abstract:

Is the abstract current? It says you will discuss pros and cons of a few
options, and recommend two. I guess you did recommend two, but the others
have been relegated to the appendix. There are no pros and cons listed for
the two recommended choices, which seems rather odd.
[MB] You are correct, it's slightly out of date.  We should just update
this to reflect that this document defines two mechanisms.  And, we'll add
additional text to the selected solutions explaining the motivation for
choosing those. So, we suggest the following change (also removing the
references as this document actually doesn't update any normative behavior
in either 3261 or 4575):
OLD:

This document describes a few options to address the above limitation
with the pros and cons for each approach, and recommends two to be
used depending on the need of the UA. The first approach uses the
Call-Info header and as a result this document updates RFC 3261
[RFC3261]. The second approach defines a new value for the 'purpose'
parameter in the 'service-uris' element in the SIP conferencing event
package, and as a result this document updates RFC 4575 [RFC4575].


NEW:

This document describes two mechanisms, depending upon the need of the
UA, to address the above limitation. The first mechanism uses the
Call-Info header, and the second mechanism defines a new value for the
'purpose' parameter in the 'service-uris' element in the SIP
conferencing event package.

[/MB]


It also mentions that these are mechanisms to be used by SIP clients.
That's not repeated in the introduction. Is this entire draft intended
exclusively for SIP clients?

[MB]  We can fix that.  The intent is for SIP clients to use this, in
particular since the Call-Info header is SIP specific. The service-uri that
is being used could also be in the XCON-Data.  But, there would be no
reason for an XCON client to care about that URI since they are using XCON
methods to create conferences, the URI they have for communicating with the
conference server MUST be an XCON URI. We propose adding text to the
Intro something like the following:

OLD:

The CCMP protocol defines a way for a client to determine if a
conference control server supports CCMP, but it does not define a way
for a client to determine if a conference focus supports CCMP.

This document defines two mechanisms to address the above limitation.
Other mechanisms that we considered are listed in Appendix A.

NEW:

The CCMP defines a way for an XCON-aware client to discover whether a
conference control server supports CCMP. However, it does not define a
way for a SIP client involved in a conference to determine if the
conference focus [RFC4353] supports CCMP. Knowing that a focus
supports CCMP would allow a SIP client (that is also XCON-aware) that
joins a conference using SIP based conferencing [RFC4579] to also
register for the XCON conference event package [RFC6502] and take
advantage of CCMP operations on the conference.

This document describes two options to address the above limitation,
depending on the need of the UA. The first option uses the Call-Info
[RFC3261] header,
and the second option defines a new value for the 'purpose' parameter
in the 'service-uris' element in the SIP conferencing event package
[RFC4575].

Other options considered are described in Appendix A.

[/MB]

-- 2.

It would be helpful to give more guidance on when one would use one method
over the other. 2.1 mentions that it might be an "easier way for a UA that
is not interested in the URI".
[MB] Would the following address this concern?
OLD:
This section defines the mechanisms that can be use to discover that a
focus supports CCMP.
NEW:
   This section defines two me

Re: IPR Disclosures for draft-ietf-xrblock-rtcp-xr-qoe

[Alan Clark]

>From 29 years experience in ATIS, CCITT, CEPT, ETSI, IETF, ITU, TIA and
other standards organizations and extensive experience with standards that
do have associated IPR it is apparent that asking for confirmation at
multiple points in the standards development process IS necessary.

For example:

(a) The ITU requires that IPR holders make statements prior to the
publication of a standard.  A top 5 telecom equipment provider submitted a
proposal to add an a new capability to an existing (IPR free) standard and
did NOT state that they had IPR related to this - in fact the inventor on
their patent was the person who wrote and submitted the contribution. Some
years after the standard was published, when their patent was granted, they
started writing to implementers to demand that they take out a license.
Intentional abuse of the standards development process DOES happen.

(b) We often hear from large organizations that, as they have thousands of
patents, they can't possibly know whether they have patents related to a
standard or not.

Repeatedly asking questions about IPR disclosure IS important as it does
make it harder for IPR holders to claim that they did not know.

It should be noted that the duty to disclose IPR is NOT ONLY for the authors
of a draft, and the IETF "reminder" system seems to be focused solely on
authors. The duty to disclose IPR lies with any individual or company that
participates in the IETF not just authors.

Alan Clark


On 9/16/13 1:00 PM, "John C Klensin"  wrote:

> 
> 
> --On Monday, September 16, 2013 19:35 +0700 Glen Zorn
>  wrote:
> 
>> ... 
>>> The wording of this question is not a choice. As WG chairs we
>>> are required to answer the following question which is part
>>> of the Shepherd write-up as per the instructions from the
>>> IESG http://www.ietf.org/iesg/template/doc-writeup.txt:
>>> 
 (7) Has each author confirmed that any and all appropriate
 IPR
 disclosures required for full conformance with the provisions
 of BCP 78
 and BCP 79 have already been filed. If not, explain why.
> 
>>> We have no choice but to relay the question to the authors.
>> 
>> I see, just following orders.
> 
> For whatever it is worth, I think there is a rather different
> problem here.  I also believe it is easily solved and that, if
> it is not, we have a far deeper problem.
> 
> I believe the document writeup that the IESG posts at a given
> time is simply a way of identifying the information the IESG
> wants (or wants to be reassured about) and a template for a
> convenient way to supply that information.  If that were not the
> case:
> 
>  (i) We would expect RFC 4858 to be a BCP, not an
> Informational document.
>  (ii) The writeup template would need to represent
> community consensus after IETF LC, not be something the
> IESG put together and revises from time to time.
>  (iii) The various experiments in alternative template
> formats and shepherding theories would be improper or
> invalid without community consensus, probably expressed
> through formal "process experiment" authorizations of
> the RFC 3933 species.
> 
> The first sentence of the writeup template, "As required by RFC
> 4858, this is the current template..." is technically invalid
> because RFC 4858, as an Informational document, cannot _require_
> anything of the standards process.  Fortunately, it does not say
> "you are required to supply this information in this form" or
> "you are required to ask precisely these questions", which would
> be far worse.
> 
>> From my point of view, an entirely reasonable response to the
> comments above that start "As WG chairs we are required to
> answer the following question..." and "We have no choice but to
> relay..." is that you are required to do no such thing.  The
> writeup template is guidance to the shepherd about information
> and assurances the IESG wants to have readily available during
> the review process, nothing more.   I also believe that any AD
> who has become sufficiently impressed by his [1] power and the
> authority of IETF-created procedures to insist on a WG chair's
> asking a question and getting an answer in some particular form
> has been on the IESG, or otherwise "in the leadership" much too
> long [2].
> 
> In fairness to the IESG, "Has each author confirmed..." doesn't
> require that the document shepherd or WG Chair ask the question
> in any particular way.   Especially if I knew that some authors
> might be uncomfortable being, in Glen's words, treated as
> 8-year-old children, I think I would ask the question in a form
> similar to "since the I-Ds in which you were involved were
> posted, have you had any thoughts or encountered any information
> that would require filing of additional IPR disclosures?".
> That question is a reminder that might be (and occasionally has
> been) useful.  A negative answer to it would be fully as much
> "confirming that any and all appropriate IPR disclosures..."
> have been filed as one whose impli

Re: ORCID - unique identifiers for bibliographers

[Dave Cridland]

On Tue, Sep 17, 2013 at 3:43 PM, John C Klensin  wrote:

> Are we far enough down this rathole?
>
> john
>

I'm not sure. Which John are you again? The car-buying psychiatric composer
who lives in Edinburgh, Georgia?

RE: ORCID - unique identifiers for bibliographers

[John C Klensin]

--On Monday, September 16, 2013 22:28 -0400 John R Levine
 wrote:

>> I do have an identical twin brother, and hashing the DNA
>> sequence collides more regularly than either random or
>> MAC-based interface-identifiers in IPv6.
>> 
>> Also, he doesn't have the same opinions.
> 
> Clearly, one of you needs to get to know some retroviruses.

Or you aren't identical enough.  Clearly the hash should be
computed over both your DNA sequence and a canonical summary of
your opinions.

Are we far enough down this rathole?

john

Re: ORCID - unique identifiers for contributors

[Michael Richardson]

I did not know about ORCID before this thread.
I think it is brilliant, and what I've read about the mandate of
orcid.org, and how it is managed, I am enthusiastic.

I agree with what Joel wrote:

Asking for ORCID support in the tool set and asking for IETF endorsement
are two very different things.

Having tool support for it is a necessary first step to permitting IETF
contributors to gain experience with it.   We need that experience before we
can talk about consensus.

So, permit ORCID, but not enforce.
An interesting second (or third) conversation might be about how I could
insert ORCIDs into the meta-data for already published documents.

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[




pgp9J1CDwgZwX.pgp
Description: PGP signature

Re: ORCID - unique identifiers for contributors

[John C Klensin]

Hi.  I agree completely with Joel, but let me add a bit more
detail and a possible alternative...

--On Tuesday, September 17, 2013 08:56 -0400 "Joel M. Halpern"
 wrote:

> If you are asking that she arrange for the tools
> to include provision for using ORCHIDs, that is a reasonable
> request.  SUch a request would presumably be prioritized along
> with the other tooling improvement that are under
> consideration.

And either explicit provision for ORCID or more general
provisions for other identifying characteristics might easily be
added as part of the still-unspecified conversions to support
non-ASCII characters.  

That said, you could get ORCID IDs into RFCs on your own
initiative by defining and registering a URN type that embedded
the ORCID and then, in xml2rfc terms, using the  element of
 to capture it.  If you want to pursue that
course, RFCs 3044 and 3187 (and others) provide examples of how
it is done although I would suggest that you also consult with
the URNBIS WG before proceeding because some of the procedures
are proposed to be changed.  The RFC Editor (at least) would
presumably need to decide that ORCID-based URNs were
sufficiently stable, but no extra tooling would be required.

> On the other hand, if youa re asking that the IETF endorse or
> encourage such uses, there are two problems.  First, the RFC
> Editor does not speak for the IETF.  You need to actually get
> a determination of IETF rough consensus on the ietf email
> list.  That consensus would need to be based on a more
> specific question than "do we want to allow ORCHIDs", and then
> would be judged on that question by the IETF chair.

And, if you asked that the ORCID be used _instead_ of other
contact information, the issues and several people have raised
would apply in that discussion and, at minimum, would make
getting consensus harder.

john

Re: ORCID - unique identifiers for contributors

[Hector Santos]

+1 Thank you for your input.   Seems to me to be a conflict of 
interest issue. I support the basic concept but why not use a IETF 
registry instead?  Solves several of the conflict of interest 
concerns, including about 3rd party entities disappearing, losing 
support, etc.


--
HLS

On 9/17/2013 8:56 AM, Joel M. Halpern wrote:

Heather Flanagan can be most easily reached at
rfc-edi...@rfc-editor.org, the specified email address for reaching
the rfc-editor.
Note however that you need to be clear as to what you are asking her.
If you are asking that she arrange for the tools to include provision
for using ORCHIDs, that is a reasonable request.  SUch a request would
presumably be prioritized along with the other tooling improvement
that are under consideration.

On the other hand, if youa re asking that the IETF endorse or
encourage such uses, there are two problems.  First, the RFC Editor
does not speak for the IETF.  You need to actually get a determination
of IETF rough consensus on the ietf email list.  That consensus would
need to be based on a more specific question than "do we want to allow
ORCHIDs", and then would be judged on that question by the IETF chair.

Yours,
Joel M. Halpern

On 9/17/13 8:26 AM, Andy Mabbett wrote:

On 17 September 2013 13:07, Melinda Shore 
wrote:

I'm not sure much needs to be done other than talking with Heather
Flanagan (the RFC Editor), getting her sign-off, and then getting
it into the xml2rfc schema and noting its existence.


Thank you. Is Heather on this list?


I hope that what's going on here is *not* that there's been
little uptake and you're trying to promote its use.


On the contrary; the uptake from both individuals, and organisations
incorporating ORCID into their publishing workflows - is impressive,
as you can see form reading the ORCID website & blog.

Re: ORCID - unique identifiers for contributors

[Joel M. Halpern]

Heather Flanagan can be most easily reached at
rfc-edi...@rfc-editor.org, the specified email address for reaching the 
rfc-editor.
Note however that you need to be clear as to what you are asking her. 
If you are asking that she arrange for the tools to include provision 
for using ORCHIDs, that is a reasonable request.  SUch a request would 
presumably be prioritized along with the other tooling improvement that 
are under consideration.


On the other hand, if youa re asking that the IETF endorse or encourage 
such uses, there are two problems.  First, the RFC Editor does not speak 
for the IETF.  You need to actually get a determination of IETF rough 
consensus on the ietf email list.  That consensus would need to be based 
on a more specific question than "do we want to allow ORCHIDs", and then 
would be judged on that question by the IETF chair.


Yours,
Joel M. Halpern

On 9/17/13 8:26 AM, Andy Mabbett wrote:

On 17 September 2013 13:07, Melinda Shore  wrote:

I'm not sure much needs to be done other than talking with Heather
Flanagan (the RFC Editor), getting her sign-off, and then getting
it into the xml2rfc schema and noting its existence.


Thank you. Is Heather on this list?


I hope that what's going on here is *not* that there's been
little uptake and you're trying to promote its use.


On the contrary; the uptake from both individuals, and organisations
incorporating ORCID into their publishing workflows - is impressive,
as you can see form reading the ORCID website & blog.

Re: [DNSOP] Practical issues deploying DNSSEC into the home.

[Jim Gettys]

On Fri, Sep 13, 2013 at 5:33 PM, Glen Wiley  wrote:

> This discussion highlights the importance of making sure that hardware
> vendors understand the need for working clocks that can be easily
> bootstrapped.  In addition to NTP radio clock receivers are ubiquitous,
> tiny and ridiculously cheap.  It is unconscionable that any consumer
> electronics are sold today that boast a visible clock without including a
> radio clock receiver!  This doesn't fix the mountain of already deployed
> SOHO gear, but it is time for vendors that know better (Cisco, Netgear,
> D-Link, etc.) to do the right thing.
>

Radio clock receivers often don't work where these devices are deployed
(like in my basement).  Not enough view of the sky (and multiple layers of
floors).  Radios are "nice to have", but can't be guaranteed to work.


>
> I put entropy in a similar class of problem as radio clock receivers.
>  There are a number of reasonable sources for entropy that take up
> virtually no PCB space and can be built with a few discrete components
> (thinking of quantum effects between 2 transistor gates or zener breakdown
> noise on a zener diode).  Stronger entropy sources get expensive - but
> something that provides reasonable entropy for light crypto should be
> available on SOHO class network gear.
>

Yes, and probably will be someday, and we should all encourage them to do
so.  I agree that SOC vendors should be encouraged to include such
generators (as but one of many sources of entropy: see the following
discussion:
https://plus.google.com/117091380454742934025/posts/SDcoemc9V3J ).

Doesn't help in the meanwhile
- Jim


> On Sep 12, 2013, at 2:19 PM, robert bownes wrote:
>
>
> Chiming in a bit late here, however, the availability of stratum 1 clocks
> and stratum 2 class time data on non IP and/or non interconnected networks
> is now so large, I question why one would run NTP outside of the building
> in many cases, certainly in an enterprise of any size.
>
> A 1pulse per second aligned to GPS is good to a few ns. Fairly
> straightforward to plug into even a OpenWrt type of router. Turn on the pps
> in NTP on the router and you are good to go.
>
>
>
>
>
> On Tue, Sep 10, 2013 at 6:45 PM, Evan Hunt  wrote:
>
>> On Tue, Sep 10, 2013 at 05:59:52PM -0400, Olafur Gudmundsson wrote:
>> > My colleagues and I worked on OpenWrt routers to get Unbound to work
>> > there, what you need to do is to start DNS up in non-validating mode
>> wait
>> > for NTP to fix time, then check if the link allows DNSSEC answers
>> > through, at which point you can enable DNSSEC validation.
>>
>> That's roughly what we did with BIND on OpenWrt/CeroWrt as well.  We
>> also discussed hacking NTP to set the CD bit on its initial DNS queries,
>> but I don't think any of the code made it upstream.
>>
>> My real recommendation would be to run an NTP pool in an anycast cloud of
>> well-known v4 and v6 addresses guaranteed to be reliable over a period of
>> years. NTP could then fall back to those addresses if unable to look up
>> the
>> server it was configured to use.  DNS relies on a well-known set of root
>> server addresses for bootstrapping; I don't see why NTP shouldn't do the
>> same.
>>
>> (Actually... the root nameservers could *almost* provide a workable time
>> tick for bootstrapping purposes right now: the SOA record for the root
>> zone encodes today's date in the serial number.  So you do the SOA lookup,
>> set your system clock, attempt validation; on failure, set the clock an
>> hour forward and try again; on success, use NTP to fine-tune. Klugey! :) )
>>
>> --
>> Evan Hunt -- e...@isc.org
>> Internet Systems Consortium, Inc.
>> ___
>> DNSOP mailing list
>> dn...@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
> ___
> DNSOP mailing list
> dn...@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>

Re: PS Characterization Clarified

[John C Klensin]

--On Tuesday, September 17, 2013 11:32 +0100 Dave Cridland
 wrote:

> I read John's message as being against the use of the phrase
> "in exceptional cases". I would also like to avoid that; it
> suggests that some exceptional argument may have to be made,
> and has the implication that it essentially operates outside
> the process.

Exactly.

> I would prefer the less formidable-sounding "on occasion",
> which still implies relative rarity.

And "on occasion" is at least as good or better than my
suggestions of "usually", "commonly", or "normally" although I
think any of the four would be satisfactory.


--On Tuesday, September 17, 2013 07:06 -0400 Scott Brim
 wrote:

>...
> Exceptions and arguments for and against are part of the
> process. Having a process with no consideration for exceptions
> would be exceptional.

Scott, it an IETF technical context, I'd completely agree,
although some words like "consideration for edge cases" would be
much more precise if that is actually what you are alluding to.
But part of the intent of this revision to 2026 is to make what
we are doing more clear to outsiders who are making a good-faith
effort to understand us and our standards.  In that context,
what you say above, when combined with Olaf's text, is likely to
be read as:

"We regularly, and as a matter of course, consider
waiving our requirements for Proposed Standard entirely
and adopt specifications using entirely different (and
undocumented) criteria."  

That is misleading at best.  In the interest of clarity, I don't
think we should open the door that sort of interpretation if we
can avoid it.

I don't think it belongs in this document (it is adequately
covered by Olaf's new text about other sections), but it is
worth remembering that we do have a procedure for making
precisely the type of exceptions my interpretation above
implies: the Variance Procedure of Section 9.1 of 2026.   I
cannot remember that provision being invoked since 2026 was
published -- it really is "exceptional" in that sense.  Its
existence may be another reason for removing "exceptional" from
the proposed new text because it could be read as implying that
we have to use the Section 9.1 procedure for precisely the cases
of a well-documented, but slightly incomplete, that most of us
consider normal.  In particular, it would make the approval of
the specs that Barry cited in his examples invalid without
invoking the rather complex procedure of Section 9.1.  I'd
certainly not like to have text in this update that encourages
that interpretation and the corresponding appeals -- it would
create a different path to the restriction Barry is concerned
about.

john

Re: ORCID - unique identifiers for contributors

[Andy Mabbett]

On 17 September 2013 13:07, Melinda Shore  wrote:
> I'm not sure much needs to be done other than talking with Heather
> Flanagan (the RFC Editor), getting her sign-off, and then getting
> it into the xml2rfc schema and noting its existence.

Thank you. Is Heather on this list?

> I hope that what's going on here is *not* that there's been
> little uptake and you're trying to promote its use.

On the contrary; the uptake from both individuals, and organisations
incorporating ORCID into their publishing workflows - is impressive,
as you can see form reading the ORCID website & blog.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

Re: ORCID - unique identifiers for contributors

[Melinda Shore]

On 9/17/13 3:56 AM, Andy Mabbett wrote:
> Thank you. So how might we raise awareness of ORCID among RfC
> contributors and and encourage its use by them?

I'm not sure much needs to be done other than talking with Heather
Flanagan (the RFC Editor), getting her sign-off, and then getting
it into the xml2rfc schema and noting its existence.

I hope that what's going on here is *not* that there's been
little uptake and you're trying to promote its use.

Melinda

Re: ORCID - unique identifiers for contributors

[Andy Mabbett]

On 17 September 2013 00:19, Melinda Shore  wrote:

>  I don't see any real downside to allowing
> people who have ORCIDs to put them in IETF documents.  I'm not
> sure there's a lot of demand for them (this is the first time
> it's come up, as far as I know) but I don't see a problem with
> plopping one more piece of information - one that has a unique
> function - into our docs.

Thank you. So how might we raise awareness of ORCID among RfC
contributors and and encourage its use by them?

Is there a "how to" guide or FAQ where it could be mentioned? How
might we get the IETF to agree to wording along the lines of "the IETF
encourages (or "recommends" or "requests") contributors to register
for an ORCID and to include it..."?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

Re: PS Characterization Clarified

[John C Klensin]

--On Tuesday, September 17, 2013 11:47 +0200 Olaf Kolkman
 wrote:

> 
> 
> Based on the conversation below I converged to:
> 
> 
>
>   While less mature specifications will usually be
> published as   Informational or Experimental RFCs, the
> IETF may, in exceptional   cases, publish a specification
> that still contains areas for   improvement or certain
> uncertainties about whether the best   engineering choices
> are made.  In those cases that fact will be   clearly and
> prominently communicated in the document e.g. in the
> abstract, the introduction, or a separate section or statement.
> 

I suggest that "communicated in the document e.g. in..." now
essentially amounts to "... communicated in the document, e.g.
in the document." since the examples span the entire set of
possibilities.   Consequently, for editorial reasons and in the
interest of brevity, I recommend just stopping after
"prominently communicated in the document.".  But, since the
added words are not harmful, I have no problem with your leaving
them if you prefer.

   john

Re: PS Characterization Clarified

[Scott Brim]

On Sep 17, 2013 6:33 AM, "Dave Cridland"  wrote:
>
> On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman  wrote:
>>
>>
>>
>> Based on the conversation below I converged to:
>>
>>
>>
>>   While less mature specifications will usually be published as
>>   Informational or Experimental RFCs, the IETF may, in exceptional
>>   cases, publish a specification that still contains areas for
>>   improvement or certain uncertainties about whether the best
>>   engineering choices are made.  In those cases that fact will be
>>   clearly and prominently communicated in the document e.g. in the
>>   abstract, the introduction, or a separate section or statement.
>> 
>>
>
> I read John's message as being against the use of the phrase "in
exceptional cases". I would also like to avoid that; it suggests that some
exceptional argument may have to be made, and has the implication that it
essentially operates outside the process.
>
> I would prefer the less formidable-sounding "on occasion", which still
implies relative rarity.
>
> Dave.

Exceptions and arguments for and against are part of the process. Having a
process with no consideration for exceptions would be exceptional.

Re: PS Characterization Clarified

[Alexey Melnikov]

On 17/09/2013 11:32, Dave Cridland wrote:
On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman > wrote:



Based on the conversation below I converged to:


   
  While less mature specifications will usually be published as
  Informational or Experimental RFCs, the IETF may, in exceptional
  cases, publish a specification that still contains areas for
  improvement or certain uncertainties about whether the best
  engineering choices are made.  In those cases that fact will be
  clearly and prominently communicated in the document e.g. in the
  abstract, the introduction, or a separate section or statement.



I read John's message as being against the use of the phrase "in 
exceptional cases". I would also like to avoid that; it suggests that 
some exceptional argument may have to be made, and has the implication 
that it essentially operates outside the process.


I would prefer the less formidable-sounding "on occasion", which still 
implies relative rarity.


+1.

Re: PS Characterization Clarified

[Dave Cridland]

On Tue, Sep 17, 2013 at 10:47 AM, Olaf Kolkman  wrote:

>
>
> Based on the conversation below I converged to:
>
>
>
>   While less mature specifications will usually be published as
>   Informational or Experimental RFCs, the IETF may, in exceptional
>   cases, publish a specification that still contains areas for
>   improvement or certain uncertainties about whether the best
>   engineering choices are made.  In those cases that fact will be
>   clearly and prominently communicated in the document e.g. in the
>   abstract, the introduction, or a separate section or statement.
> 
>
>
I read John's message as being against the use of the phrase "in
exceptional cases". I would also like to avoid that; it suggests that some
exceptional argument may have to be made, and has the implication that it
essentially operates outside the process.

I would prefer the less formidable-sounding "on occasion", which still
implies relative rarity.

Dave.

Re: PS Characterization Clarified

[Olaf Kolkman]

On 16 sep. 2013, at 17:31, John C Klensin  wrote:

>> 
>> As actionable for this draft I take that I explicitly mention
>> that Section 4.1 2026 is exclusively updated.
> 
> While I understand your desire to keep this short, the pragmatic
> reality is that your non-IETF audience is likely to read this
> document (especially after you hand it to them) and conclude
> that it is the whole story.  Since the natural question that
> immediately follows "why should we accept your standards at all"
> is "why can't you hand them off to, e.g., ISO, the way that many
> national bodies and organizations like IEEE do with many of
> their documents".  
> 
> Suggestion in the interest of brevity: in addition to mentioning
> the above, mention explicitly that there are requirements in
> other sections of 2026 that affect what is standardized and how. 

Second paragraph of the introduction now reads:


  This document exclusively updates the characterization of
  Proposed Standards from RFC2026 Section 4.1.1 and does not speak
  to or alter the procedures for the maintenance of Standards
  Track documents from RFC 2026 and RFC
  6410. For complete understanding of the requirements for
  standardization those documents should be read in conjunction
  with this document.

> By the way, while I understand all of the reasons why we don't
> want to actually replace 2026 (and agree with most of them),
> things are getting to the point that it takes far too much
> energy to actually figure out what the rules are.  Perhaps it is
> time for someone to create an unofficial redlined version of
> 2026 that incorporates all of the changes and put it up on the
> web somewhere.   I think we would want a clear introduction and
> disclaimer that it might be be exactly correct and that only the
> RFCs are normative, but the accumulation of changes may
> otherwise be taking us too far into the obscure.  If we need a
> place to put it, it might be a good appendix to the Tao.  And
> constructing it might be a good job for a relative newcomer who
> is trying to understand the ins and outs of our formal
> procedures.

I guess this is a call for volunteers.

--Olaf






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: PS Characterization Clarified

[Olaf Kolkman]

Based on the conversation below I converged to:


   
  While less mature specifications will usually be published as
  Informational or Experimental RFCs, the IETF may, in exceptional
  cases, publish a specification that still contains areas for
  improvement or certain uncertainties about whether the best
  engineering choices are made.  In those cases that fact will be
  clearly and prominently communicated in the document e.g. in the
  abstract, the introduction, or a separate section or statement.



I will be publishing version 02 shortly.

--Olaf


[This is a top-post, nothing but context below]



On 16 sep. 2013, at 18:04, John C Klensin  wrote:

> 
> 
> --On Monday, September 16, 2013 10:43 -0400 Barry Leiba
>  wrote:
> 
>> ...
>> I agree that we're normally requiring much more of PS
>> documents than we used to, and that it's good that we document
>> that and let external organizations know.  At the same time,
>> we are sometimes proposing things that we know not to be fully
>> baked (some of these came out of the sieve, imapext, and morg
>> working groups, for example), but we *do* want to propose them
>> as standards, not make them Experimental.  I want to be sure
>> we have a way to continue to do that.  The text Olaf proposes
>> is, I think, acceptable for that.
> 
> In case it wasn't clear, I have no problems with that at all.  I
> was objecting to three things that Olaf's newer text has fixed:
> 
> (1) It is a very strong assertion to say that the above is
> "exceptional".  In particular, "exceptional" would normally
> imply a different or supplemental approval process to make the
> exception.  If all that is intended is to say that we don't do
> it very often, then "commonly" (Olaf's term), "usually", or
> perhaps even "normally" are better terms.
> 
> (2) While it actually may be the common practice, I have
> difficulty with anything that reinforces the notion that the
> IESG makes standardization decisions separate from IETF
> consensus.  While it isn't current practice either, I believe
> that, were the IESG to actually do that in an area of
> significance, it would call for appeals and/or recalls.   Olaf's
> older text implied that the decision to publish a
> not-fully-mature or incomplete specification was entirely an
> IESG one.   While the text in 2026, especially taken out of
> context, is no better (and Olaf just copied the relevant bits),
> I have a problem with any action that appears to reinforce that
> view or to grant the IESG authority to act independently of the
> community.
> 
> (3) As a matter of policy and RFCs of editorially high quality,
> I think it is better to have explanations of loose ends and
> not-fully-baked characteristics of standards integrated into the
> document rather than using IESG Statements.  I don't think
> Olaf's new "front page" requirement is correct (although I can
> live with it) -- I'd rather just say "clearly and prominently
> communicated in the document" and leave the "is it clear and
> prominent enough" question for Last Call -- but don't want to
> see it _forced_ into an IESG statement.
> 
> I do note that "front page" and "Introduction" are typically
> inconsistent requirements (header + abstract + status and
> copyright boilerplate + TOC usually force the Introduction to
> the second or third page).  More important, if a real
> explanation of half-baked features (and why they aren't fully
> baked) may require a section, or more than one, on it own.  One
> would normally like a cross reference to those sections in the
> Introduction and possibly even mention in the Abstract, but
> forcing the text into the Introduction (even with "preferably"
> given experience with how easily that turns into a nearly-firm
> requirement) is just a bad idea in a procedures document.  We
> should say "clearly", "prominently", or both and then leave
> specifics about what that means to conversations between the
> authors, the IESG and community, and the RFC Editor.
> 
>best,
>john
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail