From nobody Tue Aug 1 14:23:38 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40458127735; Tue, 1 Aug 2017 14:23:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-urnbis-ns-reg-transition@ietf.org, Barry Leiba , urnbis-chairs@ietf.org, barryleiba@computer.org, urn@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> Date: Tue, 01 Aug 2017 14:23:33 -0700 Archived-At: Subject: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 21:23:33 -0000 Adam Roach has entered the following ballot position for draft-ietf-urnbis-ns-reg-transition-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Major comment: Section 3 has suggested changes for RFC3188 for the next time it is revised. It's not clear, outside of institutional knowledge (which is a very fragile construct) how the indicated changes are going to be properly remembered when such revision takes place. Is there a good reason this document doesn't simply update RFC3188 by indicating an updated template directly? If this doesn't make sense, I would think that we need at least an erratum associated with RFC3188 that indicates the nature of update that needs to be performed. Minor comments: The draft header indicates that this document obsoletes RFC3044 and RFC3187, but the abstract doesn't mention this, which it should. The document has at least nine places where external documents are mentioned but which are not, themselves, reference citations (e.g., "RFC 8141" rather than "[RFC8141]" in section 2). This will interact poorly with some RFC-related tooling. Please change these to references. From nobody Tue Aug 1 15:30:02 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0A126CD8; Tue, 1 Aug 2017 15:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xg_b8bbG8exv; Tue, 1 Aug 2017 15:29:59 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89376131C8E; Tue, 1 Aug 2017 15:29:59 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dcffo-0001We-FE; Tue, 01 Aug 2017 18:29:56 -0400 Date: Tue, 01 Aug 2017 18:29:50 -0400 From: John C Klensin To: Adam Roach , The IESG cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org Message-ID: In-Reply-To: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 22:30:02 -0000 Adam, While I disagree with your comments, thanks for the careful reading. Several comments and clarifications below, with the understanding that these are my opinions only and that, if there is evidence of WG or IETF consensus to the contrary, I'm happy to make changes... --On Tuesday, August 1, 2017 14:23 -0700 Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-urnbis-ns-reg-transition-08: No Objection > > When responding, please keep the subject line intact and reply > to all email addresses included in the To and CC lines. (Feel > free to cut this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for > more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-tran > sition/ > > > > -------------------------------------------------------------- > -------- COMMENT: > -------------------------------------------------------------- > -------- > > Major comment: > > Section 3 has suggested changes for RFC3188 for the next time > it is revised. It's not clear, outside of institutional > knowledge (which is a very fragile construct) how the > indicated changes are going to be properly remembered when > such revision takes place. Is there a good reason this > document doesn't simply update RFC3188 by indicating an > updated template directly? If this doesn't make sense, I would > think that we need at least an erratum associated with RFC3188 > that indicates the nature of update that needs to be performed. The problem is this. RFC 3188 was never an IETF WG document. It will be replaced by a new RFC, most likely in the Independent Stream unless you are one of your colleagues are interested in sponsoring it as an Informational individual submission. Juha and I have been working intermittently on a draft; the hold-up right now is mostly me, for which I apologize but I have been tied up with other IETF-related work that seemed to be more pressing. There are twp reasons why an updated template is not directly referenced: it isn't ready due to evolution in NBNs and it seemed inappropriate for the WG to make promises about what would be in it. FWIW, the specific things that this draft calls out have already been incorporated in the working draft for 3188bis. > Minor comments: > > The draft header indicates that this document obsoletes > RFC3044 and RFC3187, but the abstract doesn't mention this, > which it should. Disagree. Those are informational documents, not standards track ones, the abstract correctly reflects what the document does, and the relationships are carefully explained in Section 2. Cluttering up the abstract by putting in those RFC numbers seems neither desirable nor appropriate and this should reasonably be an editorial matter under the control of the RFC Editor, not something specified by the IESG. > The document has at least nine places where external documents > are mentioned but which are not, themselves, reference > citations (e.g., "RFC 8141" rather than "[RFC8141]" in > section 2). This will interact poorly with some RFC-related > tooling. Please change these to references. This, again, is an RFC Editor question and a stylistic issue. As far as I know, each of those documents is cited correctly on first appearance (including RFC 8141, which is cited in Section 1). Repeating those citation anchors each time the RFC (or other document) is referenced does not add to either readability or provide useful information for the user. I note that neither the RFC Style Guide (RFC 7322) nor the plain text requirements (RFC 7994) require a citation anchor each time a document is mentioned. If the IESG would like to impose such a requirement (in spite of advice against it in several style manuals), I believe it should be a topic for discussion between the IESG and the RFC Editor, not an IESG review comment on particular documents. It may be worth mentioning that, despite the observation that some RFC authors have adopted the convention and the RFC Editor, in their wisdom, has chosen to let it go, the use of a citation anchor as the subject of a sentence or predicate of a sentence, object of a preposition, etc. (e.g., "as discussed in [RFC8141]") is prohibited by every style manual for the English language that I've been able to find except those who consider the construction such a grave grammatical error as to not be worth mentioning. Perhaps the issue is most easily clarified by assuming RFCs are pretty-printed and "[RFC8141]" above were replaced by a superscript numeral. Of course, if documents were referenced without being cited properly at all, I'd be delighted to fix that when the problems are identified unless the RFC Editor gets to it first. From nobody Tue Aug 1 15:34:41 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89AE131CCC for ; Tue, 1 Aug 2017 15:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgwxUohmK7VF for ; Tue, 1 Aug 2017 15:34:37 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9BCF131CA8 for ; Tue, 1 Aug 2017 15:34:36 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id p68so18973692ywg.0 for ; Tue, 01 Aug 2017 15:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DciMXOORJMuqZIacMCFXjpMjIHY2gLyZ6wlmun8YFEQ=; b=GKIbFGp8QAkRm81Q1RYJBmqMNu3IGigk2ZdR1SyNip9wQGEHAKR1wPcuHevaUnJg6T eMDIlia6PxkfoDnZ4M23NJk6nh/fl7UaNlCQc33TO6iMhsrpI2MTPBJpn3T45imo9Nco lFPSlm78N2P5Qbtu8l84SGaWPeiuOaDPl/HpubHtppBqUlANr55fRzIeiJruX0/m50CP ZtdW76gVP6hVGgZUdV7w5D4uTlM8E9MD8xHMgSznROa657f4IlGE9IB5651YFNONVxXa vWlxEf3Y3rXsqU3UzX1P+htaUNWQ/er4LRPO+AR7ryTdSBzTx/2h5FgrFg+7msSzasqo C5pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DciMXOORJMuqZIacMCFXjpMjIHY2gLyZ6wlmun8YFEQ=; b=d82tZBVUQS6V/vNNEIVS+N+YW6RHbRLs33EBn5m6S1sYsr45KBEasNQHMqvclcY2IY tzLP6a/rBF6b0TcvrqlnWmHdDVwpsUlvMP4/bnn6O8cKYf68CiBdaSY5dtmhvDlSN4ye HwWdAkWislqb/9RM8OfaihR0McLXUnxP5fezypDi7Nit2If7/JdxJr41rTopHhFAedt7 W9VlbDdFV0MjSrW0PUpAbOxiixlZ205L+NN8DJgyMQjtFxg0EYF/FrsFRsi+avmdkw+R 4uQtmMlWcMT3lns6vhKs9Q+GYTnSInsp9nphoa0zZl6P1Hkp/EtLHfhqWth8bz5kcLX+ wKdA== X-Gm-Message-State: AIVw113d4IeOJcCPGxMrPDfdWTlMDBCx16hNPiRfOnDoMw0mSzHM8F2T rYTsZGMdTt/FjyvW9kCKHUe7BqoRw5nOnZ4= X-Received: by 10.13.231.67 with SMTP id q64mr19184934ywe.71.1501626876041; Tue, 01 Aug 2017 15:34:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.36.12 with HTTP; Tue, 1 Aug 2017 15:33:55 -0700 (PDT) In-Reply-To: References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Tue, 1 Aug 2017 15:33:55 -0700 Message-ID: To: John C Klensin Cc: Adam Roach , The IESG , urn@ietf.org, urnbis-chairs@ietf.org, Barry Leiba , draft-ietf-urnbis-ns-reg-transition@ietf.org Content-Type: multipart/alternative; boundary="94eb2c07d42c8857dd0555b8c0d4" Archived-At: Subject: Re: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 22:34:40 -0000 --94eb2c07d42c8857dd0555b8c0d4 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 1, 2017 at 3:29 PM, John C Klensin wrote: > Adam, > > While I disagree with your comments, thanks for the careful > reading. > > Several comments and clarifications below, with the > understanding that these are my opinions only and that, if there > is evidence of WG or IETF consensus to the contrary, I'm happy > to make changes... > > --On Tuesday, August 1, 2017 14:23 -0700 Adam Roach > wrote: > > > Adam Roach has entered the following ballot position for > > draft-ietf-urnbis-ns-reg-transition-08: No Objection > > > > When responding, please keep the subject line intact and reply > > to all email addresses included in the To and CC lines. (Feel > > free to cut this introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/iesg/statement/discuss-criteria.html for > > more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found > > here: > > https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-tran > > sition/ > > > > > > > > -------------------------------------------------------------- > > -------- COMMENT: > > -------------------------------------------------------------- > > -------- > > > > Major comment: > > > > Section 3 has suggested changes for RFC3188 for the next time > > it is revised. It's not clear, outside of institutional > > knowledge (which is a very fragile construct) how the > > indicated changes are going to be properly remembered when > > such revision takes place. Is there a good reason this > > document doesn't simply update RFC3188 by indicating an > > updated template directly? If this doesn't make sense, I would > > think that we need at least an erratum associated with RFC3188 > > that indicates the nature of update that needs to be performed. > > The problem is this. RFC 3188 was never an IETF WG document. > It will be replaced by a new RFC, most likely in the Independent > Stream unless you are one of your colleagues are interested in > sponsoring it as an Informational individual submission. Juha > and I have been working intermittently on a draft; the hold-up > right now is mostly me, for which I apologize but I have been > tied up with other IETF-related work that seemed to be more > pressing. There are twp reasons why an updated template is not > directly referenced: it isn't ready due to evolution in NBNs and > it seemed inappropriate for the WG to make promises about what > would be in it. FWIW, the specific things that this draft calls > out have already been incorporated in the working draft for > 3188bis. > > > Minor comments: > > > > The draft header indicates that this document obsoletes > > RFC3044 and RFC3187, but the abstract doesn't mention this, > > which it should. > > Disagree. Those are informational documents, not standards > track ones, the abstract correctly reflects what the document > does, and the relationships are carefully explained in Section > 2. Cluttering up the abstract by putting in those RFC numbers > seems neither desirable nor appropriate and this should > reasonably be an editorial matter under the control of the RFC > Editor, not something specified by the IESG. > > > The document has at least nine places where external documents > > are mentioned but which are not, themselves, reference > > citations (e.g., "RFC 8141" rather than "[RFC8141]" in > > section 2). This will interact poorly with some RFC-related > > tooling. Please change these to references. > > This, again, is an RFC Editor question and a stylistic issue. > As far as I know, each of those documents is cited correctly on > first appearance (including RFC 8141, which is cited in Section > 1). Repeating those citation anchors each time the RFC (or > other document) is referenced does not add to either readability > or provide useful information for the user. I note that > neither the RFC Style Guide (RFC 7322) nor the plain text > requirements (RFC 7994) require a citation anchor each time a > document is mentioned. If the IESG would like to impose such a > requirement (in spite of advice against it in several style > manuals), I believe it should be a topic for discussion between > the IESG and the RFC Editor, not an IESG review comment on > particular documents. > Speaking for myself, I would vastly prefer that when people cite RFCs by number, those RFCs be actual citations. The reason for this is that those can then be linkified. -Ekr > > It may be worth mentioning that, despite the observation that > some RFC authors have adopted the convention and the RFC Editor, > in their wisdom, has chosen to let it go, the use of a citation > anchor as the subject of a sentence or predicate of a sentence, > object of a preposition, etc. (e.g., "as discussed in > [RFC8141]") is prohibited by every style manual for the English > language that I've been able to find except those who consider > the construction such a grave grammatical error as to not be > worth mentioning. Perhaps the issue is most easily clarified by > assuming RFCs are pretty-printed and "[RFC8141]" above were > replaced by a superscript numeral. > > Of course, if documents were referenced without being cited > properly at all, I'd be delighted to fix that when the problems > are identified unless the RFC Editor gets to it first. > > > --94eb2c07d42c8857dd0555b8c0d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 1, 2017 at 3:29 PM, John C Klensin <john-ietf@jck.com&= gt; wrote:
Adam,

While I disagree with your comments, thanks for the careful
reading.

Several comments and clarifications below, with the
understanding that these are my opinions only and that, if there
is evidence of WG or IETF consensus to the contrary, I'm happy
to make changes...

