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

[Dave Crocker <[e-mail]>]

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.


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


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


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


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


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

d/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net