Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11

["Wojciech Dec (wdec)" <[e-mail]>]

On 05/08/2012 22:05, "Leaf yeh" <[e-mail]> wrote:

>Quick questions on this draft:
>
>a. question on the occurrence of attributes in the accounting-request
>message
>
><quote > The following table provides a guide to which attributes may be
>found
>in which kinds of packets, and in what quantity. ...
>Request Accept Reject Challenge Accounting    #  Attribute
>                           Request
>0+      0+     0      0         0+      TBA1  Framed-IPv6-Address
>0+      0+     0      0         0+      TBA2  DNS-Server-IPv6-Address
>0+      0+     0      0         0+      TBA3  Route-IPv6-Information
>0+      0+     0      0         0+      TBA4  Delegated-IPv6-Prefix-Pool
>0+      0+     0      0         0+      TBA5  Stateful-IPv6-Address-Pool
></quote>
>
>
>I guess 0+ will never be false for every attribute in every kind of
>radius message. But I doubt whether it is necessary to let the following
>attributes: 
>
>DNS-Server-IPv6-Address
>Delegated-IPv6-Prefix-Pool
>Stateful-IPv6-Address-Pool

These were specifically asked previously to be included as options in the
accounting message.

>
>or 
>
>Route-IPv6-Information
>
>into the message of accounting-request, for the attributes of
>DNS-Server-IPv6-Address, Delegated-IPv6-Prefix-Pool and
>Stateful-IPv6-Address-Pool are not for the specified-user requested for
>accounting, and Route-IPv6-Information might have no relation with the
>accounting.

Given that it is optional, no harm really in having it there.

>
>
>b. comparison question between IPv6 and IPv4 access
>
>We defined the attribute of DNS-Server-IPv6-Address for IPv6 access, but
>never defined DNS-Server-IPv4-Address before for IPv4 access. Do we need
>one more attribute for DNS-Server-IPv4-Address?

Yes, perhaps, but that would be for an IPv4 draft.

> 
>
>Supposed both of the attributes could help the operator to configure the
>DNS addresses for users at their centralized back-stage OSS system, but
>in general speaking, both of them are not user-specified attribute.

Well, they are service related, and users are bound to services. Either
way, it needs to be passed down in the user access response.

Regards,
Woj..

>
>
>Best Regards,
>Leaf
>
>
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of jouni korhonen
>Sent: Saturday, August 04, 2012 4:34 AM
>To: [e-mail]
>Cc: Benoit Claise; [e-mail]
>Subject: [radext] Publication request for RADIUS attributes for IPv6
>Access Networks; draft-ietf-radext-ipv6-access-11
>
>Dear Secretary,
>
>This is a request for publication of draft-ietf-radext-ipv6-access-11 as
>a standards track RFC.
>
>- Jouni
>
>-------------------------------------------------------
>
>(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?
>
>	RADIUS attributes for IPv6 Access Networks is to be published
>	as a Standards Track RFC, which is indicated in the I-D's
>	cover page Intended Status field.
>
>	The RADIUS attributes defined in this I-D are needed for the
>	emerging IPv6 deployments across multiple types of network
>	architectures.
>
>(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
>
>	The I-D defines additional attributes for various IPv6
>	access network deployments (be that fixes or mobile network).
>	The attributes complement already existing set of IPv6 attributes
>	defined in e.g., RFC3162 and RFC4818. Furthermore, the I-D clarifies
>	the use of some existing IPv6 related attributes and the relationship
>	of those to the newly defined attributes.
>
>
>Working Group Summary
>
>	The I-D has been discussed extensively in the RADEXT WG and has
>        reached the overall working group consensus. There was a lengthy
>        discussion regarding the Route-IPv6-Information attribute format
>        and whether it should also contain the rest of the RFC4191 Route
>        Information Option field in addition to the prefix. The WG
>        reached a consensus that the other values are local to router
>        configuration and not retrieved from the RADIUS server.
>
>Document Quality
>
>        There is specific interest from the Broadband Forum to incorporate
>        the attributes defined in this specification into their respective
>        IPv6 standards.
>
>        AAA Doctors have not reviewed the document yet. There is no need
>        for MIB or other doctorate review.
>
>        Once the document goes to IETF LC, a review from V6OPS should be
>        requested.
>
>Personnel
>
>  Who is the Document Shepherd? Who is the Responsible Area
>  Director?
>
>       Jouni Korhonen ([e-mail]) is the document
>       shepherd.
>
>(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.
>
>       The document shepherd has reviewed the document after it has
>       concluded the WGLC. The document shepherd thinks the document
>       is ready for publication and there is no reason to delay the
>       publication anymore, since the attributes defined in this
>       document are needed by the industry.
>
>(4) Does the document Shepherd have any concerns about the depth or
>breadth of the reviews that have been performed?
>
>       No.
>
>(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.
>
>       The document should be reviewed by V6OPS once it goes to
>       IETF LC.
>
>(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.
>
>       The document shepherd has no specific concerns.
>
>(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.
>
>        No IPRs have been declared.
>
>(8) Has an IPR disclosure been filed that references this document?
>If so, summarize any WG discussion and conclusion regarding the IPR
>disclosures.
>
>        No IPRs have been declared.
>
>(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 WG consensus is solid and does not represent only the
>        opinion of few individuals.
>
>(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.
>
>        The document passes IDnits.
>
>(12) Describe how the document meets any required formal review
>criteria, such as the MIB Doctor, media type, and URI type reviews.
>
>        The document does not define MIBs, media types, URIs etc.
>        The data types used in the document comply with RFC6158.
>
>(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?
>
>        No.
>
>(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.
>
>(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.
>
>        No.
>
>(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).
>
>       The document only requests for five new RADIUS attribute types
>       from an existing IANA registry.
>
>(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 registries.
>
>        None.
>
>(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.
>
>        Checked with IDnits and verified against RFC6158 RADIUS
>        design guidelines.
>
>_______________________________________________
>radext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/radext
>_______________________________________________
>radext mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/radext