Re: [Softwires] intdir Telechat Review requested: draft-ietf-softwire-map-radius

[Bernie Volz (volz)]

I am an assigned INT directorate reviewer for 
draft-ietf-softwire-map-radius-22. These comments were written primarily for 
the benefit of the Internet Area Directors. Document editors and shepherd(s) 
should treat these comments just like they would treat comments from any other 
IETF contributors and resolve them along with any other Last Call comments that 
have been received. For more details on the INT Directorate, see 
https://datatracker.ietf.org/group/intdir/about/.

This draft looks pretty good but there are a few quickly fixed issues and a 
bunch of minor nits. But, otherwise the draft looks ready to move forward.

Issues:

Section 3.1.3.1

I think the following text is in error:
   Defining multiple TLV-types achieves the same design goals as the
   "Softwire46 Rule Flags" defined in Section 4.1 of [RFC7598].  Using
   TLV-type set to 4 is equivalent to setting the F-flag in the
   OPTION_S46_RULE S46 Rule Flags field.
It should say (s/ 4 / 5 /):
   Defining multiple TLV-types achieves the same design goals as the
   "Softwire46 Rule Flags" defined in Section 4.1 of [RFC7598].  Using
   TLV-type set to 5 is equivalent to setting the F-flag in the
   OPTION_S46_RULE S46 Rule Flags field.
(I assume that "setting the F-flag" means setting it to 1.)

I'm also not sure what the following means:
 5 Forwarding Permitted Mapping Rule (may be used for
forwarding. Can also be a Basic Mapping Rule)
Shouldn't this just be:
 5 Forwarding Permitted Mapping Rule

FYI - The text in RFC7598 is:
   o  F-flag: 1-bit field that specifies whether the rule is to be used
  for forwarding (FMR).  If set, this rule is used as an FMR; if not
  set, this rule is a BMR only and MUST NOT be used for forwarding.
  Note: A BMR can also be used as an FMR for forwarding if the
  F-flag is set.  The BMR is determined by a longest-prefix match of
  the Rule IPv6 prefix against the End-user IPv6 prefix(es).

Section 5:
The "CoA-Request" message is not mentioned in this table, but was mentioned in 
3.1:
  The Softwire46-Configuration Attribute MAY appear in a CoA-Request
  packet.
It may also be appropriate to include a table number/title?


Minor Nits:

Section 3.1:
s/ efer / refer /

Section 3.1.2:
Remove the 0+ definition under Table 2 as it is not used and therefore 
not needed.

Section 3.2:
s/ orderd / ordered /
s/ attribute include one or / attributes includes one or /  
(use includes)

Section 3.3: Suggestion
It may be more consistent and shorter to combine "MAY appear", "MAY 
contain" rules? For example:

  The Softwire46-Multicast Attribute MAY appear in an Access-Request,
  Access-Accept, CoA-Request, and Accounting-Request packet.

  The Softwire46-Multicast Attribute MAY contain ASM-Prefix64 (see
  Section 3.3.1), SSM-Prefix64 (see Section 3.3.2), and U-Prefix64 (see
  Section 3.3.3) attributes.

Section 4:
In 4, s/Theses are/These are/
In 5, s/CE send a/CE sends a/

Appendix A.7:
The "TLV Field" column is a bit odd since these are really subfields 
from RFC8044.
So, rename "TLV Subfield"? And, the fields are "Prefix-Length" and 
"Prefix" from
the TLV attribute.

- Bernie

-Original Message-
From: Éric Vyncke via Datatracker  
Sent: Tuesday, April 23, 2019 1:20 PM
To: Bernie Volz (volz) ; Carlos Bernardos 
Subject: intdir Telechat Review requested: draft-ietf-softwire-map-radius


Telechat review of: draft-ietf-softwire-map-radius (no specific version)
Deadline: 2019-05-15
Requested by: Éric Vyncke

https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/reviewrequest/11924/login/

intdir Telechat Review requested: draft-ietf-softwire-map-radius


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas

[Bernie Volz (volz)]

Hi Jordi:

