Hi Suresh,

On 5/17/12 12:41 AM, Suresh Krishnan wrote:
Hi Brian, Thanks for the comments. Please find responses inline.

Brian Haberman wrote:
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?

It is mainly the MAC address of the host that initiated the RS. The
proxy RS from the AN cannot convey this to the edge router.


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

It is intended to convey that this mechanism applies to n:1 vlan
models and is not generally applicable. If we use "NOT RECOMMENDED
for deployments not using N:1" we end up with a double negative. Will
that work for you?

How about : "...is considered experimental and SHOULD only be used in deployments employing N:1 VLANs."?

I, personally, would not object to changing the above SHOULD to a MUST.



- Section 5.1 : If the AN has an IPv6 address, why is its use in
the encapsulating header only a SHOULD?

I am rewording this section to include an additional case that came
up. I will change this to a MUST, The New text will read


OLD: If the AN has an IPv6 address, it SHOULD use this address in the
Source Address field of the outer IPv6 datagram. Otherwise it MUST
use the unspecified address as the Source Address of the outer IPv6
datagram.

NEW:

If the AN has an IPv6 address, it MUST use this address in the Source
Address field of the outer IPv6 datagram. Otherwise, when the
end-device sends out a Router Solicitation and uses a link-local
address in the Source Address field, the AN MUST copy this address in
the Source Address field of the outer IPv6 datagram. In all other
cases, the AN MUST use the unspecified address as the Source Address
of the outer IPv6 datagram.

Looks good to me.



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

The LIO gets mapped to the prefix either by configuration or some
form of dynamic provisioning using a protocol like RADIUS. I will add
an explicit statement that this RA MUST carry this prefix in the
PIO.


Ok.



- 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/

OK.


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

I cannot see any reasonable cases where there can be exceptions to
this. I will change these to MUST NOTs.


Ok.


Editorial ---------

I will make all these editorial changes,


Cool.  Once the new version is out, I will start an IETF Last Call.

Regards,
Brian


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to