All,
Here are my comments on the LineID draft. It is in pretty good
shape, but I would like these issues addressed before moving on to IESG
Review/IETF Last Call...
Substantive
-----------
- Section 2 (paragraph 3) : This text talks about "the network" getting
some information from the subscriber-originated RS messages. Is it
really the AN that gets this information or is it really the Edge
Router? What information is being lost when the subscriber-initiated RS
messages stop?
- Section 2 (paragraph 5) : This paragraph states that this approach is
"NOT RECOMMENDED for general deployments". Do you really mean general
deployments or is is better to say deployments not using the N:1 VLAN model?
- Section 5.1 : If the AN has an IPv6 address, why is its use in the
encapsulating header only a SHOULD?
- Section 6.3 : How does the edge router know what prefixes to map to
the LIO? Should there be some specification that the RA transmitted
must/should carry a PIO?
- Section 7 : I would suggest for the definition of the Option Length
s/The value 0 is considered invalid/The value MUST be greater than 0/
- Section 7.1 : I have questions on the use of SHOULD NOT in the last
two paragraphs. In what situation would two line IDs be considered equal
if they do not match byte-by-byte? To me, this can be changed to MUST
NOT. I am not sure there is really any reason to say an intermediate
system SHOULD NOT examine the Line ID. There is no way to enforce that
rule. In what situation (or type of situation) would an intermediate
system be allowed to modify the Line ID?
Editorial
---------
* Introduction
- s/traditionally/traditional/
- s/[RFC1661] based some networks/[RFC1661] based, some networks/
- s/network in context/network in the context/
- None of the figures are referenced in the text
- Expand GPON acronym on its first use
* Terminology
- The definition of AN uses the terms northbound and southbound. It
would be useful to briefly define those (or use different terms).
- I would define RG before Edge Router so that there is no dangling use
of the term RG before it is defined. Or you can expand RG in the
definition...
- It may be useful to state whether the use of an RG is optional or not.
- The definition of RG is missing a term: "...similar to one specified
in or a Layer...".
* Section 2
- s/VLAN deployment models line/VLAN deployment models, line/
- DHCP should be expanded on first use and a reference given.
- I would suggest providing a reference for SLAAC.
- s/this results on some/this results in some/
- s/Router Solicitations by initiating RSs/Router Solicitations (RSes)
by initiating RSes/
- s/RSs/RSes/g
- There is a dangling "e.g." in the middle of the third paragraph.
* Section 3
- s/the end-device on the circuit the end-device is connected on/the
end-device on the circuit/
- It would be useful to include a reference for DHCP relay agents.
* Section 4
- The acronym ND needs to be expanded or changed to RS/RA.
- Specify that it is the Hop Limit of the *inner* packet that must not
be decremented.
* Section 5.1
- The section uses the term "insert" when talking about the creation of
the encapsulating (outer) packet. This makes me think of modifying an
existing packet. It would be clearer to state that the encapsulating
packet includes/contains a destination options header.
* Section 5.2
- s/router advertisement/Router Advertisement/
- Rather than saying the AN will "multicast" the inner packet, would be
sufficient to say it will "transmit" the inner packet?
* Section 6.1
- Last sentence is missing a period.
* Section 6.2
- s/this router advertisement(es./this router advertisement./
- s/All BBF Access Nodes/All-BBF-Access-Nodes/g
* Section 6.3
- Provide an informative reference for ANCP.
* Section 7
- s/an alignment requirement of (none)/no alignment requirements/
* Section 7.1
- The last sentence of the first paragraph is missing a period.
Regards,
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
