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:[email protected]] 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 <[email protected]>
To: Softwires WG <[email protected]>
CC: Yong Cui <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
