Diameter Network Access Server Application
draft-ietf-dime-rfc4005bis-14

[Ballot comment]

- Thank you for section 8.2! (hence the yes:-)

- As a side-comment, and not related to this draft at all, we
should think about whether it'd be worth a look at the TLS
ciphersuites mentioned in 6733 again, now that PFS
ciphersuites are generally being more favoured. If say,
Diameter/TLS were only starting to be deployed now, it might
be worthwhile thinking about key exfiltration attacks and the
impact of those, in the same way that the UTA WG are doing
for other protocols. That could be done with a small RFC that
updated 6733 and basically copied a new set of preferred PFS
ciphersuites from one of the UTA documents, once those have
firmed up a bit.

Note added by Benoit Claise on Nov 7th 2013:
Despite multiple pings since Feb 2013 to produce a new version (with agreed
changes as far as the doc. shepherd and I can tell), the author has not been
responding. The document shepherd, Lionel Morand, takes over the edit token from
now on. If the author is not responsive during AUTH48, the document shepherd will
also take over.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  This type of RFC request is Proposed Standard in the Standards track.
  Standards Track is indicated in the title page header.
  This document is a bis version an existing Standards Track RFC (RFC 4005)
  and this new version will obsolete the old one if approved.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document obsoletes RFC 4005 and is not backward compatible with
  that document. The main change compared to the RFC 4005 is the removal
  of all of the material related to RADIUS/Diameter protocol interactions,
  which was underspecified and misleading. Moreover, the Command Code Format
  (CCF) for the 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. The accounting model to be
  used with this application is also specified.


Working Group Summary

  -----

  The document spent almost two years as WG document and the
  proposed changes from RFC 4005 were straightforward and roughly
  endorsed by the Working Group. There was no controversy on its
  final content.

Document Quality

  -----

  A number of vendors have indicated interest on implementing
the specification due it correcting several known flaws.

There has been no MIB Doctor or Media Type reviews as those
were not seen relevant for the bis version of the specification.
There has not been explicitly requested expert reviews outside
the WG as we believe most if not all important technical experts
are already represented in the WG and its mailing list. The
document has received multiple reviews while in WGLC.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Lionel Morand (lionel.morand@orange.com) is the Document Shepherd,
  As Dime WG co-chair. Benoit Claise
  Benoit Claise (bclaise@cisco.com) is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have personally reviewed the draft, exchanged with authors to
  clarify some points and concluded that this document was ready for
  publication

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The document shepherd has no concern about quality of the reviews,
  which were performed by key WG members.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  This document does not introduce any material subject to IPR disclosure,
  as the main changes were to remove material or clarify existing part of
  the existing RFC (RFC 4005) that IPR free.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The main objective of this document, i.e. removal of material related
to RADIUS/Diameter protocol interactions in the RFC 4005, was discussed
and agreed in the Dime WG, as well as in the AAA-Doctors directorate.
  The resulting document was quite straightforward without controversial
updates. This document has beneficiated of reviews from key members.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Idnits was run. No action is required.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  I-D.ietf-dime-rfc3588bis has just been approved by IESG and is in
  the RFC Ed Queue.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Any existing document making reference to the RFC 4005 will be
  automatically updated with the reference of this new RFC, as it will
  obsolete the previous one.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document does not introduce protocol extensions or new registries.
  Existing namespaces used in this document are already managed by the IANA.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registry.

  No new registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No check has been performed on this document as ABNF description found
in this document is from the existing RFC already checked.

Note added by Benoit Claise on Nov 7th 2013:
Despite multiple pings since Feb 2013 to produce a new version (with agreed changes as far as the doc. shepherd and I can tell), the author has not been responding. The document shepherd, Lionel Morand, takes over the edit token from now on. If the author is not responsive during AUTH48, the document shepherd will also take over.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  This type of RFC request is Proposed Standard in the Standards track.
  Standards Track is indicated in the title page header.
  This document is a bis version an existing Standards Track RFC (RFC 4005)
  and this new version will obsolete the old one if approved.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document obsoletes RFC 4005 and is not backward compatible with
  that document. The main change compared to the RFC 4005 is the removal
  of all of the material related to RADIUS/Diameter protocol interactions,
  which was underspecified and misleading. Moreover, the Command Code Format
  (CCF) for the 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. The accounting model to be
  used with this application is also specified.


Working Group Summary

  -----

  The document spent almost two years as WG document and the
  proposed changes from RFC 4005 were straightforward and roughly
  endorsed by the Working Group. There was no controversy on its
  final content.

Document Quality

  -----

  A number of vendors have indicated interest on implementing
the specification due it correcting several known flaws.

There has been no MIB Doctor or Media Type reviews as those
were not seen relevant for the bis version of the specification.
There has not been explicitly requested expert reviews outside
the WG as we believe most if not all important technical experts
are already represented in the WG and its mailing list. The
document has received multiple reviews while in WGLC.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Lionel Morand (lionel.morand@orange.com) is the Document Shepherd,
  As Dime WG co-chair. Benoit Claise
  Benoit Claise (bclaise@cisco.com) is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have personally reviewed the draft, exchanged with authors to
  clarify some points and concluded that this document was ready for
  publication

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The document shepherd has no concern about quality of the reviews,
  which were performed by key WG members.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  This document does not introduce any material subject to IPR disclosure,
  as the main changes were to remove material or clarify existing part of
  the existing RFC (RFC 4005) that IPR free.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The main objective of this document, i.e. removal of material related