Haven't look at the draft in detail yet, but I did find it rather odd that you 
are using option code 46. As these are DHCPv6 option codes, this maps to:

Value   Description Client ORO  Singleton Option
Reference
46  OPTION_CLT_TIME No  Yes [RFC5007]

I understand that you may have picked this simply because it is a nice number 
for v4/v6 transition mechanisms. But it seems like a rather odd mapping.

If you really think this is a wise thing to do, you should at least document 
that you are requesting this because of its value (and because it would never 
"really" be used for RFC 8026) - not that this OPTION_CLT_TIME option itself 
has any meaning.

It may be better to request that IANA assign a DHCPv6 option for this purpose - 
which should otherwise never be requested by a client (or configured on a 
server).

- Bernie

-Original Message-
From: dhcwg  On Behalf Of JORDI PALET MARTINEZ
Sent: Wednesday, June 13, 2018 12:46 PM
To: dh...@ietf.org; softwires@ietf.org; v6...@ietf.org
Subject: [dhcwg] updating RFC8026 with draft-ietf-v6ops-transition-ipv4aas

Hi all,



I'm sending this to Sotfwires and DHC WGs, in order to let know and seek 
review, but please keep the discussion only in v6ops which is responsible of 
this document



https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/



Here is the short summary of the reasons for the update.



