Subject: Pointing to IANA registries

From: Julian Reschke <[email-masked]>
Date: Sat, 17 Apr 2010 12:05:01 +0200

Hi,

I was recently pointed at:

<http://tools.ietf.org/html/rfc5226#section-4.2>:

       1) The name of the registry (or sub-registry) being created and/or
          maintained.  The name will appear on the IANA web page and will
          be referred to in future documents that need to allocate a
          value from the new space.  The full name (and abbreviation, if
          appropriate) should be provided.  It is highly desirable that
          the chosen name not be easily confusable with the name of
          another registry.  When creating a sub-registry, the registry
          that it is a part of should be clearly identified.  When
          referring to an already existing registry, providing a URL to
          precisely identify the registry is helpful.  All such URLs,
          however, will be removed from the RFC prior to final
          publication.  For example, documents could contain: [TO BE
          REMOVED: This registration should take place at the following
          location:  http://www.iana.org/assignments/foobar-registry]

I have to say that I think that this is very very wrong.

Reasons:

1) Cool URIs do not change (<http://www.w3.org/Provider/Style/URI>).

2) If RFCs that define a registry can not carry a link to the registry, 
the reader is actually forced to look up the registry using a search 
engine. I think it's *far* more better to be optimistic and provide the 
actual link, saving the reader one indirection step.

3) Also note: "It is highly desirable that the chosen name not be easily 
confusable with the name of another registry." If that was "MUST be 
unique", instead of this handwaving (sorry...), then we already would 
have the necessary ingredient for a stable URI.

Instead, we should instruct IANA to actually maintain registry URIs they 
have assigned. Note that this does not rule out format changes or 
reorganizations; HTTP redirects exist for a reason.

Best regards, Julian

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 17 Apr 2010 22:53:54 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Julian Reschke
> Sent: Saturday, April 17, 2010 3:05 AM
> To: IETF Discussion
> Subject: Pointing to IANA registries
> 
> Hi,
> 

+1.

IANA (and the IETF) should certainly be capable of maintaining a stable URL.

-d

> Best regards, Julian
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Sun, 18 Apr 2010 23:10:33 +0300

I agree of course that uniqueness should be a MUST.

But while I don't feel strongly about this, I'm actually a little 
reluctant to put permanent URIs to RFC. First of all, from the point of 
the RFC in question the registry use is largely a publication-time 
issue. If I implement RFC XXX all the code points that I need are 
already verbatim in the RFC. Secondly, for some reason I feel 
uncomfortable with placing a permanent pointer to the RFC, while I agree 
that at times it would be helpful. Call me old-fashioned, but I fear 
that something might change in, say, the next 20+ years. By the way, 
current use at least for me does not go through a search engine but 
rather through indirection. I know the IANA registries page, and I 
search the given registry name from that. YMMV.

(That being said, I wonder if some tool magic would display these 
references as pointers, just as already happens for normal references.)

Jari

---

From: John C Klensin <[email-masked]>
Date: Sun, 18 Apr 2010 19:27:52 -0400

If my memory is correct, we've had the discussion about
completely stable registry URLs with IANA a few times, each time
with a result more or less equivalent to your "20+ years"
concern.  That concern is increased by periodic discussions
about the possibility of splitting up components of the IANA
function(s).    However, I wonder whether we might be able to
reach an agreement with them to maintain a stable search format,
e.g., to make something like

  http://protocol-registries.iana.org/?registry="Registry-Name"

work permanently and stably for all protocol parameter
registries.

      john

--On Sunday, April 18, 2010 23:10 +0300 Jari Arkko
<[email-masked]> wrote:

> But while I don't feel strongly about this, I'm actually a
> little reluctant to put permanent URIs to RFC. First of all,
> from the point of the RFC in question the registry use is
> largely a publication-time issue. If I implement RFC XXX all
> the code points that I need are already verbatim in the RFC.
> Secondly, for some reason I feel uncomfortable with placing a
> permanent pointer to the RFC, while I agree that at times it
> would be helpful. Call me old-fashioned, but I fear that
> something might change in, say, the next 20+ years. By the
> way, current use at least for me does not go through a search
> engine but rather through indirection. I know the IANA
> registries page, and I search the given registry name from
> that. YMMV.
> 
> (That being said, I wonder if some tool magic would display
> these references as pointers, just as already happens for
> normal references.)
> 
> Jari
>

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 19 Apr 2010 13:21:48 +1000

