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

[Glen Zorn <[e-mail]>]

On 10/01/2012 11:32 PM, Dave Crocker wrote:

> Glen, et al,
 >
 >
 > On 10/1/2012 12:53 AM, Glen Zorn wrote:
 >> On 07/30/2012 11:57 AM, Dave Crocker wrote:
 >>>> 1. Introduction
 >>>>
 >>>> This document describes the Diameter protocol application used
 >>>> for AAA in the Network Access Server (NAS) environment. When
 >>>> combined with the Diameter Base protocol
 >>>> [I-D.ietf-dime-rfc3588bis], Transport Profile [RFC3539], and
 >>>> EAP [RFC4072] specifications, this specification satisfies the
 >>>> NAS-related requirements defined in Aboba, et al. [RFC2989] and
 >>>> Beadles & Mitton [RFC3169].
 >>>
 >>> This assertion raises a dilemma: The cited documents are
 >>> extensive and the topic(s?) complex. There is no way to know what
 >>> details are being referred to, to evaluate the assertion.
 >>
 >> If there were only specific details that were relevant, only
 >> specific sections of the document would be cited. To evaluate the
 >> assertion read the cited documents. All of them. To understand
 >> this document, read and understand the normative references. All
 >> of them.
 >
 > Then that is what should be said in the specification.
 >
 > 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.

>
 >
 >> My understanding, as expressed above, is that in order for a reader
 >> to expect to understand an RFC, they must first have read and
 >> understood the normative references. Is that incorrect?
 >
 > It depends upon what is being drawn from the references, and it is
 > the job of the referring text to explain its use of the reference.
 >
 > 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?

>
 >
 >>> In general, this document's frequent use of "AVP" appears to be
 >>> an oddly syntactic focus. Typical specifications refer to
 >>> attributes, without such frequent, explicit reference to the form
 >>> of their having values. On its own, this point could seem like
 >>> quibbling, but it's part of the reaction I had when reading the
 >>> document, that is seemed less accessible than one would wish for
 >>> a new reader.
 >>
 >> This document is not intended to function as a primer on Diameter,
 >> AAA, or network access systems.
 >
 > Except that the document does provide /some/ primer material:
 >
 > The Diameter base protocol provides the following facilities: ... all
 > data delivered by the protocol is in the form of an AVP
 >
 >
 > 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.

>
 >
 >> 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.

>
 >
 >>>
 >>>
 >>>> by common usage. These are session identification,
 >>>> authentication, authorization, tunneling, and accounting. The
 >>>> authorization AVPs are further broken down by service type.
 >>>
 >>> This document appears to require deep knowledge of The Diameter
 >>> Base Protocol. In reality, I don't think this document can be
 >>> meaningfully read without that knowledge. So this document
 >>> should say that. (The language in the first paragraph of the
 >>> Intro doesn't actually say it.)
 >>
 >> 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?

>
 >
 >>>> 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

    Each Diameter application (e.g., NASREQ, Mobile IP) SHOULD define its
    service-specific AVPs that MUST be present in the Accounting-Request
    message in a section titled "Accounting AVPs".  The application MUST
    assume that the AVPs described in this document will be present in
    all Accounting messages, so only their respective service-specific
    AVPs need to be defined in that section.

    Applications have the option of using one or both of the following
    accounting application extension models:

    Split Accounting Service

       The accounting message will carry the Application Id of the
       Diameter base accounting application (see Section 2.4).
       Accounting messages may be routed to Diameter nodes other than the
       corresponding Diameter application.  These nodes might be
       centralized accounting servers that provide accounting service for
       multiple different Diameter applications.  These nodes MUST
       advertise the Diameter base accounting Application Id during
       capabilities exchange.


    Coupled Accounting Service

       The accounting message will carry the Application Id of the
       application that is using it.  The application itself will process
       the received accounting records or forward them to an accounting
       server.  There is no accounting application advertisement required
       during capabilities exchange, and the accounting messages will be
       routed the same way as any of the other application messages.

    In cases where an application does not define its own accounting
    service, it is preferred that the split accounting model be used.

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).

> in my review I tried to make  clear that I actually had
 > looked in RFC 3588 to resolve questions about the text I was
 > reviewing. Had that succeeded I would have made more specific
 > suggestions for resolving specific issues.
 >
 > So, for the current case, the word 'symbolic' appears in RFC 3588
 > exactly one time, for icmptypes types, very deep in Section 4.3. I
 > did not find it at all helpful for resolving the point I raised here
 > in the review.
 >
 >
 > Just to check, it appears the response to the review ended with this
 > item.

Yes, it was frankly very difficult to find anything that wasn't covered 
by either RTFRFC or a stylistic quibble.  I gave up.

>
 > d/