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.  "protocol application" is not typical 
phrasing.  Does it really mean that details are being specified for 
software implementation of Diameter at the server?

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.


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

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.


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


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


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



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


> 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/
-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net