to RADIUS/Diameter protocol interactions in the RFC 4005, was discussed
and agreed in the Dime WG, as well as in the AAA-Doctors directorate.
  The resulting document was quite straightforward without controversial
updates. This document has beneficiated of reviews from key members.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Idnits was run. No action is required.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  I-D.ietf-dime-rfc3588bis has just been approved by IESG and is in
  the RFC Ed Queue.


(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in the
Last Call procedure.

  No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Any existing document making reference to the RFC 4005 will be
  automatically updated with the reference of this new RFC, as it will
  obsolete the previous one.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document does not introduce protocol extensions or new registries.
  Existing namespaces used in this document are already managed by the IANA.
 
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registry.

  No new registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No check has been performed on this document as ABNF description found
in this document is from the existing RFC already checked.

IANA has reviewed draft-ietf-dime-rfc4005bis-11 and has the following comments:

IANA understands that, upon approval of this document, there are
a series of seven reference updates that need to be made.

First, in the IANA AAA AVP Codes Registry, located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-
parameters-1

the references that currently point to RFC 4005 should be changed to
[ RFC-to-be ].

Second, in the IANA AAA AVP Specific Values registry located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-
parameters-2

the references that currently point to RFC 4005 should be changed to
[ RFC-to-be ].

Third, in the IANA AAA Application IDs Registry, located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-
parameters-1

the references that currently point to RFC 4005 should be changed to
[ RFC-to-be ].

Fourth, in the IANA AAA Command Codes Registry, located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#command-code-
rules

the references that currently point to RFC 4005 should be changed to
[ RFC-to-be ].

Fifth, in the IANA Radius Attribute Values Registry, located at:

http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-3

the references that currently point to RFC 4005 should be changed to
[ RFC-to-be ].

Sixth, on the IANA Matrix, at http://www.iana.org/protocols - the references
for those registries will be updated.

Seventh, in the IANA AAA Application IDs Registry, located at:

http://www.iana.org/assignments/aaa-parameters/aaa-parameters.xml#aaa-
parameters-1

the reference for the value "1" im the "Application IDs" subregistry
will be changed to [ RFC-to-be ].

IANA understands that these are the only IANA actions that need to be
completed upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Diameter Network Access Server Application) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Network Access Server Application'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-09-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the Diameter protocol application used for
  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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-rfc4005bis/ballot/


No IPR declarations have been submitted directly on this I-D.

***************************
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

    This type of RFC request is Proposed Standard in the Standards track.

  Standards Track is indicated in the title page header.

This document is a bis version an existing Standards Track RFC (RFC
4005) and this new version will obsolete the old one if approved.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document obsoletes RFC 4005 and is not backward compatible with that document. The main change compared to the RFC 4005 is the removal of all of the material related to RADIUS/Diameter protocol interactions,  which was underspecified and misleading. Moreover, the Command Code
Format (CCF) for the 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. The accounting model to be used with this application is also specified.

Working Group Summary

  -----
The document spent almost two years as WG document and the
proposed changes from RFC 4005 were straightforward and roughly
endorsed by the Working Group. There was no controversy on its
final content.

Document Quality

  -----
A number of vendors have indicated interest on implementing
the specification due it correcting several known flaws.

There has been no MIB Doctor or Media Type reviews as those
were not seen relevant for the bis version of the specification.
There has not been explicitly requested expert reviews outside
the WG as we believe most if not all important technical experts
are already represented in the WG and its mailing list. The
document has received multiple reviews while in WGLC.

Personnel

Who is the Document Shepherd? Who is the Responsible Area
Director?

  Lionel Morand (lionel.morand@orange.com) is the Document Shepherd,
As Dime WG co-chair.
Benoit Claise (bclaise@cisco.com) is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

I have personally reviewed the draft, exchanged with authors to
clarify some points and concluded that this document was ready for
publication

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The document shepherd has no concern about quality of the reviews,  which were performed by key WG members.


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No concern.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  This document does not introduce any material subject to IPR
disclosure,

  as the main changes were to remove material or clarify existing part
of the existing RFC (RFC 4005) that IPR free.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The main objective of this document, i.e. removal of material related
to RADIUS/Diameter protocol interactions in the RFC 4005, was discussed
and agreed in the Dime WG, as well as in the AAA-Doctors directorate.
  The resulting document was quite straightforward without controversial
updates. This document has beneficiated of reviews from key members.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  Idnits was run. No action is required.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  I-D.ietf-dime-rfc3588bis has just been approved by IESG and is in
  the RFC Ed Queue.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  Any existing document making reference to the RFC 4005 will be
  automatically updated with the reference of this new RFC, as it will
  obsolete the previous one.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  This document does not introduce protocol extensions or new
registries.

  Existing namespaces used in this document are already managed by the
IANA.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registry.

  No new registry.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No check has been performed on this document as ABNF description found
in this document is from the existing RFC already checked.