--On Tuesday, August 1, 2017 14:23 -0700 Adam Roach
<adam@nostrum= .com> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-urnbis-ns-reg-transition-08: No Objection
>
> When responding, please keep the subject line intact and reply
> to all email addresses included in the To and CC lines. (Feel
> free to cut this introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html for
> more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found
> here:
> https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-tran
> sition/
>
>
>
> ------------------------------------------------------------= --
> -------- COMMENT:
> ------------------------------------------------------------= --
> --------
>
> Major comment:
>
> Section 3 has suggested changes for RFC3188 for the next time
> it is revised. It's not clear, outside of institutional
> knowledge (which is a very fragile construct) how the
> indicated changes are going to be properly remembered when
> such revision takes place. Is there a good reason this
> document doesn't simply update RFC3188 by indicating an
> updated template directly? If this doesn't make sense, I would
> think that we need at least an erratum associated with RFC3188
> that indicates the nature of update that needs to be performed.

The problem is this.=C2=A0 RFC 3188 was never an IETF WG docume= nt.
It will be replaced by a new RFC, most likely in the Independent
Stream unless you are one of your colleagues are interested in
sponsoring it as an Informational individual submission.=C2=A0 Juha
and I have been working intermittently on a draft; the hold-up
right now is mostly me, for which I apologize but I have been
tied up with other IETF-related work that seemed to be more
pressing.=C2=A0 There are twp reasons why an updated template is not
directly referenced: it isn't ready due to evolution in NBNs and
it seemed inappropriate for the WG to make promises about what
would be in it.=C2=A0 FWIW, the specific things that this draft calls
out have already been incorporated in the working draft for
3188bis.

> Minor comments:
>
> The draft header indicates that this document obsoletes
> RFC3044 and RFC3187, but the abstract doesn't mention this,
> which it should.

Disagree.=C2=A0 Those are informational documents, not standards
track ones, the abstract correctly reflects what the document
does, and the relationships are carefully explained in Section
2.=C2=A0 Cluttering up the abstract by putting in those RFC numbers
seems neither desirable nor appropriate and this should
reasonably be an editorial matter under the control of the RFC
Editor, not something specified by the IESG.

> The document has at least nine places where external documents
> are mentioned but which are not, themselves, reference
> citations (e.g., "RFC 8141"=C2=A0 rather than "[RFC8141= ]" in
> section 2). This will interact poorly with some RFC-related
> tooling. Please change these to references.

This, again, is an RFC Editor question and a stylistic issue.
As far as I know, each of those documents is cited correctly on
first appearance (including RFC 8141, which is cited in Section
1).=C2=A0 Repeating those citation anchors each time the RFC (or
other document) is referenced does not add to either readability
or provide useful information for the user.=C2=A0 =C2=A0 I note that
neither the RFC Style Guide (RFC 7322) nor the plain text
requirements (RFC 7994) require a citation anchor each time a
document is mentioned.=C2=A0 =C2=A0If the IESG would like to impose such a<= br> requirement (in spite of advice against it in several style
manuals), I believe it should be a topic for discussion between
the IESG and the RFC Editor, not an IESG review comment on
particular documents.

Speaking for myse= lf, I would vastly prefer that when people cite RFCs by number, those RFCs = be actual citations. The reason for this is that those can then be linkifie= d.

-Ekr
=C2=A0

It may be worth mentioning that, despite the observation that
some RFC authors have adopted the convention and the RFC Editor,
in their wisdom, has chosen to let it go, the use of a citation
anchor as the subject of a sentence or predicate of a sentence,
object of a preposition, etc. (e.g., "as discussed in
[RFC8141]") is prohibited by every style manual for the English
language that I've been able to find except those who consider
the construction such a grave grammatical error as to not be
worth mentioning.=C2=A0 Perhaps the issue is most easily clarified by
assuming RFCs are pretty-printed and "[RFC8141]" above were
replaced by a superscript numeral.

Of course, if documents were referenced without being cited
properly at all, I'd be delighted to fix that when the problems
are identified unless the RFC Editor gets to it first.



--94eb2c07d42c8857dd0555b8c0d4-- From nobody Tue Aug 1 16:06:12 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E613131CA8; Tue, 1 Aug 2017 16:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1iwWtMnIv2w; Tue, 1 Aug 2017 16:06:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B38C124B09; Tue, 1 Aug 2017 16:06:03 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v71N60CO049141 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 1 Aug 2017 18:06:01 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: John C Klensin , The IESG Cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> Date: Tue, 1 Aug 2017 18:05:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9D861E4350BCA122BA5A9F8B" Content-Language: en-US Archived-At: Subject: Re: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 23:06:05 -0000 This is a multi-part message in MIME format. --------------9D861E4350BCA122BA5A9F8B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/1/17 5:29 PM, John C Klensin wrote: > >> Major comment: >> >> Section 3 has suggested changes for RFC3188 for the next time >> it is revised. It's not clear, outside of institutional >> knowledge (which is a very fragile construct) how the >> indicated changes are going to be properly remembered when >> such revision takes place. Is there a good reason this >> document doesn't simply update RFC3188 by indicating an >> updated template directly? If this doesn't make sense, I would >> think that we need at least an erratum associated with RFC3188 >> that indicates the nature of update that needs to be performed. > The problem is this. RFC 3188 was never an IETF WG document. > It will be replaced by a new RFC, most likely in the Independent > Stream unless you are one of your colleagues are interested in > sponsoring it as an Informational individual submission. Have you asked? > Juha > and I have been working intermittently on a draft; the hold-up > right now is mostly me, for which I apologize but I have been > tied up with other IETF-related work that seemed to be more > pressing. There are twp reasons why an updated template is not > directly referenced: it isn't ready due to evolution in NBNs and > it seemed inappropriate for the WG to make promises about what > would be in it. FWIW, the specific things that this draft calls > out have already been incorporated in the working draft for > 3188bis. The fact that a document revision is actually underway does assuage my concern for the most part. Could you cite the 3188bis document as a work in progress? I think it would be useful for consumers of this document to know that a revision is actively in progress, and to have a document name to look for. > >> Minor comments: >> >> The draft header indicates that this document obsoletes >> RFC3044 and RFC3187, but the abstract doesn't mention this, >> which it should. > Disagree. Those are informational documents, not standards > track ones, the abstract correctly reflects what the document > does, and the relationships are carefully explained in Section > 2. Cluttering up the abstract by putting in those RFC numbers > seems neither desirable nor appropriate and this should > reasonably be an editorial matter under the control of the RFC > Editor, not something specified by the IESG. Rather than engaging on the broader topic of indicating Obsoletes and Updates in the abstract in general, I'll point out that *this* document is paired with a request to reclassify 3044 and 3187 as Historic. There is long-standing IESG guidance on this topic , which includes the provision "If authors wish to change the status of RFCs that are in the obsoletes header to Historic, then the authors must include an explicit statement for the RFC editor to do so; *preferably in the abstract and introduction*." You may, of course, choose to ignore this officially stated IESG preference, but doing so would unnecessarily go against convention. In terms of RFC Editor policy: while the RFC Style Guide does not explicitly require obsoleted RFCs to be listed in the abstract, I find it rather telling that it does, itself, do so. This is quite possibly because RFC Abstracts (according to said style guide) are required to give a "concise and comprehensive overview of the purpose and contents of the entire document," and some substantial portion of the purpose of *this* document is obsoleting existing RFCs -- thus failing the "comprehensive" portion of that requirement. So while it may well be outside my purview as a member of the IESG to require you to fix this defect, it seems quite probable that you'll have this conversation again with a member of the RPC in a short while. /a --------------9D861E4350BCA122BA5A9F8B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 8/1/17 5:29 PM, John C Klensin wrote:

Major comment:

Section 3 has suggested changes for RFC3188 for the next time
it is revised. It's not clear, outside of institutional
knowledge (which is a very fragile construct) how the
indicated changes are going to be properly remembered when
such revision takes place. Is there a good reason this
document doesn't simply update RFC3188 by indicating an
updated template directly? If this doesn't make sense, I would
think that we need at least an erratum associated with RFC3188
that indicates the nature of update that needs to be performed.

The problem is this.  RFC 3188 was never an IETF WG document.
It will be replaced by a new RFC, most likely in the Independent
Stream unless you are one of your colleagues are interested in
sponsoring it as an Informational individual submission.

Have you asked?

Juha
and I have been working intermittently on a draft; the hold-up
right now is mostly me, for which I apologize but I have been
tied up with other IETF-related work that seemed to be more
pressing.  There are twp reasons why an updated template is not
directly referenced: it isn't ready due to evolution in NBNs and
it seemed inappropriate for the WG to make promises about what
would be in it.  FWIW, the specific things that this draft calls
out have already been incorporated in the working draft for
3188bis.

The fact that a document revision is actually underway does assuage my concern for the most part. Could you cite the 3188bis document as a work in progress? I think it would be useful for consumers of this document to know that a revision is actively in progress, and to have a document name to look for.



Minor comments:

The draft header indicates that this document obsoletes
RFC3044 and RFC3187, but the abstract doesn't mention this,
which it should.

Disagree.  Those are informational documents, not standards
track ones, the abstract correctly reflects what the document
does, and the relationships are carefully explained in Section
2.  Cluttering up the abstract by putting in those RFC numbers
seems neither desirable nor appropriate and this should
reasonably be an editorial matter under the control of the RFC
Editor, not something specified by the IESG.

Rather than engaging on the broader topic of indicating Obsoletes and Updates in the abstract in general, I'll point out that *this* document is paired with a request to reclassify 3044 and 3187 as Historic. There is long-standing IESG guidance on this topic <https://www.ietf.org/iesg/statement/designating-rfcs-as-historic-2011-06-27.html>, which includes the provision "If authors wish to change the status of RFCs that are in the obsoletes header to Historic, then the authors must include an explicit statement for the RFC editor to do so; preferably in the abstract and introduction."

You may, of course, choose to ignore this officially stated IESG preference, but doing so would unnecessarily go against convention.

In terms of RFC Editor policy: while the RFC Style Guide does not explicitly require obsoleted RFCs to be listed in the abstract, I find it rather telling that it does, itself, do so. This is quite possibly because RFC Abstracts (according to said style guide) are required to give a "concise and comprehensive overview of the purpose and contents of the entire document," and some substantial portion of the purpose of *this* document is obsoleting existing RFCs -- thus failing the "comprehensive" portion of that requirement. So while it may well be outside my purview as a member of the IESG to require you to fix this defect, it seems quite probable that you'll have this conversation again with a member of the RPC in a short while.

/a
--------------9D861E4350BCA122BA5A9F8B-- From nobody Wed Aug 2 08:04:51 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE896132133; Wed, 2 Aug 2017 08:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8m2KjyLCFJjg; Wed, 2 Aug 2017 08:04:40 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2AC132134; Wed, 2 Aug 2017 08:04:40 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dcvCQ-00039n-6M; Wed, 02 Aug 2017 11:04:38 -0400 Date: Wed, 02 Aug 2017 11:04:31 -0400 From: John C Klensin To: Adam Roach , The IESG cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org Message-ID: In-Reply-To: <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:04:44 -0000 --On Tuesday, August 1, 2017 18:05 -0500 Adam Roach wrote: > On 8/1/17 5:29 PM, John C Klensin wrote: >> >>> Major comment: >>> >>> Section 3 has suggested changes for RFC3188 for the next time >>> it is revised. It's not clear, outside of institutional >>> knowledge (which is a very fragile construct) how the >>> indicated changes are going to be properly remembered when >>> such revision takes place. Is there a good reason this >>> document doesn't simply update RFC3188 by indicating an >>> updated template directly? If this doesn't make sense, I >>> would think that we need at least an erratum associated with >>> RFC3188 that indicates the nature of update that needs to be >>> performed. >> The problem is this. RFC 3188 was never an IETF WG document. >> It will be replaced by a new RFC, most likely in the >> Independent Stream unless you are one of your colleagues are >> interested in sponsoring it as an Informational individual >> submission. > > Have you asked? Not yet. Figured it would be better to have a posted I-D first. >> Juha >> and I have been working intermittently on a draft; the hold-up >> right now is mostly me, for which I apologize but I have been >> tied up with other IETF-related work that seemed to be more >> pressing. There are twp reasons why an updated template is >> not directly referenced: it isn't ready due to evolution in >> NBNs and it seemed inappropriate for the WG to make promises >> about what would be in it. FWIW, the specific things that >> this draft calls out have already been incorporated in the >> working draft for 3188bis. > > The fact that a document revision is actually underway does > assuage my concern for the most part. Could you cite the > 3188bis document as a work in progress? I think it would be > useful for consumers of this document to know that a revision > is actively in progress, and to have a document name to look > for. We had such a reference or something like it in an earlier draft. Barry asked us to take it out on the grounds that the WG should not be making promises about a document that was not part of its work program. That made sense to me, so we removed it. But I don't feel at all strongly about it so, if you, Barry and others want such a placeholder reference, I'm happy with that. >>> Minor comments: >>> >>> The draft header indicates that this document obsoletes >>> RFC3044 and RFC3187, but the abstract doesn't mention this, >>> which it should. >> Disagree. Those are informational documents, not standards >> track ones, the abstract correctly reflects what the document >> does, and the relationships are carefully explained in Section >> 2. Cluttering up the abstract by putting in those RFC numbers >> seems neither desirable nor appropriate and this should >> reasonably be an editorial matter under the control of the RFC >> Editor, not something specified by the IESG. > > Rather than engaging on the broader topic of indicating > Obsoletes and Updates in the abstract in general, I'll point > out that *this* document is paired with a request to > reclassify 3044 and 3187 as Historic. There is long-standing > IESG guidance on this topic > ric-2011-06-27.html>, which includes the provision "If authors > wish to change the status of RFCs that are in the obsoletes > header to Historic, then the authors must include an explicit > statement for the RFC editor to do so; *preferably in the > abstract and introduction*." There is an explicit statement in the Introduction. It does not use the word "Historic" (that is in Section 2). If you believe the document would be improved by changing the relevant sentence in the Introduction to say "Obsoletes the separate RFCs and makes them Historic...", that change is easily made (and, frankly, should be have long before this, but no one caught it). I believe there are documents where there is good reason to include RFC numbers in the abstract but this is not one of them. I also note that RFC Editor rules against putting citation anchors in abstracts causes every such included RFC number to violate your preferred citation rule because those numbers not only do not have citation numbers but are the first textual references to those numbers in the document. If "preferably" is turning in "mandatory", we need to have two discussions, one about the authority boundary between the IESG and the RFC Editor and the other about where in RFC 2026 and its updates the IESG is given authority to make policy by issuing statements rather than determining and reflecting IETF community consensus. > You may, of course, choose to ignore this officially stated > IESG preference, but doing so would unnecessarily go against > convention. See above. I am not ignoring it. I have carefully considered it and concluded that it is inappropriate for the abstract in this case, a conclusion with which no one in the WG has expressed disagreement. As to "go[ing] against convention", I believe that a careful survey of documents since that statement was issued would not show that the "preference" has been consistently enough followed to constitute normal behavior, nor that this is a "preference" that the RFC Editor is enforcing. If this were really close to a firm rule, I would expect the RFC Editor to "correct" every deviation during their editorial process, allowing any issues to be sorted out on AUTH48, just as they enforce, e.g., references without citations. > In terms of RFC Editor policy: while the RFC Style Guide does > not explicitly require obsoleted RFCs to be listed in the > abstract, I find it rather telling that it does, itself, do > so. This is quite possibly because RFC Abstracts (according to > said style guide) are required to give a "concise and > comprehensive overview of the purpose and contents of the > entire document," and some substantial portion of the purpose > of *this* document is obsoleting existing RFCs -- thus failing > the "comprehensive" portion of that requirement. So while it > may well be outside my purview as a member of the IESG to > require you to fix this defect, it seems quite probable that > you'll have this conversation again with a member of the RPC > in a short while. The "comprehensive" part of that requirement is arguably a poor choice of words (I will get an erratum filed later today), but the paragraph that follows (RFC 7322, Section 4.3) makes this perfectly clear (at least to me) that the Abstract is a matter of professional and editorial judgment, not something that should become long or confusing in the interest of covering all aspects of the document completely. The paragraph after that, requiring that the Abstract be complete in itself, prohibits citations, implying that people should not have to look at other documents to understand the abstract. However, a statement such as "This document makes RFC 3044 Historic" is a citation (even though it doesn't have an explicit anchor) and conveys no information unless one knows what 3044 refers to (see below about well-known numbers). Again, I believe this is an editorial judgment call. I believe that, had I been editing the Style Guide, I would have included the number of the previous one in the abstract and, since that preference was announced and despite my misgivings about citations in abstracts, I have generally included the numbers when a new document completely replaces an old one (or more than one) and/or when the previous spec is widely known by its number. However, those criteria identify both of the issues that have caused me to make a different judgment in this case: (1) Unless the previous document was widely known by its number, as distinct from being known by a name or not being well-known at all, I dislike, as an editorial matter, including RFC numbers in abstracts without explanations. The reason is closely linked to the RFC Editor decision to not allow citation anchors in abstracts (a decision that is supported by some, but not all, more generally used style manuals). If the goal of an abstract is to provide information to the casual reader about what the document is about, "clarifies the status of relevant older RFCs" (or even "clarifies the status of relevant older RFCs. including making the ones describing the ISBN and ISSN URNs historic", a change I'd happily make if you felt it would improve things) does that and fulfills a reasonable interpretation of the "comprehensive" requirement without folding the entire document into the abstract (which might be required by another interpretation of "comprehensive"). (2) Under most circumstances in which one document replaces (and obsoletes) another, the new document contains all of the information in the old one and/or explains what it changes. If that type of relationship and explanation is present, there is a strong argument for reflecting that (number or not) in the abstract as part of being "comprehensive". However, in this case, the substantive replacements for the substantive parts of RFCs 3044 and 3187 are not in the text in this document. This document describes the changes in general terms, but the replacement specifications are the new templates. Specifically, I disagree with your conclusion that "some substantial portion of the purpose of *this* document is obsoleting existing RFCs": a substantial portion of the document explains why the templates make the existing RFCs de facto obsolete, but the only sense in which it obsoletes them is a narrow procedural one on which it does not spend much text. Noting that there is no procedure for an IANA registration to obsolete an RFC, when we assumed that this document would be published before those templates were agreed-to and posted, there was some convoluted text in earlier versions of this I-D about not obsoleting 3044 and 3187 until the new templates were registered, text that presumably would have made this conversation even more "interesting". Situations in which a new document obsoletes all or part of an older one as part of, e.g., defining a new strategy have always been problematic in the IETF, with, e.g., frequent problems about references, sometimes normative, to sections of the older document that were not addressed anywhere. In large measure, this document was produced to avoid that problem for the relevant URN namespaces, a goal I hope the IESG would welcome. I note for purposes of comparison that RFC 8141 obsoletes RFCs 2141 and 3406 in the more traditional sense. The new specification covers all of the same ground as the older ones and there is no substantively-interesting text in the older ones that is not replaced or repeated by text in the new one. In addition, 2141 and 3406 are fairly widely known by their numbers. And the older documents are listed by number in the abstract. The above suggests another alternative, one that I would recommend if the current preference of the IESG is to make more work for the community and itself in the interest of favoring form over function. This document could be divided into two parts, one of which would be a simple explanation of the changes and relationships, that wouldn't obsolete anything (although it would provide the motivation for doing so), and that could be published as Informational. The other would be a very short, standards-track document that would obsolete the ISSN (3044) and ISBN (3187) RFCs and make them Historic, reference the first one and the templates informatively, contain the RFC numbers in the abstract because that would be its main purpose, etc. We didn't do that because we believed it would be more confusing for users, in part because we don't have a good way to link such documents together and reflect current status (another decision of a long-gone IESG), but it was a conscious decision. Of course, splitting things up at this point would require new I-Ds, probably a new WG review/ LC, a pair of IETF Last Calls, and then new IESG actions. But, again, if that is what the IESG, it its wisdom, wants and how the IESG believes the community can best spend its time, I'm willing to break the document apart so that it is possible. regards, john From nobody Wed Aug 2 11:18:42 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F03B131BFB; Wed, 2 Aug 2017 11:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LB1VsW4g8-7; Wed, 2 Aug 2017 11:18:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D2212EB99; Wed, 2 Aug 2017 11:18:37 -0700 (PDT) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v72IIYIo068570 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Aug 2017 13:18:35 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: John C Klensin , The IESG Cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> From: Adam Roach Message-ID: Date: Wed, 2 Aug 2017 13:18:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:18:39 -0000 On 8/2/17 10:04, John C Klensin wrote: > If "preferably" > is turning in "mandatory", we need to have two discussions, one > about the authority boundary between the IESG and the RFC Editor > and the other about where in RFC 2026 and its updates the IESG > is given authority to make policy by issuing statements rather > than determining and reflecting IETF community consensus. Thanks for sending me down the path of determining authority here, as it has made me realize that I was confused about the basis for insisting that Obsoleted documents be explicitly listed in the Abstract. It turns out that the 2011 IESG statement of "preferably" is a weak restating of a 2008 IETF-consensus decision to approve version 1.9 of the "ID-Checklist" document, which clearly states that the Abstract of a document needs to list obsoleted and/or updated documents (cf. ; §3, 1.D, first bullet: "if your document obsoletes or updates a previous RFC, then... say so in the abstract"). And so I am forced to concede that my "No Objection" was made in error. Since the form of this document actively goes against IETF community consensus regarding the form of IETF-stream RFCs, I realize that this should have been a "Discuss." I will be adjusting my ballot accordingly. Thank you again for pointing me in the correct direction, and I apologize for the error. > As to "go[ing] against convention", I > believe that a careful survey of documents since that statement > was issued would not show that the "preference" has been > consistently enough followed to constitute normal behavior, nor > that this is a "preference" that the RFC Editor is enforcing. I've consulted with the RFC Editor, and received confirmation that their policy is (and has historically been) to "help enforce" this requirement, on the authority of ID-Checklist. You seem to be aware of documents for which this was overlooked. If you could identify them, I would appreciate it, as doing so would allow the proper errata to be filed. /a From nobody Wed Aug 2 11:18:57 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C963131C94; Wed, 2 Aug 2017 11:18:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-urnbis-ns-reg-transition@ietf.org, Barry Leiba , urnbis-chairs@ietf.org, barryleiba@computer.org, urn@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150169791936.5772.4131400252888235469.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 11:18:39 -0700 Archived-At: Subject: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:18:39 -0000 Adam Roach has entered the following ballot position for draft-ietf-urnbis-ns-reg-transition-08: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The specification has not been properly vetted against the I-D Checklist. The draft header indicates that this document obsoletes RFC3044 and RFC3187, but the abstract doesn't mention this, which it should. Listing of obsoleted documents in the Abstract is specified by the ID-Checklist document (§3, 1.D, first bullet), ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Major comment: Section 3 has suggested changes for RFC3188 for the next time it is revised. It's not clear, outside of institutional knowledge (which is a very fragile construct) how the indicated changes are going to be properly remembered when such revision takes place. Is there a good reason this document doesn't simply update RFC3188 by indicating an updated template directly? If this doesn't make sense, I would think that we need at least an erratum associated with RFC3188 that indicates the nature of update that needs to be performed. Minor comment: The document has at least nine places where external documents are mentioned but which are not, themselves, reference citations (e.g., "RFC 8141" rather than "[RFC8141]" in section 2). This will interact poorly with some RFC-related tooling. Please change these to references. From nobody Wed Aug 2 16:01:37 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 34094126B6E; Wed, 2 Aug 2017 16:01:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-urnbis-ns-reg-transition@ietf.org, Barry Leiba , urnbis-chairs@ietf.org, barryleiba@computer.org, urn@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> Date: Wed, 02 Aug 2017 16:01:29 -0700 Archived-At: Subject: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 23:01:29 -0000 Ben Campbell has entered the following ballot position for draft-ietf-urnbis-ns-reg-transition-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have a different take on Adam's discuss point. I don't think its appropriate for this draft to both obsolete 3044 and 3187 and make them historical. This draft doesn't replace them. And since IANA may have to deal with a mix of old and new templates for some transition period, it doesn't remove the need for them. Instead, I think it would make more sense for this draft to just change their status to historical, but not obsolete them. And also mention that in the abstract :-) . From nobody Wed Aug 2 17:39:54 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B892F129AAD; Wed, 2 Aug 2017 17:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L89LpPIGmPhR; Wed, 2 Aug 2017 17:39:45 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43EB4126C7A; Wed, 2 Aug 2017 17:39:45 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dd4Av-00041d-VR; Wed, 02 Aug 2017 20:39:41 -0400 Date: Wed, 02 Aug 2017 20:39:34 -0400 From: John C Klensin To: Ben Campbell , The IESG cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org Message-ID: In-Reply-To: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> References: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 00:39:47 -0000 --On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell wrote: >... > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for > more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found > here: > https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-tran > sition/ > > > > -------------------------------------------------------------- > -------- COMMENT: > -------------------------------------------------------------- > > I have a different take on Adam's discuss point. I don't think > its appropriate for this draft to both obsolete 3044 and 3187 > and make them historical. This draft doesn't replace them. First of all, you are absolutely right. This document doesn't "obsolete" (note that a verb only in IETf-speak) either 3044 or 3187. That doesn't mean that they are anything but obsolete, but what gets them into that state is the combination of: * Changes, by ISO, in the underlying standards for the relevant identifiers. * The language in RFC 8141 that makes the templates normative for definition of URN namespaces rather than, e.g., RFCs that describe those namespaces. * The submission, by the namespace registrants/ managers for ISSN and ISSN, of templates to IANA as specified by RFC 8141 and the acceptance and recording by IANA of those templates for those namespaces. The reason for moving the existing namespace description and registration document to Historic is to prevent confusion about what constitutes the current spec. I (and I think the WG) thought it would be less confusing to identify them as obsolete and create the usual forward pointers to a document that explained what was going on even if that document doesn't do any "obsoleting". If the IESG believes that 3044 and 3187 should be Historic but not obsolete, go for it. However, before doing so, note that state would not make any entry in the RFC Index pointing to an explanation, possibly leaving readers with the impression that the URN namespaces for ISSN and ISBN had simply be discontinued. To me, there are two fundamental problems underlying this discussion, both independent of my specific concerns with Adam's DISCUSS and the associated logic, which I will address separately. The first is that it has become increasingly clear in the last few years that, while the "Obsolete" and "Historic" categories are adequate for many obvious cases, they are only vaguely defined, with a number of problematic edge cases. Based on exchanges on the IETF list that are not directly related to this draft, the IESG is aware of those issues, but, at least as far as I know, has not made a serious attempt (such as trying to initiate a WG with appropriate focus) to get them resolved, introduce additional categories or guidance, etc. Given that situation. getting into a situation in which advancement of document is questioned because of some particular theory about the definition of "Obsoletes" seems to me to be of questionable appropriateness. YMMD, of course. Second, and in my opinion more important, the WG discussed and understood the relationships involved here. It concluded that a "transition" document of this type was appropriate to provide an explanation of the relationship between namespaces created/ registered under RFC 2141 and either 2611 or 3406 and those created under what is now 8141. Making sure that there was no ambiguity about the status of 3044 and 3187 (and, eventually, 3188) and new, 8141-compatible templates was an important objective, and the decision to identify the earlier documents as obsolete and historic was part of that. Over the last few decades, when I've been asked how the IETF is different from most traditional standards bodies, one of the answers I give most often is that we usually figure out what the right thing is to do to get the results we want and them do it rather than getting wrapped around assorted procedural and make-work axles. It seems to me that, in the absence of a better set of categories and definitions, "the right thing for the users and readers" is exactly what the WG was trying to do here. If the IESG has a better approach to recommend, that is fine with me. But, so far, it seems to me that your suggestions (and Adam's) add work and would either make things more complex or less clear. > And > since IANA may have to deal with a mix of old and new > templates for some transition period, it doesn't remove the > need for them. Whoops! I either don't understand what you are saying above or it indicates one or more series editorial or explanatory problems in this I-D, RFC 8141, or both. For any given namespace, there is only one template at any given time and IANA has only one such template registered. There is no transition in IANA's scope and no need (or opportunity) for IANA to deal with an old template and a new one at the same time for any given namespace. I assume that a template (again for a particular namespace) could discuss transitions from an earlier form, but that would be an intra-namespace issue, not anything IANA needs to deal with or even be aware of. The sense in which IANA needs to deal with both old and new templates is that there are namespaces defined under RFC 2611 or 3406 for which new templates have not yet been provides (and may never be), but that isn't a transition topic that IANA has to manage either (and the procedures for having some older registrations conforming to the old template and mechanisms and some conforming to the new ones was carefully sorted out with IANA as part of RFC 8141, so, if there is an issue, it isn't with this document. RFC 3044 and 3187 because inconsistent with the underlying standards when those standard were published. That doesn't make them obsolete in the IETF sense, but it does make them a little questionable as specs because it isn't completely clear whether they consider the newer ISO specs normative or are still dependent on specs ISO considers "replaced" and/or "withdrawn" (categories that overlap with our "obsolete" and "historic" but are definitely not the same as either). They became obsolete by any reasonable criterion when IANA replaced information based on them, and references to them, in the registry by information and references associated with the new templates. However, as I reminded Adam, an IANA registration cannot obsolete an RFCs, some something was needed, preferably something that leaves tracks. Hence those aspects of this document even if it pushes the usual boundaries of our practices in the interest of clarity and good sense. > Instead, I think it would make more sense for this draft to > just change their status to historical, but not obsolete them. But they _are_ obsolete. The respective registration agencies have specified new templates for the namespaces, the new namespace rules are forward-compatible with the older ones, the new templates reference the current standards which the old RFCs do not, etc. So I don't see what possible purpose, other than promotion of confusion, could be served by treating the old definitions of still current (or not-obsolete, if that is different). > And also mention that in the abstract :-) . See separate note. john From nobody Wed Aug 2 18:41:00 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3F8129B2A; Wed, 2 Aug 2017 18:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=Whmj7v9F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aIKMqZxG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS1YLs5w4j5O; Wed, 2 Aug 2017 18:40:56 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EF2131CE8; Wed, 2 Aug 2017 18:40:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9EB1920984; Wed, 2 Aug 2017 21:40:55 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Wed, 02 Aug 2017 21:40:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=IDC3C2pa7WNQaCW8ni muhxq46jAIjZiHw8VOCYf0hSY=; b=Whmj7v9Fy4hQyaK9Gq60u2zfiQ2OKYgbbs sv3t93CIFx6U5ZZMScDwVFliE/BrmpbOfpl37JTtkjE/XFhK0Ah57hYZ6Qn+trpL O7KdQKkC403ZeYI/gJ3o+6McR6fh0AnOB9XyOsViCtG0H8NpRSCCn9PIpXG1bEo6 Bj3+d5SMOw7uLBd+jBC3UOWBItAX7cemytivUHZkATo/CQw1xDjyWj8UMSe9WQii QI1ZKYpp2mCaLykGFpWwguI8QI8omj7GvJu8CViIX3lrH6YdCcmrZewTm0KXn+YS geNTV6tObk4I+x06qScwpukDtAEDqdBQjR3z5y+8w1m1sF/WCfZQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=IDC3C2pa7WNQaCW8nimuhxq46jAIjZiHw8VOCYf0hSY=; b=aIKMqZxG LCR3PDLF/q33VtVQ/k3BlaIJTst+UfjauZvMm55mG9nTsfNTCy4rRjaKgYyJ5Lcn 96WSNFXkKrpb9sqxPN//BTBLMi6Grvo9w7diMHgod0CkUx08bbnEq9MoPFDKwwVZ +ziI6hg5azs6XPHulnawb5TcwTWu6FHbfaFhaB19sv+p6KpliP9I+C2BmJqQE7KM 2gaJMlI4q9lTYjU8TX+Gpv71zeR8B77GyteazN6JCFb22ppeu+Kt8zrneDdaTlmC htrIabnZ+n89DyTDuJ9NIoXdeMGda1DhwIqBFzZZQe9sTE35HLdyIYE7Pd7K5H7d 4EoX6pRQLg1+8g== X-ME-Sender: X-Sasl-enc: 5G5dtI8FywKF0WVnvLOxNUg/AQLUlnbNJ+EAyGyMvNa6 1501724455 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 9082224515; Wed, 2 Aug 2017 21:40:54 -0400 (EDT) To: John C Klensin , Ben Campbell , The IESG References: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org From: Peter Saint-Andre Message-ID: <60d0c8a5-e20e-a5f1-0482-56183aed4a74@stpeter.im> Date: Wed, 2 Aug 2017 19:40:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 01:40:58 -0000 A small comment on one point... On 8/2/17 6:39 PM, John C Klensin wrote: > > > --On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell > wrote: >> And >> since IANA may have to deal with a mix of old and new >> templates for some transition period, it doesn't remove the >> need for them. > > Whoops! I either don't understand what you are saying above or > it indicates one or more series editorial or explanatory > problems in this I-D, RFC 8141, or both. For any given > namespace, there is only one template at any given time and IANA > has only one such template registered. There is no transition > in IANA's scope and no need (or opportunity) for IANA to deal > with an old template and a new one at the same time for any > given namespace. I assume that a template (again for a > particular namespace) could discuss transitions from an earlier > form, but that would be an intra-namespace issue, not anything > IANA needs to deal with or even be aware of. The sense in which > IANA needs to deal with both old and new templates is that there > are namespaces defined under RFC 2611 or 3406 for which new > templates have not yet been provides (and may never be), but > that isn't a transition topic that IANA has to manage either > (and the procedures for having some older registrations > conforming to the old template and mechanisms and some > conforming to the new ones was carefully sorted out with IANA as > part of RFC 8141, so, if there is an issue, it isn't with this > document. With my RFC 8141 co-author hat on, I concur. There is no transition period in general, and there is no transition period for any particular namespace because if the registration is updated (e.g., from version 1 to version 2) then the old registration is immediately outdated as soon as the new registration is placed in the registry by IANA. IMHO this is clearly spelled out in RFC 8141 (and RFC 3406 before that). Peter From nobody Wed Aug 2 19:15:07 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523B71321BE; Wed, 2 Aug 2017 19:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO1Mx2PHmO8t; Wed, 2 Aug 2017 19:14:50 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811A41321B9; Wed, 2 Aug 2017 19:14:50 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v732ElvF049535 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Aug 2017 21:14:47 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 2 Aug 2017 21:14:46 -0500 Cc: The IESG , urn@ietf.org, Barry Leiba , urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <232B7A5D-DF83-4979-9D51-D8AA0D442BE3@nostrum.com> References: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> To: John C Klensin X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 02:14:57 -0000 > On Aug 2, 2017, at 7:39 PM, John C Klensin wrote: >=20 >=20 >=20 > --On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell > wrote: >=20 >> ... >> Please refer to >> https://www.ietf.org/iesg/statement/discuss-criteria.html for >> more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found >> here: >> https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-tran >> sition/ >>=20 >>=20 >>=20 >> -------------------------------------------------------------- >> -------- COMMENT: >> -------------------------------------------------------------- >>=20 >> I have a different take on Adam's discuss point. I don't think >> its appropriate for this draft to both obsolete 3044 and 3187 >> and make them historical. This draft doesn't replace them. >=20 > First of all, you are absolutely right. This document doesn't > "obsolete" (note that a verb only in IETf-speak) either 3044 or > 3187. That doesn't mean that they are anything but obsolete, > but what gets them into that state is the combination of: >=20 > * Changes, by ISO, in the underlying standards for the > relevant identifiers. > =09 > * The language in RFC 8141 that makes the templates > normative for definition of URN namespaces rather than, > e.g., RFCs that describe those namespaces. > =09 > * The submission, by the namespace registrants/ managers > for ISSN and ISSN, of templates to IANA as specified by > RFC 8141 and the acceptance and recording by IANA of > those templates for those namespaces. >=20 > The reason for moving the existing namespace description and > registration document to Historic is to prevent confusion about > what constitutes the current spec. I (and I think the WG) > thought it would be less confusing to identify them as obsolete > and create the usual forward pointers to a document that > explained what was going on even if that document doesn't do any > "obsoleting". If the IESG believes that 3044 and 3187 should be > Historic but not obsolete, go for it. However, before doing so, > note that state would not make any entry in the RFC Index > pointing to an explanation, possibly leaving readers with the > impression that the URN namespaces for ISSN and ISBN had simply > be discontinued. Since I wrote that comment, I=E2=80=99ve found examples of other RFCs = that declared previous RFCs obsolete, without containing the = =E2=80=9Creplacement=E2=80=9D material. I personally find that = confusing, since I have always interpreted the =E2=80=9CObsoleted by=E2=80= =9D tag on an RFC to mean =E2=80=9Cdon=E2=80=99t read this, read = that.=E2=80=9D. But I guess it=E2=80=99s not insane for the =E2=80=9Cthat=E2= =80=9D in that sentence to redirect to somewhere else. In this case, I = was thinking =E2=80=9Cobsolete=E2=80=9D didn=E2=80=99t make sense due to = a misreading of the IANA considerations. (details below.) I even found an example that did that and also made the target RFC = historic. But I am still confused over what that means. (more below). >=20 > To me, there are two fundamental problems underlying this > discussion, both independent of my specific concerns with Adam's > DISCUSS and the associated logic, which I will address > separately. >=20 > The first is that it has become increasingly clear in the last > few years that, while the "Obsolete" and "Historic" categories > are adequate for many obvious cases, they are only vaguely > defined, with a number of problematic edge cases. Based on > exchanges on the IETF list that are not directly related to this > draft, the IESG is aware of those issues, but, at least as far > as I know, has not made a serious attempt (such as trying to > initiate a WG with appropriate focus) to get them resolved, > introduce additional categories or guidance, etc. I agree the categories are vague, so the best we can do is think in = terms of common usage. I tend to think of an =E2=80=9Cobsolete=E2=80=9D = RFC is one that people should not need to read, and that we might even = delete or replace with a tombstone if not for the fact we treat RFCs as = immutable. On the other hand, I think of =E2=80=9Chistorical=E2=80=9D to mean that = the RFC is no longer in use for its original purpose, but may be of = historical interest of instructive for other reasons. Making an RFC both at the same time confuses me, because those = definitions seem contradictory. I recognize other people may have = different definitions. So the bottom line is, you=E2=80=99ve convinced me =E2=80=9Cobsolete=E2=80= =9D is appropriate, but I=E2=80=99m now less convinced about = =E2=80=9Chistorical=E2=80=9D. > Given that > situation. getting into a situation in which advancement of > document is questioned because of some particular theory about > the definition of "Obsoletes" seems to me to be of questionable > appropriateness. YMMD, of course. >=20 You will note I did not ballot DISCUSS. Nothing in my comment blocks = advancement unless the authors and/or sponsoring AD decides it should. > Second, and in my opinion more important, the WG discussed and > understood the relationships involved here. It concluded that a > "transition" document of this type was appropriate to provide an > explanation of the relationship between namespaces created/ > registered under RFC 2141 and either 2611 or 3406 and those > created under what is now 8141. Making sure that there was no > ambiguity about the status of 3044 and 3187 (and, eventually, > 3188) and new, 8141-compatible templates was an important > objective, and the decision to identify the earlier documents as > obsolete and historic was part of that. =20 >=20 > Over the last few decades, when I've been asked how the IETF is > different from most traditional standards bodies, one of the > answers I give most often is that we usually figure out what the > right thing is to do to get the results we want and them do it > rather than getting wrapped around assorted procedural and > make-work axles. It seems to me that, in the absence of a > better set of categories and definitions, "the right thing for > the users and readers" is exactly what the WG was trying to do > here. If the IESG has a better approach to recommend, that is > fine with me. But, so far, it seems to me that your suggestions > (and Adam's) add work and would either make things more complex > or less clear. >=20 >> And >> since IANA may have to deal with a mix of old and new >> templates for some transition period, it doesn't remove the >> need for them. >=20 > Whoops! I either don't understand what you are saying above or > it indicates one or more series editorial or explanatory > problems in this I-D, RFC 8141, or both. For any given > namespace, there is only one template at any given time and IANA > has only one such template registered. There is no transition > in IANA's scope and no need (or opportunity) for IANA to deal > with an old template and a new one at the same time for any > given namespace. I assume that a template (again for a > particular namespace) could discuss transitions from an earlier > form, but that would be an intra-namespace issue, not anything > IANA needs to deal with or even be aware of. The sense in which > IANA needs to deal with both old and new templates is that there > are namespaces defined under RFC 2611 or 3406 for which new > templates have not yet been provides (and may never be), but > that isn't a transition topic that IANA has to manage either > (and the procedures for having some older registrations > conforming to the old template and mechanisms and some > conforming to the new ones was carefully sorted out with IANA as > part of RFC 8141, so, if there is an issue, it isn't with this > document. Apoligies, this was a misread if the IANA considerations on my part. I = incorrectly conflated the statements there that IANA would have both old = and new templates to mean old and new templates for the obsoleted RFCs. = On reflection, that=E2=80=99s clearly nonsensical, and I realized that = over dinner even before I got back online and saw your email :-) >=20 > RFC 3044 and 3187 because inconsistent with the underlying > standards when those standard were published. That doesn't make > them obsolete in the IETF sense, but it does make them a little > questionable as specs because it isn't completely clear whether > they consider the newer ISO specs normative or are still > dependent on specs ISO considers "replaced" and/or "withdrawn" > (categories that overlap with our "obsolete" and "historic" but > are definitely not the same as either). They became obsolete by > any reasonable criterion when IANA replaced information based on > them, and references to them, in the registry by information and > references associated with the new templates. However, as I > reminded Adam, an IANA registration cannot obsolete an RFCs, > some something was needed, preferably something that leaves > tracks. Hence those aspects of this document even if it pushes > the usual boundaries of our practices in the interest of clarity > and good sense. >=20 >> Instead, I think it would make more sense for this draft to >> just change their status to historical, but not obsolete them. >=20 > But they _are_ obsolete. The respective registration agencies > have specified new templates for the namespaces, the new > namespace rules are forward-compatible with the older ones, the > new templates reference the current standards which the old RFCs > do not, etc. So I don't see what possible purpose, other than > promotion of confusion, could be served by treating the old > definitions of still current (or not-obsolete, if that is > different). >=20 To summarize: I am convinced that they are obsolete. I have a mild = objection to also calling them historic, but I=E2=80=99m not going to = stand on that. Ben. >> And also mention that in the abstract :-) . >=20 > See separate note.=20 >=20 > john >=20 From nobody Wed Aug 2 19:15:47 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF4B1321B8; Wed, 2 Aug 2017 19:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eblF4KhNVQN8; Wed, 2 Aug 2017 19:15:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02581321B9; Wed, 2 Aug 2017 19:15:44 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v732ElvG049535 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 Aug 2017 21:15:44 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <60d0c8a5-e20e-a5f1-0482-56183aed4a74@stpeter.im> Date: Wed, 2 Aug 2017 21:15:43 -0500 Cc: John C Klensin , The IESG , urn@ietf.org, urnbis-chairs@ietf.org, Barry Leiba , draft-ietf-urnbis-ns-reg-transition@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1E2161F0-2460-4767-94CD-5BBF8C652A33@nostrum.com> References: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> <60d0c8a5-e20e-a5f1-0482-56183aed4a74@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 02:15:46 -0000 > On Aug 2, 2017, at 8:40 PM, Peter Saint-Andre = wrote: >=20 > A small comment on one point... >=20 > On 8/2/17 6:39 PM, John C Klensin wrote: >>=20 >>=20 >> --On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell >> wrote: >=20 > >=20 >>> And >>> since IANA may have to deal with a mix of old and new >>> templates for some transition period, it doesn't remove the >>> need for them. >>=20 >> Whoops! I either don't understand what you are saying above or >> it indicates one or more series editorial or explanatory >> problems in this I-D, RFC 8141, or both. For any given >> namespace, there is only one template at any given time and IANA >> has only one such template registered. There is no transition >> in IANA's scope and no need (or opportunity) for IANA to deal >> with an old template and a new one at the same time for any >> given namespace. I assume that a template (again for a >> particular namespace) could discuss transitions from an earlier >> form, but that would be an intra-namespace issue, not anything >> IANA needs to deal with or even be aware of. The sense in which >> IANA needs to deal with both old and new templates is that there >> are namespaces defined under RFC 2611 or 3406 for which new >> templates have not yet been provides (and may never be), but >> that isn't a transition topic that IANA has to manage either >> (and the procedures for having some older registrations >> conforming to the old template and mechanisms and some >> conforming to the new ones was carefully sorted out with IANA as >> part of RFC 8141, so, if there is an issue, it isn't with this >> document. >=20 > With my RFC 8141 co-author hat on, I concur. There is no transition > period in general, and there is no transition period for any = particular > namespace because if the registration is updated (e.g., from version 1 > to version 2) then the old registration is immediately outdated as = soon > as the new registration is placed in the registry by IANA. IMHO this = is > clearly spelled out in RFC 8141 (and RFC 3406 before that). >=20 Yes, that was a mistake on my part (see my response to John). In my = defense, I=E2=80=99ve reviewed a lot of documents over the past couple = of days and my brain was tired :-) Ben. From nobody Wed Aug 2 20:35:34 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90527132182; Wed, 2 Aug 2017 20:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUy0s7OAKBVx; Wed, 2 Aug 2017 20:35:30 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8107C131563; Wed, 2 Aug 2017 20:35:30 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1dd6v2-0004Im-NK; Wed, 02 Aug 2017 23:35:28 -0400 Date: Wed, 02 Aug 2017 23:35:21 -0400 From: John C Klensin To: Ben Campbell cc: The IESG , urn@ietf.org, Barry Leiba , urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org Message-ID: <3E58DE3AD4EC2D3D09FE8FA3@PSB> In-Reply-To: <232B7A5D-DF83-4979-9D51-D8AA0D442BE3@nostrum.com> References: <150171488920.5832.9826493259107180995.idtracker@ietfa.amsl.com> <232B7A5D-DF83-4979-9D51-D8AA0D442BE3@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Ben Campbell's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 03:35:34 -0000 Ben, (top post and I hope brief) Thanks. Glad we are back in synch on the "obsolete" part. I think (and, IIR, the WG thought) that historic would be appropriate because those documents are part of the history of URNs and those particular namespaces. If the IESG concludes differently, I'm unlikely to lose much sleep over it. I thought this had been discussed recently (in some form) on the IETF list, but one problem with treating "obsolete" as "don't read this" is that we've got documents floating around that are very much alive and active (IIR, even a few full standards) that contain normative references to material in "obsolete" documents that has not been copied into the successors of those documents. In some cases, that has occurred because the newer documents are not replacement-type updates of the same general protocol spec but are, instead, a new spec that makes the older one obsolete and irrelevant... except for the things that depend on the older one. This may be a problem of not enough granularity in the categories. Or, if the last WG that I remember trying to consider it was right, we need to junk the whole "obsoletes" (and probably "historic" and maybe "updates") business and start doing relationship summary documents and/or applicability statements that can describe what is going on rather than reducing things to a handful (or fewer) of categories. I have been thinking about those issues for rather a long time and would be happy to be part of an effort to sort them out if the IESG ever wants to do so, but hope we can deal with the general issue when the time is right rather than trying to construct policy around one, already somewhat unusual, document. best, john --On Wednesday, August 2, 2017 21:14 -0500 Ben Campbell wrote: > >> On Aug 2, 2017, at 7:39 PM, John C Klensin >> wrote: >> >> >> >> --On Wednesday, August 2, 2017 16:01 -0700 Ben Campbell >> wrote: >> >>> ... >>> Please refer to >>> https://www.ietf.org/iesg/statement/discuss-criteria.html for >>> more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found >>> here: >>> https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-tr >>> an sition/ >>> >>> >>> >>> ------------------------------------------------------------ >>> -- -------- COMMENT: >>> ------------------------------------------------------------ >>> -- >>> >>> I have a different take on Adam's discuss point. I don't >>> think its appropriate for this draft to both obsolete 3044 >>> and 3187 and make them historical. This draft doesn't >>> replace them. >> >> First of all, you are absolutely right. This document doesn't >> "obsolete" (note that a verb only in IETf-speak) either 3044 >> or 3187. That doesn't mean that they are anything but >> obsolete, but what gets them into that state is the >> combination of: >> >> * Changes, by ISO, in the underlying standards for the >> relevant identifiers. >> >> * The language in RFC 8141 that makes the templates >> normative for definition of URN namespaces rather than, >> e.g., RFCs that describe those namespaces. >> >> * The submission, by the namespace registrants/ managers >> for ISSN and ISSN, of templates to IANA as specified by >> RFC 8141 and the acceptance and recording by IANA of >> those templates for those namespaces. >> >> The reason for moving the existing namespace description and >> registration document to Historic is to prevent confusion >> about what constitutes the current spec. I (and I think the >> WG) thought it would be less confusing to identify them as >> obsolete and create the usual forward pointers to a document >> that explained what was going on even if that document >> doesn't do any "obsoleting". If the IESG believes that 3044 >> and 3187 should be Historic but not obsolete, go for it. >> However, before doing so, note that state would not make any >> entry in the RFC Index pointing to an explanation, possibly >> leaving readers with the impression that the URN namespaces >> for ISSN and ISBN had simply be discontinued. > > Since I wrote that comment, I've found examples of other > RFCs that declared previous RFCs obsolete, without containing > the "replacement" material. I personally find that > confusing, since I have always interpreted the "Obsoleted > by" tag on an RFC to mean "don't read this, read > that.". But I guess it's not insane for the "that" in > that sentence to redirect to somewhere else. In this case, I > was thinking "obsolete" didn't make sense due to a > misreading of the IANA considerations. (details below.) > > I even found an example that did that and also made the target > RFC historic. But I am still confused over what that means. > (more below). > > >> >> To me, there are two fundamental problems underlying this >> discussion, both independent of my specific concerns with >> Adam's DISCUSS and the associated logic, which I will address >> separately. >> >> The first is that it has become increasingly clear in the last >> few years that, while the "Obsolete" and "Historic" categories >> are adequate for many obvious cases, they are only vaguely >> defined, with a number of problematic edge cases. Based on >> exchanges on the IETF list that are not directly related to >> this draft, the IESG is aware of those issues, but, at least >> as far as I know, has not made a serious attempt (such as >> trying to initiate a WG with appropriate focus) to get them >> resolved, introduce additional categories or guidance, etc. > > I agree the categories are vague, so the best we can do is > think in terms of common usage. I tend to think of an > "obsolete" RFC is one that people should not need to read, > and that we might even delete or replace with a tombstone if > not for the fact we treat RFCs as immutable. > > On the other hand, I think of "historical" to mean that > the RFC is no longer in use for its original purpose, but may > be of historical interest of instructive for other reasons. > > Making an RFC both at the same time confuses me, because those > definitions seem contradictory. I recognize other people may > have different definitions. > > So the bottom line is, you've convinced me "obsolete" is > appropriate, but I'm now less convinced about > "historical". > > >> Given that >> situation. getting into a situation in which advancement of >> document is questioned because of some particular theory about >> the definition of "Obsoletes" seems to me to be of >> questionable appropriateness. YMMD, of course. >> > > You will note I did not ballot DISCUSS. Nothing in my comment > blocks advancement unless the authors and/or sponsoring AD > decides it should. > > > >> Second, and in my opinion more important, the WG discussed and >> understood the relationships involved here. It concluded >> that a "transition" document of this type was appropriate to >> provide an explanation of the relationship between namespaces >> created/ registered under RFC 2141 and either 2611 or 3406 >> and those created under what is now 8141. Making sure that >> there was no ambiguity about the status of 3044 and 3187 >> (and, eventually, 3188) and new, 8141-compatible templates >> was an important objective, and the decision to identify the >> earlier documents as obsolete and historic was part of that. >> >> Over the last few decades, when I've been asked how the IETF >> is different from most traditional standards bodies, one of >> the answers I give most often is that we usually figure out >> what the right thing is to do to get the results we want and >> them do it rather than getting wrapped around assorted >> procedural and make-work axles. It seems to me that, in the >> absence of a better set of categories and definitions, "the >> right thing for the users and readers" is exactly what the WG >> was trying to do here. If the IESG has a better approach to >> recommend, that is fine with me. But, so far, it seems to me >> that your suggestions (and Adam's) add work and would either >> make things more complex or less clear. >> >>> And >>> since IANA may have to deal with a mix of old and new >>> templates for some transition period, it doesn't remove the >>> need for them. >> >> Whoops! I either don't understand what you are saying above >> or it indicates one or more series editorial or explanatory >> problems in this I-D, RFC 8141, or both. For any given >> namespace, there is only one template at any given time and >> IANA has only one such template registered. There is no >> transition in IANA's scope and no need (or opportunity) for >> IANA to deal with an old template and a new one at the same >> time for any given namespace. I assume that a template >> (again for a particular namespace) could discuss transitions >> from an earlier form, but that would be an intra-namespace >> issue, not anything IANA needs to deal with or even be aware >> of. The sense in which IANA needs to deal with both old and >> new templates is that there are namespaces defined under RFC >> 2611 or 3406 for which new templates have not yet been >> provides (and may never be), but that isn't a transition >> topic that IANA has to manage either (and the procedures for >> having some older registrations conforming to the old >> template and mechanisms and some conforming to the new ones >> was carefully sorted out with IANA as part of RFC 8141, so, >> if there is an issue, it isn't with this document. > > Apoligies, this was a misread if the IANA considerations on my > part. I incorrectly conflated the statements there that IANA > would have both old and new templates to mean old and new > templates for the obsoleted RFCs. On reflection, that's > clearly nonsensical, and I realized that over dinner even > before I got back online and saw your email :-) > >> >> RFC 3044 and 3187 because inconsistent with the underlying >> standards when those standard were published. That doesn't >> make them obsolete in the IETF sense, but it does make them a >> little questionable as specs because it isn't completely >> clear whether they consider the newer ISO specs normative or >> are still dependent on specs ISO considers "replaced" and/or >> "withdrawn" (categories that overlap with our "obsolete" and >> "historic" but are definitely not the same as either). They >> became obsolete by any reasonable criterion when IANA >> replaced information based on them, and references to them, >> in the registry by information and references associated with >> the new templates. However, as I reminded Adam, an IANA >> registration cannot obsolete an RFCs, some something was >> needed, preferably something that leaves tracks. Hence those >> aspects of this document even if it pushes the usual >> boundaries of our practices in the interest of clarity and >> good sense. >> >>> Instead, I think it would make more sense for this draft to >>> just change their status to historical, but not obsolete >>> them. >> >> But they _are_ obsolete. The respective registration agencies >> have specified new templates for the namespaces, the new >> namespace rules are forward-compatible with the older ones, >> the new templates reference the current standards which the >> old RFCs do not, etc. So I don't see what possible purpose, >> other than promotion of confusion, could be served by >> treating the old definitions of still current (or >> not-obsolete, if that is different). >> > > To summarize: I am convinced that they are obsolete. I have a > mild objection to also calling them historic, but I'm not > going to stand on that. > > Ben. > > >>> And also mention that in the abstract :-) . >> >> See separate note. >> >> john >> > From nobody Thu Aug 3 05:49:41 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0C131EB1; Thu, 3 Aug 2017 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByRf7-i4eSGH; Thu, 3 Aug 2017 05:49:30 -0700 (PDT) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C3D12EC13; Thu, 3 Aug 2017 05:49:29 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ddFZ9-0005Kn-CL; Thu, 03 Aug 2017 08:49:27 -0400 Date: Thu, 03 Aug 2017 08:49:19 -0400 From: John C Klensin To: Adam Roach , The IESG cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org Message-ID: In-Reply-To: References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 12:49:40 -0000 --On Wednesday, August 2, 2017 13:18 -0500 Adam Roach wrote: > On 8/2/17 10:04, John C Klensin wrote: >> If "preferably" >> is turning in "mandatory", we need to have two discussions, >> one about the authority boundary between the IESG and the RFC >> Editor and the other about where in RFC 2026 and its updates >> the IESG is given authority to make policy by issuing >> statements rather than determining and reflecting IETF >> community consensus. >=20 >=20 > Thanks for sending me down the path of determining authority > here, as it has made me realize that I was confused about the > basis for insisting that Obsoleted documents be explicitly > listed in the Abstract. >=20 > It turns out that the 2011 IESG statement of "preferably" is a > weak restating of a 2008 IETF-consensus decision to approve > version 1.9 of the "ID-Checklist" document, which clearly > states that the Abstract of a document needs to list obsoleted > and/or updated documents (cf. > ; = =C2=A73, > 1.D, first bullet: "if your document obsoletes or updates a > previous RFC, then... say so in the abstract"). >=20 > And so I am forced to concede that my "No Objection" was made > in error. Since the form of this document actively goes > against IETF community consensus regarding the form of > IETF-stream RFCs, I realize that this should have been a > "Discuss." I will be adjusting my ballot accordingly. Thank > you again for pointing me in the correct direction, and I > apologize for the error. >... Adam, Silly me. I was about to propose a compromise in this area -- one that I hoped would allow the document to move forward, for me to be able to get back to RFC 3188bis and for you and the IESG to get back to more important work -- and either didn't do it soon enough or should have just kept my mouth shut and sorted this out with the RFC Editor. I was sufficiently appalled by your decision that I needed to take overnight to raise my confidence that I was not overreacting. Sadly, I don't think I was overreacting. Consequently, unless this DISCUSS can be resolved in some other way today, I will submit a formal appeal against your use of a blocking DISCUSS on an essentially editorial matter that puts form over substance and that is abusive of working group decisions and the Last Call and IESG review processes. =20 In addition to the narrow issues in this particular case, the appeal is likely to raise the following issues: (1) The need to clarify the boundary between the IESG's authority, reflecting community consensus, over matters of content for documents in the IETF Stream and the RFC Editor's authority over editorial matters. General guidance and statements of preference notwithstanding, I believe that existing documents and long-standing tradition make rules about the editorial (as distinct from substantive) content and structure the exclusive province of the RFC Editor, with the only important exception being the provision for the IESG to demand "as is" publication of IETF Stream documents. The requirement is=20 (2) The pattern of migration of "guidance" or "recommendations" into firm requirements ("rules") on which a blocking DISCUSS can be based and publication of such requirements only in IESG statements rather than archival documents of record. I note that Section 5 of RFC 3710 (the IESG Charter) makes a distinction between "problems and how to avoid them" and "commonly used guidelines" on the one hand and "rules" on the other. While that document says that the latter are "commonly published as BCP RFCs", I suggest that substituting poorly-indexed and non-archival "statements" or "checklists" for such RFCs sets a trap for the inexperienced or unwary and is hence inconsistent with a predictable and fair process. (3) Imposition of specific blocking rules involving the use or applicability of terms such as "obsolete[s]" and "historic" is inappropriate when it is generally recognized in the community that those terms are insufficiently defined and inconsistently applied. The way to solve those problems of definition and application involves a proposal for what should be done, community discussion and consensus, and RFC publication, not dropping a DISCUSS on a single document that was either arbitrarily chosen or that was singled out because one of the author-editors chose to push back on an editorial "preference". The observation that the IESG has not seen fit to initiate a community-based effort (such as a WG) to clarify those definitions makes a DISCUSS based on the use of those terms particularly questionable. (4) There are some specific issues with the checklist statement you cite that make it subject to different interpretations and highlight the issues identified in (2) above. For example: (4.1) As noted in erratum 5076, a statement similar to "this document obsoletes RFC 4687" is a citation whether an anchor appears there or not, yet C(1)(B) of the checklist prohibits citations. =20 (4.2) C(1)(C) references "section 4.5 in https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.tx= t" in a context that can only be interpreted as normative, yet that link is dead (leads to a 404 error) and the document to which it referred became obsolete (sic) when RFC 7322 was published if not earlier. To save you the time of checking, Section 4.5 of RFC 7322 is not about abstracts. (4.3) C(1)(D), which you have cited in support of the presumed requirement, says "if your document obsoletes or updates a previous RFC, then: say so in the abstract". However, "say so" appears to be general guidance, not a requirement for specific language. The abstract in draft-ietf-urnbis-ns-reg-transition-08 includes "This document clarifies the status of relevant older RFCs...", which I contend is consistent with the checklist "say so" statement. Had you requested that statement be expanded to say "...document clarifies the status of relevant older RFCs and formally makes two of them historic...", I would have made a bad face but, unless my co-author, the WG Chairs, or the WG disagreed, I would have made the change and we would not be having this discussion. If the IESG (or even a single AD) is going to treat a particular document as a set of requirements that justifies a blocking DISCUSS, then it is obligated to maintain them so that statements are clear and normative references are usable. Failure to do so makes application of the documents or statements in that way fundamentally unfair. (5) Even if none of the considerations outlined above applied, it would be inappropriate to use a blocking DISCUSS because the guidance in a particular document violates a "rule" or "checklist item" when that guidance has existed for a long time and has never been enforced consistently. regards, john From nobody Sat Aug 5 01:29:27 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D146127B60; Sat, 5 Aug 2017 01:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMaT0gGY8TjS; Sat, 5 Aug 2017 01:29:18 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0134.outbound.protection.outlook.com [104.47.93.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9182E12708C; Sat, 5 Aug 2017 01:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J7FJzWiMGLKVyL4Amyr1NQAE/aRz33VN09ElJC0RS6U=; b=IkyC7xRpAD5HV7fTFWS2P4QbY+foJ2N0T2/93O5S5yoOlrIPBlsNjfz6UKiNcCyuz9WJGdvmNNJ8CpEK5RIPsSp6R3T1GcIswxH8DOSaWIWpM57l0KEUJSqx4mbZvJRiAZrAbsu2/wzypSWAY0Sw3xgj2bD+xC+y5zFeAww7U2I= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [10.71.6.3] (185.25.95.132) by OS2PR01MB0251.jpnprd01.prod.outlook.com (10.161.78.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1282.10; Sat, 5 Aug 2017 08:29:09 +0000 To: John C Klensin , Adam Roach , The IESG Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Fri, 4 Aug 2017 17:36:05 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [185.25.95.132] X-ClientProxiedBy: VI1PR0701CA0067.eurprd07.prod.outlook.com (10.168.131.157) To OS2PR01MB0251.jpnprd01.prod.outlook.com (10.161.78.18) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0c8496aa-4b6e-47e5-8f54-08d4dbdc0dff X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(2017082002075)(300000503095)(300135400095)(201703131423075)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:OS2PR01MB0251; X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 3:LbaqNGtQ/NusCB5Y0wn5ifw8CmMXctNMDnS2shHZwyQ7KALdq4HPieVxKMHue3lWg07edhVtw0SmFoaTKcRMZ+uVg/Of0X3PXhY9IFdFPFsiVgEp4yL3xIMFh/7GGUIDwD02jS41p/56pIxyM5A/i6XHLCz5p/PdRa4iLU2NlxrfPK/IGXAHQ7mdWqOH9M4hdVrhXg5dkcVaaPwhmRm588H5+lNjmZ/9P3cwhQIwtOv5qUb9814ZsxI6EPQk+RhFdJYRl1/jHDlpj5mgbYZsEGdStpJWO0dQhNsmE7s1ALbrxDNuK4lA79PvRFK6SmcDfUcvPmirR2YbHxTTsL00y7T8qVkc5qTtboS8W5Mk9L2qgQsE0//Fgus/ZNjJZ1LLAQ5ynzseumqYENHG5ZS286NZfBXRasRW4uZry6G8suFMMDdYiQA4UqmEOJm9BTiwFxOSOH/xQnWthVnAX6FNJfyZjLfgsAUI0L4KLMz2geeoz6IF5hnYBsVr+4RlC24pDoJMVS8giChB0jiS0VK0KyJH96k296sK3BJb0FHeej/zv17Hv6VdcUWaDmTm0Er3GiCRkPUBX/zQkR1zmCrnUmrBu0/VcYYEDpvVfk5LoADvR3ZTIWLOqknxVdf0heuIcGI+E0HTMGMamttZGCyhsLTgW1iVRVdUaxmcNRycYOi1iXjyukmXxuLsSctpeDuR2b7zBz4BZ0kc7ZzCYLGv5+6UG4FK8w+pf8ElfE8HMeV5tNyBrcRH3ECbUSfO5pPuPY9qFx47rgH9SzpikzvH5Z3JRPihQTSoUp9ntxqYe9o= X-MS-TrafficTypeDiagnostic: OS2PR01MB0251: X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 25:NO8iOjSUwF1ELk40H/tutQklFVsxBUIrawu7+z62x9MPTREzthh5PCl6xIgkvnHHtLuH7heLO7DZELVtEkVyoGio6z5zDLBw37NcVT+oUuIVof1czgz2mHlK9m/J3bBzyrpxTOsQfpOLKi+ypdGRLbAwJa+nBBYlEsUIy3L7DY6XVAnvvyJ/OO4JH61oryOWRx7MHYDinMYCFwpU+mgpJmMOZKLi+ajIRWYAfuGpg5eKnhcFcW1a15fSwhvO2gVpqRGxKQNcGPoa0zi3ZOUKeRwIfVWV1PEDGkvtaHTwKOEnzwHNQPQYAak2umLaLW5/Rlgqk7WMEb5XGo8hd1hI9nd9TUFMC+CVg5gXmoUPRAaTB50+X4igeEl+k7Cy2SY02gyM3UdxxLQN1zYT9Dk8/hKRXtPHR/sZ7kMaL30vzSeVWvW8o514igRPX/ZHYnlGl8gCiPz1iwmZYFu/foQXLiL4SFoUuv0oQYe/JNS8CTn8DiMEI+DNqmWC+R4Dd81/xBs55sgxkTWFuwBmNsGRlTDRyIxWBLv39UcsDw4699scjpyEtMwSUEkYsuqq4w9a5eNBVXo643PvxIIoQqG2ah5++V0qsbC2uBPI8BNzz8IkxXZHyOTiilELo6GJ8rusLJ+pF32qLlJolL94eS8whzuemQNxl6U0pybdWv+yq9o+pBbe9Colou/VudT3t1KSXwgo6IKX2B7se6QdZ507k1uVG9NQVblOKDcvYAQA0Stx9zyqrATuNxei4q02ZKm5H9xdouZs7ltoVlXycswICfEO3y67dMDZAadlgVXi1GP53vlhyqMTD0zUhacm1ZFZ9N5enflr8RlWJ/uXTp0u4RWQPpl5CqZJZo5JPj7O1NafUtoNurZPvCbWGvtQAZzPaklatyeBgHyWCHwMf0A33o80QF9X4sd74LCynYgsFhc= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 31:spjmRb2XhCdm3hTsiNbUaeqnVMQOcyHD2VnSWumTuSmNmqPtFhHlEx7SeWNpxSFHhGvIpBSAlXPmZjngD8HbZagLmbeV5Y9JFcLAiR2XYF6+f65rLTSHEaxHL9YP539+YSlDBvl2p75UYLLlhFZCNvmumaDtL2jV7lQhv/qEZh3D6+l9jphlGZWmuy22S6cw2PNW353alzXd4tPsRLr13L8lxmxxVA6iXdsJtIc3XYdxrk5e8mhYaLlmI+3ZZNmwQUDx3yCgkOPUl+Mxw08eGFFd/9RhvlcdNnaGgQMUWA/b7dPDmDK838Yfqs2fzNdZ4+wudFHzTLtvkNOdPjyxC36bFSF05Lt3zGfO0/BiDebTbrZtFgUwv/JbDZY0aIftkWUdmU5APXRQpTgZqfVspnaVLhkqYzSQmgFDlwU8++PraCktxmJG4RmJcmcgKcoWyB8HwU3QT27fBoikEL/IKi/hJZ0/guliDJqwpV62R7gaZVeJ+9BSmR8nC/Wzr5eNh3SwF0VX7bb3Vl3E7F9nYScNBY2TrWriw1tGZ4SYzL/gdfEr8qdkvYN3/0hSoLyfav8Knvz4hhyge6C3JuxMrCS6Lzo/FNGenji6ZfSMTkg8X86MJvBGjysK93Afl5naUrwyBeT+UbRkNZFjHexxBcCC8L2fMoaml/FEQaoPpXQke0pI5/vqJx3asYJx7lEbBZDhgRs+y1e2qnFiuraqCQ== X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(2016111802025)(20161123555025)(20161123558100)(20161123560025)(20161123564025)(6072148)(6043046)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:OS2PR01MB0251; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:OS2PR01MB0251; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMjUxOzQ6MTJTU2NNTFUvaFJZRUZ2RUlmc0hwb2dqcXFa?= =?utf-8?B?eTl1N3VwK0t1YTNSNlhEeUh5WWF1MnN1VnlwTkZrUWFnYmQ3UHE1T0tsZ3RT?= =?utf-8?B?c2MxeUJHaHl4UHZiMG9WY0lBLzN3aWtxOTd6Yll4bHVmeXg4QmVuc1haVG5Z?= =?utf-8?B?MmtkUEhjSWlDeUpDSVlzMkhLUGlNRUxoVnlPN3RwbGUzQmcvN3BDalRKNzRy?= =?utf-8?B?R0I3Q2JCWjVrR21jYnMxWVBQcGxNQjl6R2swdmh4S3hiNGhYOHNLNllqSWhH?= =?utf-8?B?UWpXNDhvVEZaSk5GQUZzb2pML1JkYURZMEk0TnRCTGp4QWNsTGxHL3FoV1NK?= =?utf-8?B?a3NvaW5ibnpSUlIxanRySG1tN3JZcHdnZjRmaVlLY0Z4a2xzQ0hLNE1sQ1hG?= =?utf-8?B?OWQzekNKalV5eVZTcVdjWEFWMzJCc0Z3dmlPVUZTRC9CUFowd243MHpDa3E0?= =?utf-8?B?Q2FtaERMRXhHdUVtdTNVYmptRE9RR3d2bW9jVXdPRWtiRzRDN1Zsc1dOYVNN?= =?utf-8?B?SHlqbDlldDNqbHJ3Q3BNcWc1MVNVTkJZdGMweEd6M0NaSlZnWUpoa1A0MlY3?= =?utf-8?B?VHB4Q2xXUU42TnFSTHdUdDV6eHptVGJWK08yNkQvbmc4K3VXZGZaK3QxaXQ5?= =?utf-8?B?enJ2NjJWQ3hRd2hpeUliZ2trWWtlb0hUYjk5Smthb2xORVcyWm1mM3cxNnJP?= =?utf-8?B?enREZDZkKzJiUXZHNXlWRVp2VnBSSnhWaUJ4d3NWZ1FMaHRQY0JOTW81V0d4?= =?utf-8?B?OEhIZnR6S0JQbGF5Q2ZKWTdvRkdyK1NzbG15SGtieFlpSmFwVVNQQUFYQXI0?= =?utf-8?B?bHNTOGR3M0lPWml6cVk1UUVSWVpIZUtDc3JsQ3puYTFxU3ZDYU12OERnK29a?= =?utf-8?B?ZDZrc05WTWF3VTF1bGpNVUtDdHYxL09LV0IrVkhqbnJvT1BSSTczQnpERjNr?= =?utf-8?B?bktLRElpb2hkOHRmeFQ2ZkpWNzd6aEtiQm5YeFB3QUw3V042ejFzSkVFeWNk?= =?utf-8?B?YjFUd04reUpKNm52NFFXN0ptZWJCSCtVeC9xQkZJTXVnZWlodElicUZYYyt2?= =?utf-8?B?Skp3Ni96UTdLTkN4TXpEZTducGo4aFJMd1owUSs3b1lUMXB2dWRoV3A0V3gz?= =?utf-8?B?N3Y3NXZzVjhidHA4Q1VqclVJdmlvMHl6dFhmdFFoZkZyQXNwRnZSZk9LcDQw?= =?utf-8?B?a3hFZW5VMzJKNkd0ZkhMQkQvWFZzNmsyblUyOUNTOUw4MktFVmZXT2I4SmZB?= =?utf-8?B?bmhKM09QNWtsUnNKVUZkaGlUNFJWTWZrL1dzQTNoSmFTTjdORnFrMTF3L0xR?= =?utf-8?B?NlhxdkNscTFyQXJrRUFOMVBXYzRjVlRJTjg5bTFMQ2ExZ1hHbUhmSjJ2MVdz?= =?utf-8?B?dnFKYkZNK0J3ckJLZTZvelZoMlJLZGMxdDNBUFQ2aXdoYndRSitXWGw2WUlW?= =?utf-8?B?dnBHQ3I2NDlwYUZOZ1lIdUxCdWlVZ2tBeUhSNzZhUTFpaHQ0MmROV2dEc3ZC?= =?utf-8?B?bkgwdlhHZ0ZYWVV0cjlMS1J1dlJyT3l4T2htdGZRbFEzZUV4Nlhtb3lORTBs?= =?utf-8?B?TjBYTlZ0b3ZweXE5QmpiNlUyYndoMGZIVUFJd0laQWNEMit3YytHT2lSR1pQ?= =?utf-8?B?U21mNmdKSVlIOEZqMkZRTkttYTJlQzVCLzVxeTM4VElaa0QxRG5PT3IzQmhm?= =?utf-8?Q?0OqxAZtGiLZ1m9wiuYMxnj4HBfjO5giWfgBxS9?= X-Forefront-PRVS: 0390DB4BDA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6049001)(6009001)(39840400002)(39410400002)(39400400002)(39450400003)(72854002)(199003)(51444003)(24454002)(377424004)(189002)(229853002)(97736004)(6666003)(478600001)(6486002)(4001350100001)(4326008)(2950100002)(42186005)(105586002)(50986999)(65806001)(65956001)(31686004)(66066001)(25786009)(76176999)(42882006)(93886004)(77096006)(106356001)(54356999)(33646002)(90366009)(47776003)(101416001)(561944003)(23676002)(189998001)(7350300001)(3846002)(6116002)(83506001)(65826007)(64126003)(5660300001)(53546010)(38730400002)(53936002)(6306002)(74482002)(7736002)(50466002)(81166006)(68736007)(2870700001)(6246003)(305945005)(31696002)(2906002)(966005)(8676002)(230783001)(86362001)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:OS2PR01MB0251; H:[10.71.6.3]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMjUxOzIzOmovUlR5cFE2YXdIeWd0dFRNODFsOXc3aWYz?= =?utf-8?B?M2xKN1czVlNFc3ZiS2FzVlVRYXE0dVBwaDJOTnNHMHNKWnVvYlpoMUdZMkd0?= =?utf-8?B?Y2x1OFJVcDA4WTlGck1zMDVFN2tzK3BJQ3JPRnlTbVdVNDBZamxBMm5HMStF?= =?utf-8?B?ZWdoa0Z3WXlzOVpoLzg4K0dxeklaclRIdWc2ekJUQWdxMVVnaHZ3ZTd4VVZO?= =?utf-8?B?RWJUNktCNzR3bW5YTWRScThFSVRCQkwyaGR0c3ZMcDZoa2V6YlV0bFJpRXBm?= =?utf-8?B?OTgxOVZ3WDNnMldsbFBSMGFxTUZRcXlFRUZoOE92NC93alpoN08rdlRtTVR0?= =?utf-8?B?bjVYYmtIVisrY2JlaUZCRkw4a05Qd0F6REtzbnZTem9BdXdZc2dXaC9UdVhZ?= =?utf-8?B?VGZqM3VXM1lTcGwyMkl0VmpCcExweGxLOW1jV0JpR2t4OHdzbXliRTltM1c2?= =?utf-8?B?ZjZvd3hUa1FxRkJOeDNPekFxTC80YTlnSGs0dm1IUjd2ZTIvb0k3cFRuNDBO?= =?utf-8?B?c0dVR3ZRak00ZzIzZ1hZdzB1MXpJNndJbTlHNDRxNXhXQmRqRk8rMjdON05N?= =?utf-8?B?TnNHbXJ5UnMzcmFwSy9RcnhmRlptMnVac3luVGdjVjIvd2RVakgrcDVFN01O?= =?utf-8?B?bkZPNjBobHMxNmEyeHdjTWFXa0lJUG9sTGxVZU9IMXpxbDRLYVZtbnByTndC?= =?utf-8?B?UEZUMGx4VEh1UlhuMUVwNllVc0I5eU5sN3VhdGFqcFRabUYwTFQyZnd3Q2RD?= =?utf-8?B?YTduTnd1OENHRnFacFFlWXpYb1JGN1VDVm1Xa09iRTBvTk1rWmxnQ1gyUG9R?= =?utf-8?B?ejhDUGwvM2tUVEpkVWMreWhUblJqanNSYkhrcXIwb1hNUkdEMXhtcXBiamY5?= =?utf-8?B?SDF1ZVNzdUJOVE0rL2F4K2VXcmdTU09ZeU5QdGJWSitUWTVzUys3VFQ1bmdV?= =?utf-8?B?T0h6RGxWSnpKM201cFBCaFdwN01aVHZqSGgvZzU2N0V1b2JvSjZNVXo2UklF?= =?utf-8?B?d2I4QURTSXI1Y0dmaWErS2RXUWs1SDN0Yk1FZTVnS0MwWHdyK1F1bDN6eGtM?= =?utf-8?B?bEZkMDlLY1BVWGpCR0hQNm5KNDczbk9Vcmp0U3pEaHVqcUJSNFRXVGlER1Nm?= =?utf-8?B?WCtlRmlNMnNIVzFsUnRTcnVRaUNVTHhRRTRaR1dvVjVmTDBnajJPQjFXeTZI?= =?utf-8?B?bUdHNHBDWkhWcFQzUDRxUjJ3c3dKZHVvUFNVZU5xL2VyM2tRYnU4ZnMrZS9p?= =?utf-8?B?SG0zK3JTSTRLbFZMT3pidHllYjZzejNxZ3RlNFhMRXN1YWdIYTlHcDVBYVZN?= =?utf-8?B?eTFSc01qZ0t0UHhNcTZnL3JGSVNFQ0NWb3huY0pRTG9nN3pseWR2ZyticWFY?= =?utf-8?B?SytpQ1FENFZWMklsdGVyZ2NuYW5MQVBwZlRyWExDMG1iUkNKY3NSWjNHdktS?= =?utf-8?B?ZVJKWXVNcmJLTGN6UFR0aGZpNWptMkJXSWg3QkgxT3VrWEVSWlpmY1NYd2w3?= =?utf-8?B?c0lxdU5BTjdPaXNTTmowbEd5SFhqc0c1bExqVEhXNFRCdmYrMXZycWR1K0t3?= =?utf-8?B?V0Z3Z3o0RzRGTWRxM3dxWmxwL2ZpUU9iTG5pay9ReHpNVHdMTVRMekZTWnlV?= =?utf-8?B?anp2cll0eHQwMVFDVnVPcUNyaUFieTJPeUMvVUlEUSswMDBIb3FXSHdNY2dR?= =?utf-8?B?M3QxZDNrbXpzRmc2Rm9VN3FVRTJrc3o5Sm05Q3dhaWRvelI1N3dnTnB6STVq?= =?utf-8?B?RGdURENVZSsxZDJlVUpjYWhjR2V5UEMvdnpjQU9iQStIMy8zdlJ6aElxVnlK?= =?utf-8?B?MHRvdXdseFVwR1d5MjZqQ1ZWUXg2Njl3Sm1KNWxXY25IRjBTa2N6QTAydGpv?= =?utf-8?B?WkxrVkM1QkhKYkViV0tpRlJ2YVFreG52ZjlzYkEyMDZEejBmSGlxSVNGTHRY?= =?utf-8?B?OEhYY2hIcCtwenRRK3FHVXYwVHg1ei84RFVyVkp0ZjBJM0oxeTdmMjN4R0pP?= =?utf-8?B?M1l4SWwvUW1RcnNuRnFqRCtRTFFnSmdlSGMvMUJlQ1J2ZEprN1dWWWc4L2FR?= =?utf-8?B?NWlvM3UrUjhCUm1uRjh3aHg4TzAwdllHR2k4NkswTDBGYi84UW5lSHBZVmdj?= =?utf-8?B?dUM3aXhyWURWYzBBaGUyU0pHdi9pcGZQb1ZWUUhZMVJ3akJkU0cvcWVYdyt5?= =?utf-8?B?dlhHT0tiYS9pZGd5VmpKNUFLTmhIdVB3Z1E1ekZLdzUzRlNWR2xQZTVSUUds?= =?utf-8?Q?j3n9o7aqRblj7r4DLb?= X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtPUzJQUjAxTUIwMjUxOzY6enhPS0hiMU5UVlVMUm10ajlKbmF2d1VaT1k0?= =?utf-8?B?MUR1VHU1OVhkdjdXZUI2aWlFWEd6bTJlVFlHQjQwKzZaZDh5Zmg0YXJaOERB?= =?utf-8?B?akdncDcvNHRsTmxFYUF2SmNDK3lzVm5ycGVpcVJTc2poR0xOWVE5eElmNFQx?= =?utf-8?B?Yng1T1Y0S2htb1NZNmV4VFNNSnFNYzJwL2s4aXlaSHppUFZzQVJnRFlCR0xT?= =?utf-8?B?Mmp1UzJDcW00RjkxU3ZuMFBYcmY3ZWI0NmF1cGVjWHE2NUFyQVU3Sm00aFNK?= =?utf-8?B?aDB3RnY3bmhBSnkzZkRMYUQ0V0RNTmZTbWxJOUhXMExuMFhERktQZHZ4dm9a?= =?utf-8?B?VTJVd1VtQW1kWGxBZys4YmlhT00yWmd4Rk5DWFhFYzg2dW5UdTk1elloNUIv?= =?utf-8?B?cVNWeGM1YlYvazFXdlA0dmc4cDJIYTNlejVkN2N4dklXbksxSGRPMzNXUGZk?= =?utf-8?B?WmZrWEhHQk9pMkhxYTdqc0k1SVo4ZzkzdGdzYnZMVDNoZWZycGtuZHdRRmxT?= =?utf-8?B?Y28xSlp2cVBOaXVVbXhYTVVtNjdQMW8wMGFQSHVDK1doL0Z0VUJxUm9zQjFZ?= =?utf-8?B?OTUwcnVOVGJKZ1lEM2UzWmxSRGluRUpzR0NKekROVGQ1MHBxOG90RW01ZTB3?= =?utf-8?B?R1RzaWplMkpYN1Q2YWZNYWl5QTVxM3RHZFBJZW8ybUZMZWtXOGtjMUkzZDV2?= =?utf-8?B?blpWR3BnSzVPNlhuUjkyMnFCN2QwYWNTbCtQN3p1QnhidW92NndOTEVtb1Zr?= =?utf-8?B?OEpMTW1hQjR5SkprNXcvMjNxS0FwdU5nOU9EM1dQSnorZitOdFhpa01uYmhI?= =?utf-8?B?TTZNWEg5eDRqZi9BTWQ1MllCZlJRd1AyL00zUjJDaHdhd1l4VXF5ZGQ2bUZI?= =?utf-8?B?ZzdVNE1GekR4QndPN3R6eE5MVlNTYlA4K0VVaS9YVWUzc3dGWnBQMjhKc0hW?= =?utf-8?B?WHE0TXNJT2Y5L0RPNnV6a2wvdVNTRjBHZlBadXp3Q0xBZnhzN2JzSzR5NUxp?= =?utf-8?B?ckJCWi9YdWVGQkN3dnN3THpiLzNpdE9tdm5XZWJVZ2t5dFhIN3hoalZvWmJX?= =?utf-8?B?cDBsMG5GQ2NVc09xQ2F2SkVLQmcxZjdHcFpPUHM0SlByNHVUdlFhQ3EvZXZJ?= =?utf-8?B?MEQybGE1VGs3QTJ3UE5KdkpwVGROM0hiTmhVc05XZC8rQVBtQUNtR1JabCtV?= =?utf-8?B?Y1BwZzdqTmZ0bFkxVG9JSTI5UFExRzVUdmIzWlJwNVZXMVhON05pN0xSaHRR?= =?utf-8?B?dVRscDlRb3p5Nm0ycWxjbXNZREtXYStyb0NLalkxc2lETEpONGtiQUhTRzNh?= =?utf-8?Q?O1gcHYYWW3WJu2MTytqsmSSMOqNSGRg=3D?= X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 5:YYvPzDrqY8+XylnskCJUCVpKc3AIlQtu8F1b5x7dVMSSvtQTHmoRL/o3vwzTktbzHQTA83pZJscsmzGjEMxxXiVE9p3oqrizGOHwQMAq6DqqghVljjbAAyq+vjvLzEdVDLEiHe9T/gJNlsBykjC8YUDeXFIwZj7J0qVHZvfp1HTszb5fE3jSvJWpDgNmWlwEoCXtHtRsyIACVwtzwFj8JMCMzqNRTkFOSDG6pgqUAeXSNP4Dmpabed0Yv/BWQs1foUqnifzyTDhEUhVNI+u75oGelUezonEGsm0gEYhq+MyQKB+Hj3uYAPfEVk+u1m+0Yu3F1Bk64oB9QDnO9iEL42ZKHqtjNEvQlu4XHmiT/S2WNvmHM1aSt7FcRvOsOY+kOAAVAShZwseN0lNJEs4LGZER6/svMG70EQxEg12QXtKyzHSFetnSF5WVxKXkWj6na8mZGzfr0CF1JhUtK3Zt4xc/y8VByxRMB0TiKaECF/+SDbxxFu7fsl4VQiOCHHi2; 24:Uqe9UWqg7Tms32aaKu3RzW7XHtw1FZkNf38+Za0F/9SL/YBG+x6bc/CSxeZ1xi6ZwAb/NGhSRpDQlQSyONhUEhPp+oTgHRBkcQPtDgagsNc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; OS2PR01MB0251; 7:s0RHxoATGap2tlxJVrjiStTzRhUmLornvD1zyBQv+bVsP0z8y0gNSqn1ZBUInP83ALQoftZDNL9oMnbTaaOfywJdtrXv0uPIRV/PmaaRZxrIbwh0pv5xBBklqFCIhQC0Al2E4xbW9bGKLgnzHwBSlnV92SRmA9SVS9MYbX+fd05gPvRZaQH3s3BUFh3t+/x+lO1XXMCuUqejy6+/CKEoPN+gDJp0c1PdP7NXUdXNwCtnJq9mjd+wZkwfS70QjdwLtgG1GnXFw3n3iFqogeHvPVR1kP8Rc5Gb+Klw4DAWEn26v5rs2MfGRME/JyI6gSl1Yt0iPbm8gOTHm4THMXcv5d1EHT7fGN8qRombiZEglOeG1b2gIv9iPLy4VkTh6xD5AuY4WkrJjL9lT0Pj6fd+6QsqjeqWO7gWIqW4KK3Hj+qxRH9vmpSnmkjfgOtHaSTqeXkM0JLPXZWwInGMautP/cx9iXVHxlI73qfH0EgOvoSQ17LZ8br9LA1OKN86GLOW1sG9739mVmP7uRLg51S13Q27yW/Db/cLN4fzrKW0Zbiunf/MXR5003+jTZjXH5MbAwgq8RwjTdD0nC0sP6IkTE36Ga7mTmDwlZhTUHmrk7d8hWQL7KU9vXtUQ+Dg1K89Zw62GceJhrwDAKzgrdMDaPd/VlGfl3vBopPi6HkYNTn/GOuUE4g1hOOWHwGRSEiE/kBNmp8L31ChnS5t2Wy16z9P8Epbdebm+XXj5IKOsXLFUR+jxS0M3KYMXGcC7pguQ2I5XUUjsuc8Xenxlj8aiDkRuRijPVD/fzd1s5LFYuM= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2017 08:29:09.7409 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: OS2PR01MB0251 Archived-At: Subject: Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 08:29:20 -0000 Hello John, Adam, I'm currently on a plane heading for vacations, so I very much hope that by the time you get this email, things have cooled down a bit rather than escalating further. I seriously think that exchanges like this are not worth the time of two busy people like you, not to speak of the rest of the IESG and the WG (or those in the WG who still read its mail). It may seem like Adam is singling out this draft, but he only recently became an AD, and to support that claim, it would be necessary to show that he on-purpose ignored the same issue in other drafts that have recently come up to the IESG. Maybe he's just trying to do his best as a new AD. Or maybe he is just trying to give a bit more attention to an issue that is somewhat more important to him than to other IESG members; that's definitely not something that other ADs haven't done in the past. As for RFC numbers in abstracts, how exactly to show them can be left to the RFC Editor. Every reader will know how to get more information by going to the references section of the main document even if the number isn't styled as a reference. The concept of 'well-known RFC number' is very relative; there may be RFC numbers that the potential readers of the document know quite well even though the 'average' RFC reader won't. Also, if I as a reader don't know an RFC number that's obsoleted, then that's a very good signal that I may not have to care. If we still want to help the reader more, an additional phrase giving the title may also help. I'm not saying that because I think that these RFC numbers need to be in the abstract, just to say that it won't be the end of the world if they are. As for WG consensus, I'm not the one who judges that, but I'd think that questions like whether to put RFC numbers in the abstract or not haven't been discussed seriously, and the average WG member could care less about it either way. I strongly suggest that John take down his threat of an appeal, and Adam take down the discuss, and that you both, if necessary with the help of others, figure this out with less heat. Regards, Martin. On 2017/08/03 21:49, John C Klensin wrote: > --On Wednesday, August 2, 2017 13:18 -0500 Adam Roach > wrote: > >> On 8/2/17 10:04, John C Klensin wrote: >>> If "preferably" >>> is turning in "mandatory", we need to have two discussions, >>> one about the authority boundary between the IESG and the RFC >>> Editor and the other about where in RFC 2026 and its updates >>> the IESG is given authority to make policy by issuing >>> statements rather than determining and reflecting IETF >>> community consensus. >> >> >> Thanks for sending me down the path of determining authority >> here, as it has made me realize that I was confused about the >> basis for insisting that Obsoleted documents be explicitly >> listed in the Abstract. >> >> It turns out that the 2011 IESG statement of "preferably" is a >> weak restating of a 2008 IETF-consensus decision to approve >> version 1.9 of the "ID-Checklist" document, which clearly >> states that the Abstract of a document needs to list obsoleted >> and/or updated documents (cf. >> ; §3, >> 1.D, first bullet: "if your document obsoletes or updates a >> previous RFC, then... say so in the abstract"). >> >> And so I am forced to concede that my "No Objection" was made >> in error. Since the form of this document actively goes >> against IETF community consensus regarding the form of >> IETF-stream RFCs, I realize that this should have been a >> "Discuss." I will be adjusting my ballot accordingly. Thank >> you again for pointing me in the correct direction, and I >> apologize for the error. >> ... > > Adam, > > Silly me. I was about to propose a compromise in this area -- > one that I hoped would allow the document to move forward, for > me to be able to get back to RFC 3188bis and for you and the > IESG to get back to more important work -- and either didn't do > it soon enough or should have just kept my mouth shut and sorted > this out with the RFC Editor. I was sufficiently appalled by > your decision that I needed to take overnight to raise my > confidence that I was not overreacting. > > Sadly, I don't think I was overreacting. Consequently, unless > this DISCUSS can be resolved in some other way today, I will > submit a formal appeal against your use of a blocking DISCUSS on > an essentially editorial matter that puts form over substance > and that is abusive of working group decisions and the Last Call > and IESG review processes. > > In addition to the narrow issues in this particular case, the > appeal is likely to raise the following issues: > > (1) The need to clarify the boundary between the IESG's > authority, reflecting community consensus, over matters of > content for documents in the IETF Stream and the RFC Editor's > authority over editorial matters. General guidance and > statements of preference notwithstanding, I believe that > existing documents and long-standing tradition make rules about > the editorial (as distinct from substantive) content and > structure the exclusive province of the RFC Editor, with the > only important exception being the provision for the IESG to > demand "as is" publication of IETF Stream documents. The > requirement is > > (2) The pattern of migration of "guidance" or "recommendations" > into firm requirements ("rules") on which a blocking DISCUSS can > be based and publication of such requirements only in IESG > statements rather than archival documents of record. I note > that Section 5 of RFC 3710 (the IESG Charter) makes a > distinction between "problems and how to avoid them" and > "commonly used guidelines" on the one hand and "rules" on the > other. While that document says that the latter are "commonly > published as BCP RFCs", I suggest that substituting > poorly-indexed and non-archival "statements" or "checklists" for > such RFCs sets a trap for the inexperienced or unwary and is > hence inconsistent with a predictable and fair process. > > (3) Imposition of specific blocking rules involving the use or > applicability of terms such as "obsolete[s]" and "historic" is > inappropriate when it is generally recognized in the community > that those terms are insufficiently defined and inconsistently > applied. The way to solve those problems of definition and > application involves a proposal for what should be done, > community discussion and consensus, and RFC publication, not > dropping a DISCUSS on a single document that was either > arbitrarily chosen or that was singled out because one of the > author-editors chose to push back on an editorial "preference". > The observation that the IESG has not seen fit to initiate a > community-based effort (such as a WG) to clarify those > definitions makes a DISCUSS based on the use of those terms > particularly questionable. > > (4) There are some specific issues with the checklist statement > you cite that make it subject to different interpretations and > highlight the issues identified in (2) above. For example: > > (4.1) As noted in erratum 5076, a statement similar to "this > document obsoletes RFC 4687" is a citation whether an anchor > appears there or not, yet C(1)(B) of the checklist prohibits > citations. > > (4.2) C(1)(C) references "section 4.5 in > https://www.rfc-editor.org/rfc-style-guide/rfc-style-manual-08.txt" > in a context that can only be interpreted as normative, yet that > link is dead (leads to a 404 error) and the document to which it > referred became obsolete (sic) when RFC 7322 was published if > not earlier. To save you the time of checking, Section 4.5 of > RFC 7322 is not about abstracts. > > (4.3) C(1)(D), which you have cited in support of the presumed > requirement, says "if your document obsoletes or updates a > previous RFC, then: say so in the abstract". However, "say so" > appears to be general guidance, not a requirement for specific > language. The abstract in > draft-ietf-urnbis-ns-reg-transition-08 includes "This document > clarifies the status of relevant older RFCs...", which I contend > is consistent with the checklist "say so" statement. Had you > requested that statement be expanded to say "...document > clarifies the status of relevant older RFCs and formally makes > two of them historic...", I would have made a bad face but, > unless my co-author, the WG Chairs, or the WG disagreed, I would > have made the change and we would not be having this discussion. > > If the IESG (or even a single AD) is going to treat a particular > document as a set of requirements that justifies a blocking > DISCUSS, then it is obligated to maintain them so that > statements are clear and normative references are usable. > Failure to do so makes application of the documents or > statements in that way fundamentally unfair. > > (5) Even if none of the considerations outlined above applied, > it would be inappropriate to use a blocking DISCUSS because the > guidance in a particular document violates a "rule" or > "checklist item" when that guidance has existed for a long time > and has never been enforced consistently. > > regards, > john > > > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Sat Aug 5 05:38:11 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE26131CDC; Sat, 5 Aug 2017 05:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1SLrISgUbxM; Sat, 5 Aug 2017 05:37:56 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3031131CE7; Sat, 5 Aug 2017 05:37:56 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1ddyKz-000A0s-HI; Sat, 05 Aug 2017 08:37:49 -0400 Date: Sat, 05 Aug 2017 08:37:42 -0400 From: John C Klensin To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Adam Roach , The IESG cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org Message-ID: <3697C9447D3D8F548171E3AD@PSB> In-Reply-To: References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 12:37:59 -0000 --On Friday, August 4, 2017 17:36 +0900 "Martin J. D=C3=BCrst" wrote: > Hello John, Adam, >=20 > I'm currently on a plane heading for vacations, so I very much > hope that by the time you get this email, things have cooled > down a bit rather than escalating further. Martin, Thanks for the wise and calming words. If I were seeking to recall Adam over this, they would be entirely appropriate, but I am not. This is a matter of an appeal from a particular AD decision that I believe is out of line and that is _exactly_ what appeals are intended for: to ask the IESG, and, if necessary, the IAB and ISOC to review a particular decision, think about it a bit more, determine whether it was appropriate and, if it is not, to then take whatever actions are needed to adjust and avoid unnecessary recurrences. The bar for what seem to be blocking DISCUSS positions -- ones that have the character of "unless the IESG overrides my position, I am not going to let this go through until my concerns are reflected by changes in the I-D" rather than "I think this issue needs further consideration and discussion" is critical to the efficient and effective functioning of the IETF. I believe that its being set too low is one of the reasons important work has been migrating away from the IETF. More important for this particular issue, the IESG has been asked repeatedly to change names or procedures so that the intent that separates those two very different DISCUSS procedures was made clear. I note that issue was included in at least one appeal over 11 years ago and that, AFAICT, the IESG has, in the subsequent decade, neither taken action on that issue or explained why not -- itself, IMO, as significant violation of the intent of the appeals model and a threat to fairness. Because of that, I would feel obligated to produce a formal appeal and carry it forward even if Adam changed his mind about the DISCUSS. > It may seem like Adam is singling out this draft, but he only > recently became an AD, and to support that claim, it would be > necessary to show that he on-purpose ignored the same issue in > other drafts that have recently come up to the IESG. Maybe > he's just trying to do his best as a new AD. Or maybe he is > just trying to give a bit more attention to an issue that is > somewhat more important to him than to other IESG members; > that's definitely not something that other ADs haven't done in > the past. Again, if I were contemplating a recall, you would be absolutely correct about a pattern of bad behavior. I am not, although whether I even have the right to contemplate such things raises other issues. No such pattern is required for an appeal of a particular action. You can legitimately question whether an appeal in this case should simply say "this is a bad decision, please reconsider it" or whether it is appropriate for me to point out that, intentionally or not, the action raises other questions including, in this case, the authority (as inviolable rules rather than general guidance or preferences) of IESG statements or positions (especially those not published in the RFC Series), the question of whether general editorial decisions and style-setting for the RFC Series lie with the IESG or the RFC Editor, and those issues of the bar for blocking DISCUSSes and the IESG's failure to adequately distinguish between the two despite at least on earlier appeal. One unfortunate, but I presume unavoidable, aspect of this is that Adam was not on the Thursday IESG call when this draft was on the agenda. Because he was not available to participate in the discussion and did not submit any clarifying material in advance, the document, rather than being considered and probably advanced or even specifically rescheduled, could not be discussed and was dropped into an "AD followup" state with, so far, no scheduled date for more of a discussion. Whatever else you may think of my response to Adam's note announcing the DISCUSS, it was an explicit indication to Adam (and anyone else watching) that I intended to make this an appeal issue and an outline of the issues I intended to raise. That sort of indication, essentially a "please reconsider this, if possible, before it gets out of hand" is a _requirement_ of an appeal of an AD action. > As for RFC numbers in abstracts, how exactly to show them can > be left to the RFC Editor. >... But that is exactly the point. Adam's position, as I understand it, is that the IESG has set those rules and neither WGs nor the RFC Editor has any discretion. > Every reader will know how to get > more information by going to the references section of the > main document even if the number isn't styled as a reference. > The concept of 'well-known RFC number' is very relative; there > may be RFC numbers that the potential readers of the document > know quite well even though the 'average' RFC reader won't. > Also, if I as a reader don't know an RFC number that's > obsoleted, then that's a very good signal that I may not have > to care. If we still want to help the reader more, an > additional phrase giving the title may also help. I'm not > saying that because I think that these RFC numbers need to be > in the abstract, just to say that it won't be the end of the > world if they are. I think the comments above would be excellent input to a discussion about whether the RFC Editor should do and what the guidelines should be. The issue here is whether the RFC Editor should even have that authority/ discretion of whether this type of editorial content is not only specified by the IESG in some materials I believe are imprecise and badly-worked as well as illegitimate as rules (Adam presumably disagrees) and than an appropriate basis for blocking documents until they conform with an AD's interpretation of those IESG specifications (Adam presumably disagrees with that too). >... =20 > I strongly suggest that John take down his threat of an > appeal, and Adam take down the discuss, and that you both, if > necessary with the help of others, figure this out with less > heat. Not a threat, but a promise. If either the underlying issues here did not go well beyond that particular action and that particular editorial decision or if appeals were the heavyweight action you seem to assume, I would not have written that note. best, john From nobody Sat Aug 5 14:15:48 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75F9712EAF7; Sat, 5 Aug 2017 14:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjKnxgQzGbsK; Sat, 5 Aug 2017 14:15:43 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60468131F5A; Sat, 5 Aug 2017 14:15:43 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v75LFeLI041944 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 5 Aug 2017 16:15:41 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: John C Klensin , The IESG Cc: urn@ietf.org, barryleiba@computer.org, urnbis-chairs@ietf.org, draft-ietf-urnbis-ns-reg-transition@ietf.org References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> From: Adam Roach Message-ID: Date: Sat, 5 Aug 2017 16:15:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D1E69D1BCCFCDD5D168CD5FB" Content-Language: en-US Archived-At: Subject: Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 21:15:46 -0000 This is a multi-part message in MIME format. --------------D1E69D1BCCFCDD5D168CD5FB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/3/17 7:49 AM, John C Klensin wrote: > Sadly, I don't think I was overreacting. Consequently, unless > this DISCUSS can be resolved in some other way today, I will > submit a formal appeal against your use of a blocking DISCUSS on > an essentially editorial matter that puts form over substance > and that is abusive of working group decisions and the Last Call > and IESG review processes. John -- Thanks for sharing your rather extensive thoughts on this topic. I apologize that I was unable to meet your deadline of "today," as I was physically located in a part of the world that had limited to no data connectivity by the time you had sent it. As Martin points out, I'm still rather junior at this position, and have been led to believe that the Discuss Criteria has some fundamental authority to it. You will note, for example, that the DISCUSS ballot I entered was carefully selected, in a word-for-word fashion, from that document. I'm also under the impression that the current version of the ID-Checklist , having had extensive discussions on the IETF mailing list, is a reflection of IETF consensus regarding the form and format of documents to be turned over to the RFC editor. Interpreted that way, I have concerns that I would be derelict in my duties if I allowed an author to unilaterally ignore guidance that has received IETF-wide review. I'll return to this in a moment. I do very much appreciate that you had already formulated a compromise proposal with the intention of sharing it at some point. I find your intended formulation (as hinted by the snippet you included) to satisfy both word and spirit of the ID-Checklist provision for abstracts to indicate document obsoletion. At the same time, you have raised a host of collateral points of interest regarding the provenance and maintenance of Discuss Criteria and ID-Checklist. If we had a common understanding of their authority, then the path forward would be clear: if these documents are merely advisory and have no power to bind, then I'm free to concede the point and allow you to push forward with a document that does not conform to their contents -- and would likely do so at this point. Alternately, if they are expected by the IETF community to be binding, then it would seem my duty to assist in their enforcement. We could hold the publication of this document until we were able to resolve which of these two situations is true, but it seems a mild disservice to the URNBIS working group to do so. In an attempt to avoid delaying this document unnecessarily, I propose the following path forward: 1. You provide your aforementioned compromise text to Alexey (in his role as sponsoring AD) for inclusion as an RFC Editor Note, and I will clear my DISCUSS position. 2. As a tactical matter, you propose to the IESG a set of administrative updates to the ID-Checklist document reflecting those areas you believe it has fallen out of maintenance (e.g., the reference to an older version of the RFC style manual). I would expect these to be mechanical and uncontroversial to apply. 3. As a strategic matter, you or we begin a conversation with the IETF community at large regarding the provenance and authority of the Discuss Criteria and ID-Checklist documents. I do not want to presuppose the outcome of those conversations, so I suggest no specific potential conclusions. I'm happy to help you with formulation of the question, if you'd like, but I don't feel compelled to insert myself in doing so if you'd prefer to ask in your own terms. 4. Subsequent to conclusion of that conversation, and contingent on its outcome, we begin a conversation with the IETF community at large regarding the ambiguities you perceive as being present in the ID-Checklist so that we can more precisely reflect an IETF consensus position in its contents. /a --------------D1E69D1BCCFCDD5D168CD5FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 8/3/17 7:49 AM, John C Klensin wrote:
Sadly, I don't think I was overreacting.  Consequently, unless
this DISCUSS can be resolved in some other way today, I will
submit a formal appeal against your use of a blocking DISCUSS on
an essentially editorial matter that puts form over substance
and that is abusive of working group decisions and the Last Call
and IESG review processes.


John --

Thanks for sharing your rather extensive thoughts on this topic. I apologize that I was unable to meet your deadline of "today," as I was physically located in a part of the world that had limited to no data connectivity by the time you had sent it.

As Martin points out, I'm still rather junior at this position, and have been led to believe that the Discuss Criteria <https://www.ietf.org/iesg/statement/discuss-criteria.html> has some fundamental authority to it. You will note, for example, that the DISCUSS ballot I entered was carefully selected, in a word-for-word fashion, from that document. I'm also under the impression that the current version of the ID-Checklist <https://www.ietf.org/id-info/checklist.html>, having had extensive discussions on the IETF mailing list, is a reflection of IETF consensus regarding the form and format of documents to be turned over to the RFC editor. Interpreted that way, I have concerns that I would be derelict in my duties if I allowed an author to unilaterally ignore guidance that has received IETF-wide review. I'll return to this in a moment.

I do very much appreciate that you had already formulated a compromise proposal with the intention of sharing it at some point. I find your intended formulation (as hinted by the snippet you included) to satisfy both word and spirit of the ID-Checklist provision for abstracts to indicate document obsoletion.

At the same time, you have raised a host of collateral points of interest regarding the provenance and maintenance of Discuss Criteria and ID-Checklist. If we had a common understanding of their authority, then the path forward would be clear: if these documents are merely advisory and have no power to bind, then I'm free to concede the point and allow you to push forward with a document that does not conform to their contents -- and would likely do so at this point. Alternately, if they are expected by the IETF community to be binding, then it would seem my duty to assist in their enforcement. We could hold the publication of this document until we were able to resolve which of these two situations is true, but it seems a mild disservice to the URNBIS working group to do so.

In an attempt to avoid delaying this document unnecessarily, I propose the following path forward:

  1. You provide your aforementioned compromise text to Alexey (in his role as sponsoring AD) for inclusion as an RFC Editor Note, and I will clear my DISCUSS position.

  2. As a tactical matter, you propose to the IESG a set of administrative updates to the ID-Checklist document reflecting those areas you believe it has fallen out of maintenance (e.g., the reference to an older version of the RFC style manual).  I would expect these to be mechanical and uncontroversial to apply.

  3. As a strategic matter, you or we begin a conversation with the IETF community at large regarding the provenance and authority of the Discuss Criteria and ID-Checklist documents. I do not want to presuppose the outcome of those conversations, so I suggest no specific potential conclusions. I'm happy to help you with formulation of the question, if you'd like, but I don't feel compelled to insert myself in doing so if you'd prefer to ask in your own terms.

  4. Subsequent to conclusion of that conversation, and contingent on its outcome, we begin a conversation with the IETF community at large regarding the ambiguities you perceive as being present in the ID-Checklist so that we can more precisely reflect an IETF consensus position in its contents.


/a

--------------D1E69D1BCCFCDD5D168CD5FB-- From nobody Sun Aug 6 17:37:13 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096B71241F5; Sun, 6 Aug 2017 17:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkfw5xadB0Xo; Sun, 6 Aug 2017 17:37:03 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D04124234; Sun, 6 Aug 2017 17:37:03 -0700 (PDT) Received: by mail-oi0-x22f.google.com with SMTP id d71so53576051oih.0; Sun, 06 Aug 2017 17:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=gMVUZuLDjZ1DbImJ5Gel5+CaDOc7TcH/YkCbMr6tMlg=; b=QaU09F8lB4Yfyh+BKutetWiXIsdoqMlkg2y+LaYSbEmcUHkZAiPuDmj1JJ4pEvoxbD pCccCtn/3+SzMoEslJxlyyVN8EhsLZ1GtKZ1Ev3r5VRKmni637OhYQvbPtdKGv1NbhnS bj4pxCOKpcB++ZnAz8Lot78Wvze6qUY57c7kmZVAPKYhsNRvs2vZbfasIj5k8mUksuRt 08zxuRMie+8LSyXHTKgVCkcGGPGv0yUT0ZsP0ToPk+WPlbaU9MTEr55MF4jwnQHoFW2D KWK3G5i7haXfij7XRAwOWJXQDXwJxfKNtYgfsLC1cImS3K++8hZz6IhcMtC+Yv6xcGqX +DHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=gMVUZuLDjZ1DbImJ5Gel5+CaDOc7TcH/YkCbMr6tMlg=; b=HB4MZXLxYy2rVy8GfWYOWXZ2Xc1mvAzamJ/URnE2fAdhmo2pLlvl3Nb3nyf5uC5StW 4VwguuqwNB58+/+KrVpgsK3XtNguND4Y95+7F+0P9ygU8aRLSbfmvu45jy8daZxxj1YG IpFgOVV26KB+YW/PNaTJg4deb7vwz4BaZFoWl8oTNtrvqS3EJgNBNG7m0LfGhYbOyG12 Yy8zf3GKNq0BmWBdYFwuHlVDofhWbBR5L4E6tHHcLI3UMvelsITcTvcTrZEvhvlq2lHk RjkBl4IL2k/0yAPCGbJOurOzZr5AcvkhujsMnP7+jNOeqACc3dCnmeMZcFCRMRt4+dqP i3bA== X-Gm-Message-State: AHYfb5ilxp4FNrUIBEDaXj3UnlrMxY4eKJAHYLzva6Bs6ZvOp44M2+vY 7hTTenBPQYKD4VzZDQI= X-Received: by 10.202.104.194 with SMTP id o63mr5498762oik.294.1502066222336; Sun, 06 Aug 2017 17:37:02 -0700 (PDT) Received: from [192.168.1.5] (cpe-66-25-210-163.tx.res.rr.com. [66.25.210.163]) by smtp.gmail.com with ESMTPSA id p65sm2718837oia.49.2017.08.06.17.37.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Aug 2017 17:37:01 -0700 (PDT) To: Adam Roach , John C Klensin , The IESG Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> From: Spencer Dawkins Message-ID: <9069cade-dc09-66d1-0cda-a368a9b09a11@gmail.com> Date: Sun, 6 Aug 2017 19:37:00 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------49BFB7C3BF2D9056008AAE87" Content-Language: en-US Archived-At: Subject: Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 00:37:06 -0000 This is a multi-part message in MIME format. --------------49BFB7C3BF2D9056008AAE87 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear All, On 08/05/2017 04:15 PM, Adam Roach wrote: > On 8/3/17 7:49 AM, John C Klensin wrote: >> Sadly, I don't think I was overreacting. Consequently, unless >> this DISCUSS can be resolved in some other way today, I will >> submit a formal appeal against your use of a blocking DISCUSS on >> an essentially editorial matter that puts form over substance >> and that is abusive of working group decisions and the Last Call >> and IESG review processes. > > > John -- > > Thanks for sharing your rather extensive thoughts on this topic. I > apologize that I was unable to meet your deadline of "today," as I was > physically located in a part of the world that had limited to no data > connectivity by the time you had sent it. > > As Martin points out, I'm still rather junior at this position, and > have been led to believe that the Discuss Criteria > has some > fundamental authority to it. You will note, for example, that the > DISCUSS ballot I entered was carefully selected, in a word-for-word > fashion, from that document. I'm also under the impression that the > current version of the ID-Checklist > , having had extensive > discussions on the IETF mailing list, is a reflection of IETF > consensus regarding the form and format of documents to be turned over > to the RFC editor. Interpreted that way, I have concerns that I would > be derelict in my duties if I allowed an author to unilaterally ignore > guidance that has received IETF-wide review. I'll return to this in a > moment. > > I do very much appreciate that you had already formulated a compromise > proposal with the intention of sharing it at some point. I find your > intended formulation (as hinted by the snippet you included) to > satisfy both word and spirit of the ID-Checklist provision for > abstracts to indicate document obsoletion. > > At the same time, you have raised a host of collateral points of > interest regarding the provenance and maintenance of Discuss Criteria > and ID-Checklist. If we had a common understanding of their authority, > then the path forward would be clear: if these documents are merely > advisory and have no power to bind, then I'm free to concede the point > and allow you to push forward with a document that does not conform to > their contents -- and would likely do so at this point. Alternately, > if they are expected by the IETF community to be binding, then it > would seem my duty to assist in their enforcement. We could hold the > publication of this document until we were able to resolve which of > these two situations is true, but it seems a mild disservice to the > URNBIS working group to do so. > > In an attempt to avoid delaying this document unnecessarily, I propose > the following path forward: > > 1. You provide your aforementioned compromise text to Alexey (in his > role as sponsoring AD) for inclusion as an RFC Editor Note, and I > will clear my DISCUSS position. > > 2. As a tactical matter, you propose to the IESG a set of > administrative updates to the ID-Checklist document reflecting > those areas you believe it has fallen out of maintenance (e.g., > the reference to an older version of the RFC style manual). I > would expect these to be mechanical and uncontroversial to apply. > > 3. As a strategic matter, you or we begin a conversation with the > IETF community at large regarding the provenance and authority of > the Discuss Criteria and ID-Checklist documents. I do not want to > presuppose the outcome of those conversations, so I suggest no > specific potential conclusions. I'm happy to help you with > formulation of the question, if you'd like, but I don't feel > compelled to insert myself in doing so if you'd prefer to ask in > your own terms. > > 4. Subsequent to conclusion of that conversation, and contingent on > its outcome, we begin a conversation with the IETF community at > large regarding the ambiguities you perceive as being present in > the ID-Checklist so that we can more precisely reflect an IETF > consensus position in its contents. > It may be helpful to note that I would support this resolution, or something like it. There are other resolutions that I would also support, of course. If I might offer what I hope is a friendly amendment to Adam's proposal, I wouldn't mind seeing a list of the updates named in (2) before asking people to develop actual update text. And thanks for making that proposal. Spencer --------------49BFB7C3BF2D9056008AAE87 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Dear All,

On 08/05/2017 04:15 PM, Adam Roach wrote:
On 8/3/17 7:49 AM, John C Klensin wrote:
Sadly, I don't think I was overreacting.  Consequently, unless
this DISCUSS can be resolved in some other way today, I will
submit a formal appeal against your use of a blocking DISCUSS on
an essentially editorial matter that puts form over substance
and that is abusive of working group decisions and the Last Call
and IESG review processes.


John --

Thanks for sharing your rather extensive thoughts on this topic. I apologize that I was unable to meet your deadline of "today," as I was physically located in a part of the world that had limited to no data connectivity by the time you had sent it.

As Martin points out, I'm still rather junior at this position, and have been led to believe that the Discuss Criteria <https://www.ietf.org/iesg/statement/discuss-criteria.html> has some fundamental authority to it. You will note, for example, that the DISCUSS ballot I entered was carefully selected, in a word-for-word fashion, from that document. I'm also under the impression that the current version of the ID-Checklist <https://www.ietf.org/id-info/checklist.html>, having had extensive discussions on the IETF mailing list, is a reflection of IETF consensus regarding the form and format of documents to be turned over to the RFC editor. Interpreted that way, I have concerns that I would be derelict in my duties if I allowed an author to unilaterally ignore guidance that has received IETF-wide review. I'll return to this in a moment.

I do very much appreciate that you had already formulated a compromise proposal with the intention of sharing it at some point. I find your intended formulation (as hinted by the snippet you included) to satisfy both word and spirit of the ID-Checklist provision for abstracts to indicate document obsoletion.

At the same time, you have raised a host of collateral points of interest regarding the provenance and maintenance of Discuss Criteria and ID-Checklist. If we had a common understanding of their authority, then the path forward would be clear: if these documents are merely advisory and have no power to bind, then I'm free to concede the point and allow you to push forward with a document that does not conform to their contents -- and would likely do so at this point. Alternately, if they are expected by the IETF community to be binding, then it would seem my duty to assist in their enforcement. We could hold the publication of this document until we were able to resolve which of these two situations is true, but it seems a mild disservice to the URNBIS working group to do so.

In an attempt to avoid delaying this document unnecessarily, I propose the following path forward:

  1. You provide your aforementioned compromise text to Alexey (in his role as sponsoring AD) for inclusion as an RFC Editor Note, and I will clear my DISCUSS position.

  2. As a tactical matter, you propose to the IESG a set of administrative updates to the ID-Checklist document reflecting those areas you believe it has fallen out of maintenance (e.g., the reference to an older version of the RFC style manual).  I would expect these to be mechanical and uncontroversial to apply.

  3. As a strategic matter, you or we begin a conversation with the IETF community at large regarding the provenance and authority of the Discuss Criteria and ID-Checklist documents. I do not want to presuppose the outcome of those conversations, so I suggest no specific potential conclusions. I'm happy to help you with formulation of the question, if you'd like, but I don't feel compelled to insert myself in doing so if you'd prefer to ask in your own terms.

  4. Subsequent to conclusion of that conversation, and contingent on its outcome, we begin a conversation with the IETF community at large regarding the ambiguities you perceive as being present in the ID-Checklist so that we can more precisely reflect an IETF consensus position in its contents.

It may be helpful to note that I would support this resolution, or something like it. There are other resolutions that I would also support, of course.

If I might offer what I hope is a friendly amendment to Adam's proposal, I wouldn't mind seeing a list of the updates named in (2) before asking people to develop actual update text.

And thanks for making that proposal.

Spencer
--------------49BFB7C3BF2D9056008AAE87-- From nobody Mon Aug 7 03:26:59 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24A132199; Mon, 7 Aug 2017 03:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=WNv6OOP8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dclUHHeB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7s3SCVMcZrM; Mon, 7 Aug 2017 03:26:56 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3059132194; Mon, 7 Aug 2017 03:26:56 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 3FCCD20980; Mon, 7 Aug 2017 06:26:56 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute7.internal (MEProxy); Mon, 07 Aug 2017 06:26:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=9HlJqkhruDYLQ6Gwp9hoLNOz1IPtt 6fuepPqEJwpVWs=; b=WNv6OOP8GHmhcRC/h8QkHCzhgCvTcvd7M542bVC21CKwW vQKNrH/AYfU1VnxkkDEWNP2aRW4PqfO0pcK5uNIq2WZJKcr7b71eL6NDwwrGMM78 UiOln16DIoOqcsriW8ke5kKVJHGsXZRJzL7XDtQBXIk4KcsDH9Cq1km52Tz8lzPB OLzB3QAeQGUpof47I1w8JW8jtDvURzZv6PjfJw95f8y3XFx5kOBghdJ4DDyxrpsL qkBpY7wifSXFxrbl61503gcRcWDYtwP5UC6py22EPcPnfIxB+N/1k580NKvKOnAM kvAWnxThsWgfwoWMU2zniFe7L7djDwBC29gwSakHg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9HlJqk hruDYLQ6Gwp9hoLNOz1IPtt6fuepPqEJwpVWs=; b=dclUHHeBc9xifQe+q7GByY 0Gg0VfgBKW55x3M5fBmVRWXf/Z8vDZU1R6CXPkiXapqSK8/Yd3KFId2Ra4gxNfLp bvGs81LanhbrzMXDA/4MpHzHWokcLkniAlAPukFtn179GaAyEbilwPsbtHporn/S UalUdW8Lfel4x57V9oAaOebXSOpERG0VrGcWgazrdLWLza1q1r/KeCmOMkPl9f/k h3kHOcSvykJ3P7Y4GI3poPuE/lwKtKF55lnmRd9wq6nyLQFHYNfbz7oB0n/hNakG bxmHhZbmnikUDMDBGTgI+v6z2SgMLMrwBVK5YyYq2v9NIaAkGCuMmeqd4kZqK+Vg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1DA9C9E249; Mon, 7 Aug 2017 06:26:56 -0400 (EDT) Message-Id: <1502101616.3072010.1065417832.725BDDF3@webmail.messagingengine.com> From: Alexey Melnikov To: Adam Roach , John C Klensin , The IESG Cc: urn@ietf.org, urnbis-chairs@ietf.org, barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150210161630720100" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b2cde4a References: <150162261325.12068.7781273814707022394.idtracker@ietfa.amsl.com> <3ac23f7e-9e21-b977-694a-18d136d3abc1@nostrum.com> In-Reply-To: Date: Mon, 07 Aug 2017 11:26:56 +0100 Archived-At: Subject: Re: [urn] Adam Roach's Discuss on draft-ietf-urnbis-ns-reg-transition-08: (with DISCUSS and COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 10:26:58 -0000 This is a multi-part message in MIME format. --_----------=_150210161630720100 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hi, On Sat, Aug 5, 2017, at 10:15 PM, Adam Roach wrote: > In an attempt to avoid delaying this document unnecessarily, I propose > the following path forward:> > 1. You provide your aforementioned compromise text to Alexey (in his > role as sponsoring AD) for inclusion as an RFC Editor Note, and I > will clear my DISCUSS position. > I just updated RFC Editor note based on text suggested by John: Change the last sentence in the Abstract OLD: This document clarifies the status of relevant older RFCs and confirms and documents advice to IANA about selected existing registrations. NEW: This document clarifies the status of relevant older RFCs, including obsoleting two of them (RFC 3044 and RFC 3187) and making them historic, and confirms and documents advice to IANA about selected existing registrations. Please check and clear, if it looks reasonable to you. Thank you, Alexey --_----------=_150210161630720100 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hi,

On Sat, Aug 5, 2017, at 10:15 PM, Adam Roach wrote:
In an attempt to avoid delaying this document unnecessarily, I propose the following path forward:


  1. You provide your aforementioned compromise text to Alexey (in his role as sponsoring AD) for inclusion as an RFC Editor Note, and I will clear my DISCUSS position.


I just updated RFC Editor note based on text suggested by John:

Change the last sentence in the Abstract

OLD:
   This document clarifies the status of relevant older
   RFCs and confirms and documents advice to IANA about selected
   existing registrations.

NEW:

   This document clarifies the status of relevant older
   RFCs, including obsoleting two of them (RFC 3044 and RFC 3187)
   and making them historic, and confirms and documents advice to IANA
   about selected existing registrations.


Please check and clear, if it looks reasonable to you.

Thank you,
Alexey

--_----------=_150210161630720100-- From nobody Mon Aug 7 09:28:28 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDD2131CE8; Mon, 7 Aug 2017 09:28:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-urnbis-ns-reg-transition@ietf.org, Barry Leiba , urnbis-chairs@ietf.org, barryleiba@computer.org, urn@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150212330031.19032.14659298928423291006.idtracker@ietfa.amsl.com> Date: Mon, 07 Aug 2017 09:28:20 -0700 Archived-At: Subject: [urn] Adam Roach's No Objection on draft-ietf-urnbis-ns-reg-transition-08: (with COMMENT) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 16:28:20 -0000 Adam Roach has entered the following ballot position for draft-ietf-urnbis-ns-reg-transition-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The text in the RFC editor note looks fine to me. If you'd like to work with the author to refine the phrasing, I'm okay with variations in how this is worded. From nobody Tue Aug 8 06:47:25 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B02BB1321C5; Tue, 8 Aug 2017 06:47:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , Barry Leiba , barryleiba@computer.org, draft-ietf-urnbis-ns-reg-transition@ietf.org, urnbis-chairs@ietf.org, alexey.melnikov@isode.com, urn@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <150220002771.12443.12345667117626548349.idtracker@ietfa.amsl.com> Date: Tue, 08 Aug 2017 06:47:07 -0700 Archived-At: Subject: [urn] Protocol Action: 'Uniform Resource Name (URN) Namespace Registration Transition' to Proposed Standard (draft-ietf-urnbis-ns-reg-transition-08.txt) X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 13:47:08 -0000 The IESG has approved the following document: - 'Uniform Resource Name (URN) Namespace Registration Transition' (draft-ietf-urnbis-ns-reg-transition-08.txt) as Proposed Standard This document is the product of the Uniform Resource Names, Revised Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-reg-transition/ Technical Summary This document follows from RFC 8141, which changed the registration requirements for formal URN namespaces. This document clarifies the status of relevant older RFCs and advises IANA about some specific existing registrations. Working Group Summary This document was written in order to make the status of certain bits of the URNBIS working group's work clear, and to take it out of the path of the document that became RFC 8141. Much of what's in here was discussed before this document existed, and there has been ample discussion of and agreement to the content of it. This is really a non-controversial housekeeping document, which is set to Standards Track only so as to cleanly obsolete some existing Standards Track RFCs and to request their reclassification to Historic. Document Quality The real meat of what this document accomplishes has been submitted to IANA separately, as updated registration templates for the ISSN and ISBN URN namespaces. This document is mostly clarifies status of existing RFCs. Personnel Barry Leiba is the document shepherd. Alexey Melnikov is the responsible AD. RFC Editor Note 1) Please replace the last sentence at the end of the current Abstract: The original registration procedure for formal Uniform Resource Name (URN) namespaces required IETF Consensus. That requirement discouraged some registrations and increased the risk for problems that could occur as a result. The requirements have now been changed by RFC 8141, which adopts a different model, focusing on encouraging registration and publication of information for all appropriate namespaces. OLD: This document clarifies the status of relevant older RFCs and confirms and documents advice to IANA about selected existing registrations. NEW: This document clarifies the status of relevant older RFCs and confirms and documents advice to IANA about selected existing registrations. This document also makes the RFCs that describe the ISSN and ISBN namespaces obsolete and historic, as their descriptions now reside in registration templates. 2) RFC Editor should also consider whether including specific RFC numbers for ISSN and ISBN in the above text is appropriate and is consistent with the Style Guide. From steve@advance-software.com Tue Aug 22 05:04:45 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C695D1329A8 for ; Tue, 22 Aug 2017 05:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.786 X-Spam-Level: ** X-Spam-Status: No, score=2.786 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DEAR_SOMETHING=1.973, RDNS_NONE=0.793, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cevHvzmi0iNY for ; Tue, 22 Aug 2017 05:04:39 -0700 (PDT) Received: from server.advance-software.com (unknown [62.100.206.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52A4A132932 for ; Tue, 22 Aug 2017 05:04:34 -0700 (PDT) Received: from [90.255.112.168] (helo=[192.168.1.11]) by server.advance-software.com with esmtpa (Exim 4.82) (envelope-from ) id 1dk7u5-0002FH-K2 for urn@ietf.org; Tue, 22 Aug 2017 13:03:29 +0100 From: Steve Williams Reply-To: steve@advance-software.com To: urn@ietf.org Organization: Advance Software Message-ID: Date: Tue, 22 Aug 2017 13:03:46 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 22 Aug 2017 06:53:30 -0700 Subject: [urn] Request to register a URN (urn:xsg) for virtual reality 3D web use X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 12:20:04 -0000 Dear Sirs, If possible, I'd like to register the URN XSG so we can use urn:xsg in fastinfoset headers for binary encoded versions of our 3D web grammar, XSG. XSG is similar to W3C Web3D but is an independently developed alternative 3D web standard for consideration. I'd like this registering to avoid possible namespace collisions in future if someone else tries to register the URN for the same or some other purpose. Thank you for your consideration of this request. XSG stands for eXtendible Scene Graph. It is an XML based grammar, optionally fastinfoset binary encoded. It is used for designing and delivering 3D websites and can be considered a 3D/virtual reality equivalent of HTML. Further details on request. Our browser is Windows only for now but XSG and our core technology is platform independent. XSG examples can be seen running by installing our 3D web browser, linked below. Infinity caches files it accesses to [ProgramData]/Infinity/cache from where you can inspect them. Binary encoded xsg files can be converted into text equivalents by using the editxsg tool we provide. From Windows explorer, 'open with' editxsg provides text conversion for easy editing. The file is then converted back to binary when you're done. Please forwards as required - not quite sure where this should go as I don't yet fully understand the URN registration procedure. Best regards, Steve Williams Managing Director Advance Software Limited Mobile: +44 (0)745 9344854 Skype: steve--w <><> Infinity is here... Get your free 3D web browser today : http://advance-software.com/products How does your organisation plan to exploit the virtual reality opportunity ? Visit our 3D web portal : http://infinity-online.net https://www.facebook.com/advance.sw Twitter : @AdvanceSoftware https://www.linkedin.com/in/advsw From nobody Tue Aug 22 17:52:16 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BABA13218C for ; Tue, 22 Aug 2017 17:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.747 X-Spam-Level: X-Spam-Status: No, score=-0.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=V5LYxPn/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CQAR8Whi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZAmV6x1O0BS for ; Tue, 22 Aug 2017 17:52:12 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC2A1321A6 for ; Tue, 22 Aug 2017 17:52:12 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E88B8217D5; Tue, 22 Aug 2017 20:52:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Tue, 22 Aug 2017 20:52:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=+edZ8cTiu5fs+dhO16 b2fulrwTG7vF8b3gRfITmc6g0=; b=V5LYxPn/TgpVT1eRhBnQIRYDccQpeET0zc 5zvDc+yQk1gN0HDPscmPxlJtbf3mEyFOB4qTCI4hk4NEFOZ85sGYseuB+Mzv7u06 0bYCyTLhXl9yOz7Sb822xCW3zdg8NYTlLgs8n9MxBSontMvYBctwSo2pE9ypR00r wex9a+w4OsjEquhR8RZyPWYde10InEJB+p/UGdMyNOoiM4mbaQpC82pdt6HfhgVu 4bc1ElWAlMdaJ0ZxC1aQsbEoEhaQaYdicLrdR0LejfKh4vkK6r1mCO3AXA53EHkL 1xA/MQbRsebsSAS1RuM0yArxjJB9Dd7bIJ4ieEEwXJdVleoTshgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=+edZ8cTiu5fs+dhO16b2fulrwTG7vF8b3gRfITmc6g0=; b=CQAR8Whi kYJvxcuF7iFEsslCXs4CXlaMiz9xFCjRWKEZ/rkQmGDgYa7JwZwyRVA2K+1tEC7E H13QfHGk/CzDnysSMVm1Ngx+M3hkrVHYYg40u42l7C7VhLdcI633mVdaznHBf0E5 Xsx7aMMUShNsQt/DNtfQunQ4SDXaKF9RcTIrO522MRLETS8pstIih4y4JewtogNh bhe3xKEYzjzyZwojFD+L1FIaHQSe9fL7hWJSuqthGDG/C7USYFjCU0Kiyh4EiZ+/ 3f73EX4z77Tb0rQS18lH6dz8cKkA3wHoCUbd+DrtMQ8ew2dxtb9Qo/1RkxuRwBOm 05RD851VPAk4Og== X-ME-Sender: X-Sasl-enc: UReZKYIA8HM5sz7EkIKveVwe+5ZyM2PnGiMJrXy5k0hm 1503449531 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 274DE7E6AD; Tue, 22 Aug 2017 20:52:11 -0400 (EDT) To: steve@advance-software.com, urn@ietf.org References: From: Peter Saint-Andre Message-ID: <9e2880eb-0de1-274a-e5a7-3dfd66a77c4b@stpeter.im> Date: Tue, 22 Aug 2017 18:52:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Request to register a URN (urn:xsg) for virtual reality 3D web use X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 00:52:14 -0000 Hi Steve, Thank you for your inquiry. The process of registering a URN namespace is defined in Section 6 of RFC 8141: https://tools.ietf.org/html/rfc8141#section-6 See also Appendix A: https://tools.ietf.org/html/rfc8141#appendix-A A list of registered namespaces is maintained by IANA: https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml In particular, the ISBN and ISSN namespace registrations were recently updated to conform to the RFC 8141 template and thus they provide good examples for you to consult as you work on a registration for XSG: https://www.iana.org/assignments/urn-formal/isbn https://www.iana.org/assignments/urn-formal/issn Let us know if you have further questions as you work on your registration request. Best Regards, Peter On 8/22/17 6:03 AM, Steve Williams wrote: > Dear Sirs, > > If possible, I'd like to register the URN XSG so we can use urn:xsg > in fastinfoset headers for binary encoded versions of our 3D web > grammar, XSG. > > XSG is similar to W3C Web3D but is an independently developed > alternative 3D web standard for consideration. > > I'd like this registering to avoid possible namespace collisions in > future if someone else tries to register the URN for the same or some > other purpose. > > Thank you for your consideration of this request. XSG stands for > eXtendible Scene Graph. It is an XML based grammar, optionally > fastinfoset binary encoded. > > It is used for designing and delivering 3D websites and can be > considered a 3D/virtual reality equivalent of HTML. Further details on > request. > > Our browser is Windows only for now but XSG and our core technology is > platform independent. > > XSG examples can be seen running by installing our 3D web browser, > linked below. Infinity caches files it accesses to > [ProgramData]/Infinity/cache from where you can inspect them. Binary > encoded xsg files can be converted into text equivalents by using the > editxsg tool we provide. From Windows explorer, 'open with' editxsg > provides text conversion for easy editing. The file is then converted > back to binary when you're done. > > Please forwards as required - not quite sure where this should go as I > don't yet fully understand the URN registration procedure. > > Best regards, > Steve Williams > Managing Director > Advance Software Limited > > Mobile: +44 (0)745 9344854 > Skype: steve--w > > <><> Infinity is here... > > Get your free 3D web browser today : http://advance-software.com/products > > How does your organisation plan to exploit the virtual reality > opportunity ? > > Visit our 3D web portal : http://infinity-online.net > > https://www.facebook.com/advance.sw > > Twitter : @AdvanceSoftware > > https://www.linkedin.com/in/advsw > > _______________________________________________ > urn mailing list > urn@ietf.org > https://www.ietf.org/mailman/listinfo/urn From nobody Thu Aug 24 06:39:43 2017 Return-Path: X-Original-To: urn@ietf.org Delivered-To: urn@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F10D91326F4; Thu, 24 Aug 2017 06:39:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: urn@ietf.org, barryleiba@gmail.com, urnbis-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150358198194.24412.5068668270112045844.idtracker@ietfa.amsl.com> Date: Thu, 24 Aug 2017 06:39:41 -0700 Archived-At: Subject: [urn] urnbis - Not having a session at IETF 100 X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 13:39:42 -0000 Barry Leiba, a chair of the urnbis working group, indicated that the urnbis working group does not plan to hold a session at IETF 100. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Thu Aug 24 08:16:02 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B4D1321EB for ; Thu, 24 Aug 2017 08:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byf-suWwNUK7 for ; Thu, 24 Aug 2017 08:15:59 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DAC913237B for ; Thu, 24 Aug 2017 08:15:59 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id a76so2948143vke.5 for ; Thu, 24 Aug 2017 08:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=EnQPZtUlc1XSefYoKJh4k6kze5W992JNY2Rd99J33xI=; b=KUxt04l/SQibUysYoxG+i9Lob73rDppnG15nqao87HOLb80J4ZBLGasTLurUmFIlgK p7cIBYyqdipbqLilixoTlZl8QfsvVQszWegkeUALeC64ki7RT7s40H5V5zy9/OPSnbKL wqcnKFwtSFASxKWJnhN+gg0FwvWO6r59ZQ+9OmKUrl1WzKeJu00xzPDA4vtg4lq0h/T/ /eZ8rJxaFljg+uE9zPZayVdgBOqxYmbINOumEvKlekrmQa/GjbxK0U9PCp7KTY/dWDqS 67AolVBFwLpNUvNi+TthhcyrtlSGkeL9YkRxd841wQnDyTZAByzvSRaBA/cfngi5AF3X dkLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=EnQPZtUlc1XSefYoKJh4k6kze5W992JNY2Rd99J33xI=; b=eZh24S/Uk1Gdy1PlhvLPWgZAqThG1gznzg8AdiLkDzq0a6Bu1jYDbaDv93bbsIiej4 aJEsj9/REcLkpncFUM2k4svqmtAV+p9EDka94IzzU1c1Y6CeZXf/2/b9ZnuM0NQBEFTr 1X7xAJQt/o31ZUi6V7cXYmMAiO/8jniibZ/xCQ9mJc4+SuNTROnqPIspbI8OePgQqOCl g+a5AF3j6hcL8pkbV4HYvN5OYhqiZXx0RObwf8oi/a4/aRjK+yK02IY0LonabZkKckZ9 0r7V1KnIfY4312U4SVxiEQyDwOEUmXEiY/PIfM9qs2+GQEBBtN/+9+fAatwLFBOnMmOb e7LQ== X-Gm-Message-State: AHYfb5gbgPKbRlOmuyFBYmfzX79I2YYDPppSkbjoqObyrWUXLDzEc2bI HEskmW7T5hFmxRn4XaM0xLcvh4viXLAF53I= X-Received: by 10.31.48.79 with SMTP id w76mr3497905vkw.51.1503587758524; Thu, 24 Aug 2017 08:15:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.20.75 with HTTP; Thu, 24 Aug 2017 08:15:58 -0700 (PDT) In-Reply-To: References: <03a0480a-6ed4-51ce-5a34-f311c5a1b4c6@stpeter.im> From: Kasper Nielsen Date: Thu, 24 Aug 2017 17:15:58 +0200 Message-ID: To: urn@ietf.org Content-Type: multipart/alternative; boundary="001a1143f0d23c50a90557814edf" Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:16:02 -0000 --001a1143f0d23c50a90557814edf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I have updated my submission to reflect RFC 8141. https://raw.githubusercontent.com/dma-dk/www.mrnregistry.org/gh-pages/iana-= registration There are some mentions in my submission to some guidelines at http://www.mrnregistry.org regarding MRN assignment that are not yet available. However, we are still figuring out the details and they will be available in the near future. Best Kasper On 8 July 2017 at 10:21, Kasper Nielsen wrote: > Hi Peter, > > Thank you so much for bringing this to my intention. I've modelled the > draft after previous URN RFC submissions based on RFC 2141 + 3406, are > there any RFCs following RFC 8141 that I can use as a basis for > restructuring my submission? I have been unable to find any at > https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml > > I am especially struggling with the overall layout. I currently have thes= e > chapters > > Introduction > Specification Template > Namespace ID > Registration Information > ... > Examples > Namespace Considerations > Community Considerations > Security Considerations > IANA Considerations > > But in RFC 8141 all of these are put into a specification template. > What overall structure should I use? Should I just put everything into a > specification chapter? > > Best > Kasper > > > On 1 July 2017 at 23:51, Peter Saint-Andre wrote: > >> Hi Kaspar, >> >> Thank you for working on this proposed namespace ID and for the careful >> documentation in Internet-Draft form. >> >> RFC 2141 and RFC 3406 have been replaced by RFC 8141, and the >> registration template has changed (based on many years of experience >> with registration of new namespaces). As a result, the Internet-Draft >> you have posted is not quite conformant to the new template and process. >> Please refer to RFC 8141 for details: >> >> https://tools.ietf.org/html/rfc8141 >> >> Please let us know when you have posted version -03 of the specification >> so that we can review it again. >> >> Best Regards, >> >> Peter >> >> On 7/1/17 4:03 AM, Kasper Nielsen wrote: >> > Greetings, >> > >> > On behalf of the International Association of Marine Aids to Navigatio= n >> > and Lighthouse Authorities (IALA AISM) I would like to submit a >> > registration request for the urn =E2=80=9Cmrn=E2=80=9D. >> > >> > The International Association of Marine Aids to Navigation and >> > Lighthouse Authorities (IALA) is a non-profit, international technical >> > association servicing more than 80 countries in the field of marine ai= ds >> > to navigation. >> > >> > The detail about the request can be seen at >> > https://tools.ietf.org/html/draft-knielsen-mrn-urn-02 >> > >> > Please contact me and let me know in case you need further information >> > to process the request. >> > >> > Best Regards >> > >> > Kasper Nielsen >> > >> > IT Architect >> > Danish Maritime Authority >> > Carl Jacobsens Vej 31 >> > 2500 Valby >> > Denmark >> > +45 26737340 >> > >> >> > --001a1143f0d23c50a90557814edf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I have updated my submission to ref= lect RFC 8141.

On 8 July 2017 at 10:21, K= asper Nielsen <kasperni@gmail.com> wrote:
Hi Peter,

Thank you so= much for bringing this to my intention. I've modelled the draft after = previous URN RFC submissions based on RFC 2141 + 3406, are there any RFCs f= ollowing RFC 8141 that I can use as a basis for restructuring my submission= ? I have been unable to find any at https://www.ian= a.org/assignments/urn-namespaces/urn-namespaces.xhtml

I am especially struggling with the overall layout. I cur= rently have these chapters

Introduction
= Specification Template
=C2=A0 Namespace ID
=C2=A0 Regis= tration Information
=C2=A0 ...
Examples
Names= pace Considerations
Community Considerations
Security C= onsiderations
IANA Considerations

But in= RFC 8141 all of these are put into a specification template.
Wha= t overall structure should I use? Should I just put everything into a speci= fication chapter?

Best
=C2=A0 Kasper=C2=A0
=C2=A0

On 1 July 2017 at 23:51, Peter Sain= t-Andre <stpeter@stpeter.im> wrote:
Hi Kaspar,

Thank you for working on this proposed namespace ID and for the careful
documentation in Internet-Draft form.

RFC 2141 and RFC 3406 have been replaced by RFC 8141, and the
registration template has changed (based on many years of experience
with registration of new namespaces). As a result, the Internet-Draft
you have posted is not quite conformant to the new template and process. Please refer to RFC 8141 for details:

https://tools.ietf.org/html/rfc8141

Please let us know when you have posted version -03 of the specification so that we can review it again.

Best Regards,

Peter

On 7/1/17 4:03 AM, Kasper Nielsen wrote:
> Greetings,
>
> On behalf of the International Association of Marine Aids to Navigatio= n
> and Lighthouse Authorities (IALA AISM) I would like to submit a
> registration request for the urn =E2=80=9Cmrn=E2=80=9D.
>
> The International Association of Marine Aids to Navigation and
> Lighthouse Authorities (IALA) is a non-profit, international technical=
> association servicing more than 80 countries in the field of marine ai= ds
> to navigation.
>
> The detail about the request can be seen at
> https://tools.ietf.org/html/draft-kn= ielsen-mrn-urn-02
>
> Please contact me and let me know in case you need further information=
> to process the request.
>
> Best Regards
>
> Kasper Nielsen
>
> IT Architect
> Danish Maritime Authority
> Carl Jacobsens Vej 31
> 2500 Valby
> Denmark
> +45 26737340
>



--001a1143f0d23c50a90557814edf-- From nobody Thu Aug 24 11:27:02 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04791321AC for ; Thu, 24 Aug 2017 11:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.886 X-Spam-Level: X-Spam-Status: No, score=0.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, RDNS_NONE=0.793, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL5DD1hdW1Mv for ; Thu, 24 Aug 2017 11:26:58 -0700 (PDT) Received: from server.advance-software.com (unknown [62.100.206.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9717E13219C for ; Thu, 24 Aug 2017 11:26:57 -0700 (PDT) Received: from [90.255.112.168] (helo=[10.42.0.125]) by server.advance-software.com with esmtpa (Exim 4.82) (envelope-from ) id 1dkwpF-0008Jf-0m; Thu, 24 Aug 2017 19:25:53 +0100 Reply-To: steve@advance-software.com To: Peter Saint-Andre References: <9e2880eb-0de1-274a-e5a7-3dfd66a77c4b@stpeter.im> Cc: urn@ietf.org From: Steve Williams Organization: Advance Software Message-ID: <988e4d28-e6b8-ae0c-72d1-719fa41b06df@advance-software.com> Date: Thu, 24 Aug 2017 19:25:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9e2880eb-0de1-274a-e5a7-3dfd66a77c4b@stpeter.im> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [urn] Request to register a URN (urn:xsg) for virtual reality 3D web use X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 18:27:01 -0000 Hi Peter, Thanks for your prompt and clear reply. Will work through this shortly. Much appreciated. Best regards, Steve. On 23/08/17 01:52, Peter Saint-Andre wrote: > Hi Steve, > > Thank you for your inquiry. The process of registering a URN namespace > is defined in Section 6 of RFC 8141: > > https://tools.ietf.org/html/rfc8141#section-6 > > See also Appendix A: > > https://tools.ietf.org/html/rfc8141#appendix-A > > A list of registered namespaces is maintained by IANA: > > https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml > > In particular, the ISBN and ISSN namespace registrations were recently > updated to conform to the RFC 8141 template and thus they provide good > examples for you to consult as you work on a registration for XSG: > > https://www.iana.org/assignments/urn-formal/isbn > > https://www.iana.org/assignments/urn-formal/issn > > Let us know if you have further questions as you work on your > registration request. > > Best Regards, > > Peter > > On 8/22/17 6:03 AM, Steve Williams wrote: >> Dear Sirs, >> >> If possible, I'd like to register the URN XSG so we can use urn:xsg >> in fastinfoset headers for binary encoded versions of our 3D web >> grammar, XSG. >> >> XSG is similar to W3C Web3D but is an independently developed >> alternative 3D web standard for consideration. >> >> I'd like this registering to avoid possible namespace collisions in >> future if someone else tries to register the URN for the same or some >> other purpose. >> >> Thank you for your consideration of this request. XSG stands for >> eXtendible Scene Graph. It is an XML based grammar, optionally >> fastinfoset binary encoded. >> >> It is used for designing and delivering 3D websites and can be >> considered a 3D/virtual reality equivalent of HTML. Further details on >> request. >> >> Our browser is Windows only for now but XSG and our core technology is >> platform independent. >> >> XSG examples can be seen running by installing our 3D web browser, >> linked below. Infinity caches files it accesses to >> [ProgramData]/Infinity/cache from where you can inspect them. Binary >> encoded xsg files can be converted into text equivalents by using the >> editxsg tool we provide. From Windows explorer, 'open with' editxsg >> provides text conversion for easy editing. The file is then converted >> back to binary when you're done. >> >> Please forwards as required - not quite sure where this should go as I >> don't yet fully understand the URN registration procedure. >> >> Best regards, >> Steve Williams >> Managing Director >> Advance Software Limited >> >> Mobile: +44 (0)745 9344854 >> Skype: steve--w >> >> <><> Infinity is here... >> >> Get your free 3D web browser today : http://advance-software.com/products >> >> How does your organisation plan to exploit the virtual reality >> opportunity ? >> >> Visit our 3D web portal : http://infinity-online.net >> >> https://www.facebook.com/advance.sw >> >> Twitter : @AdvanceSoftware >> >> https://www.linkedin.com/in/advsw >> >> _______________________________________________ >> urn mailing list >> urn@ietf.org >> https://www.ietf.org/mailman/listinfo/urn > -- Best regards, Steve Williams Managing Director Advance Software Limited Mobile: +44 (0)745 9344854 Skype: steve--w <><> Infinity is here... Get your free 3D web browser today : http://advance-software.com/products How does your organisation plan to exploit the virtual reality opportunity ? Visit our 3D web portal : http://infinity-online.net https://www.facebook.com/advance.sw Twitter : @AdvanceSoftware https://www.linkedin.com/in/advsw From nobody Sun Aug 27 19:55:28 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F8D1321F5 for ; Sun, 27 Aug 2017 19:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=hTJklsc8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=V6kHfa9O Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXM0G4qvGgyQ for ; Sun, 27 Aug 2017 19:55:25 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D84E1321A0 for ; Sun, 27 Aug 2017 19:55:25 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B822E20D0F; Sun, 27 Aug 2017 22:55:24 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 27 Aug 2017 22:55:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=I8/yOCwT5DYbZrICmj gv5T2NFbvTjgfo/hx0S/h4C4A=; b=hTJklsc8H5j8nJfemLuXlzZiCWAhzPt+9v lXLpefgz46M8Qd7sbGI0ujNnflFdZ7rWZIbAr1C6RBYKUoBNWyPywdbKJiGWTPYn ppsU4e+DfWPSlpVDmEMl5WwVt384ty67lHur9FARSlUM+PcKHHAEqoHVsx4R+lJX U43nyYPvSPyUKOH6rOEijdeCSNbq0qlhtS0PDPZWd8kJ1pEw20HiX5vIl8JhN4D1 zWdtBPyGGFfR2fmdcbwtYjHe72V6e5GUn1c64L6P6hf9zWDEK5PEAkWLAKCUUd15 mDZjA8EYcoalf7kL5rApDo/JaW7Mt3ONupmu6BU+a6FjefyYmEiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=I8/yOCwT5DYbZrICmjgv5T2NFbvTjgfo/hx0S/h4C4A=; b=V6kHfa9O LJsPq9rlyGrbF39SP7+Jy9er71Rmyz6wF0nnXC0c7x7PEOah39lh/xbOVaIBL+Lj zw4hPNM0v+CdDQ7h5F7xpUw4AJbwwuuN4f4p4K3n8BDXctwFnBV36rl6Ag39CPZD BSopySwrYJsIBpKj9uiBn8IAPkq3JCMGbi8wdmlpRXc1OYE8ehVh8JlEs0MkLOdJ asZf17tvQgn649wbHppdoIiI0WOMJxrPKxmbwoDmcEuTRC7M7Te0dZVNQ064ZM2v S72XGTaSlActv9vLS722yVEhXO5H3EbWks8OmLDOjqMZg6PVL1zOyQAkDcQnxp1A 3aCzttCeKZfV5Q== X-ME-Sender: X-Sasl-enc: U98oaH6wq6/kCUAgEU0uz/F/wEXqgVSkJsrHMU4+3kBo 1503888924 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 28D547F3FA; Sun, 27 Aug 2017 22:55:24 -0400 (EDT) To: Kasper Nielsen , urn@ietf.org References: <03a0480a-6ed4-51ce-5a34-f311c5a1b4c6@stpeter.im> From: Peter Saint-Andre Message-ID: <78d1861b-68f1-2f3d-a586-0566e5b7cd86@stpeter.im> Date: Sun, 27 Aug 2017 20:55:24 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 02:55:28 -0000 Hi Kasper, Thank you for updating the registration proposal. I have two additional comments, which you might want to address before submission to IANA under the "fast track" process. Both topics are related to the fact that some of the examples reflect standards outside of IALA and the "mrn" namespace, such as MMSI numbers (defined in ITU recommendation M.585). 1. You might want to make it a bit clearer that such "external" identifiers will not be defined as MRN URNs unless the relevant organization (e.g., ITU) explicitly requests registration of an Organization ID with IALA through mrnregistry.org. 2. How will the MRN namespace handle such external identifiers if in their native format they include characters that are not allowed by the URN syntax as defined in RFC 8141? Please see point 4 of Section 6.4.2 of RFC 8141 (as well as Section 2.2) for some guidance. Best Regards, Peter On 8/24/17 9:15 AM, Kasper Nielsen wrote: > Hi, > > I have updated my submission to reflect RFC 8141. > https://raw.githubusercontent.com/dma-dk/www.mrnregistry.org/gh-pages/iana-registration > > There are some mentions in my submission to some guidelines at > http://www.mrnregistry.org regarding MRN assignment that are not yet > available. However, we are still figuring out the details and they will > be available in the near future. > > Best > Kasper > > On 8 July 2017 at 10:21, Kasper Nielsen > wrote: > > Hi Peter, > > Thank you so much for bringing this to my intention. I've modelled > the draft after previous URN RFC submissions based on RFC 2141 + > 3406, are there any RFCs following RFC 8141 that I can use as a > basis for restructuring my submission? I have been unable to find > any at > https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml > > > I am especially struggling with the overall layout. I currently have > these chapters > > Introduction > Specification Template > Namespace ID > Registration Information > ... > Examples > Namespace Considerations > Community Considerations > Security Considerations > IANA Considerations > > But in RFC 8141 all of these are put into a specification template. > What overall structure should I use? Should I just put everything > into a specification chapter? > > Best > Kasper > > > On 1 July 2017 at 23:51, Peter Saint-Andre > wrote: > > Hi Kaspar, > > Thank you for working on this proposed namespace ID and for the > careful > documentation in Internet-Draft form. > > RFC 2141 and RFC 3406 have been replaced by RFC 8141, and the > registration template has changed (based on many years of experience > with registration of new namespaces). As a result, the > Internet-Draft > you have posted is not quite conformant to the new template and > process. > Please refer to RFC 8141 for details: > > https://tools.ietf.org/html/rfc8141 > > > Please let us know when you have posted version -03 of the > specification > so that we can review it again. > > Best Regards, > > Peter > > On 7/1/17 4:03 AM, Kasper Nielsen wrote: > > Greetings, > > > > On behalf of the International Association of Marine Aids to > Navigation > > and Lighthouse Authorities (IALA AISM) I would like to submit a > > registration request for the urn “mrn”. > > > > The International Association of Marine Aids to Navigation and > > Lighthouse Authorities (IALA) is a non-profit, international > technical > > association servicing more than 80 countries in the field of > marine aids > > to navigation. > > > > The detail about the request can be seen at > > https://tools.ietf.org/html/draft-knielsen-mrn-urn-02 > > > > > Please contact me and let me know in case you need further > information > > to process the request. > > > > Best Regards > > > > Kasper Nielsen > > > > IT Architect > > Danish Maritime Authority > > Carl Jacobsens Vej 31 > > 2500 Valby > > Denmark > > +45 26737340 > > From nobody Mon Aug 28 07:46:00 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95DAB13219B for ; Mon, 28 Aug 2017 07:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z14hd2pKiKVo for ; Mon, 28 Aug 2017 07:45:55 -0700 (PDT) Received: from tana.servicios.spamina.com (tana.spamina.com [92.54.27.39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0BDD132C2B for ; Mon, 28 Aug 2017 07:45:53 -0700 (PDT) Received: from [207.249.28.249] (helo=SVRMB2.infotec.mx) by tana.servicios.spamina.com with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1dmLIM-0000rY-TA for urn@ietf.org; Mon, 28 Aug 2017 16:45:48 +0200 Received: from SVRMB3.infotec.mx (192.168.97.27) by SVRMB2.infotec.mx (192.168.97.26) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 28 Aug 2017 09:46:28 -0500 Received: from SVRMB3.infotec.mx ([fe80::3ced:1738:53ae:d456]) by SVRMB3.infotec.mx ([fe80::3ced:1738:53ae:d456%17]) with mapi id 15.00.1178.000; Mon, 28 Aug 2017 09:46:28 -0500 X-Envelope-From: itzel.morales@infotec.mx From: Itzel Morales Ramirez To: "urn@ietf.org" Thread-Topic: REFSQ'18 24th International Working Conference on Requirements Engineering: Foundation for Software Quality Thread-Index: AdMdsdcYQRUFAFdfRWiBancLlNA1uwCWoZhQ Date: Mon, 28 Aug 2017 14:46:27 +0000 Message-ID: <18a755e5490647e9aa16cf99c54ecf93@SVRMB3.infotec.mx> Accept-Language: es-MX, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.81.168] Content-Type: multipart/alternative; boundary="_000_18a755e5490647e9aa16cf99c54ecf93SVRMB3infotecmx_" MIME-Version: 1.0 X-CTCH-IPCLASS: T2 X-SPF-Received: 2 X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -2.9 (--) X-Spamina-Spam-Report: Content analysis details: (-2.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: goo.gl] -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 0.0 HTML_MESSAGE BODY: HTML included in message Archived-At: Subject: [urn] REFSQ'18 24th International Working Conference on Requirements Engineering: Foundation for Software Quality X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 14:45:58 -0000 --_000_18a755e5490647e9aa16cf99c54ecf93SVRMB3infotecmx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CALL FOR SUBMISSIONS REFSQ'18 -- 24th International Working Conference on Requirements Engineering: Foundation for Software Quality 19 - 22 March 2018, Utrecht, The Netherlands https://www.refsq.org =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Important Dates --------------- - Submission of Abstracts: September 25, 2017 - Paper Submission: October 2, 2017 - Conference: Mar 19 - Mar 22, 2018 Description ----------- Requirements Engineering (RE) is a critical factor in developing high-quali= ty and successful software, systems and services. The REFSQ working confere= nce series is a well-established international forum for discussing current= and state-of-the-art RE practices, now celebrating its 24th year. We are e= xcited to hold REFSQ in Utrecht, returning to the location of the first REF= SQ meeting in 1994. We very much welcome participants to attend REFSQ'18 in= the Netherlands. Working Conference Format ------------------------- REFSQ has a long tradition of being a highly structured and interactive eve= nt. Each session is organised to emphasize discussion among the presenters = of papers, pre-assigned discussants, and all the other participants. The RE= FSQ'18 program will include keynote speakers, technical papers, research pr= eviews, industrial presentations, as well as posters and tools. Workshops a= nd the REFSQ doctoral symposium will be co-located with the main conference= . Scope ----- REFSQ 2018 seeks reports of novel ideas and techniques that enhance the qua= lity of RE products and processes, reflections on current research and indu= strial RE practices, as well as new views on RE. We invite submissions on a= ny aspect of RE. We encourage researchers and practitioners from the RE, so= ftware engineering, information systems, service science, embedded systems,= and product management fields to present original work. RE methods, tools = and processes are expected to support engineering diverse types of systems = of different scale and complexity and are applied in diverse domains. As su= ch, contributions from related areas such as systems engineering, economics= , and management, providing insights to RE, are welcome. The special theme = of REFSQ'18 is "RE and Digital Transformation" to emphasize an important is= sue: what role can RE play in the dramatic changes that take place in our s= ociety today to innovate and design new heterogeneous systems and services = to fit the needs of users and to keep values of society. Submissions ----------- We invite original submissions in several categories: - Technical design papers (15 pages) describe the design of new artifacts,= i.e., novel solutions for requirements-related problems or significant imp= rovements of existing solutions. - Scientific evaluation papers (15 pages) investigate existing real-world = problems, evaluate existing real-world implemented artifacts, or validate n= ewly designed artifacts, e.g., by means such as case studies, experiments, = simulation, surveys, systematic literature reviews, mapping studies, or act= ion research. - Vision papers (6 pages) state where research in the field should be head= ing. - Research previews (6 pages) describe well-defined research ideas at an e= arly stage of investigation which may not be fully developed. - Research method papers (15 pages) discuss methodological aspects of good= quality empirical RE research. Conclusions should be supported by evidenc= e. Please submit your paper through the EasyChair system: https://goo.gl/RocwN= a Other Contributions ------------------- REFSQ'18 also calls for workshops focussing on relevant topics, posters, an= d doctoral symposium submissions. Check out the website! Call to Requirements Empiricists! Live Study Proposal Submissions ----------------------------------------------------------------- The REFSQ conference has a tradition of a special plenary session for condu= cting a "live study" involving the conference attendees. We invites proposa= l submissions of compelling live studies to be conducted at REFSQ 2018. Det= ails can be found on the REFSQ'18 website. Publications ------------ The REFSQ 2018 proceedings will be published in Springer's LNCS series. REFSQ 2018 Special Section -------------------------- Following the conference, the authors of two of the best manuscripts will b= e invited to extend their papers into full journal papers, for a Special Se= ction of the Information and Software Technology Journal. ADVERTENCIA LEGAL De conformidad con los Art?culos 13, 14 y 63 de la Ley Federal de Transpare= ncia y Acceso a la Informaci?n P?blica Gubernamental, y lineamiento Trig?si= mo S?ptimo de los Lineamientos Generales para la Clasificaci?n y Desclasifi= caci?n de la Informaci?n de las Dependencias y Entidades de la Administraci= ?n P?blica Federal, la informaci?n contenida en este mensaje electr?nico o = anexa al mismo, podr? ser considerada como reservada o confidencial por lo = que cualquier uso, reproducci?n, difusi?n o distribuci?n ya sea total o par= cial de este mensaje y sus anexos est? estrictamente prohibida. Si recibe e= sta comunicaci?n por error, elimine de su computadora el mensaje y cualquie= r documento adjunto; abst?ngase de efectuar su reproducci?n, difusi?n o dis= tribuci?n y notifique inmediatamente esta situaci?n al remitente, en caso d= e incumplimiento, adem?s de las responsabilidades administrativas que se ge= neren, podr? ser sujeto de las acciones de orden civil y/o penal que proced= an. Lo anterior conforme a los art?culos 210, 211, 211 Bis, 211 Bis 1, 211 = Bis 2, 211 Bis 3, 211 Bis 4, 211 Bis 5, 211 Bis 6, 211 Bis 7, y de m?s rela= tivos y aplicables del C?digo Penal Federal. "LA INFORMACI?N DE ESTE CORREO= AS? COMO LA CONTENIDA EN LOS DOCUMENTOS QUE SE ADJUNTAN, PUEDE SER OBJETO = DE SOLICITUDES DE ACCESO A LA INFORMACI?N" Antes de imprimir este mensaje, por favor compruebe si es verdaderamente ne= cesario hacerlo. El compromiso con el MEDIO AMBIENTE es tarea de todos. --_000_18a755e5490647e9aa16cf99c54ecf93SVRMB3infotecmx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

CALL FOR SUBMISSIONS

REFSQ’18 -- 24th International Working Confere= nce on

Requirements Engineering: Foundation for Software Qu= ality

19 - 22 March 2018, Utrecht, The Netherlands

https://www.refsq.= org

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

 

Important Dates

---------------

- Submission of Abstracts: September 25, 2017

- Paper Submission:     &nb= sp;  October    2, 2017

- Conference:      &nb= sp;    Mar 19 - Mar 22, 2018

 

 

Description

-----------

Requirements Engineering (RE) is a critical factor i= n developing high-quality and successful software, systems and services. Th= e REFSQ working conference series is a well-established international forum= for discussing current and state-of-the-art RE practices, now celebrating its 24th year. We are excited to hold REFSQ = in Utrecht, returning to the location of the first REFSQ meeting in 1994. W= e very much welcome participants to attend REFSQ'18 in the Netherlands.

 

 

Working Conference Format

-------------------------

REFSQ has a long tradition of being a highly structu= red and interactive event. Each session is organised to emphasize discussio= n among the presenters of papers, pre-assigned discussants, and all the oth= er participants. The REFSQ’18 program will include keynote speakers, technical papers, research previews, indust= rial presentations, as well as posters and tools. Workshops and the REFSQ d= octoral symposium will be co-located with the main conference.

 

 

Scope

-----

REFSQ 2018 seeks reports of novel ideas and techniqu= es that enhance the quality of RE products and processes, reflections on cu= rrent research and industrial RE practices, as well as new views on RE. We = invite submissions on any aspect of RE. We encourage researchers and practitioners from the RE, software engin= eering, information systems, service science, embedded systems, and product= management fields to present original work. RE methods, tools and processe= s are expected to support engineering diverse types of systems of different scale and complexity and are applied= in diverse domains. As such, contributions from related areas such as syst= ems engineering, economics, and management, providing insights to RE, are w= elcome. The special theme of REFSQ’18 is "RE and Digital Transformation" to emphasize an important iss= ue: what role can RE play in the dramatic changes that take place in our so= ciety today to innovate and design new heterogeneous systems and services t= o fit the needs of users and to keep values of society.

 

 

Submissions

-----------

We invite original submissions in several categories= :

-  Technical design papers (15 pages) describe = the design of new artifacts, i.e., novel solutions for requirements-related= problems or significant improvements of existing solutions.

-  Scientific evaluation papers (15 pages) inve= stigate existing real-world problems, evaluate existing real-world implemen= ted artifacts, or validate newly designed artifacts, e.g., by means such as= case studies, experiments, simulation, surveys, systematic literature reviews, mapping studies, or action researc= h.

-  Vision papers (6 pages) state where research= in the field should be heading.

-  Research previews (6 pages) describe well-de= fined research ideas at an early stage of investigation which may not be fu= lly developed.

-  Research method papers (15 pages) discuss me= thodological aspects of good quality empirical RE research.  Conclusio= ns should be supported by evidence.

 

Please submit your paper through the EasyChair syste= m: https://goo.gl/RocwNa

 

 

Other Contributions

-------------------

REFSQ’18 also calls for workshops focussing on= relevant topics, posters, and doctoral symposium submissions. Check out th= e website!

 

 

Call to Requirements Empiricists! Live Study Proposa= l Submissions

----------------------------------------------------= -------------

The REFSQ conference has a tradition of a special pl= enary session for conducting a "live study" involving the confere= nce attendees. We invites proposal submissions of compelling live studies t= o be conducted at REFSQ 2018. Details can be found on the REFSQ'18 website.

 

 

Publications

------------

The REFSQ 2018 proceedings will be published in Spri= nger’s LNCS series.

 

 

REFSQ 2018 Special Section

--------------------------

Following the conference, the authors of two of the = best manuscripts will be invited to extend their papers into full journal p= apers, for a Special Section of the Information and Software Technology Jou= rnal.

 



ADVERTENCIA LEGAL

De conformidad con los Artículos 13, 14 y 63 de la Ley Federal de Tr= ansparencia y Acceso a la Información Pública Gubernamental, = y lineamiento Trigésimo Séptimo de los Lineamientos Generales= para la Clasificación y Desclasificación de la Informaci&oac= ute;n de las Dependencias y Entidades de la Administración Pública Federa= l, la información contenida en este mensaje electrónico o ane= xa al mismo, podrá ser considerada como reservada o confidencial por= lo que cualquier uso, reproducción, difusión o distribuci&oa= cute;n ya sea total o parcial de este mensaje y sus anexos está estrictamente pro= hibida. Si recibe esta comunicación por error, elimine de su computa= dora el mensaje y cualquier documento adjunto; absténgase de efectua= r su reproducción, difusión o distribución y notifique inmediatamente esta situación al remitente, en caso de incumplimien= to, además de las responsabilidades administrativas que se generen, = podrá ser sujeto de las acciones de orden civil y/o penal que proced= an. Lo anterior conforme a los artículos 210, 211, 211 Bis, 211 Bis 1, 211 Bis 2, 211 Bis 3, 211 Bis 4, 211 Bis 5, 211 Bis 6, 211= Bis 7, y de más relativos y aplicables del Código Penal Fede= ral. "LA INFORMACIÓN DE ESTE CORREO ASÍ COMO LA CONTENID= A EN LOS DOCUMENTOS QUE SE ADJUNTAN, PUEDE SER OBJETO DE SOLICITUDES DE ACCESO A LA INFORMACIÓN"

Antes de imprimir este mensaje, por favor compruebe si es verdaderamente ne= cesario hacerlo. El compromiso con el MEDIO AMBIENTE es tarea de todos.
--_000_18a755e5490647e9aa16cf99c54ecf93SVRMB3infotecmx_-- From nobody Thu Aug 31 01:31:50 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738FF13235A for ; Thu, 31 Aug 2017 01:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LVNR9izjmyf for ; Thu, 31 Aug 2017 01:31:47 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334F5132335 for ; Thu, 31 Aug 2017 01:31:47 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 37so152104ual.0 for ; Thu, 31 Aug 2017 01:31:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t65huWxo2ZuY1gajcI+aAZovvNdyNxx5Dy8fSgJc6Nw=; b=ZAQScZa+QDYSp98eMXQfBvHIX80JonZsxhJ46YtANDPX4YyC1/fWtXU0R6YTw3BTVv tXbtxkDqum3Thhe/ztsXCkkW8k0nbgeqHzmiYQM08onJH1QsfpEyyHHo/bXGIPLXqiRZ OYIpvJYW2fGQ33/HFa8dtlyiQ/te2uCu682AfMS2jQtNv9rlcWGBceYTQMrBcav2Cdr1 bVwQtm293w+2aLWibangfNwmUmzmzLJAq+QTqUcE8V+dV8Z8A7G53Q2piZ95ZDRjI0Xd u5mdXJBKAXTuFgCmgyeXI2yNKzTrCVepLpwOwCq6JeqbDM+0umHggDGiPZL4jtiScI8I YjUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t65huWxo2ZuY1gajcI+aAZovvNdyNxx5Dy8fSgJc6Nw=; b=FWzTEAggB4vSVi9MCo29XUfLKy8D0LQtpUq9fVsZCUor0z0y5J47WbFpDcENDXke5Y xNGl1mfpvBxUZ+qMPpEKT/NKTdHAZZc2mrmxfPi33dN1t0XpE+XKF5VzKvUhhS/4IP3U bZpLp+hsM/C9RDJAkk4AS8cfMGtR2D6rsMvLsmhCO/Q11Ofg2INSuT0wnFFkSBS+eNhV yZVidGDmgh1T/klxwiKCnUVADvPr2hY5QmKMOLrrGJ4/cHARBoEU9vR1cyc3n9effsaV XhtOuxvBf3r4FIdfpbBWv6s1tvIO24ZMOCh/pIAQxllcglfXZQkVNQSwvBfJ7BaFYPfU x/5w== X-Gm-Message-State: AHYfb5irmCz3TRIftH131ABZwcRgojj5D0nFAXpfrmuQ+BGv3EU0gJoQ nlJNYuvc8x5jazIm4vOfZafOlwZMRsYQgQg= X-Received: by 10.159.55.168 with SMTP id q37mr2429335uaq.80.1504168306060; Thu, 31 Aug 2017 01:31:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.20.75 with HTTP; Thu, 31 Aug 2017 01:31:45 -0700 (PDT) In-Reply-To: <78d1861b-68f1-2f3d-a586-0566e5b7cd86@stpeter.im> References: <03a0480a-6ed4-51ce-5a34-f311c5a1b4c6@stpeter.im> <78d1861b-68f1-2f3d-a586-0566e5b7cd86@stpeter.im> From: Kasper Nielsen Date: Thu, 31 Aug 2017 10:31:45 +0200 Message-ID: To: Peter Saint-Andre Cc: urn@ietf.org Content-Type: multipart/alternative; boundary="94eb2c03f99290b5b00558087903" Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 08:31:49 -0000 --94eb2c03f99290b5b00558087903 Content-Type: text/plain; charset="UTF-8" Hi Peter, Thank you for the your pointers. I should have addressed both of your concerns (see inlined) An updated version is available at https://raw.githubusercontent.com/dma-dk/www.mrnregistry.org/gh-pages/iana-registration On 28 August 2017 at 04:55, Peter Saint-Andre wrote: > > 1. You might want to make it a bit clearer that such "external" > identifiers will not be defined as MRN URNs unless the relevant > organization (e.g., ITU) explicitly requests registration of an > Organization ID with IALA through mrnregistry.org. > Added the following to the example section ++++ It is important to note that even though IALA is the maintainer of the MRN URN namespace it cannot define MRNs outside of the "urn:mrn:iala" namespace. All of the above examples that are not in the "urn:mrn:iala" namespace, requires that the relevant organization explicitly requests an Organization ID with IALA. ++++ > > 2. How will the MRN namespace handle such external identifiers if in > their native format they include characters that are not allowed by the > URN syntax as defined in RFC 8141? Please see point 4 of Section 6.4.2 > of RFC 8141 (as well as Section 2.2) for some guidance. > Added the following to the Syntax section ++++ If adopting existing non-URN based identifier systems that includes characters not allowed by the URN syntax as specified in [RFC8141]. The representation of these characters should be handled by percent-encoding the character as specified in Section 2.1 of the URI specification [RFC3986]. ++++ /Kasper --94eb2c03f99290b5b00558087903 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Peter,

Thank you for the your pointe= rs. I should have addressed both of your concerns (see inlined)

On 28 August 2017 at 04:55, Peter Saint-Andre <stpeter@stpeter.im> wrote:
1. You might want to make it a bit clearer that such "external" identifiers will not be defined as MRN URNs unless the relevant
organization (e.g., ITU) explicitly requests registration of an
Organization ID with IALA through mrnregistry.org.
Ad= ded the following to the example section

++++
It is important to note that even though IALA is the maintainer = of the MRN
URN namespace it cannot define MRNs outside of the &qu= ot;urn:mrn:iala" namespace.
All of the above examples that a= re not in the "urn:mrn:iala" namespace,
requires that t= he relevant organization explicitly requests an Organization
ID w= ith IALA.
++++
=C2=A0

2. How will the MRN namespace handle such external identifiers if in
their native format they include characters that are not allowed by the
URN syntax as defined in RFC 8141? Please see point 4 of Section 6.4.2
of RFC 8141 (as well as Section 2.2) for some guidance.
Added the following to the Syntax section

++++
If adopting existing non-URN based identifier systems that in= cludes=C2=A0
characters not allowed by the URN syntax as specifie= d in [RFC8141].
The representation of these characters should be = handled by percent-encoding=C2=A0
the character as specified in S= ection 2.1 of the URI specification [RFC3986].
++++

/Kasper
--94eb2c03f99290b5b00558087903-- From nobody Thu Aug 31 04:18:19 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95F6132D59 for ; Thu, 31 Aug 2017 04:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPCmULPnBFDC for ; Thu, 31 Aug 2017 04:18:15 -0700 (PDT) Received: from mail.dnb.de (prodfix-out0.dnb.de [193.175.100.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DB28132223 for ; Thu, 31 Aug 2017 04:18:13 -0700 (PDT) Received: from smg1.ad.ddb.de (unknown [10.69.63.232]) by mail.dnb.de (Postfix) with ESMTP id A6D8B4DA4AC7; Thu, 31 Aug 2017 13:18:11 +0200 (CEST) X-AuditID: 0a453fe7-24dff70000000e76-7f-59a7f073ed4c Received: from dnbf-ex1.AD.DDB.DE (dnbf-ex1.ad.ddb.de [10.69.63.245]) by smg1.ad.ddb.de (DNB Symantec Messaging Gateway) with SMTP id 7B.2B.03702.370F7A95; Thu, 31 Aug 2017 13:18:11 +0200 (CEST) Received: from DNBF-EX1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0]) by dnbf-ex1.AD.DDB.DE ([fe80::7076:30f7:60ad:16a0%12]) with mapi id 14.03.0352.000; Thu, 31 Aug 2017 13:18:10 +0200 From: "Svensson, Lars" To: Kasper Nielsen CC: "urn@ietf.org" Thread-Topic: Re: [urn] Request for urn mrn Thread-Index: AdMiStJlrW7X9hV0QJmV2NsF8iM6KA== Date: Thu, 31 Aug 2017 11:18:10 +0000 Message-ID: <24637769D123E644A105A0AF0E1F92EF010D31E7A1@dnbf-ex1.AD.DDB.DE> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.69.96] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELsWRmVeSWpSXmKPExsXC5Wr/Vbf4w/JIg7dHBS32/FnJZjG1+QOT A5PHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJXxt/cUa8Ey0Yolb7UbGB+IdDFyckgImEgs mvWbtYuRi0NI4AijRMP8d+wQznZGiUfH25m6GNk52AS0JN5ngNSLCKhLPL+6jwXEZhZQlNh0 fwoTiC0MVLFn7V8WiBptiYu/3rJD2HoSa5adYgOxWQRUJf6+3wtm8wp4S3yc0QpmMwrISmzY cJ4ZYqa4xKZn31khbhOQWLIHIi4hICrx8vE/qLiCRPfNeUB7OYDqNSXW79KHOWdK90N2iPGC EidnPmGZwCg8C8nUWQgds5B0zELSsYCRZRUjX3FuuqFeYopeSkqSXkrqJkZIgD/fwdh3yeUQ owAHoxIPb8iuZZFCrIllxZW5hxj9OZiURHkf3l4eKcSXlJ9SmZFYnBFfVJqTWqwkwnvmDVCY Fy6cVJqTrSTHO8lraaSQOFy0uLS4IDM5M7+0OL60KOcQowQHM1Dr+9cgrSmJlVWpRfkQAw8x SnOwKInzvtzHECEkkJ5YkpqdmlqQWgSTjeDgUJLgtXkP1ChYlJqeWpGWmVMCkwbqu58BlBFA lgE7SJG3SBvoISlkCXQ3MXFwHmL04eABOswSZD5vcUFibnFmOtRsYd6050BRHpgo2FxZXkuQ R8VggqhmnmKM59jy+8R3JiGWvPy8VClxXtt3IOeBVGeU5sHdLSXGK2MMdB4/kgTIeCkF3l32 iyKFJJHEUW14xegJjC5h3nkgB/MAsxDCvUK8sW+BgtxQQbBzZXi9Qc4VhYqhm+UDjGcR3liQ Et7iksQSZM8vAonywEShnp8D8TxUENU4qQbGE02ts+3bxSuPSYfYqOd27LTblBZ5nN1zfs+X Reer1LZfX76+/Oyi9qa1f33sry3U//HMo+li4OH3x3j6NQx3Vah5JnsLFW8Nd7P6mvWraCrv +fA0K/nrMwKXMsxQ3c+osKWQ9ebyX3z781SSn+z7xqHOeOfudrnvJzfvvOyeUTyZ8ZrDmdqz SizFGYmGWsxFxYkAnNxwl2UEAAA= Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 11:18:17 -0000 SGkgS2FzcGVyLA0KDQpPbiBUaHVyc2RheSwgQXVndXN0IDMxLCAyMDE3IDEwOjMyIEFNLCB1cm4g W21haWx0bzp1cm4tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthc3BlciBOaWVsc2Vu IHdyb3RlOg0KDQo+IFRoYW5rIHlvdSBmb3IgdGhlIHlvdXIgcG9pbnRlcnMuIEkgc2hvdWxkIGhh dmUgYWRkcmVzc2VkIGJvdGggb2YgeW91cg0KPiBjb25jZXJucyAoc2VlIGlubGluZWQpDQo+IEFu IHVwZGF0ZWQgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXTCoGh0dHBzOi8vcmF3LmdpdGh1YnVzZXJj b250ZW50LmNvbS9kbWEtDQo+IGRrL3d3dy5tcm5yZWdpc3RyeS5vcmcvZ2gtcGFnZXMvaWFuYS1y ZWdpc3RyYXRpb24NCiANCkV2ZW50dWFsbHkgSSBhbHNvIGdvdCBhcm91bmQgdG8gcmV2aWV3IHlv dXIgcmVxdWVzdC4gSXQgbG9va3MgYWxtb3N0IHJlYWR5IHRvIG1lLCBidXQgdGhlcmUgYXJlIHR3 byBhcmVhcyB5b3UgbWlnaHQgd2FudCB0byBsb29rIGludG86DQoNCjEpIEkgY2Fubm90IGZpbmQg YW55dGhpbmcgb24gaG93IHlvdSB3YW50IHRvIGVuc3VyZSB0aGF0IHRoZSBpZGVudGlmaWVycyAo ZS4gZy4gdGhlIFVSTnMpIHJlbWFpbiB1bmlxdWUgYW5kIHRoYXQgdGhleSBhcmUgbm90IGJ5IGFj Y2lkZW50IGFzc2lnbmVkIHR3aWNlLiBJbiB0aGUgIkFzc2lnbm1lbnQiIHNlY3Rpb24geW91IHdy aXRlIHRoYXQgIk1hbmFnZW1lbnQgb2YgT3JnYW5pemF0aW9uLVNwZWNpZmljIE5hbWVzcGFjZSBJ RHMgc2hvdWxkIGJlIGRvbmUgaW4gICAgYWNjb3JkYW5jZSB0byB0aGUgZ3VpZGVsaW5lcyBwcm92 aWRlZCBhdCBodHRwOi8vd3d3Lm1ybnJlZ2lzdHJ5Lm9yZy4iIElmIHRoYXQgZW5vdWdoIHRvIGVu c3VyZSB1bmlxdWVuZXNzIG9mIHRoZSB0aGF0J3MgZmluZSB3aXRoIG1lIGJ1dCBpdCB3b3VsZCBi ZSBoZWxwZnVsIHRvIGhhdmUgdGhhdCBleHBsaWNpdCBpbiB0aGUgcmVnaXN0cmF0aW9uIGRvY3Vt ZW50Lg0KDQoyKSBUaGVyZSBpcyBubyBzZWN0aW9uIG9uIGxleGljYWwgZXF1aXZhbGVuY2UgKGUu IGcuIGhvdyB5b3UgY2FuIGRlY2lkZSBpZiB0d28gY2hhcmFjdGVyIHNlcXVlbmNlcyBhcmUgInRo ZSBzYW1lIiBVUk4pLiBUaGUgIlN5bnRheCIgc2VjdGlvbiBzYXlzOiAiVGhlIG5hbWVzcGFjZSwg 4oCcbXJu4oCdLCBpcyBjYXNlLWluc2Vuc2l0aXZlIGluIHByb2Nlc3NpbmcgYnV0IGlzICBjb252 ZW50aW9uYWxseSB3cml0dGVuIGluIGxvd2VyIGNhc2UiIGJ1dCB0aGF0J3MgYWJvdXQgYWxsLiBT aW5jZSBtdWNoIG9mIHRoZSBoYW5kbGluZyBpcyBkb25lIGluIHN1Yi1uYW1lc3BhY2VzLCBJIHVu ZGVyc3RhbmQgdGhhdCBpdCBjYW4gYmUgZGlmZmljdWx0IHRvIGdpdmUgZXhhY3QgcnVsZXMgaGVy ZSwgYnV0IEkgdGhpbmsgdGhhdCB0aGUgcmVnaXN0cmF0aW9uIGF0IGxlYXN0IHNob3VsZCBzYXkg dGhhdCBmb3IgY29tcGFyaXNvbiwgdGhlIHN0cmluZ3MgInVybiIgYW5kICJtcm4iIG11c3QgYmUg Y29udmVydGVkIHRvIGxvd2VyIGNhc2UuIElmIHlvdSBjYW4gaGF2ZSBzdWNoIGEgcnVsZSBmb3Ig dGhlIE9JRCwgdG9vLCBpdCB3b3VsZCBiZSBleGNlbGxlbnQuIEJleW9uZCB0aGF0LCBJIGd1ZXNz IHRoYXQgaXQgZGVwZW5kcyBvbiB0aGUgaG93IHRoZSBvcmdhbmlzYXRpb24gaWRlbnRpZmllZCBi eSB0aGUgT0lEIGhhbmRsZXMgaXRzIE9TUy4NCg0KQmVzdCwNCg0KTGFycw0KDQoqKiogTGVzZW4u IEjDtnJlbi4gV2lzc2VuLiBEZXV0c2NoZSBOYXRpb25hbGJpYmxpb3RoZWsgKioqIA0KLS0gDQpE ci4gTGFycyBHLiBTdmVuc3Nvbg0KRGV1dHNjaGUgTmF0aW9uYWxiaWJsaW90aGVrDQpJbmZvcm1h dGlvbnNpbmZyYXN0cnVrdHVyDQpBZGlja2VzYWxsZWUgMQ0KNjAzMjIgRnJhbmtmdXJ0IGFtIE1h aW4NClRlbGVmb246ICs0OSA2OSAxNTI1LTE3NTINClRlbGVmYXg6ICs0OSA2OSAxNTI1LTE3OTkN Cm1haWx0bzpsLnN2ZW5zc29uQGRuYi5kZSANCmh0dHA6Ly93d3cuZG5iLmRlDQoNCg0KDQo= From nobody Thu Aug 31 19:20:27 2017 Return-Path: X-Original-To: urn@ietfa.amsl.com Delivered-To: urn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B041D132703 for ; Thu, 31 Aug 2017 19:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=UjPpuBJM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gLx+MT6Z Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrioPJIcew6L for ; Thu, 31 Aug 2017 19:20:22 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060D913304D for ; Thu, 31 Aug 2017 19:20:21 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 2F9E32147A; Thu, 31 Aug 2017 22:20:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute2.internal (MEProxy); Thu, 31 Aug 2017 22:20:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-me-sender:x-me-sender:x-sasl-enc :x-sasl-enc; s=fm1; bh=L4YeWfX8mbdrbSli1GldXXo0fn2HOlL9KTypUrb0P TE=; b=UjPpuBJMg8VjALKZjxIIc4LhL/Fqi7pCiHC/iLzkLDXa2sgbOEqHC+i8J rsTFjIPr/VtmW3R+sJvqVynr6/9pmN+OimHj4vgrVuSifMuS1hHc2jG+Cju0RXq8 5M5FHSfUdZQVmmSm3Cloek3L3Cd2TWzjfOg0QXEjjT/X90R70HisbtOBrcm4N7Tm e1WdlKw0uYploPVjyn46uOM8x8NB4ztjk1FogVhGo9KHe1RAvdak+gGgSqeudmf3 y4Paecs59r9ayBeNsmjC5JQPAAoLhVUtGgJBckqB6aVjcFFI9+MjezbFeL0tF14R cJY8FUyK3R0KfgaH4K2F+CtAUG3fA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=L4YeWfX8mbdrbSli1G ldXXo0fn2HOlL9KTypUrb0PTE=; b=gLx+MT6ZKiJGJWcL8bCS62ZQhronFNIq2i YCiYB3r8gNR1SHrzhndWXJci6pESR1O2OcnjYuzUn47Tu5vbBRTf2WpsXWWk3c9d r6KbQaHzRJZKqX5MTE8oONW3EkYRU/ijqg3/VMGoEKQjUtqEVur66h9Uv+YlqrQf k4LfESEZ/omKQ0VX2ir9loBJja6byvgA7IB6PxFAyc1gUGZc3pvuE+NnRtR3BMga XxqbCJIN4geYSOTsw7X5Z8C94I8AVO2rJF91IhWGQHBc6eDSF4QcjDF+NSXs7Obx N8X+UBMEpFrpOHBkZC44i96QzQXZ/rgIXifMcvL8x8gzWPQaagAg== X-ME-Sender: X-Sasl-enc: OSIhRwiVR2TCJGWjgsFcgA5D0koenmNHE3bO5QAPtFQq 1504232420 Received: from aither.local (unknown [76.25.4.24]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C5B57F018; Thu, 31 Aug 2017 22:20:20 -0400 (EDT) To: Kasper Nielsen References: <03a0480a-6ed4-51ce-5a34-f311c5a1b4c6@stpeter.im> <78d1861b-68f1-2f3d-a586-0566e5b7cd86@stpeter.im> Cc: urn@ietf.org From: Peter Saint-Andre Message-ID: Date: Thu, 31 Aug 2017 20:20:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QE9SLsJV8oGPnVEuwOHtaDw5sNVrEv4b4" Archived-At: Subject: Re: [urn] Request for urn mrn X-BeenThere: urn@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Revisions to URN RFCs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 02:20:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QE9SLsJV8oGPnVEuwOHtaDw5sNVrEv4b4 Content-Type: multipart/mixed; boundary="ih46JtHJTOqoJcFmkIFvukleOfEo2lobl"; protected-headers="v1" From: Peter Saint-Andre To: Kasper Nielsen Cc: urn@ietf.org Message-ID: Subject: Re: [urn] Request for urn mrn References: <03a0480a-6ed4-51ce-5a34-f311c5a1b4c6@stpeter.im> <78d1861b-68f1-2f3d-a586-0566e5b7cd86@stpeter.im> In-Reply-To: --ih46JtHJTOqoJcFmkIFvukleOfEo2lobl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/31/17 2:31 AM, Kasper Nielsen wrote: > Hi Peter, >=20 > Thank you for the your pointers. I should have addressed both of your > concerns (see inlined) > An updated version is available > at https://raw.githubusercontent.com/dma-dk/www.mrnregistry.org/gh-page= s/iana-registration That looks good to me. Thank you for considering my feedback. Peter --ih46JtHJTOqoJcFmkIFvukleOfEo2lobl-- --QE9SLsJV8oGPnVEuwOHtaDw5sNVrEv4b4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJZqMPiAAoJEOoGpJErxa2pBFAP/j/IOQQU7HAYaHq31R81qrGi 34vBNkIlAhyEaddH3W7B2+j75544HxuGv6mwXpRHDu3Qa4WEvcbdUg2qAIWdbGPH TtoBwyzl9v5KKhu0M+8zsygaDk5SJwCWAXpnPCQh26carriM8yVG+9gRMp+DNjs0 pfEnIL7eCG0pv8BZgLyevGHgd4KBjGMcrHB+YQ+kazbdW6ze49/xN/9Xs0WF26wj O1ZG3/uVP8PQFQ/8Y5wz4CComm5+BIU7CwkhpZc0r9hHx1Yh8swDgKHIGtw1Cd/v NAQEghCt2IK/AnVFywQ8fnZvb9DRrFVTdamCzhtfk4Pf+lx+mvz9/RvvDXYnLjq/ 3MFa2wNaeighiUvv6Ez856DupQV19B0ulH+4X/qg84popS+uvq3Oi6ZfzoaLO80d HSX3q+uwjltKLlrRg9Ozn+hIva2MDr2w6bqaT7V/8seBd3LK3647H1ahJGD6KAV+ bwXy/0D+HzzIB4K9HclVudhYRIna3My0moGGhiSkR2z7BGYqzs9gF8oY0VMnlxPo YO66NTS64MP3rCVeBJDCiSgF2rrcM3WAms+Uyz8CwaDXkRq5bhRAz8pAQi4MC0/6 AL8KDSq4ky82cWYjRjtAFlJcYymFm71cq5xXHy33Nn1XLvEd2l61xCogCtA1UiOr j1Ji9M6yMw+HeIxLQ9q/ =z+vK -----END PGP SIGNATURE----- --QE9SLsJV8oGPnVEuwOHtaDw5sNVrEv4b4--