Couldn't IANA just implement the "search format" as

  http://www.iana.org/assignments/Registry-Name

and cut out the middle man?

Regarding the "20 year" argument, it seems to imply that one of the following will happen in that time scale:

  1) HTTP will be replaced by another protocol in a non-backwards-compatible fashion, and support in software is dropped (i.e., obviating all existing HTTP URLs), or
  2) URIs themselves will be replaced in a non-backwards-compatible way, and URI-handling software disappears (obviating all URIs, period), or
  3) The domain name system crashes and burns irrevocably, or
  4) IANA loses legal control of iana.org, or
  5) IANA lacks the organisational ability to guarantee stable identifiers for its products, or
  6) No Web serving software is available that gives IANA the ability to control their own URI path components, and it is illegal for them to write it themselves.

If #1 or #2 happens (unlikely), we will have enough warning to revise the RFCs as appropriate, or provide a mapping to the new way of doing things. Not fun, but a reasonably calculated risk, given the shelf life of most IETF products.

If #3 - #6 happens (likelihood is reader-deterimined), we've got far worse problems than some RFCs whose registries can't be easily found -- A STATE THAT I WOULD MENTION WE ARE ALREADY IN TODAY.

*shakes head in disbelief*

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 19 Apr 2010 07:37:43 +0200

On 18.04.2010 22:10, Jari Arkko wrote:
 > ...

Like

   http://www.rfc-editor.org/info/rfcnnnn

or

   http://trustee.ietf.org/license-info

?

If a URI indeed every breaks, the reader can try to find the resource 
with other means. But *until* it breaks, why no avoid the indirection?

> ...

Best regards, Julian

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 20 Apr 2010 12:23:05 +0200

On 19/Apr/10 01:27, John C Klensin wrote:
> [...] I wonder whether we might be able to reach an agreement with them to maintain a stable search format, e.g., to make something like
>
> work permanently and stably for all protocol parameter registries.

+1

Besides the practical aspect of being able to link to a registry from 
the RFC that defines it, that ability would endow the registry with 
the official authority conferred by the definition itself. Currently, 
we have no means to formally ascertain the identity of IANA registries 
w.r.t. their definition. Therefore, they are not more authoritative 
than, say, wikipedia pages.

---

From: [email-masked]
Date: Tue, 20 Apr 2010 17:07:43 -0700 (PDT)

> issue.

No, not really. There are basically two cases and only the second meets your
criteria:

(1) RFCs that define or augment registries.
(2) RFCs that define one or more registry entries.

Case (1) Is hardly a publication-time thing. And even in case (2), depending on
the type of registry there may be a need to check and see if something has been
changed in the entry. In the case of media types, for example,  entries may be
augmented with things like additional security considerations at any time.

> If I implement RFC XXX all the code points that I need are
> already verbatim in the RFC.

That's false in a significant number of cases, see above.

> Secondly, for some reason I feel
> that something might change in, say, the next 20+ years.

That's entirely possible, but as others have pointed out, so what? If you  have
the URL and it works, you save time. If the URL is broken, well, all that does
is reduce you to looking up the registry by name. So you're no worse off than
if the URL wasn't there.

> By the way,

I see no reason to assume that the registries page would be any more stable
than the page for a specific registry, and some reasons to assume it will be
less stable.

Another issue with using the registry index page is that it actually makes
finding some registries hard. Suppose, for example, I want to find the charset
registry. I pull up the page and search for charset. There's only one match,
and it isn't the charset registry:

    IANA Charset MIB    RFC 3808

Now, if you happen to notice the line underneath, saying "See Character Sets",
that might give you a clue what to search for. But that's easy to miss.

Of coruse the issue in this case is the result of a longstanding error on the
page which can (and should) be fixed. (We register charsets, not character
sets; the two are not remotely synonymous.) But that's sort of the point:
Arguing that an index page that's regularly edited by a bunch of different
people and whose contents cannot be checked mechanically in any useful sense is
going to be more stable than a bunch of URLs that are completely trivial to
check mechanically doesn't come close to passing the laugh test.

> references as pointers, just as already happens for normal references.)

This wierd resistance to including useful information in our documents may have
made some small amount of sense in the past when things were less clear. It is
completely silly and totally counterproductive now.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Apr 2010 10:49:11 +0200

>> references as pointers, just as already happens for normal references.)

1925, 6a.

> This wierd resistance to including useful information in our documents 
> may have made some small amount of sense in the past when things were 
> less clear. It is completely silly and totally counterproductive now.

+1

It's 2010 now, lots of people know how to set up the URL scheme for a 
site so URLs can be stable for a long, long time.

Arnt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Apr 2010 13:37:14 -0400

The IETF has in fact already got a URN defined for its documents, it
is just not a locatable identifier at the current time.

I used the URN form of the documents in XKMS to specify the protocol
that a key is being requested for use with. That is one case where you
want to have a fixed identifier that is unambiguous. A URL does not
achieve that.

In theory we could use NAPTR records to disambiguate this form of URN
to a URL. But this is not very satisfactory as NAPTR essentially
introduces a re-ex capability into DNS retrieval. That is a good deal
more power than makes me for one comfortable.

A simpler solution would be to insert the existing URNs into the
documents and leave it to the people who develop tools for converting
them into HTML with links to do something intelligent with the URNs.
Which is not that difficult since the URNs will all be links to IETF
documents in any case.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 21 Apr 2010 07:43:15 -0400

> completely silly and totally counterproductive now.

The weird resistance to providing the information in a useful format
may have made sense some time in the past when people actually used
dot matrix printers.

Not using URIs here is just another silly tradition that the IETF has
acquired and will be insisted on regardless of whether it makes sense
or not.

Like barnacles on a boat, pointless traditions may appear to be
harmless decoration at first.

-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Apr 2010 00:46:57 +0200 (MEST)

Julian Reschke wrote:
>                                                          All such URLs,
>           publication.

It might be worse than that, actually.

When RFC-5746 was recently published, the URL from an extremely useful
informative reference apparently got stripped by the RFC Editor:

draft -03:

   [Ray09]    Ray, M., "Authentication Gap in TLS Renegotiation",
              November 2009, <http://extendedsubset.com/?p=8>.

   [SSLv3]    Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
              Version 3.0", November 1996, <http://www.mozilla.org/
              projects/security/pki/nss/ssl/draft302.txt>.

RFC-5746:

   [Ray09]    Ray, M., "Authentication Gap in TLS Renegotiation",
              November 2009, <http://extendedsubset.com/?p=8>.

   [SSLv3]    Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
              Version 3.0", Work in Progress, November 1996.

But not only the URL was stripped, also the reference was changed
to a "Work in Progress" -- because that document happens to be
still formatted as a long expired I-D (both, the original authors
and TLS WG forgot to ask for publication as an information RFC).

Curiously, I did complain that the I-D marking and expiration was
never removed from this document, pointing out that some folks may
not believe that this is not the real/final SSLv3 spec -- and was
assured by several others that this would not happen.

