draft-ietf-softwire-ds-lite-tunnel-option-01.txt
I have read the draft, and support it on its technical merits.
However, it could use a bit of word-smithing.
The biggest thing is that the Address option is a MUST, and the Name
option is a MAY ALSO:
A client that supports B4 functionality of the DS-Lite (defined in
[draft-ietf-softwire-dual-stack-lite-02]) MUST include
OPTION_DS_LITE_ADDR on its OPTION_ORO, and MAY include
OPTION_DS_LITE_NAME at its option and ability.
I'd have expected to see the two options on an equal footing, where
clients could request one or the other without prejudice, but probably
wouldn't request both.
Further:
If the client requests and receives both the OPTION_DS_LITE_ADDR and
the OPTION_DS_LITE_NAME, it MUST proceed with resolving the
OPTION_DS_LITE_NAME.
This says that the Address option is a throw-away in this context.
i.e. There's no reason to request the Address option in this context,
except that this draft mandates it.
I'd suggest something like:
A client that supports B4 functionality of DS-Lite MUST include
either OPTION_DS_LITE_ADDR or OPTION_DS_LITE_NAME on its
OPTION_ORO. If the client requests and receives both
OPTION_DS_LITE_ADDR and the OPTION_DS_LITE_NAME, it MUST proceed
with resolving OPTION_DS_LITE_NAME.
I'm not overly enthusiastic about resolving the conflict in favor of
the Name option, but there should be some deterministic resolution
mechanism.
On to the language nits...
It's "DS-Lite", not "DS Lite" or "the DS-Lite".
In most places, the latest draft changed "option" to "DHCPv6 Option".
I'm not sure this is really necessary.
This draft is tied much more closely to the terminology of DS-Lite
than previously, e.g. Softwire Initiator -> B4 element, Softwire
Concentrator -> AFTR element. However, the options are still called
"The Dual-Stack Lite Softwire Concentrator Address DHCPv6 Option" and
"The Dual-Stack Lite Softwire Concentrator Name DHCPv6 Option".
For simplicity (and being able to say them in one breath), I'd
suggest "The Dual-Stack Lite Address DHCPv6 Option" and "The
Dual-Stack Lite Name DHCPv6 Option".
Related to this, the Abstract goes half way:
This document specifies two DHCPv6 Options which are meant to be used
by Softwire Initiator (SI) to retrieve its attached DS-Lite AFTR
(Address Family Transition Router).
I'd suggest something like;
This document specifies two DHCPv6 Options which are meant to be
used by a Dual-Stack Lite client (Basic Bridging BroadBand element)
to discover its AFTR (Address Family Transition Router) address.
Section 2, 4th paragraph says:
This document assumes that the SI is provided with appropriate
instructions for the activation of an IPv4-in-IPv6 scheme which is
supposed to be supported in both B4 and AFTR. Consequently, this
memo does not precise the IPv4-in-IPv6 encapsulation scheme to be
used by B4.
In additon to "the SI" (a term that has been stripped of context) and
"precise" (prescribe?), this paragraph could be a lot more direct, e.g.
The details of how the B4 establishes an IPv4-in-IPv6 tunnel to the
AFTR are out of scope for this document.
In 3.1, it's not necessary to spell out Address Family Transition
Router a third time.
In 3.1 and 3.2, you say "Below is provided the description of the
enclosed fields:". Not only is the language tortured, it's frankly
unnecessary.
At the end of 3.1, you say:
The definition of this option is simple and encloses only a single
IPv6 address. It is temping to define a flexible option which may
convey several IPv6 addresses (for robustness and service
availability reasons), but for the sake of simplicity and consistency
it is recommended to use a FQDN Option instead of conveying several
IPv6 addresses.
This could be interpreted as a recommendation to use the FQDN option
instead of the Address option. Perhaps something like:
For the sake of simplicity, this option conveys a single IPv6
address. If you want to convey multiple IPv6 addresses, you should
instead use the Dual-Stack Lite Name option, where the DNS name
could resolve to multiple addresses.
In 3.2, the caption for Figure 2 says "DS-Lite FQDN DHCPv6 Option".
Change to "DS-Lite Name DHCPv6 Option".
In section 3.2, I'm not sure you need to say anything on the subject
of redundancy of high availability.
In section 4 (line 352), change FDQN to FQDN.
paul
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires