Re: [Dime] [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09

Dave Crocker <> Sun, 07 October 2012 14:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 210DF21F86D8; Sun, 7 Oct 2012 07:32:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fK5lj0OVRsOR; Sun, 7 Oct 2012 07:32:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B62A121F86D6; Sun, 7 Oct 2012 07:32:48 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id q97EWgwL032054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 7 Oct 2012 07:32:42 -0700
Message-ID: <>
Date: Sun, 07 Oct 2012 07:32:42 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
To: Glen Zorn <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sun, 07 Oct 2012 07:32:45 -0700 (PDT)
Cc:, dime mailing list <>,,, iesg <>
Subject: Re: [Dime] [apps-discuss] Review of: draft-ietf-dime-rfc4005bis-09
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 07 Oct 2012 14:32:50 -0000

On 10/6/2012 11:48 PM, Glen Zorn wrote:
> On 10/01/2012 11:32 PM, Dave Crocker wrote:
>  > When citing references, it is typical (and I believe essential) to
>  > have the citation text be specific about what it being used from the
>  > cited document.
>  >
>  > If what is being used is 'everything', then that's what is said.
>  > Explicitly. Language along the lines of "the current specification
>  > requires completely familiarity with: cite1, cite2, ... is typical.
> I've read a fair number of RFCs (though not all of them, by any means)
> but I do not recall ever having encountered that language.

I don't either.  Specs usually describe the prior normative knowledge 
that is required.

It's not typical to require as much as this one, such as taking 
knowledge of specialized terminology as a given, to the point of not 
declaring it explicitly.

>  > It also is not typical to require the reader to check the references
>  > section to find out what is normative and what isn't. That's why we
>  > have normative vocabulary.
>  >
>  > By requiring the reader to flip back and forth to the references
>  > section, to find out what is normative and what isn't, the
>  > specification is made markedly more cumbersome to use.
> Having ascertained what the normative references are, having read and
> understood them, why would one need to flip back and forth?

The flaw in the question is the "having ascertained".

The usual form of citations is to the specific text that is used at a 
particular point.  When an attorney cites a law, they don't simply say 
"Federal Code" or "California Code".  They cite the specific 
sub-section.  We try to do that for technical specifications, too.

>  > Documents need to define their normative context. There is benefit
>  > in making different documents minimize that context. Obviously
>  > documents that extend a service must rely on the foundation of that
>  > service, but the specification of an extension can be made more or
>  > less complicated by the way divide-and-conquor writing is done.
> Sorry, you've lost me.

I was suggesting benefit in modularization with clean, limited, 
explicitly-defined interfaces, for specifications as well as software.

>  >> The centrality of AVPs to the operation of the Diameter protocol
>  >> might explain the focus of this draft upon them.
>  >
>  > My point was not that the use of attributes was unusual, but that the
>  > terminologic focus on what is essentially a syntactic aspect of the
>  > construct is unusual and, in my view, overly detailed. It's a bit
>  > like spelling out 'period' at the end of every sentence in a
>  > document. Distracting and unnecessary.
>  >
>  > And again, the term isn't defined in this document, in spite of there
>  > being a Terminology section.
> Again, the term is defined in RFC 3588.

Again, the reader of the document doesn't have an explicit way to know 
that, since this is a specialized term and its importation from 3588 
isn't declared.  Specifications that have a default source for 
definitions usually state that explicitly.

>  >> One more time: read the normative references. Understand them.
>  >> All of them.
>  >
>  > Once again: say that. have the text cite them as musts for
>  > background and familiarity.
> OK, let's try a thought experiment: suppose that I had included a
> (redundant) sentence like "The reader is assumed to have read and
> understood all of the documents listed as normative references." in the
> Abstract (& maybe, just to double-down on redundancy, in the
> Introduction, too).  Would you have actually done that as part of your
> review?

I did.

Note, for example, that I made a point of citing some omissions in the 
current document that are not satisfied by knowledge of the underlying 

>  >>>> 1.6. Accounting Model
>  >>>>
>  >>>> It is RECOMMENDED that the coupled accounting model (Section
>  >>>> 9.3 of [I-D.ietf-dime-rfc3588bis]) be used with this
>  >>>> application; therefore, the value of the Acct-Application-Id
>  >>>> AVP in the Accounting-Request (Section 3.10) and
>  >>>> Accounting-Answer (Section 3.9) messages SHOULD be set to one
>  >>>> (1).
>  >>>
>  >>> All of the values in those two sections (except the "271") are
>  >>> symbolic. As such, setting a value to "1" has no obvious
>  >>> meaning.
>  >>>
>  >>> I assume that the issue would be fixed by using symbolic values
>  >>> here?
>  >>
>  >> Or by reading RFC 3588.
>  >
>  > Which part?
> The part that is, in this case, specifically referenced: Section 9.3,
> reproduced below.
> 9.3.  Accounting Application Extension and Requirements
> Since the recommendation is to use the coupled accounting model, the
> value of the Acct-Application-Id AVP should be set to the NASREQ
> Application Id (1).

I assume this is the specific text that you are referring to.

In other words, the current draft is redundantly specifying normative 
detail, after already 'recommending' a controlling normative source. 
This is a good way to encourage divergent normative detail, over time.

That is, the text after te semi-colon should be dropped.


  Dave Crocker
  Brandenburg InternetWorking