In order to prioritize the different IPv4-as-a-Service (in IPv6-only networks) 
transition mechanisms (so the ISP can "agree" with each CPE which one to use or 
even if none), we are using RFC8026 (in short "a DHCPv6-Based Prioritization 
Mechanism for IPv4-in-IPv6 CPEs"), which was developed in softwires, but it is 
a DHCPv6 based mechanism.



The interesting issue is that because 464XLAT don't have an option code in 
RFC8026, it can't be ranked the same way, and ideally it should be, as we use 
also that in order to facilitate the operator to "manage" each transition 
mechanism status to be on/off (even to different customers).



So, what we do with this update, is adding that option code for 464XLAT to the 
existing ones and instruct IANA about that.



If you want to understand the suggested updated and how our algorithm works, 
you can read directly section 3.3, 7 and 10. Of course, inputs on the complete 
document are welcome!



Thanks!



Regards,

Jordi

 

 




**
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or 
confidential. The information is intended to be for the exclusive use of the 
individual(s) named above and further non-explicilty authorized disclosure, 
copying, distribution or use of the contents of this information, even if 
partially, including attached files, is strictly prohibited and will be 
considered a criminal offense. If you are not the intended recipient be aware 
that any disclosure, copying, distribution or use of the contents of this 
information, even if partially, including attached files, is strictly 
prohibited, will be considered a criminal offense, so you must reply to the 
original sender to inform about this communication and delete it.



___
dhcwg mailing list
dh...@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

[Bernie Volz (volz)]

Hi Ian:

Thanks … suggested text changes look good. I would think it best to reference 
3315bis … hopefully it won’t hold up publication of this draft since it may 
take RFC Editor a bit longer to process the 3315bis document, but they also 
will have a head start. (If it does hold it up and we need to expedite release 
of this draft as an RFC, we can always ask for reference to change to 3315.)


  *   Bernie

From: Ian Farrer 
Date: Tuesday, May 8, 2018 at 10:10 AM
To: Bernie Volz 
Cc: "dh...@ietf.org" , 
"draft-ietf-dhc-dhcp4o6-saddr-...@ietf.org" 
, "softwires@ietf.org" 

Subject: Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - 
EXTENDED - Respond by April 17, 2018

Hi Bernie,

Many thanks for the review. I’ve had a look through your comments and they all 
look straightforward enough. They will be in the next version with Tomek’s 
comments.

Here’s my suggestions in response to a couple of your comments:

SECTION 9:

-  More of a question – do the new options or procedures add any new or 
different considerations? If not, great.

There is one case that I think is missed. I’ve update the Security 
Considerations section to add the following text:

  A rogue client could attempt to use the mechanism described
  in "Changing the Bound IPv6 Softwire Source Address” to redirect IPv4 
traffic
  intended for another client to itself. This would be performed by
  sending a DHCPREQUEST message for another client's active IPv4
  lease containing the attacker's softwire IPv6 address in
  OPTION_DHCP4O6_S46_SADDR.

  For such an attack to be effective, the attacker would
  need to know both the client identifier and active IPv4
  address lease currently in use by another client. The risk
  of this can be reduced by using a client identifier format
  which is not easily guessable, e.g. by including a time
  component for when the client identifier was generated
  (see [I-D.ietf-dhc-rfc3315bis] Section 11.2).


-  And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 
(draft-ietf-dhc-rfc3315bis) aren’t referenced in the document. They are 
implicit because RFC7341 is referenced, but not always clear that this is the 
best way to go. But I didn’t find any easy way to incorporate these references 
directly.

I’ve added the following to Section 4. Solution Overview:

In order to provision a softwire, both IPv6 and IPv4 configuration
needs to be passed to the client. To map this to the DHCP 4o6
configuration process, the IPv6 configuration is carried in
DHCPv6 options [I-D.ietf-dhc-rfc3315bis], carried
inside the DHCPv6 message DHCPV4-RESPONSE (21)
sent by the server.

And:

IPv4 configuration is carried in DHCPv4 messages ,
(inside the DHCP 4o6 option OPTION_DHCPV4_MSG (87)) using the mechanism
described in .

The normative refs. are updated with these as well.

BTW, should I be referencing RFC3315 or the -bis version as normative at this 
stage?

Thanks,
Ian

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

[Bernie Volz (volz)]

Tomek has been traveling, so we have not had a chance to discuss and make a 
determination. I expect we'll have an answer mid next week (4/25 or so). Hint 
to others - you still have time to look at the document and comment as to the 
WGLC!!!

In the interim as the document shepherd I took another look in preparing the 
shepherding write up. And, I have found a bunch of mostly nits that should be 
addressed.

They are:

ABSTRACT:


-  I'd change the very first sentence to start with "DHCPv4 over DHCPv6 
(RFC7341) is ..." - add the RFC, but don't make it a reference!

-  Change: "This address, in conjunction with the client's IPv4 address 
and (in some deployments), the Port Set ID" to: "This address, in conjunction 
with the client's IPv4 address, and (in some deployments) the Port Set ID ..." 
(move the comma as it ended up in the wrong place).

-  I'd delete the last sentence of the first paragraph as it DUPLICATES 
the next paragraph. Perhaps you can change the 2nd paragraph to read:


   This document updates "DHCPv6 Options for Configuration of Softwire

   Address and Port-Mapped Clients" (RFC7598) to allow the OPTION_S46_BR

   (90) to be enumerated in the DHCPv6 client's ORO request and appear

   directly within subsequent messages sent by the DHCPv6 server.

General Issue:


-  The XML2RFC short title is "Softwire Provising with DHCP 4o6". I 
think you want to changing "Provising" to "Provisioning"?

SECTION 4.1:


-  Remove "'s'" in "border relay (BR)'s'" from first sentence. I think 
it is fine without this and looks weird with it.

SECTION 7:


-  Remove the period after "Section 5. of [RFC..." as the period made 
me first think it was Section 5 of this document.

SECTION 7.1:


-  Remove the period after "Section 6. of [RFC..." as the period made 
me first think it was Section 6 of this document.

SECTION 7.2.1:


-  Response is misspelled as repsonse in the last paragraph.

SECTION 7.6:


-  Add a space after the first reference ([RFC7618] describes".

SECTION 8.1:


-  In the last paragraph, existing is misspelled as "exisiting".

SECTION 9:


-  More of a question - do the new options or procedures add any new or 
different considerations? If not, great.

SECTION 10:


-  I'd suggest add that these are TBD2 and TBD1 (respectively) in the 
first two paragraphs. And, I'd recommend swapping the first two paragraphs so 
TBD1 (v6 option)is first and TBD2 (v4) is second.

-  - Later you have "OPTION_S46_BIND_IPV6_PREFIX TBD1)" - you should 
add open parenthesis around TBD1?

SECTION 12:


-  I do wonder if the updated RFC (7598) really should be in the 
Normative section? Hard to see how it can just be informational if it is being 
updated?

-  And, it is rather odd that DHCPv4 (RFC2131) and DHCPv6 
(draft-ietf-dhc-rfc3315bis) aren't referenced in the document. They are 
implicit because RFC7341 is referenced, but not always clear that this is the 
best way to go. But I didn't find any easy way to incorporate these references 
directly.

I'm not saying you should publish a new version immediately - it may make more 
sense to wait for the WGLC decision as perhaps we'll get someone else to review 
the document and comment on the WGLC.

>From a WG chair/shepherd hat off position, I support moving this document 
>forward.


-  Bernie

From: dhcwg <dhcwg-boun...@ietf.org> On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 11, 2018 4:18 PM
To: dh...@ietf.org
Cc: softw...@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - 
Respond by April 17, 2018

Tomek and I discussed this today and decided we'd extend the comment period for 
a week in the hopes of getting more input as to the WGLC. Also, I had failed to 
include the Softwire WG, so adding (this work originally started out there).

Please take a look at the draft and comment! We need your assistance in 
determining whether this work is ready to advance.

Thanks much!


-  Bernie & Tomek


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - Respond by April 17, 2018

[Bernie Volz (volz)]

It would of course help if I used the correct email address for the softwire 
WG! Sorry about that.


-  Bernie

From: dhcwg <dhcwg-boun...@ietf.org> On Behalf Of Bernie Volz (volz)
Sent: Wednesday, April 11, 2018 4:18 PM
To: dh...@ietf.org
Cc: softw...@ietf.org
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - EXTENDED - 
Respond by April 17, 2018

Tomek and I discussed this today and decided we'd extend the comment period for 
a week in the hopes of getting more input as to the WGLC. Also, I had failed to 
include the Softwire WG, so adding (this work originally started out there).

Please take a look at the draft and comment! We need your assistance in 
determining whether this work is ready to advance.

Thanks much!


-  Bernie & Tomek

From: dhcwg <dhcwg-boun...@ietf.org> On Behalf Of Bernie Volz (volz)
Sent: Tuesday, March 27, 2018 11:32 AM
To: dh...@ietf.org
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt - Respond by April 
10, 2018

Hello:

The authors have requested a WGLC for draft-ietf-dhc-dhcp4o6-saddr-opt.

Please review this document and provide your comments and whether you support 
the document moving forward or not, by April 10th, 2018 (23:59 UTC).

Please see https://tools.ietf.org/html/draft-ietf-dhc-dhcp4o6-saddr-opt-03.

There are no IPR notices filed against this work (as of this writing).

Thank you!


-  Tomek & Bernie

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017

[Bernie Volz (volz)]

Hi:

The DHC WG will adopt this document. There was good support for it, and no one 
opposed the adoption.

The authors are requested to published the DHC WG -00 version of the draft 
(with the minor fix to reference the correct RFC (RFC7568 -> RFC7598) as 
pointed out by Jordi.

- Tomek & Bernie

-Original Message-
From: dhcwg [mailto:dhcwg-boun...@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Wednesday, February 22, 2017 12:38 PM
To: dhcwg 
Cc: Softwires-wg ; 
draft-fsc-softwire-dhcp4o6-saddr-...@ietf.org
Subject: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - 
Respond by Mar 8th, 2017

Hi,

This message initiates a two weeks long DHC WG adoption call on:

Title: DHCPv4 over DHCPv6 Source Address Option
Pages: 9
Date: 2017-02-01
Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07
Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07

This document initially started as work intended to be adopted in Softwires, 
but after a discussion with chairs, responsible AD (Suresh) and presenting this 
work in DHC, the conclusion is to aim for DHC adoption, not Softwires. 
Therefore this is a DHC adoption call.

This message is cross-posted to Softwires to let Softwire experts weigh in 
their opinion. Please be sure to post your comments to DHC list, though. 
Comments sent by end of March 8th, 2017 are much appreciated.

Bernie & Tomek

___
dhcwg mailing list
dh...@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - Respond by Mar 8th, 2017

[Bernie Volz (volz)]

I support adoption of this draft in the DHC WG.

- Bernie (w/DHC WG co-chair hat off)

-Original Message-
From: dhcwg [mailto:dhcwg-boun...@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Wednesday, February 22, 2017 12:38 PM
To: dhcwg 
Cc: Softwires-wg ; 
draft-fsc-softwire-dhcp4o6-saddr-...@ietf.org
Subject: [dhcwg] Adoption call for draft-fsc-softwire-dhcp4o6-saddr-opt-07 - 
Respond by Mar 8th, 2017

Hi,

This message initiates a two weeks long DHC WG adoption call on:

Title: DHCPv4 over DHCPv6 Source Address Option
Pages: 9
Date: 2017-02-01
Document: draft-fsc-softwire-dhcp4o6-saddr-opt-07
Link: tools.ietf.org/html/draft-fsc-softwire-dhcp4o6-saddr-opt-07

This document initially started as work intended to be adopted in
Softwires, but after a discussion with chairs, responsible AD (Suresh)
and presenting this work in DHC, the conclusion is to aim for DHC
adoption, not Softwires. Therefore this is a DHC adoption call.

This message is cross-posted to Softwires to let Softwire experts weigh
in their opinion. Please be sure to post your comments to DHC list,
though. Comments sent by end of March 8th, 2017 are much appreciated.

Bernie & Tomek

___
dhcwg mailing list
dh...@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg

___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

[Softwires] Review of draft-ietf-softwire-multicast-prefix-option-11

[Bernie Volz (volz)]

Hi:

A few comments on this draft.

Section 2:

The dslite-multicast draft uses uPrefix64 instead of U_PREFIX64? Consistency 
between the various softwire documents might be useful?

Nit: SSM_PREFIX64 has an extra closing parenthesis (after the RFC4607 
reference).

Section 3:

I am not sure that the *-length fields are correctly documented? Can they 
really be 0-128. I understand 0 if there is none, and I can see 1-96 
potentially, but does more than 96 make sense? It seems that the other 
documents referenced typically say to use the prefix (96 bits – perhaps zero 
extended if needed to make 96 bits) and then add 32-bits IPv4 for multicast 
(unicast is a bit more complex when prefix is not 96). But none of this other 
text seems to imply that the prefix length can be > 96?

Also, while 2001::/96 could be sent as 2001::/16 in terms of the option 
encoding (as bits 17 to 96 are 0), the two are vastly different in terms of 
what they might mean (if the prefix is always mapped to /96 it may not matter). 
I just wonder if this needs to be clarified some? I believe the first encoding 
(2001::/96 is always intended as that communicate the true prefix length).

Is the reference to “Section 6 of RFC7051” correct? Was this intended to be RFC 
7227 (Section 6 there is titled “Avoid Conditional Formatting”).

I think it would be useful to clearly state that multiple instances of this 
option are allowed. Yes, if you carefully read the text (in Section 4 & 5) this 
is evident, but it is useful to state this explicitly when defining the option!

Section 5:

Nit: There are two “Pv4 mulitcast” instances; are these supposed to be “IPv4 
multicast”?

Note here that the text for ASM and SSM says to insert last 32-bits. This would 
imply that a prefix length > 96 does not work. (See comments above for section 
3.)

And, there is talk here about scope selection and adding the same reference as 
in Section 4 (to RFC7346) might be useful? Client implementers may not read the 
server section, so duplicating the reference here would be useful.

- Bernie




___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires

Re: [Softwires] [dhcwg] WGLC for draft-ietf-softwire-map-dhcp-07 in Softwires WG

[Bernie Volz (volz)]

Hi:

I'm reviewing this document from the DHC perspective and not evaluating it with 
respect to Softwires.

From an options definition/formatting perspective, I think this draft follows 
the draft-ietf-dhc-option-guidelines-17 recommendations.

There are some minor nits that could improve the clarity of the draft:

For example:

   o  S46_RULE-options: a variable field that may contain zero or more
  options that specify additional parameters for this S46 rule, e.g.
  a Port Parameter Option.

Says e.g. a Port Parameter Option. Are there others (today)? Be nice to be 
explicit as to what can appear today (future documents can always add 
additional options).

And, in other places when options are referenced the option name is given (so 
perhaps replace with OPTION_S46_PORTPARAMS)? There are similar issues in other 
places in the draft.

Also:

   The OPTION_S46_PORTPARAMS option MUST be encapsulated in a
   OPTION_S46_RULE option or an OPTION_S46_V4V6BIND option.  It MUST NOT
   appear directly within a container option.

5.  Softwire 46 Container DHCPv6 Options

  +---+---+---++
  | Option| MAP-E | MAP-T | Lightweight 4over6 |
  +---+---+---++
  | OPTION_S46_RULE   |   M   |   M   |N/A |
  | OPTION_S46_BR |   M   |  N/A  | M  |
  | OPTION_S46_PORTPARAMS |   O   |   O   | O  |
  | OPTION_S46_DMR|  N/A  |   M   |N/A |
  | OPTION_S46_V4V6BIND   |  N/A  |  N/A  | O  |
  +---+---+---++

 M - Mandatory, O - Optional, N/A - Not Applicable

   Table 1: Option to Container Mappings

So, the last sentence before section 5 (It MUST NOT appear directly within a 
container Option). But section 5 calls the two options it is allowed in 
Container options? Perhaps just drop that sentence? Also, the MUST be 
encapsulated seems wrong (it is optional)? Well, it all depends what is meant 
by this sentence. I think it is trying to say may only or can only?

This table 1 should probably have an introduction / description? Perhaps it 
should also be moved to the end of section 5?


It is wise to have the Security Considerations reference an expired and dead 
document - [I-D.ietf-dhc-secure-dhcpv6]? It is Informative, but still ... 
Perhaps worth adding whatever material makes sense? It looks like many of 
Informative references are to older (expired) draft documents?


- Bernie

-Original Message-
From: dhcwg [mailto:dhcwg-boun...@ietf.org] On Behalf Of Tomek Mrugalski
Sent: Tuesday, April 22, 2014 12:39 PM
To: dhcwg
Cc: Softwires-wg
Subject: [dhcwg] WGLC for draft-ietf-softwire-map-dhcp-07 in Softwires WG

Oops, that slipped under the radar for while.

I'd like to bring up to DHC attention a document that goes through WGLC in 
Softwires. This is a document that specifies provisioning mechanism for MAP, 
lw4over6 and possibly other IPv4/IPv6 transition technologies.
It defines 8 DHCPv6 options. Some of them are containers and there are many 
inter-option dependencies (including dependence on PD options), so it's not a 
straightforward doc.

Please post your DHCP-related comments to Softwires list with cc: to dhc. If 
you have MAP-, lw4over6- or other IPv4/IPv6 transition specific comments, 
please post them to Softwires only and not to DHC.

With my DHC co-chair hat off: I used to be a primary author of that draft 
around 1,5 years ago. Since then I gave up and didn't follow on the discussions 
(simply because of lack of time). While technically I'm still listed as a 
co-author, I can't make any comments on the quality or correctness of this 
draft.

Tomek

 Original Message 
Subject: [Softwires] Working group last call for
draft-ietf-softwire-map-dhcp-07
Date: Mon, 7 Apr 2014 00:37:35 -0400
From: Suresh Krishnan suresh.krish...@ericsson.com
To: Softwires WG softwires@ietf.org
CC: Yong Cui cuiy...@tsinghua.edu.cn

Hi all,
  This message starts a two week softwire working group last call on advancing 
the draft about the DHCPv6 Options for configuration of Softwire Address and 
Port Mapped Clients as a Standards Track RFC. The authors believe that this 
version has addressed all the issues raised on the document. The latest version 
of the draft is available at

http://www.ietf.org/id/draft-ietf-softwire-map-dhcp-07.txt
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp-07

Substantive comments and statements of support/opposition for advancing this 
document should be directed to the mailing list. Editorial suggestions can be 
sent directly to the authors. This last call will conclude on April 21 2014.

Regards,
Suresh  Yong


___
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires