Subject: Re: Revision of RFC 7302

From: Ted Hardie <[email-masked]>
Date: Mon, 2 May 2016 11:02:19 -0700

Thanks for the pointer.  The RFC series allows a document to update a
previous document, as well as along one to obsolete a previous document.
Looking through this, it appears that only the process for identifier
resolution has changed.  Given that, a much shorter document updating RFC
7302 noting the change might be simpler.

Generally speaking this is a stylistic choice, and there is certainly no
requirement to take that path.  But given the general stability
requirements for URNs, highlighting that the only changes are to resolution
might be useful.

regards,

Ted Hardie

On Sat, Apr 30, 2016 at 2:23 PM, Pierre-Anthony Lemieux <[email-masked]>
wrote:

> Good morning/evening,
>
> Please find at the link below a proposed revision of RFC 7302. This
> revision adds support for confidential resolution of EIDR Identifiers
> using HTTP over TLS -- addressing a known limitation of RFC 7302.
>
> https://www.ietf.org/id/draft-pal-eidr-urn-2016-00.txt
>
> Very much looking forward to your comments and feedback. Let me know
> if you need additional information.
>
> Best,
>
> -- Pierre [on behalf of MovieLabs (http://movielabs.com)]
>
>

---

From: Pierre-Anthony Lemieux <[email-masked]>
Date: Mon, 2 May 2016 13:11:13 -0700

Hi Ted,

I appreciate the quick review.

> Looking through this, it appears that only the process for identifier resolution has changed.

Yes.

> Given that, a much shorter document updating RFC 7302 noting the change might be simpler.

This would require the reader to consult two documents -- not sure
this is fatal however.

If the "updates" approach is chosen, would IANA [1] continue to
reference RFC 7302, or would instead reference the updated RFC?

[1] http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

> But given the general stability requirements for URNs, highlighting that the only
> changes are to resolution might be useful.

If the "obsolete" path is chosen, perhaps there is a way to explicitly
highlight the (very limited) changes, beyond the short description in
the abstract?

IMHO it would be ideal to update RFC 7302 in place, since the changes
do not impact identifier semantics, but this is not possible, right?

Best,

-- Pierre

On Mon, May 2, 2016 at 11:02 AM, Ted Hardie <[email-masked]> wrote:
> requirement to take that path.  But given the general stability requirements
> for URNs, highlighting that the only changes are to resolution might be
> useful.
>
> regards,
>
> Ted Hardie
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 May 2016 13:34:21 -0700

On Mon, May 2, 2016 at 1:11 PM, Pierre-Anthony Lemieux <[email-masked]>
wrote:

> resolution has changed.
> It would reference them both; see the dvb entry for an example.

> You can include an appendix with a list of the changes.  That's
non-normative,
but it would likely be consulted by anyone who wanted to simply check on the
relationship between the two.

> That's correct; once issues, RFCs don't change in place.

regard,

Ted Hardie

> requirements

---

From: Pierre-Anthony Lemieux <[email-masked]>
Date: Mon, 2 May 2016 14:40:49 -0700

Hi Ted,

> You can include an appendix with a list of the changes.  That's non-normative,

This sounds like a promising approach since the reader is left with
only one document to consult and it sounds like the IANA entry will
need to be amended regardless.

I plan to revise the I-D accordingly unless I hear objections.

Should the Registration Information/Version be incremented to "2" even
though the identifier semantics/syntax do not change?

Best,

-- Pierre

---

From: Ted Hardie <[email-masked]>
Date: Mon, 2 May 2016 14:57:59 -0700

On Mon, May 2, 2016 at 2:40 PM, Pierre-Anthony Lemieux <[email-masked]>
wrote:

> My best guess would be "no", but others may chime in with other data.  I'd
start
with leaving it at 1, and seeing if a reason emerges to bump it up.

regards,

Ted Hardie

> > On Mon, May 2, 2016 at 1:11 PM, Pierre-Anthony Lemieux <[email-masked]
> >
> > wrote:
> >>
> >> Hi Ted,
> >>
> >> > Given that, a much shorter document updating RFC 7302 noting the
> change
> >> > might be simpler.
> >>
> >> > But given the general stability requirements for URNs, highlighting
> that
> >> > the only

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 2 May 2016 20:12:18 -0400

> relationship between the two.

The trouble I have with this approach is that a reviewer must either 
*trust* that the summary is right, or else must check that there aren't 
other changes. If I am doing a serious review I would never have this 
level of trust.)

Doing the latter depends on the size of the document and how extensive 
the changes (even superficial ones) are.

I would be inclined to first try rfcdiff between the two documents. 
Sometimes this can work if the changes are really minor. But more likely 
there will be enough superficial changes that the diff is a mess and you 
can't easily distinguish the superficial changes from the substantial ones.

	Thanks,
	Paul

---

From: Pierre-Anthony Lemieux <[email-masked]>
Date: Wed, 18 May 2016 07:53:07 -0700

Good morning/evening,

Please find a revised I-D at [1].

[1] https://www.ietf.org/id/draft-pal-eidr-urn-2016-01.txt

This revision is intended to address the comments raised the thread so far:

- the IANA registration version is rolled back to 1 since identifier
semantics and syntax remain unchanged
- changes from previous versions of the specification are listed
(informatively) in Appendix A, with a reminder to readers to use tools
such as rfcdiff for a definitive answer.

Given the limited scope of changes, I intend to submit to IESG by
Friday COB PDT unless further comments are raised.

Thanks again for the review!

Best,

-- Pierre

On Mon, May 2, 2016 at 5:12 PM, Paul Kyzivat <[email-masked]> wrote:
> The trouble I have with this approach is that a reviewer must either *trust*
> that the summary is right, or else must check that there aren't other
> changes. If I am doing a serious review I would never have this level of
> trust.)
>
> Doing the latter depends on the size of the document and how extensive the
> changes (even superficial ones) are.
>