RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)
RFC 8658

Received changes through RFC Editor sync (created alias RFC 8658, changed title to 'RADIUS Attributes for Softwire Mechanisms Based on Address plus Port (A+P)', changed abstract to 'IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity services over IPv6 native networks during the IPv4/IPv6 coexistence period. DHCPv6 options have been defined to configure clients for Lightweight 4over6, Mapping of Address and Port with Encapsulation (MAP-E), Mapping of Address and Port using Translation (MAP-T) unicast softwire mechanisms, and multicast softwires. However, in many networks, configuration information is stored in an Authentication, Authorization, and Accounting (AAA) server, which utilizes the Remote Authentication Dial In User Service (RADIUS) protocol to provide centralized management for users. When a new transition mechanism is developed, new RADIUS attributes need to be defined correspondingly.

This document defines new RADIUS attributes to carry softwire configuration parameters based on Address plus Port from a AAA server to a Broadband Network Gateway. Both unicast and multicast attributes are covered.', changed pages to 34, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-11-11, changed IESG state to RFC Published)

[Ballot comment]
It might be worth a brief note somewhere about why attributes of this
sort can be included in Accounting-Request packets (and, to a lesser
extent, CoA-Request packets).

Section 1

  Since IPv4-in-IPv6 softwire configuration information is stored in an
  AAA server, and user configuration information is mainly transmitted
  through DHCPv6 between the BNGs and Customer Premises Equipment (CEs,
  a.k.a., CPE), new RADIUS attributes are needed to propagate the
  information from the AAA servers to BNGs.

nit: maybe "from the AAA servers to BNGs so that they can be propagated
to CPE over the existing DHCPv6 options."?

Section 2

Please use the boilerplate text from RFC 8174 (including BCP 14
mention).

Section 3.1

      The Softwire46-Configuration Attribute conveys the configuration
      information for MAP-E, MAP-T, or Lightweight 4over6.  The BNG
      SHALL use the configuration information returned in the RADIUS
      attribute to populate the DHCPv6 Softwire46 Container Option
      defined in Section 5 of [RFC7598].

nit: "Option(s)" seems more appropriate, since that section defines
separate options for MAP-E and MAP-T.

Section 3.1.1.1

Just to double-check my understanding: since this is an "attribute",
it's a top-level container with the 'type' value bearing universal
semantics for all RADIUS packets, as opposed to a "tlv" that appears
within a given attribute and whose 'type' values only have meaning in
the context of that attribute?  But this interpretation doesn't hold up
for (e.g.) Section 3.3.3, which defines an "attribute" but uses a
"TLV-Type" that is in the range of values scoped only to the structures
defined in this document.

Section 3.1.3.2

  There MUST be at least one Softwire46-BR included in each
  Softwire46-MAP-E or Softwire46-Lightweight-4over6.

This seems to be in conflict with Table 2, which says that exactly one
Softwire-BR is included in each MAP-E or Lightweight-4over6 attribute.

Section 3.1.6.1

                        This field that specifies the
        numeric value for the Softwire46 algorithm's excluded
        port range/offset bits (a bits), as per Section 5.1
        of [RFC7597]. Allowed values are between 0 and 15.

nit: "This field that specifies" is redundant; just "This field
specifies" would be  fine.

I'm also not sure I understand the range being between 0 and 15, when we
previously talk about this being an 8-bit value ("right justified").

Section 3.1.6.3

This format seems needlessly confusing.  We encode as an integer (32-bit
unsigned), but then state that this 32-bit integer contains a 16-bit
value, right justified.  And then we only interpret the f irst 'k' bits
on the left of the 16-bit value.  Isn't there a simpler way to encode a
'k' bit value in a 32-bit field?

Section 3.2

          Softwire46 mechanisms are prioritized in the appearance order
          of the in the Softwire46-Priority Attribute.

Do we want to say explicitly that the first-appearing mechanism is most
preferred?

Section 3.3.1

    TLV-Length
      16 octets. The length of asm-prefix64 must be to 96 [RFC8115].

nit(?): I can't parse the grammar here -- what does "must be to" mean?
(Same question for following section.)

Please expand "ASM" on first use.

Section 4

  1.  The CE creates a DHCPv6 Solicit message.  For unicast softwire
      configuration, the message includes an OPTION_REQUEST_OPTION (6)
      with the Softwire46 Container option codes as defined in
      [RFC7598].  [...]

nit: with all of them (the Softwire46 Container option codes)?

  2.  On receipt of the Solicit message, the BNG constructs a RADIUS
      Access-Request message containing a User-Name Attribute (1)
      (containing either a CE MAC address, interface-id or both), a
      User-Password Attribute (2) (with a pre-configured shared
      password as defined in [RFC2865].  The Softwire46-Configuration
      Attribute and/or Softwire46-Multicast Attribute are also included
      (as requested by the client).  The resulting message is sent to
      the AAA server.

Perhaps clarify whether the shared password is shared between BNG/AAA
server, or CE/AAA server?

  6.  The BNG sends a Reply message to the client containing the
      softwire container options enumerated in the ORO.

nit: maybe "DHCPv6 Reply" to match the "DHCPv6 Request" in step (5)?

  The authorization operation could also be done independently, after
  the authentication process.  In this case, steps 1-5 are completed as
  above, then the following steps are performed:

nit: "authorization" or "authorize" do not appear in the previous
procedure anywhere; it would be rhetorically more clear what this
statement refers to if there was explicit mention in the prior
procedure.

  o  In both the configuration message flows described above the
      Message-authenticator (type 80) [RFC2869] SHOULD be used to
      protect both Access-Request and Access-Accept messages.

Why is this SHOULD and not MUST?  Maybe an example of when it would not
be needed would be helpful?
nit: Message-Authenticator has two capital letters.

  o  As specified in [RFC8415], Section 18.2.5, "Creation and
      Transmission of Rebind Messages", if the DHCPv6 server to which
      the DHCPv6 Renew message was sent at time T1 has not responded by
      time T2, the CE (DHCPv6 client) SHOULD enter the Rebind state and
      attempt to contact any available server.  In this situation, a

This seems to just be restating the requiremnets from RFC 8415, in which
case the normative language is not needed...

      secondary BNG receiving the DHCPv6 message MUST initiate a new
      Access-Request message towards the AAA server.  The secondary BNG
      includes the Softwire46-Configuration Attribute in this Access-
      Request message.

... but this MUST does need to use normative language (as it currently
does).

  o  For Lightweight 4over6, the subscriber's binding state needs to be
      synchronized between the clients and the Lightweight AFTR
      (lwAFTR)/BR.  This can be achieved in two ways: static pre-

We have not previously talked about the "subscriber"; is there some
realignment of terminology or earlier definition that would help clarify
how the subscriber relates to the other entities in play?

      configuration of the bindings on both the AAA server and lwAFTR,
      or on-demand whereby the AAA server updates the lwAFTR with the
      subscriber's binding state as it is created or deleted.

(I assume this is done "out of band" from the perspective of this
document.)

Section 6

As the secdir reviewer notes, there are a lot of references here.
That's usually good, avoiding duplication of content/etc., but this text
seems to claim that there is discussion of known security
vulnerabilities in RADIUS discussed in RFCs 2607, 2865, and 2869, and a
quick review of those documents does not find extensive discussion of
such vulnerabilities (and not much in the Security Considerations
section where one might expect to find it).  I think that just those
references may not provide a comprehensive picture of the state of
RADIUS (in)security, and so some additional exposition to tie together
what those documents are saying (including Section references as
appropriate), as well as potential other information, would be in order.
I note that there was some fairly recent discussion of the general state
of RADIUS security in the IESG processing of
draft-ietf-radext-coa-proxy, along the lines of "it basically boils down
to you have to trust your neighbor/contractual arrangement".  I do *not*
think that the three RFCs from 2000 convey that sentiment well, and so
the following paragraph's statement about targetting deployments with a
trust relationship is quite important.  Perhaps we can tweak the writing
a bit so that these two points tie together more clearly.

It may be worth mentioning earlier (in the Introduction?) that this
document only targets deployments with a trusted relationship between
RADIUS client/server (that can use IPsec/TLS as appropriate).

I am also not entirely sure about the "does not introduce any security
issue other than the ones already identified in RADIUS documents",
though admittedly the additional exposure seems quite minimal.
Specifcally, without these RADIUS attributes, DHCPv6 negotiation of
softwires includes in-band protocol flows conveying softwire
configuration information between DHCP client and BNG, but now that
information flows additionally to the AAA server.  The additional
exposure seems minimal, though, since the necessary softwire
configuration information inherently needs to be in *some* central
location, so we're just exchanging one way of configuring the BNG ("out
of band") for another (RADIUS).  The most notable difference would seem
to be that now we have to trust the AAA server to not leak the softwire
configuration details (as opposed to whatever central configuration
server would otherwise be used), but since both are rather inherently
trusted roles, there's not in the general case more attack surface to
worry about.

Section 7.3

If the registry is to be "Option Codes Permitted in the
Softwire46-Priority Attribute", that seems to imply that there are some
option codes *not* permitted.  Where are those option codes enumerated?
(I would have guessed at
https://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2
, but the values don't seem to match up.)  Do we need to add a note
somewhere about future allocations of such option codes needing to
decide whether or not they are permitted in the Softwire46-Priority
Attritube?

[Ballot discuss]
I am really glad to see this document getting published. It has been a long while in the making.

This should be easy to clear but I would like to make sure that the calculation used here to determine TLV lengths is accurate.

* In Sections 3.1.3.3., 3.1.4.1., 3.1.4.2., 3.1.5.2, 3.3.3. the TLV-Length is shown to be 4+length of the contents of the TLV-Data (either the ipv6pref or the ipv4pref). Maybe I am missing something, but I think this should be 2+length of the contents of the TLV-Data instead.

Can you please clarify how you arrived at 4+x instead of 2+x?

[Ballot discuss]
I am really glad to see this document getting published. It has been a long while in the making.

This should be easy to clear but I would like to make sure that the terminology used here to determine TLV lengths is accurate.

* In Sections 3.1.3.3., 3.1.4.1., 3.1.4.2., 3.1.5.2, 3.3.3. the TLV-Length is shown to be 4+length of the contents of the TLV-Data (either the ipv6pref or the ipv4pref). I think this should be 2+length of the contents of the TLV-Data instead.

Can you please clarify how you arrived at 4+x instead of 2+x?

[Ballot comment]
* Section 3.1.3.3.

The datatype for Softwire46-DMR is misspelt.

OLD:
The attribute Softwire46-DMR is of type ip6pref

NEW:
The attribute Softwire46-DMR is of type ipv6pref

* Not a strong opinion but I think RFC7596, RFC7597 and RFC7599 should probably be normative instead of informative.

[Ballot comment]
I have a couple of (mostly) process notes:

(1) A Normative Reference to rfc5176 was added during IETF LC, resulting in a Downref not called out during the LC.  rfc5176 has been used before as a Downref, so I don't think this is a very big deal (nor that a new LC is needed), but I'll leave that decision to the Responsible AD.  [It may be time to update the Downref registry.]

(2) Section 9 (Acknowledgements) includes this text:

  This document was merged with draft-sun-softwire-lw4over6-radext-01
  and draft-wang-radext-multicast-radius-ext-00, thanks to everyone who
  contributed to this document.

But there are no formal References to either document -- an Informative one should me included.  Also, the datatracker page for the document doesn't reflect the relationship.

[Ballot comment]
A few editorial nits:

-- Section 3.  Per “Depending on the deployment scenario …”, this sentence doesn’t parse for me.  I think s/so// would address it.

-- Section 3.1.4.2.  Typo.  s/pecifies/specifies/

[Ballot comment]
This is a fine document. I have one small question:

In 3.1:

      The Softwire46-Configuration Attribute MUST only encapsulate one
      or more of the Softwire46 attributes defined in this document.

This reads to me that only attributes defined in this document can be encapsulated.
Does this make this attribute deliberately non extensible? You have created various IANA registries, which makes me wonder whether this was intentional.

[Ballot comment]
Editorial: In section 4 I would recommend to maybe move the points to consider at the end to its own section, as these contain normative requirements and could be overlooked if one skips over the example.

Also on this specifically:
“As specified in [RFC8415], Section 18.2.5, "Creation and
      Transmission of Rebind Messages", if the DHCPv6 server to which
      the DHCPv6 Renew message was sent at time T1 has not responded by
      time T2, the CE (DHCPv6 client) SHOULD enter the Rebind state and
      attempt to contact any available server.  In this situation, a
      secondary BNG receiving the DHCPv6 message MUST initiate a new
      Access-Request message towards the AAA server. “
If this is normatively specified in RFC8415, I recommend to not use normative language here. However, I didn’t check the wording in RFC8415…

Request for posting confirmation emailed to previous authors: softwire-chairs@ietf.org, Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-softwire-map-radius-23. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the RADIUS Attribute Types registry on the RADIUS Types registry page located at:

https://www.iana.org/assignments/radius-types/

three, new registrations are to be made from the short extended space. The registrations are as follows:

Type: 241.[ TBD-at-Registration ]
Description: Softwire46-Configuration
Data Type: tlv
Reference: [ RFC-to-be Section 3.1]

Type: 241.[ TBD-at-Registration ]
Description: Softwire46-Priority
Data Type: tlv
Reference: [ RFC-to-be Section 3.2]

Type: 241.[ TBD-at-Registration ]
Description: Softwire46-Multicast
Data Type: tlv
Reference: [ RFC-to-be Section 3.3]

Second, a new registry is to be created called the RADIUS Softwire46 Configuration and Multicast Attributes registry.

IANA Question --> Where should this new registry be located? Should it be on the RADIUS Types registry page located at:

https://www.iana.org/assignments/radius-types/

If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry will be managed via Standards Action as defined in RFC 8126.

There are initial registrations in the new registry. Note that all the references in this table point to sections in [ RFC-to-be ]:

Value Description Data Type Reference
----- ----------- --------- ---------
0 Reserved
1 Softwire46-MAP-E tlv Section 3.1.1.1
2 Softwire46-MAP-T tlv Section 3.1.1.2
3 Softwire46-Lightweight-4over6 tlv Section 3.1.1.3
4 Softwire46-Rule tlv Section 3.1.3.1
5 Softwire46-Rule tlv Section 3.1.3.1
6 Softwire46-BR ipv6addr Section 3.1.3.2
7 Softwire46-DMR ipv6prefix Section 3.1.3.3
8 Softwire46-V4V6Bind tlv Section 3.1.3.4
9 Softwire46-PORTPARAMS tlv Section 3.1.3.5
10 Rule-IPv6-Prefix ipv6prefix Section 3.1.4.1
11 Rule-IPv4-Prefix ipv4prefix Section 3.1.4.2
12 EA-Length integer Section 3.1.4.3
13 IPv4-address ipv4addr Section 3.1.5.1
14 Bind-IPv6-Prefix ipv6prefix Section 3.1.5.2
15 PSID-offset integer Section 3.1.6.1
16 PSID-len integer Section 3.1.6.2
17 PSID integer Section 3.1.6.3
18 Softwire64-Option-Code integer Section 3.2.1
19 ASM-Prefix64 ipv6prefix Section 3.3.1
20 SSM-Prefix64 ipv6prefix Section 3.3.2
21 U-Prefix64 ipv6prefix Section 3.3.3

Third, a new registry is to be created called the Option Codes Permitted in the Softwire46-Priority Attribute registry.

IANA Question --> Where should this new registry be located? Should it be on the RADIUS Types registry page located at:

https://www.iana.org/assignments/radius-types/

If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Standards Action as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+-----------------------+--------------------+----------+
|Option Code |Softwire46 Mechanism| Reference|
+-----------------------+--------------------+----------+
|[ TBD-at-Registration ]| MAP-E | RFC7597 |
|[ TBD-at-Registration ]| MAP-T | RFC7599 |
|[ TBD-at-Registration ]| Lightweight 4over6 | RFC7596 |
| 144 | DS-Lite | RFC6519 |
+--------------------------------------------+----------+

The IANA Functions Operator understands that these are the only actions required 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. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-05-31):

From: The IESG
To: IETF-Announce
CC: softwire-chairs@ietf.org, Ian Farrer , ianfarrer@gmx.com, draft-ietf-softwire-map-radius@ietf.org, Yong Cui , softwires@ietf.org, evyncke@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (RADIUS Attributes for Address plus Port (A+P) based Softwire Mechanisms) to Proposed Standard


The IESG has received a request from the Softwires WG (softwire) to consider
the following document: - 'RADIUS Attributes for Address plus Port (A+P)
based Softwire
  Mechanisms'
  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 2019-05-31. 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


  IPv4-over-IPv6 transition mechanisms provide IPv4 connectivity
  services over IPv6 native networks during the IPv4/IPv6 co-existence
  period.  DHCPv6 options have been defined for configuring clients for
  Lightweight 4over6, Mapping of Address and Port with Encapsulation,
  and Mapping of Address and Port using Translation unicast softwire
  mechanisms, and also multicast softwires.  However, in many networks,
  configuration information is stored in an Authentication,
  Authorization, and Accounting server which utilizes the RADIUS
  protocol to provide centralized management for users.  When a new
  transition mechanism is developed, new RADIUS attributes need to be
  defined correspondingly.

  This document defines new RADIUS attributes to carry Address plus
  Port based softwire configuration parameters from an Authentication,
  Authorization, and Accounting server to a Broadband Network Gateway.
  Both unicast and multicast attributes are covered.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ballot/


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

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Dear INT Area Directors and IESG-Secretary -

Please advance in the process and publish this draft from the
Softwires WG. Here is the proto writeup for the draft:
draft-ietf-softwire-mesh-multicast-24

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

Intended status: Standards Track (Indicated on title page)
This document describes new RADIUS TLVs for provisioning IPv4 in IPv6
softwire mechanisms.

(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

DHCPv6 options have already been defined for configuring clients for
IPv4-over-IPv6 softwires. However, in many networks, centralised
configuration information is stored centrally in AAA servers accessed
via RADIUS.  This document defines new RADIUS attributes to carry
Address plus Port based softwire configuration parameters between
the AAA server and the Broadband Network Gateway.
Mappings between RADIUS parameters and the corresponding DHCPv6
options/fields are included so that the BNG can assign them to
DHCPv6 clients. Attributes for configuring both unicast and multicast
softwires are covered.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

No points or controversy has been raised during the authoring or review
process. The author's original scope was just to define RADIUS attributes
for MAP-E & MAP-T based softwire configuration, but by agreement of
the WG, the document scope was extended to cover all standards track
softwire mechanisms (unicast and multicast) that do not currently
have RADIUS configuration defined.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

The draft has been reviewed by Alan DeKok (RADEXT) who
suggested substantial changes to make the document more
readable and in line with recent RADIUS document conventions.
 
Chongfeng Xie from China Telecom made the following statement regarding an
implementation:
"We have done some implementations when we carried out Lightweight4over6
trial in some provinces of China."

Personnel

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

Ian Farrer (Softwire co-chair), is the Document Shepherd.
Eric Vyncke is the Responsible AD.

(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 has been reviewed by the Document Shepherd for
technical content, completeness and language. All raised comments
have been addressed. The document is well written and ready for
publication.

(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 defines new RADIUS attributes and TLVs, and so has been
reviewed by RADEXT (Alan DeKok). Comments received have been addressed
by the authors.


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

N/A.

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

Yes

(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 issues have been filed. All authors have confirmed that
they are not aware of any IPR related to this document.


(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 has been achieved and all of the related active
participants agree on the advancement of this document.

(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

I-D nits reports:
== Line 1245 has weird spacing: '...uration  tlv ...'
The referenced line is as follows:

      241.TBD1    Softwire46-Configuration  tlv        Section 3.1

The above is a table entry and is correctly spaced, so not an error.



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

The docuemt has been reviewed by RADEXT (Alan DeKok). Comments received
have been addressed by the authors.


(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 defines a new IANA registry called "RADIUS Softwire46
Configuration and Multicast Attributes" and provides the initial values for
the registry. The document defines the registry as being 'Standards Action'
according to RFC8126.


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

No registries requiring Expert Review are defined.

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

None (no formal language included in the document).

Dear INT Area Directors and IESG-Secretary -

Please advance in the process and publish this draft from the
Softwires WG. Here is the proto writeup for the draft:
draft-ietf-softwire-mesh-multicast-24

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

Intended status: Standards Track (Indicated on title page)
This document describes new RADIUS TLVs for provisioning IPv4 in IPv6
softwire mechanisms.

(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

DHCPv6 options have already been defined for configuring clients for
IPv4-over-IPv6 softwires. However, in many networks, centralised
configuration information is stored centrally in AAA servers accessed
via RADIUS.  This document defines new RADIUS attributes to carry
Address plus Port based softwire configuration parameters between
the AAA server and the Broadband Network Gateway.
Mappings between RADIUS parameters and the corresponding DHCPv6
options/fields are included so that the BNG can assign them to
DHCPv6 clients. Attributes for configuring both unicast and multicast
softwires are covered.

Working Group Summary

Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

No points or controversy has been raised during the authoring or review
process. The author's original scope was just to define RADIUS attributes
for MAP-E & MAP-T based softwire configuration, but by agreement of
the WG, the document scope was extended to cover all standards track
softwire mechanisms (unicast and multicast) that do not currently
have RADIUS configuration defined.

Document Quality

Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

The draft has been reviewed by Alan DeKok (RADEXT) who
suggested substantial changes to make the document more
readable and in line with recent RADIUS document conventions.
 
Chongfeng Xie from China Telecom made the following statement regarding an
implementation:
"We have done some implementations when we carried out Lightweight4over6
trial in some provinces of China."

Personnel

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

Ian Farrer (Softwire co-chair), is the Document Shepherd.
Eric Vyncke is the Responsible AD.

(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 has been reviewed by the Document Shepherd for
technical content, completeness and language. All raised comments
have been addressed. The document is well written and ready for
publication.

(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 defines new RADIUS attributes and TLVs, and so has been
reviewed by RADEXT (Alan DeKok). Comments received have been addressed
by the authors.


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

N/A.

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

Yes

(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 issues have been filed. All authors have confirmed that
they are not aware of any IPR related to this document.


(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 has been achieved and all of the related active
participants agree on the advancement of this document.

(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

I-D nits reports:
== Line 1245 has weird spacing: '...uration  tlv ...'
The referenced line is as follows:

      241.TBD1    Softwire46-Configuration  tlv        Section 3.1

The above is a table entry and is correctly spaced, so not an error.



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

The docuemt has been reviewed by RADEXT (Alan DeKok). Comments received
have been addressed by the authors.


(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 defines a new IANA registry called "RADIUS Softwire46
Configuration and Multicast Attributes" and provides the initial values for
the registry. The document defines the registry as being 'Standards Action'
according to RFC8126.


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

No registries requiring Expert Review are defined.

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

None (no formal language included in the document).

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: softwire-chairs@ietf.org, Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: Peter Deacon , Mohamed Boucadair , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: softwire-chairs@ietf.org, Peter Deacon , Yu Fu , Tianxiang Li , Sheng Jiang , Chongfeng Xie , Bing Liu

Request for posting confirmation emailed to previous authors: Chongfeng Xie , softwire-chairs@ietf.org, Peter Deacon , Yu Fu , Tianxiang Li , Sheng Jiang , Bing Liu

Request for posting confirmation emailed to previous authors: Chongfeng Xie , softwire-chairs@ietf.org, Peter Deacon , Yu Fu , Tianxiang Li , Sheng Jiang , Bing Liu