Looks like it happened to the RFC Editor...  :-(

-Martin

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Apr 2010 07:58:45 +0200

> It might be worse than that, actually.

What you describe is a separate problem, the RFC publishing guidelines 
with respect to URIs.

I totally agree that these need to be fixed. Hopefully the new RSE will 
look into this.

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Thu, 22 Apr 2010 08:59:18 +0300

>              Version 3.0", Work in Progress, November 1996.

Nice, so they took out the link to a draft that has been there forever, but left a link to somebody's blog (even if that someone is the document author)

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Apr 2010 08:33:44 +0200

On 22.04.2010 07:59, Yoav Nir wrote:
>>               November 2009,<http://extendedsubset.com/?p=8>.
>>
>>               Version 3.0", November 1996,<http://www.mozilla.org/
>>               November 2009,<http://extendedsubset.com/?p=8>.
>>

Well, this was approved by the authors during AUTH48, no?

Best regards, Julian

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 22 Apr 2010 10:16:40 +0200

[Replying to Mark, only because he inspired to make the remark]

> If #3 - #6 happens (likelihood is reader-deterimined), we've got far worse problems than some RFCs whose registries can't be easily found -- A STATE THAT I WOULD MENTION WE ARE ALREADY IN TODAY.

Slightly orthogonal to how one approaches long-term stability of references in RFCs there is the issue of the needs of the IETF. It is not completely hypothetical that in a far, far future there will other or even multiple 'vendors' that offer the service[*]. It that context stability is important too. See http://tools.ietf.org/html/draft-iab-iana 

The IAB is close to finalizing that document.

--Olaf

[*] In fact there are two organizations today, see Appendix A of draft-iab-iana 

________________________________________________________ 

Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 22 Apr 2010 11:32:09 +0200

> Well, this was approved by the authors during AUTH48, no?

It is easy to fail to catch a change like that, even if you are an
author.

The RFC Editor modified SASL GS2 (still in RFC Editor's queue) in a
similar way: they replaced a reference to an old I-D with the final RFC,
but the reference to that particular old I-D was intentional.

How about a "IETF48" review period?  The to-be-published RFC is
published again as a new I-D and the entire community can do final
review of the changes introduced during the RFC editing process.

Right now, the I-D approved by the community and the IESG can be
considerably different from what is published as an RFC.  There is a
risk that errors are introduced.  For example, compare SCRAM and GS2
changes:

http://tools.ietf.org/rfcdiff?url2=http://www.rfc-editor.org/authors/rfc5802.txt&url1=draft-ietf-sasl-scram-11
http://tools.ietf.org/rfcdiff?url2=http://www.rfc-editor.org/authors/rfc5801.txt&url1=draft-ietf-sasl-gs2-20

There is a bunch of quite technical changes in there that we really want
to get right, and the review of these modifications have been limited.

/Simon

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 22 Apr 2010 19:46:47 +1000

That's a GREAT document and it makes me feel much better; thanks!

A bit of feedback:

* Section 2.1: "The registry operator maintains public mailing lists as specified in IANA Considerations" -- is this always true? Many of the lists are @ietf.org; do they operate these as well?

* Section 3: "it's" -> "its"

* Does it make sense for new drafts defining registries to talk in terms of PPROs instead of IANA? E.g., should there be a "PPRO Considerations" section?

One other way that I think the IETF needs to improve is in advertising who fills defined roles like this, whether it be the PPRO(s) or the expert reviewers (AFAIK there isn't anywhere you can determine who the experts for a particular registry are). This information needs to be collected in a prominent, well-labeled and stable place (probably on the IETF Web site, at a minimum); it's very confusing for newcomers.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Apr 2010 11:50:12 +0200

On 22.04.2010 11:32, Simon Josefsson wrote:
> Julian Reschke<[email-masked]>  writes:
> ...

I have learned the hard way to repeat all RFC Editor edits in my copy of 
the draft, and only to approve publication when the only difference that 
is left is formatting. I also learned recently that it may be necessary 
to request *another* review step after NROFFing (generation of the 
"final" NROFF format involves manual intervention, so there's a risk new 
errors are introduced).

+1.

> to get right, and the review of these modifications have been limited.

In some cases there's also a considerable amount of fine-tuning 
post-IESG approval (*), both with individual ADs to get them clear their 
DISCUSSes, and with the RFC Editor team. For transparency it would be 
good if this was more visible.

In particular, the idea of attaching "RFC Editor instructions" instead 
of just providing a clean new ID is ... odd.

Best regards, Julian

(*) It's probably always well-intended, but there's a risk of making 
changes after the community has stopped paying attention.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Apr 2010 16:10:01 +0300

Simon,

> review of the changes introduced during the RFC editing process.

I fear that might turn the current 48 day review period into a 48 week 
review period :-)

In any case, the data about what drafts are in AUTH48 is public, and the 
URLs for the to-be-RFCs are guessable... there are a few people outside 
the authors who seem to be checking some drafts this way. I wouldn't 
mind if the latest version from the RFC editor was more conveniently 
accessible.

In short, I think having easier access to the drafts in their various 
states would always be welcome. And input would very much be appreciated 
if something is broken. But I don't think we need more formal periods or 
process after the draft has been approved. We already now have the RFC 
Editor, the authors, the chairs, and the ADs checking each change and 
attempting to catch mistakes and flag non-editorial changes. I know 
there are cases where these checks have failed, but in general, if we 
have more review power in the IETF community I think I would probably 
put it to work in earlier phases for bigger bang for the buck.

Jari

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Apr 2010 12:41:15 -0400

(I've changed the subject line because this topic might interest
members of the community who have long since tuned out the
"Pointers to IANA..." topic.)

Below...

--On Thursday, April 22, 2010 11:50 +0200 Julian Reschke
<[email-masked]> wrote:

>...
> In some cases there's also a considerable amount of
> fine-tuning post-IESG approval (*), both with individual ADs
> to get them clear their DISCUSSes, and with the RFC Editor
> team. For transparency it would be good if this was more
> visible.
> 
> In particular, the idea of attaching "RFC Editor instructions"
> instead of just providing a clean new ID is ... odd.
> 
> Best regards, Julian
> 
> (*) It's probably always well-intended, but there's a risk of
> making changes after the community has stopped paying
> attention.

I think it is safe to say that the topic of what changes are
reasonable to make after all of the Last Call comments are in
without at least issuing a new draft and possibly repeating the
Last Call has been debated on and off for many years.  Similar
arguments have been going on for nearly as long about what
changes are appropriate in AUTH48.  The AUTH48 process has
gradually expanded from "none" (once the IESG or other process
handed a document off to the RFC Editor, its edited form was
published without any intermediate review), to an author-only
review for unintended editorial changes, to including authors,
WG Chairs, and ADs.   One supposes that each new review
opportunity and reviewer has increased quality; it has certainly
increased the length of time it takes to get documents published
after they enter that supposedly 48 hour review.

At one extreme, one would like to be sure there is rough
community consensus for every change.  At the other, there is an
argument for efficiency and for not adding months to the
document production process.  

My own personal view is that we would be better off if there
were no "RFC Editor notes" more substantive than "we have found
the following editorial nits in reviewing the document; please
pay attention to them in editing" and that anything else is
better dealt with by issuing a new I-D and handing the RFC
Editor clean copy.  Generating new I-Ds typically doesn't take
long these days.  Conversely if a delay is needed, I'd rather
see that delay before the document goes to the RFC Editor rather
than in quibbling at AUTH48.

If a new I-D were posted and the AD, WG, or other concerned
parties noticed a problem, they would have the opportunity to
complain.

But I think my view of adding more formal review steps is
similar to Jari's -- adding more review steps or sign-off
activities would cause significant further slow-downs to a
process that is too slow already in order to catch (maybe) a
very small number of significant problems.  I think that would
be a lousy tradeoff; YMMD.

    john

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 22 Apr 2010 13:27:32 -0500

I might drift slightly toward "there should be a published Internet-Draft 
that differs only in formatting-as-an-RFC from what is published as an RFC", 
but would be willing to listen to arguments that this is too strict - but I 
broadly agree with what's said below.

Spencer

---

From: John C Klensin <[email-masked]>
Date: Thu, 22 Apr 2010 15:48:52 -0400

--On Thursday, April 22, 2010 13:27 -0500 Spencer Dawkins
<[email-masked]> wrote:

> I might drift slightly toward "there should be a published
> Internet-Draft that differs only in formatting-as-an-RFC from
> what is published as an RFC", but would be willing to listen
> to arguments that this is too strict - but I broadly agree
> with what's said below.

Unless you have a plan about how to improve the writing skills
of every person who takes on editing responsibilities in the
IETF --and that is intended to very explicitly include a lot of
people who are native, first-language speakers of one of the
languages called "English"-- I think it is in everyone's
interest that the RFC Editor be permitted to edit.   The
real/original purpose of AUTH48 was supposed to be a mechanism
for checks that the editing process did not introduce
substantive technical errors.   Some of us have appreciated the
opportunity to use it to arm-wrestle with RFC Editor staff over
some editing changes, but I'd argue that even that is secondary.

We could make a requirement that a pre-AUTH48 I-D be posted that
reflects the final, edited, content of a soon-to-be-published
RFC prior to switching formatting and boilerplate (note that
difference is _required_ to these days), but I think,
personally, that I'd be against it unless:

	(i) it could somehow be guaranteed to neither increase
	costs nor add delays
	
	(ii) there was some way to ensure that any comments that
	amounted to reopening issues about the substantive
	content of the document or that were _intended_ to delay
	it stayed out of the system and, in particular, off the
	IETF list, and, if such issues came up, that they did
	not turn into opportunities for more process, more
	delays, possible appeals, etc.

The former is impossible if only because it would effectively
require busy authors and editors to do two final reviews --this
one and the AUTH48 one (which does contain the final
boilerplate, etc.).    The reasons why the latter is only
slightly more plausible are left as an exercise.

I think it is lots better, and lots more efficient, to make sure
that the draft that goes to the RFC Editor is correct and
complete substantively and then to expect those who participate
in the AUTH48 review on a given document to exercise
self-discipline about making changes that second-guess the
substance of that approved draft.   Put differently, we would be
well-served by establishing a principle that AUTH48 is for
resolving editorial issues only and not for making substantive
changes of any sort without review by the approving stream.  For
documents in the IETF stream that required Last Call as part of
the approval process, substantive changes after approval ought
to require at least an opportunity for community [re]review.

The one change that, IMO, might be worth making in this regard
would be to explicitly empower the RFC Editor to push back, if
necessary by going back to the community, if, in their judgment,
substantive changes that deviate from the approved document are
requested at AUTH48.  My own view is that they have always had
the ability to do that although I don't believe it has been
exercised since the AUTH48 procedures were created.  I have no
opinion as to whether there are cases in which it should have
been.

     john

---

From: Bob Braden <[email-masked]>
Date: Thu, 22 Apr 2010 13:23:30 -0700

If I may comment from my position as ex-RSE, the RFC Editor's policy for 
at least the past 10 years has been to fuss at authors who ask for 
substantive changes in AUTH48, but then to follow the dictum: "better to 
get it right than get it early". In other words, the RFC Editor did push 
back but generally did not refuse suhstantive changes in AUTH48.

Bob Braden

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 23 Apr 2010 09:12:31 +1200

Bob,

I hope we all agree with that. There can be a difficulty, however,
if the apparently obvious and correct technical fix actually has
implications beyond the obvious that might be picked up by renewed
WG discussion or even a repeat Last Call.

But I think we would be foolish to legislate on this or to mandate
the overhead of a new draft in every case. Let's leave it to the
judgment of the RSE, document authors, shepherd and cognizant AD to
decide if wider discussion is needed in a particular case.

    Brian

---

From: Martin Rex <[email-masked]>
Date: Thu, 22 Apr 2010 23:45:30 +0200 (MEST)

Brian E Carpenter wrote:
> 
>                                There can be a difficulty, however,

Maybe this is much more of a tools than of a procedural issue?
(I personally don't know the AUTH48 and editing process).

If the RFC Editor would provide his edited document back to the
document author in a format that can be diffed to the approved I-D
with a tool like

http://tools.ietf.org/rfcdiff?url1=approved-I-D.txt&url2=RFC-Edited-I-D.txt

then it should be sufficiently easy for the document author to
quickly and easily review the RFC Editor's changes and their impact.

If instead, like it just happened on TLS, you get two blocks of 10 lines
of Text titled "errata" with no further comment and an eyeball comparison
takes 5 minutes to determine that only a closing parenthesis was added,
then this makes reviewing changes pretty difficult.

-Martin

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Apr 2010 00:31:21 -0400

--On Thursday, April 22, 2010 13:23 -0700 Bob Braden
<[email-masked]> wrote:

> If I may comment from my position as ex-RSE, the RFC Editor's
> policy for at least the past 10 years has been to fuss at
> authors who ask for substantive changes in AUTH48, but then to
> follow the dictum: "better to get it right than get it early".
> In other words, the RFC Editor did push back but generally did
> not refuse suhstantive changes in AUTH48.

Bob,

My concern, and what motivated my comment, is that, for
documents that are supposed to represent consensus within some
stream, the author (and even the author + WG Chair + AD) may not
be the final authority on "right". If was not a concern that the
RFC Editor has behaved inappropriately at any time.  So, for
really substantive changes about which there is any doubt, I
would interpret "better to get it right than get it early" as
requiring a trip back to the relevant WG and/or IETF Last Call
for confirmation, not just an author assertion.

I don't think we ought to need specific rules on that subject.
I do think that, if they community's preference agrees with
mine, it would be good for the community to make it clear to
authors, ADs, and the RFC Editor that the expectation is that
they will use discretion and initiate a community [re]review of
proposed changes when appropriate.

best,
    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Apr 2010 00:34:02 -0400

--On Thursday, April 22, 2010 23:45 +0200 Martin Rex
<[email-masked]> wrote:

> document author in a format that can be diffed to the approved
> I-D with a tool like
> 

The RFC Editor has been providing authors with both proposed
final text and a diff (in "HTML diff" form) for some years.
When  the document is submitted in XML form, the RFC Editor has
also been providing the updated XML and asking that additional
changes or corrections be made directly on it.

So I think the problem to which you are proposing a solution was
solved years ago, and solved more or less the way you are
suggesting.

    john

---

From: Jari Arkko <[email-masked]>
Date: Fri, 23 Apr 2010 10:20:43 +0300

John,

> the expectation is that

... and I think that is already happening. We do bring documents back at 
times, either completely bringing them back in the process or confirm a 
change with the working group.

Jari

---

From: John C Klensin <[email-masked]>
Date: Fri, 23 Apr 2010 04:59:58 -0400

--On Friday, April 23, 2010 10:20 +0300 Jari Arkko
<[email-masked]> wrote:

> John,
> 
>> the expectation is that
>> they will use discretion and initiate a community [re]review
>> of proposed changes when appropriate.
>>   
> 
> ... and I think that is already happening. We do bring
> documents back at times, either completely bringing them back
> in the process or confirm a change with the working group.

Yes.   I hope it has been clear that I'm not convinced that we
have a significant problem in this area.  I was responding to
what seemed to be otherwise-unchallenged (except by the two of
us) suggestions that we add a lot of process and reviews to the
document editing and publication cycle.  If there is any issue
at all, I think there are two "virtual knobs" that might need to
be adjusted slightly:

(1) How much change can be made during IESG review by "RFC
Editor notes" versus having new drafts posted so the RFC Editor
gets clean copy and the community gets a chance to look.   I
think that sometimes there have been errors on the side of doing
too much in such notes and that posting a new draft instead is
rarely harmful.  It is, however, clearly a judgment call, not
something about which I think an attempt at firm rules would be
worth the effort.

(2) What kinds of changes can be made at AUTH48 without bringing
documents back at that stage and initiating an additional
review.  Again a judgment call.  Again, I think that some things
that should have been re-reviewed after changes have not been.
I don't have nearly enough data to know whether things have been
pulled back than didn't need it.  But, unlike the "spin a new
I-D before the document goes to the RFC Editor" case, taking a
document back to a WG has real and significant costs, so good
judgment is very important.

I suspect we are in violent agreement.

    john

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 23 Apr 2010 11:17:21 +0200

Bob Braden <[email-masked]> writes:

> If I may comment from my position as ex-RSE, the RFC Editor's policy
> for at least the past 10 years has been to fuss at authors who ask for
> substantive changes in AUTH48, but then to follow the dictum: "better
> to get it right than get it early". In other words, the RFC Editor did
> push back but generally did not refuse suhstantive changes in AUTH48.

This doesn't appear to be what is happening today -- I haven't heard any
"fuss" from the RFC Editor for the GS2 changes.

/Simon

---

From: SM <[email-masked]>
Date: Fri, 23 Apr 2010 14:49:15 -0700

>for confirmation, not just an author assertion.

There is a difference between "right" and getting a document through 
the system.  For the latter, it's a matter of placating those in a 
position of authority.  It would have been good if substantive 
changes are brought to the attention of the WG or posted to this 
mailing list.  if they are not clear-cut.  Naturally, substantive 
changes that would not reflect what was asked during the Last-Call 
would require another Last-Call.

>I don't think we ought to need specific rules on that subject.

The Area Directory could say "notify the community" for such 
cases.  This is the kind of stuff that leads to a rule unfortunately 
as there seems to be a confusion within the IETF about guidance and rules.

>proposed changes when appropriate.

That's the expectation at this end.  I am not suggesting having an "IETF48".

Regards,
-sm

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 26 Apr 2010 18:59:13 +0900

> * Section 2.1: "The registry operator maintains public mailing lists as specified in IANA Considerations" -- is this always true? Many of the lists are @ietf.org; do they operate these as well?

And some are operated by volunteers, with IANA just providing an alias. 
An example is [email-masked], which is hosted by Harald.

Regards,   Martin.

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:[email-masked]