Subject: Gen-ART LC Review of draft-ietf-eai-rfc5721bis-07,

From: Ben Campbell <[email-masked]>
Date: Tue, 18 Sep 2012 20:45:19 -0500

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

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq> .

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

Document:  draft-ietf-eai-rfc5721bis-07
Reviewer: Ben Campbell
Review Date: 2012-09-18
IETF LC End Date: 2012-09-20

Summary:   The draft is mostly ready for publication as a draft standard. I have a few editorial comments that should be considered prior to publication.

Major issues: None

Minor issues: 

Nits/editorial comments:

-- IDNits has some complaints; please check.

-- The abstract should mention that this obsoletes 5721

-- section 2.1, 2nd paragraph: "The character encoding format of maildrops may not be UTF-8 or ASCII."

I'm confused by this sentence, as it seems to say that the format can't be UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the draft.  Do you mean to say that it may be some format other than those?

-- same paragraph : "The UTF8 command MAY fail."

Under what circumstances? (this seems sort of tacked onto the paragraph--does it belong there?)

-- 2.1, 4th paragraph: "...need not be accurate, but it is preferable if they were."

Not preferable enough for a SHOULD? (Note that the previous sentence used SHOULD for reporting actual message size counts)

-- section 7, 3rd paragraph: "It is possible for a man-in-the-middle attacker to insert a LANG command in the command stream, thus making protocol-level diagnostic responses unintelligible to the user."

This seems a bit unnecessary to call out, given that a MiTM could just change the diagnostic responses into Klingon even in the absence of the LANG command. It's at least worth mentioning that the LANG command really doesn't make this issue worse than it already was.

---

From: Pete Resnick <[email-masked]>
Date: Fri, 21 Sep 2012 10:23:23 -0500

> -- IDNits has some complaints; please check.

They were checked.

> -- The abstract should mention that this obsoletes 5721

It does.

> I'm confused by this sentence, as it seems to say that the format can't be UTF-8 or ASCII, which otherwise seem to be the only ones contemplated by the draft.  Do you mean to say that it may be som…

Yes, I believe that is an editing error. I will confirm and put in an 
RFC Editor note.

> Under what circumstances? (this seems sort of tacked onto the paragraph--does it belong there?)

AFAICT, it is simply a warning to client writers that the server may 
(for whatever reasons under whatever circumstances) send back an -ERR 
response to the command, even if it advertises the capability. Seems 
appropriate.

> Not preferable enough for a SHOULD? (Note that the previous sentence used SHOULD for reporting actual message size counts)

There is no interoperability impact regarding sizes in STAT and 
free-form text (unlike LIST), so SHOULD is inappropriate.

> This seems a bit unnecessary to call out, given that a MiTM could just change the diagnostic responses into Klingon even in the absence of the LANG command. It's at least worth mentioning that the…

Taken under advisement.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: Pete Resnick <[email-masked]>
Date: Fri, 21 Sep 2012 10:44:18 -0500

>> -- The abstract should mention that this obsoletes 5721

Sorry. You said abstract, not intro. Got it.

pr

---

From: Glen Zorn <[email-masked]>
Date: Fri, 21 Sep 2012 22:52:33 +0700

>>> -- The abstract should mention that this obsoletes 5721

Why?  There is a statement in the header, 10 lines above the abstract, 
that says "Obsoletes: 5721 (if approved)".

---

From: Pete Resnick <[email-masked]>
Date: Fri, 21 Sep 2012 11:14:19 -0500

[Changing the subject and removing GenArt and the document authors/chairs]

> that says "Obsoletes: 5721 (if approved)".

The IESG put this into the nits check before my time. The Last Call and 
publication announcements normally contain only the abstract, not the 
metadata above, and I believe the thinking was that if you are a person 
who scans through those announcements, you probably would (and would 
want to) take notice of documents that purport to obsolete or update 
document that you recognize. We could probably change the tool to add 
the metadata to the announcements, but apparently quite a few people 
read "abstracting" services that grab the abstracts of newly published 
documents. Not much we can do for them.

It's certainly useful to some folks. Necessary? (*Shrug*) Not enough 
wasted bits for me to care one way or the other.

pr

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Sep 2012 11:15:12 -0500

On Sep 21, 2012, at 10:52 AM, Glen Zorn <[email-masked]> wrote:

> Why?  There is a statement in the header, 10 lines above the abstract, that says "Obsoletes: 5721 (if approved)".

The abstract is sometimes displayed without the rest of the document, for example, in new RFC announcements.

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Sep 2012 09:21:57 -0700

On 9/21/2012 8:23 AM, Pete Resnick wrote:
> On 9/18/12 8:45 PM, Ben Campbell wrote:abstract should mention that this obsoletes 5721
>
> It does.

Stylistic point:  RFCs last a long time.  Including ephemeral 
information can be distracting, especially in the Abstract.  5 and 10 
years from now, the fact that this RFC replaces another will be 
essentially irrelevant, but the Abstract will still be spending valuable 
space citing the fact.

It is better to have the document written as standing on its own, rather 
than focus on its relationship to its predecessors, except perhaps in 
isolated 'background' or 'history' discussions (and, of course, the 
Updates field...)

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Sep 2012 13:03:31 -0500

Thanks for the response!

On Sep 21, 2012, at 10:23 AM, Pete Resnick <[email-masked]> wrote:

[...]

> AFAICT, it is simply a warning to client writers that the server may (for whatever reasons under whatever circumstances) send back an -ERR response to the command, even if it advertises the capability. Seems appropriate.
> 
> There is no interoperability impact regarding sizes in STAT and free-form text (unlike LIST), so SHOULD is inappropriate.
> 

Okay.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 21 Sep 2012 15:25:24 -0500

On Sep 21, 2012, at 11:14 AM, Pete Resnick <[email-masked]> wrote:

> The IESG put this into the nits check before my time. The Last Call and publication announcements normally contain only the abstract, not the metadata above, and I believe the thinking was that if you are a person who scans through those announcements, you probably would (and would want to) take notice of documents that purport to obsolete or update document that you recognize. We could probably change the tool to add the metadata to the announcements, but apparently quite a few people read "abstracting" services that grab the abstracts of newly published documents. Not much we can do for them.
> 
> It's certainly useful to some folks. Necessary? (*Shrug*) Not enough wasted bits for me to care one way or the other.
> 

As a Gen-ART reviewer, I called it out for exactly the reasons Pete mentions, and care about the same amount :-) But putting it there seems to hurt nothing, and maybe help just a little bit in some cases.

---

From: [email-masked]
Date: Fri, 21 Sep 2012 14:04:03 -0700 (PDT)

> As a Gen-ART reviewer, I called it out for exactly the reasons Pete mentions,
> and care about the same amount :-) But putting it there seems to hurt nothing,
> and maybe help just a little bit in some cases.

That's your opinion. Others, myself included, strongly disagree.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Sep 2012 17:16:22 -0400

--On Friday, September 21, 2012 15:25 -0500 Ben Campbell
<[email-masked]> wrote:

>> It's certainly useful to some folks. Necessary? (*Shrug*) Not
>> enough wasted bits for me to care one way or the other.
>> 
> 
> As a Gen-ART reviewer, I called it out for exactly the reasons
> Pete mentions, and care about the same amount :-) But putting
> it there seems to hurt nothing, and maybe help just a little
> bit in some cases.

Ben,

An observation as an individual rather than in any EAI capacity:

The scholarly publication and information science fields have
generally-accepted criteria for abstracts.  The devil is in the
details, of course, but, in general,  structural comments or
comments about relationships to earlier works are included only
if they are essential to understanding what the current document
is about.   I note that this comment is consistent with Dave
Crocker's earlier one, although I'd go a bit further.

There is an additional issue, which is that the RFC Editor
normally requires that citations of RFCs be treated as citations
and referenced but, consistent with those generally-accepted
practices, prohibits citations from abstracts.  Ending up with
"this obsoletes RFC NNNN" in an abstract sneaks by that
combination of rules, but borders on the unprofessional.

There are documents for which "this obsoletes that" really does
belong in the abstract because it is essential for understanding
the role of the document but in almost all cases, "that" won't
be an RFC reference but a topical one.  As an example in the RFC
series that might mean that the abstract for RFC 5378 might more
reasonably have said "This memo is effective XXXX and supercedes
all policies about rights in contributions prior to that date".

To the extent to which the issue is metadata information in
announcements, let's fix the announcement templates, not
introduce kludges to get around them.   The argument that there
is some other information that people might want to know that
doesn't appear when the abstract alone is posted is, by
contrast, completely bogus: people might want to know the date
of publication, the author's names, etc., but no one has
suggested that they be included in the abstract.

On the other hand, I'm a strong advocate of requiring text in
the document -- in the Introduction or a specially-identified
section-- that describes the relationship of the current
document to anything it updates, obsoletes, modifies,
criticizes, or is otherwise directly related to.  That is
important explanation, not a few words in the abstract that
partially identify a relationship without even hinting about
what it is about substantively.

FWIW, I believe this is ultimately an RFC Style issue and that
the community should expect guidance on it from the RFC Editor.  

Finally, as I have previously pointed out to the IESG, the
"requirement" for that sentence in the abstract made it into
IDnits without anything resembling a consensus call or
consultation of the RFC Editor.  While I'd rather see the
substantive issue addressed and have tried to do so above, we do
have rules about community consensus before requirements are
imposed and this hasn't made that test as a requirement.  If the
nits checker wanted to say "are you sure that the relationship
between this document and any predecessors are not significant
enough to justify inclusion in the abstract" I think that would
be fine, especially if it also generated a question of "are you
sure that the relationship between this document and any
predecessors are significant enough to justify putting text in
the abstract (and possibly cluttering it)" when the citation
does appear.  But, as a requirement, it is basically bogus
absent either a style requirement from the RFC Editor or a
consensus call.

   john

---

From: Glen Zorn <[email-masked]>
Date: Sat, 22 Sep 2012 10:37:32 +0700

On 09/22/2012 03:25 AM, Ben Campbell wrote:

...

 >>> Why? There is a statement in the header, 10 lines above the
 >>> abstract, that says "Obsoletes: 5721 (if approved)".
 >>
 >> The IESG put this into the nits check before my time. The Last Call
 >> and publication announcements normally contain only the abstract,
 >> not the metadata above, and I believe the thinking was that if you
 >> are a person who scans through those announcements, you probably
 >> would (and would want to) take notice of documents that purport to
 >> obsolete or update document that you recognize. We could probably
 >> change the tool to add the metadata to the announcements, but
 >> apparently quite a few people read "abstracting" services that grab
 >> the abstracts of newly published documents. Not much we can do for
 >> them.
 >>
 > As a Gen-ART reviewer, I called it out for exactly the reasons Pete
 > mentions, and care about the same amount :-) But putting it there
 > seems to hurt nothing, and maybe help just a little bit in some
 > cases.

Hanging fuzzy dice from a car mirror doesn't hurt anything and might 
attract people who otherwise would pay no attention to the vehicle, but 
that doesn't mean that there should be a law requiring everyone to 
display said dice.