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

[Glen Zorn <[e-mail]>]

On 07/30/2012 11:57 AM, Dave Crocker wrote:

> G'day.
 >
 >
 > I have been selected as the Applications Area Directorate reviewer
 > for this draft (for background on appsdir, please see
 >
 >
 > 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
 >
 > Please resolve these comments along with any other Last Call
 > comments you may receive. Please wait for direction from your
 > document shepherd or AD before posting a new version of the draft.
 >
 >
 > Document: draft-ietf-dime-rfc4005bis-09 Title: Diameter
 > Network Access Server Application Reviewer: Dave Crocker Review
 > Date: 18 June 2012
 >
 >
 > Summary:
 >
 > This draft continues problems from the original, at a minimum lacking
 > definitions of terms, citation or definition of notational
 > conventions, apparent normative redundancy with base documents.
 >
 >
 > Major Issues:
 >
 > Active vs. passive voice -- the documents use of passive voice
 > greatly expands the verbiage but also sometimes make it difficult to
 > discern which participating entity is the identified actor.
 >
 > Apparently redundant normative text -- this document appears to
 > contain restatements of normative text from the base Diameter
 > document. This is extremely poor practice, since it invites
 > divergence.
 >
 > Possibly inconsistent use of terminology -- Some of the terms used
 > appear to have equivalent meaning but are not defines; to the extent
 > that they are meant to have different meaning I could not tell what
 > that was.
 >
 > Most significantly, it appears that this document cannot readily be
 > read without very deep familiarity with other Diameter documentation,
 > making this nearly an appendix to those. At the least, the
 > dependencies should be made explicit and detailed. The
 > Introduction's opening paragraph might have been thought to take care
 > of this requirement, but it doesn't, at least not for me. For one
 > thing, it isn't phrase so as to accomplish this. For another, the
 > references are to entire documents, implying -- but not saying --
 > don't read this until you are deeply familiar with all of these other
 > documents.
 >
 > The broader comments appear to apply to the original documents as
 > well as this (and related) current ones. It's likely that making
 > changes accordingly would be a major effort. Whether that's worth
 > the effort isn't something I can judge. I think the revisions would
 > make for tighter, clearer specifications that are probably easier to
 > maintain, but I can't offer an opinion about the benefit this would
 > have in terms of existing implementers or better market adoption,
 > since I'm not familiar with Diameter's degree of market penetration
 > nor the skills of those who have (or might) adopt it.
 >
 >
 >
 > Minor Issues: --
 >
 >
 > Nits: --
 >
 >
 > Detailed comments:
 >
 >
 >> Network Working Group G.
 >> Zorn, Ed. Internet-Draft Network Zen Obsoletes: 4005 (if approved)
 >> May 18, 2012 Intended status: Standards Track Expires: November
 >> 19, 2012
 >>
 >>
 >> Diameter Network Access Server Application
 >> draft-ietf-dime-rfc4005bis-09
 >>
 >> Abstract
 >>
 >> This document describes the Diameter protocol application used for
 >
 > When summarizing the nature or purpose of a document, it is best for
 > the abstract and Introduction to use different words than are in the
 > title. Simply repeating the language of the title does not explain
 > the title. The simple rule should be to assume that the new reader
 > does not automatically understand the meaning of the title.
 >
 > In this case, I also have no idea what "the Diameter protocol
 > application" means here.

RFC 3588.

> "protocol application" is not  typical
 > phrasing. Does it really mean that details are being specified for
 > software implementation of Diameter at the server?

No.

>
 > Typically, the IETF does not specify details about software
 > implementation, nevermind put such a specification on the standards
 > track. (And, yes, I see that this is a -bis document; but that does
 > not change the underlying concern.)
 >
 > What is the motivation for this version of the document? What
 > problems or improvements are being provided? That is, why was it
 > worth the effort to revise the previous document? These are not
 > explained in the bis document.

Section 1.1

>
 >
 >> Authentication, Authorization, and Accounting (AAA) services in
 >> the Network Access Server (NAS) environment; it obsoletes RFC 4005.
 >> When combined with the Diameter Base protocol, Transport Profile,
 >> and Extensible Authentication Protocol specifications, this
 >> application specification satisfies typical network access services
 >> requirements.
 >
 > ...
 >> 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.

> Worse, fixing this
 > deficiency is certain to be a large effort.
 >
 >
 >> First, this document describes the operation of a Diameter NAS
 >> application.
 >
 > What is "a Diameter NAS application"? It does not seem to be
 > explained in this document, nor is there a citation to its
 > definition.
 >
 >
 >> Then it defines the Diameter message Command-Codes. The following
 >> sections list the AVPs used in these messages, grouped
 >
 > AVPs?
 >
 > Define acronyms when they are introduced. Explain their meaning. If
 > the acronym is not destined for regular use within the document,
 > consider replacing the acronym with the full term.
 >
 > If this document is a case of "this document only makes sense when
 > you are intimately familiar with these other documents", then specify
 > those other documents. As the document stands now, it does not
 > formally citte foundational documents, although it does seem to rely
 > on some.

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?

>
 > 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.  As I mentioned above, the "new" reader is 
fully expected to have read and thoroughly understand all of the 
normative references.  That reader would have found that Section 1.1 of 
RFC 3588 (referencing that document since RFC3588bis is still something 
of a moving target) says:

    All data delivered by the protocol is in the form of an AVP. Some of
    these AVP values are used by the Diameter protocol itself, while
    others deliver data associated with particular applications that
    employ Diameter.

The centrality of AVPs to the operation of the Diameter protocol might 
explain the focus of this draft upon them.

>
 >
 >> 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.  I realize that this is a rather tall order for a review, but the 
target audience for this draft is not people who are less than 
intimately familiar with the Diameter base protocol, as well as RADIUS 
ans network access systems in general.

>
 >
 >> 1.1. Changes from RFC 4005
 >>
 >> This document obsoletes RFC 4005 and is not backward compatible
 >> with that document. An overview of some the major changes are
 >> given below.
 >
 > "not backward compatible" automatically raises basic questions about
 > transition from old to new and support during an extended
 > transition. The word 'transition' does not appear in this document.
 >
 >
 >> o All of the material regarding RADIUS/Diameter protocol
 >> interactions has been removed.
 >>
 >> o The Command Code Format (CCF) [I-D.ietf-dime-rfc3588bis] for
 >> the
 >
 > presumably the references to I-Ds need to be changed for RFC
 > publication?

Presumably the RFC Editor will take care of that; this draft is part of 
a rather large cluster that is waiting on the publication of RFC 3588 bis.

>
 >
 >> Accounting-Request and Accounting-Answer messages has been changed
 >> to explicitly require the inclusion of the Acct-Application-Id AVP
 >> and exclude the Vendor-Specific-Application-Id AVP. Normally, this
 >> type of change would also require the allocation of a new command
 >> code and consequently, a new application-id (See Section 1.3.3 of
 >> [I-D.ietf-dime-rfc3588bis]). However, the presence of an instance
 >> of the Acct-Application-Id AVP was required in RFC 4005, as well:
 >>
 >> The ACR message [BASE] is sent by the NAS to report its session
 >> information to a target server downstream.
 >>
 >> Either of Acct-Application-Id or Vendor-Specific-Application-Id
 >> AVPs MUST be present. If the Vendor-Specific-Application-Id
 >> grouped AVP is present, it must have an Acct-Application-Id
 >> inside.
 >>
 >> Thus, though the syntax of the commands has changed, the semantics
 >> have not (with the caveat that the Acct-Application-Id AVP can no
 >> longer be contained in the Vendor-Specific-Application-Id AVP).
 >
 > Sounds oddly disruptive. /Why/ has the syntax been changed? What
 > problem is this solving?
 >
 >>
 >>
 >>
 >>
 >> Zorn Expires November 19, 2012 [Page 5] 
 >> Internet-Draft Diameter NASREQ May 2012
 >>
 >>
 >> o The lists of RADIUS attribute values have been deleted in favor
 >> of references to the appropriate IANA registries.
 >>
 >> o The accounting model to be used is now specified.
 >>
 >> There are many other many miscellaneous fixes that have been
 >> introduced in this document that may not be considered significant
 >> but they are useful nonetheless. Examples are fixes to example IP
 >
 > Useful, but not significant. Interesting concept. Perhaps what is
 > meant is not major or not substantive or not normative?
 >
 >
 >> addresses, addition of clarifying references, etc. All of the
 >> errata previously filed against RFC 4005 have been fixed. A
 >> comprehensive list of changes is not shown here for practical
 >> reasons.
 >>
 >> 1.2. Terminology
 >>
 >> Section 1.2 of the base Diameter specification
 >> [I-D.ietf-dime-rfc3588bis] defines most of the terminology used in
 >> this document. Additionally, the following terms and acronyms are
 >> used in this application:
 >>
 >> NAS (Network Access Server) A device that provides an access
 >> service for a user to a network. The service may be a network
 >> connection or a value-added service such as terminal emulation
 >> [RFC2881].
 >
 > Do not define a term by re-using the words in the term. In this
 > case, even a word as obvious as 'access' could mean a variety of
 > things.
 >
 > Everything is "a network connection". Perhaps the distinction here
 > is between host-level attachment service, versus user-level
 > application service? I can't tell.
 >
 >
 > ...
 >> VPN (Virtual Private Network) In this document, this term is used
 >> to describe access services that use tunneling methods.
 >
 > Since VPN is a well-entrenched, standard term of art, it seems odd --
 > and likely counterproductive -- to imply that use in this document
 > will be non-standard, especially since the definition provided seems
 > on a par with usual definitions, such as wikipedia's.

Fine.

>
 >
 >
 >> 1.4. Advertising Application Support
 >>
 >> Diameter nodes conforming to this specification MUST advertise
 >> support by including the value of one (1) in the
 >> Auth-Application-Id of the Capabilities-Exchange-Request (CER)
 >> message.
 >
 > "this specification' -> this version of specification [???]
 >
 > There is no other reference to the CER message in this document. As
 > such, it's not clear what context for the message is meant. Offhand,
 > it appears that advertising support of the spec is made during a
 > session that implements the spec? This seems at least odd.
 >
 > Since this version of the spec uses a different syntax, it's not
 > likely that any implementation will be speaking a different version
 > of the protocol.
 >
 >
 >> 1.5. Application Identification
 >>
 >> When used in this application, the Auth-Application-Id AVP MUST be
 >> set to the value one (1) in the following messages
 >>
 >> o AA-Request (Section 3.1)
 >>
 >>
 >>
 >>
 >>
 >> Zorn Expires November 19, 2012 [Page 7] 
 >> Internet-Draft Diameter NASREQ May 2012
 >>
 >>
 >> o Re-Auth-Request(Section 3.3)
 >>
 >> o Session-Termination-Request (Section 3.5)
 >>
 >> o Abort-Session-Request (Section 3.7)
 >>
 >> 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.

>
 >
 >> 2. NAS Calls, Ports, and Sessions
 >>
 >> The arrival of a new call or service connection at a port of a
 >
 > "a port"? is this a reference to a transport-level port? That's the
 > only use of the word in the base diameter document.
 >
 > What is a 'call' and what does it mean for it to "arrive", in this
 > context? How is it different from a service connection?
 >
 > The word 'call' in the base document does not have a usage that seems
 > relevant here.
 >
 > Is this document really trying to specify how a host dispatches a
 > server? If so, that means it's discussing implementation details
 > rather than protocol details.
 >
 >
 >> Network Access Server (NAS) starts a Diameter NAS message
 >> exchange.
 >
 > I would guess that the Diameter-level initiation of a NAS message
 > exchange is caused by a Diameter-level message, not the transport
 > connection it triggers. If so, what message would that be?
 >
 >
 >> Information about the call, the identity of the user, and the
 >> user's
 >
 > The base Diameter document does not specify the concept of a 'call'.
 >
 >
 >> authentication information are packaged into a Diameter AA-Request
 >> (AAR) message and sent to a server.
 >>
 >> The server processes the information and responds with a Diameter
 >> AA-
 >
 > "processes the information"? What does this mean, in protocol
 > interoperability terms? I'd expect some statement about the
 > semantics of the processes, relative to the overall exchange.
 >
 >
 >> Answer (AAA) message that contains authorization information for
 >> the NAS, or a failure code (Result-Code AVP). A value of
 >> DIAMETER_MULTI_ROUND_AUTH indicates an additional authentication
 >> exchange, and several AAR and AAA messages may be exchanged until
 >> the transaction completes.
 >
 > "may"?
 >
 > This paragraph appears to be largely redundant with the base Diameter
 > document. Redundancy like this invites divergence over time and
 > ambiguity about which text is controlling.
 >
 >
 >> Depending on the value of the Auth-Request-Type AVP, the Diameter
 >
 > The reader is supposed to guess what values produce what results or
 > actions? I don't see the choices/mappings/whatever documented.
 >
 >
 >
 >> 3.1. AA-Request (AAR) Command
 >>
 >> The AA-Request (AAR), which is indicated by setting the
 >> Command-Code field to 265 and the 'R' bit in the Command Flags
 >> field, is used to request authentication and/or authorization for a
 >> given NAS user.
 >
 > The text provides detail about the internals of the AAR, but doesn't
 > say who sends it.
 >
 > By the way, does the AA- mean Authentication/Authorization? That's
 > implied but not stated. Since the labels are symbolic, mnemonic
 > utility is improved by explaining the basis of the string.
 >
 >
 >> The type of request is identified through the Auth-Request-Type
 >> AVP [I-D.ietf-dime-rfc3588bis] The recommended value for most
 >> situations is AUTHORIZE_AUTHENTICATE.
 >>
 >> If Authentication is requested, the User-Name attribute SHOULD be
 >> present, as well as any additional authentication AVPs that would
 >> carry the password information. A request for authorization
 >> SHOULD only include the information from which the authorization
 >> will be performed, such as the User-Name, Called-Station-Id, or
 >> Calling-
 >
 > This implies that some other sorts of information SHOULD NOT be
 > included, but gives no indication what it is (or why).
 >
 >
 >> Station-Id AVPs. All requests SHOULD contain AVPs uniquely
 >> identifying the source of the call, such as Origin-Host and
 >> NAS-Port.
 >
 > This is a classic and frequent bit of guidance, but lacks any
 > technical substance. The "such as" gives a concrete example, but
 > otherwise the implementer has no idea what will satisfy the SHOULD.
 >
 >
 >> Certain networks MAY use different AVPs for authorization
 >> purposes. A request for authorization will include some AVPs
 >> defined in Section 4.4.
 >
 > Which ones? How is the implementer to know?
 >
 >
 >> It is possible for a single session to be authorized first and
 >> then for an authentication request to follow.
 >
 > What is the implementer to do with this statement?
 >
 >
 >> This AA-Request message MAY be the result of a multi-round
 >> authentication exchange, which occurs when the AA-Answer message
 >> is received with the Result-Code AVP set to
 >> DIAMETER_MULTI_ROUND_AUTH. A subsequent AAR message SHOULD be sent,
 >> with the User-Password AVP that includes the user's response to the
 >> prompt, and MUST include any State AVPs that were present in the
 >> AAA message.
 >>
 >> Message Format
 >
 > What meta-syntax is being used for specifying formats? It isn't ABNF
 > and it isn't cited.
 >
 >
 >
 >> 3.2. AA-Answer (AAA) Command
 >>
 >> The AA-Answer (AAA) message is indicated by setting the
 >> Command-Code field to 265 and clearing the 'R' bit in the Command
 >> Flags field. It
 >
 > Is it really helpful to have each of these say how to set the
 > command, given that it's already listed in a table? Having prose
 > that merely repeats details, rather than explaining them, expands the
 > size of the document but, I believe, actually makes the substance
 > less accessible.
 >
 > Worse, isn't that already done in the base Diameter document?
 >
 > And by the way, the base document defines a command as a
 > request/answer pair. As such neither one, on its own, is a command.
 > That is, this one appears to be the a "command answer", rather than
 > a command. (And yes, that's painfully redundant, given the symbolic
 > name.)
 >
 > I notice that the text often uses the word 'message' to refer to one
 > of these transaction components of a command. That looks like a
 > simple and reasonable choice. Hence, AA-Answer (AAA) Message? This
 > assumes that "command" means a request/response pair.
 >
 >
 >> is sent in response to the AA-Request (AAR) message. If
 >> authorization was requested, a successful response will include
 >> the authorization AVPs appropriate for the service being provided,
 >> as defined in Section 4.4.
 >
 > The "if" seems odd, since the preceding sentence declares the
 > necessary (and obvious) predicate.
 >
 >
 >>
 >> For authentication exchanges requiring more than a single round
 >> trip, the server MUST set the Result-Code AVP to
 >> DIAMETER_MULTI_ROUND_AUTH. An AAA message with this result code MAY
 >> include one Reply-Message or
 >>
 >>
 >>
 >> Zorn Expires November 19, 2012 [Page 12] 
 >> Internet-Draft Diameter NASREQ May 2012
 >>
 >>
 >> more and MAY include zero or one State AVPs.
 >>
 >> If the Reply-Message AVP was present, the network access server
 >> SHOULD send the text to the user's client to display to the user,
 >
 > "was present" suffers the problem of passive sentence form in a
 > protocol specification -- and using past tense adds to the challenge:
 > it isn't clear who does what. Offhand, I would think that it is, in
 > fact, the server that generates replies (and presumably, therefore,
 > chooses to include Reply-Message text.) However the above sentence
 > implies otherwise.
 >
 > Since Diameter is a protocol specification, what does it mean for a
 > server to send text to the user's client? What is the protocol
 > mechanism for doing this?
 >
 >
 >> instructing the client to prompt the user for a response. For
 >> example, this capability can be achieved in PPP via PAP. If the
 >> access client is unable to prompt the user for a new response, it
 >> MUST treat the AA-Answer (AAA) with the Reply-Message AVP as an
 >> error and deny access.
 >
 > The 'it' means the client? The client must deny access?
 >
 >
 >> 3.3. Re-Auth-Request (RAR) Command
 >>
 >> A Diameter server may initiate a re-authentication and/or re-
 >
 > may?
 >
 >
 >> authorization service for a particular session by issuing a
 >> Re-Auth- Request (RAR) message [I-D.ietf-dime-rfc3588bis].
 >
 > Re-authorization "service"? I don't understand what the word means
 > here and didn't find any obvious guidance in the base Diameter
 > document.
 >
 > The additional uses of the word in the next paragraph added to my
 > confusion.
 >
 >
 >> For example, for pre-paid services, the Diameter server that
 >> originally authorized a session may need some confirmation that
 >> the user is still using the services.
 >
 > I have no idea what this is about, what it's basis is or what it
 > means. It seems to presume that the reader knows exactly what is
 > being referred to, as 'pre-paid services' and why it would need some
 > (additional) confirmation.
 >
 >
 >> If a NAS receives an RAR message with Session-Id equal to a
 >> currently active session and a Re-Auth-Type that includes
 >> authentication, it MUST initiate a re-authentication toward the
 >> user, if the service supports this particular feature.
 >
 > and if it doesn't, then what?
 >
 >
 >
 >> 3.4. Re-Auth-Answer (RAA) Command
 >>
 >> The Re-Auth-Answer (RAA) message [I-D.ietf-dime-rfc3588bis] is
 >> sent in response to the RAR. The Result-Code AVP MUST be present
 >> and indicates the disposition of the request.
 >>
 >> A successful RAA transaction MUST be followed by an AAR message.
 >
 > transaction -> command { ? }
 >
 >
 >> 3.5. Session-Termination-Request (STR) Command
 >>
 >> The Session-Termination-Request (STR) message
 >> [I-D.ietf-dime-rfc3588bis] is sent by the NAS to inform the
 >> Diameter Server that an authenticated and/or authorized session is
 >> being terminated.
 >
 > "is being". Again, this is passive voice for a 'command'.
 > Consequently it is not clear whether the requestor has done the
 > termination or is requesting that the server terminate. I assume the
 > latter, but the text leaves this open.
 >
 >
 >> 3.6. Session-Termination-Answer (STA) Command
 >>
 >> The Session-Termination-Answer (STA) message
 >> [I-D.ietf-dime-rfc3588bis] is sent by the Diameter Server to
 >> acknowledge the notification that the session has been terminated.
 >> The Result-Code AVP MUST be present and MAY contain an indication
 >> that an error occurred while the STR was being serviced.
 >>
 >> Upon sending or receiving the STA, the Diameter Server MUST
 >> release all resources for the session indicated by the Session-Id
 >> AVP. Any intermediate server in the Proxy-Chain MAY also release
 >> any resources, if necessary.
 >
 > The server can /receive/ an STA? That appears to be at odds with the
 > first paragraph.
 >
 >
 >> 3.7. Abort-Session-Request (ASR) Command
 >>
 >> The Abort-Session-Request (ASR) message [I-D.ietf-dime-rfc3588bis]
 >> may be sent by any server to the NAS providing session service, to
 >> request that the session identified by the Session-Id be stopped.
 >
 > "by any server" suggests a multi-server model, with a NAS talking to
 > more than one at a time (for a given session...?) As I understand
 > it, NAS/Server sessions are bilateral, not multi-lateral. In
 > addition, the "providing session service" implies that a NAS could be
 > relevant to this text when it is /not/ providing session service.
 > This seems unlikely.
 >
 > So the language here probably should be:
 >
 > MAY be sent by the server to the NAS to request that...
 >
 >
 >
 >> 3.8. Abort-Session-Answer (ASA) Command
 >>
 >> The ASA message [I-D.ietf-dime-rfc3588bis] is sent in response to
 >> the ASR. The Result-Code AVP MUST be present and indicates the
 >> disposition of the request.
 >
 > Who sends to whom?
 >
 >
 >> 3.9. Accounting-Request (ACR) Command
 >>
 >> The ACR message [I-D.ietf-dime-rfc3588bis] is sent by the NAS to
 >> report its session information to a target server downstream.
 >
 > 'downstream'? Is it relayed through intermediaries? What does
 > 'downstream' mean here, beyond simply having a client/server
 > dialogue?
 >
 >
 >> The Acct-Application-Id AVP MUST be present.
 >>
 >> The AVPs listed in the Base protocol specification
 >> [I-D.ietf-dime-rfc3588bis] MUST be assumed to be present, as
 >
 > What does "assumed to be present" mean? What is the point behind
 > "assuming" and does this just mean supported by client and server
 > software? Required to be used in the protocol exchanges? Something
 > else?
 >
 >
 >
 >> 3.10. Accounting-Answer (ACA) Command
 >>
 >> The ACA message [I-D.ietf-dime-rfc3588bis] is used to acknowledge
 >> an
 >
 > is used to acknowledge -> acknowledges
 >
 >
 >> Accounting-Request command. The Accounting-Answer command
 >> contains the same Session-Id as the Request. The same level of
 >> security MUST be applied to both the Accounting-Request and the
 >> corresponding
 >
 > Is this security requirement special to this command or is it
 > univeral? Why?
 >
 >
 >> Accounting-Answer message. For example, if the ACR was protected
 >> using end-to-end security techniques then the corresponding ACA
 >> message MUST be protected in the same way; note, however, that the
 >> definition of such techniques is outside the scope of this
 >> document.
 >>
 >> Only the target Diameter Server or home Diameter Server SHOULD
 >> respond with the Accounting-Answer command.
 >
 > target vs. home. What distinguishes which is to respond? How are
 > they to know?
 >
 >
 >
 >> 4. Diameter NAS Application AVPs
 >>
 >> The following sections define a new derived AVP data format, a set
 >> of
 >
 > "new" will not mean much 10 years from now. RFCs should be written
 > for long-term reading.
 >
 > "derived"? What does this mean?
 >
 >
 >> application-specific AVPs and describe the use of AVPs defined in
 >> other documents by the Diameter NAS Application.
 >>
 >> 4.1. Derived AVP Data Formats
 >>
 >> 4.1.1. QoSFilterRule
 >
 > What is the /purpose/ of this? Presumably it has something to do
 > with filtering, but there's no context for it established.
 >
 >
 >> The QosFilterRule format is derived from the OctetString AVP Base
 >> Format. It uses the ASCII charset. Packets may be marked or
 >> metered based on the following information:
 >>
 >
 > marked vs. metered ?
 >
 >
 >>
 >>
 >> Zorn Expires November 19, 2012 [Page 23] 
 >> Internet-Draft Diameter NASREQ May 2012
 >>
 >>
 >> o Direction (in or out)
 >>
 >> o Source and destination IP address (possibly masked)
 >>
 >> o Protocol
 >>
 >> o Source and destination port (lists or ranges)
 >>
 >> o DSCP values (no mask or range)
 >
 > DSCP?
 >
 >
 >> Rules for the appropriate direction are evaluated in order; the
 >> first
 >
 > "Rules for the appropriate direction"? What does this mean?
 >
 >
 >> matched rule terminates the evaluation. Each packet is evaluated
 >> once. If no rule matches, the packet is treated as best effort.
 >> An access device unable to interpret or apply a QoS rule SHOULD
 >> NOT terminate the session.
 >
 > This appears to be discussing a /set/ of rules, but there's been no
 > discussion of a set. This appears to presume a model that hasn't
 > been introduced.
 >
 >
 >>
 >> QoSFilterRule filters MUST follow the following format:
 >
 > There is more than one filter? Does this mean multiple sets or
 > multiple rules within a single set?
 >
 >
 >> action dir proto from src to dst [options]
 >
 > Where are the /semantics/ of these defined?
 >
 >
 >> where
 >>
 >> action tag Mark packet with a specific DSCP [RFC2474] meter
 >> Meter traffic
 >>
 >> dir The format is as described under IPFilterRule
 >> [I-D.ietf-dime-rfc3588bis]
 >>
 >> proto The format is as described under IPFilterRule
 >> [I-D.ietf-dime-rfc3588bis]
 >>
 >> src and dst The format is as described under IPFilterRule
 >> [I-D.ietf-dime-rfc3588bis]
 >>
 >> The options are described in Section 4.4.9.
 >
 > I didn't see them there.
 >
 >>
 >> The rule syntax is a modified subset of ipfw(8) from FreeBSD, and
 >> the ipfw.c code may provide a useful base for implementations.
 >
 > "may be provided"??? I thought this was a protocol specification
 > which defines its details or cites them formally.
 >
 >
 >> 4.2. NAS Session AVPs
 >>
 >> Diameter reserves the AVP Codes 0 - 255 for RADIUS Attributes that
 >> are implemented in Diameter.
 >>
 >> 4.2.1. Call and Session Information
 >>
 >> This section describes the AVPs specific to Diameter applications
 >> that are needed to identify the call and session context and
 >> status
 >>
 >>
 >>
 >> Zorn Expires November 19, 2012 [Page 24] 
 >> Internet-Draft Diameter NASREQ May 2012
 >>
 >>
 >> information. On a request, this information allows the server to
 >> qualify the session.
 >
 > "on a request"?
 >
 >
 >> These AVPs are used in addition to the following AVPs from the
 >> base protocol specification [I-D.ietf-dime-rfc3588bis]:
 >>
 >> Session-Id Auth-Application-Id Origin-Host Origin-Realm
 >> Auth-Request-Type Termination-Cause
 >>
 >> The following table gives the possible flag values for the session
 >> level AVPs.
 >
 > "session-level"?
 >
 >
 >> +----------+ | AVP Flag | | rules | |----+-----+ |MUST| MUST|
 >> Attribute Name Section Defined | | NOT|
 >> -----------------------------------------|----+-----| NAS-Port
 >> 4.2.2 | M | V | NAS-Port-Id 4.2.3 | M |
 >> V | NAS-Port-Type 4.2.4 | M | V |
 >> Called-Station-Id 4.2.5 | M | V |
 >> Calling-Station-Id 4.2.6 | M | V | Connect-Info
 >> 4.2.7 | M | V | Originating-Line-Info 4.2.8 | M
 >> | V | Reply-Message 4.2.9 | M | V |
 >> -----------------------------------------|----+-----|
 >>
 >> 4.2.2. NAS-Port AVP
 >>
 >> The NAS-Port AVP (AVP Code 5) is of type Unsigned32 and contains
 >> the physical or virtual port number of the NAS which is
 >> authenticating the user. Note that "port" is meant in its sense as
 >> a service connection on the NAS, not as an IP protocol identifier.
 >
 > "service connection on the NAS"?
 >
 > "virtual" port number? This is the only time the term is used, and I
 > don't see it in the base Diameter document and I don't know what it
 > means.
 >
 >
 >> Either the NAS-Port AVP or the NAS-Port-Id AVP (Section 4.2.3)
 >> SHOULD be present in the AA-Request (AAR, Section 3.1) command if
 >> the NAS differentiates among its ports.
 >>
 >> 4.2.3. NAS-Port-Id AVP
 >>
 >> The NAS-Port-Id AVP (AVP Code 87) is of type UTF8String and
 >> consists of ASCII text identifying the port of the NAS
 >> authenticating the
 >>
 >>
 >>
 >> Zorn Expires November 19, 2012 [Page 25] 
 >> Internet-Draft Diameter NASREQ May 2012
 >>
 >>
 >> user. Note that "port" is meant in its sense as a service
 >> connection on the NAS, not as an IP protocol identifier.
 >
 > Although this doesn't distinguish physical from virtual, it does
 > explain the term port. I suspect such explanations should be broken
 > out into an earlier section that provides some framework and
 > terminology. This will avoid having definitions buried deeply and
 > possibly after first use. This can be especially helpful for
 > sections, like this one, that seem likely to be used for reference,
 > and therefore not read sequentially.
 >
 >
 >>
 >> Either the NAS-Port-Id AVP or the NAS-Port AVP (Section 4.2.2)
 >> SHOULD be present in the AA-Request (AAR, Section 3.1) command if
 >> the NAS differentiates among its ports. NAS-Port-Id is intended
 >> for use by NASes that cannot conveniently number their ports.
 >>
 >> 4.2.4. NAS-Port-Type AVP
 >>
 >> The NAS-Port-Type AVP (AVP Code 61) is of type Enumerated and
 >
 > "Enumerated"? Where are the types defined?
 >
 >
 >> 4.2.9. Reply-Message AVP
 >>
 >> The Reply-Message AVP (AVP Code 18) is of type UTF8String and
 >> contains text that MAY be displayed to the user. When used in an
 >> AA-
 >
 > Since I doubt that this specification is intended to cover user
 > interface design -- and hope that it is not -- I think that the
 > normative, semantic point in specification terms is that the strings
 > MUST be created with the intent of displaying them to humans. That
 > is, these are human-consumable strings, not (necessarily)
 > computer-consumable.
 >
 >
 >
 >> 4.4.1. Service-Type AVP
 >>
 >> The Service-Type AVP (AVP Code 6) is of type Enumerated and
 >> contains the type of service the user has requested or the type of
 >> service to be provided. One such AVP MAY be present in an
 >> authentication and/or authorization request or response. A NAS is
 >> not required to implement all of these service types. It MUST
 >> treat unknown or unsupported Service-Types received in a response
 >> as a failure and end the session with a DIAMETER_INVALID_AVP_VALUE
 >> Result-Code.
 >>
 >> When used in a request, the Service-Type AVP SHOULD be considered
 >> a hint to the server that the NAS believes the user would prefer
 >> the kind of service indicated. The server is not required to honor
 >> the
 >
 > A hint is a hint. It would be odd and probably wrong for an
 > implementer to be "required to honor the hint". If they are
 > required, it's not a hint.
 >
 > I believe the simpler and more useful phrasing would simply be:
 >
 > When used in a request, the Service-Type AVP is only a hint to the
 > server that the NAS believes...
 >
 > And then delete the sentence after.
 >
 >> hint. Furthermore, if the service specified by the server is
 >> supported, but not compatible with the current mode of access, the
 >> NAS MUST fail to start the session. The NAS MUST also generate the
 >> appropriate error message(s).
 >
 > Doesn't "MUST fail to start" equate to "MUST NOT start" and wouldn't
 > that be the simpler and more typical phrasing?
 >
 > "appropriate"? What are the criteria and how is the implementer to
 > know?
 >
 >
 >
 >> 4.4.10.5.4. Framed-Pool AVP
 >>
 >> The Framed-Pool AVP (AVP Code 88) is of type OctetString and
 >> contains the name of an assigned address pool that SHOULD be used
 >> to assign an address for the user. If a NAS does not support
 >> multiple address pools, the NAS SHOULD ignore this AVP. Address
 >> pools are usually used for IP addresses but can be used for other
 >> protocols if the NAS supports pools for those protocols.
 >
 > Hmmm. If the NAS does not support multiple address pools and doesn't
 > ignore this AVP, what happens and how will it be interoperable?
 >
 > This seems like something that requires an exact, shared model
 > between the two sides, or else it's merely a notational convenience
 > without interoperability substance. That is, either it's a MAY or a
 > MUST? Or there needs to be some explanation of how to deal with the
 > mismatch between the two sides.
 >
 >
 >
 > //
 >
 > d/