Subject: [Tsvwg] addip comments

From: [email-masked]
Date: Tue, 24 Jul 2001 19:24:36 +0300

Hi all!

	I have the next comments regarding the addip draft...

	- Page 1. Index: The word "Acknowledgement" appears as
"Acknowledgment" 7 times all over the draft, being the first one in the
index (3.1.2). Also, by chance when verifying the places in which
"Acknowledment" was written, I realized that the "Acknowledgements" section
(number 7) doesn't appear in the index, and that the "Author Addresses" and
"References" sections should be sections number 8 and 9 respectively...

	- Page 2. Section 1. A): The wording is not so clear:

     "A) a graceful method to add to the interfaces of an existing 
        association. For IPv6 this feature allows renumbering
        of existing associations."

	Wouldn't it be better like this?:

     A) a graceful method to add new interfaces to an existing
        association, or to delete interfaces from an existing
        association. For IPv6 this feature allows renumbering
        of existing associations.

	- Page 3. Section 3: A copy-and-paste typo:

	"- Dynamic deletion of IP Addresses to an association."

	I guess that the "to" should be replaced with a "from".

	- Page 4. Section 3.1: On top of the page, when the new chunks are
presented, I guess that the chunk name for chunk type 0x80 should be
"Address/Stream Configuration Acknowledgment" instead of "Address
Configuration Acknowledgement".

	- Page 8. Section 3.2.3. Valid Chunk Appearance: When using the
INIT/INIT ACK chunks to send these stream and address configuration
parameters, we can't use the Serial Number nor the Correlation ID. The
Serial Number is not necessary since we will receive the answer in the INIT
ACK chunk or bundled together with the COOKIE ECHO chunk, and so they can be
differentiated (one could think about the Verification Tag doing somehow the
work of the Serial Number since they must be the same number in these
cases), but I'm not that sure that the Correlation ID is not necessary in
these situations... In theory, one could send a "Stream Flow Limit Change",
"Set Primary IP Address", "Stream Message Limit Change" and "Association
Message Limit Change" parameters inside the INIT/INIT ACK chunk, so some
could be accepted and some rejected... How could we identify the ones
accepted and the ones rejected? Moreover, the "Error Cause Indication" and
"Success report" parameters are not allowed to be inside the INIT ACK chunk,
so I don't see a straightforward solution to this issue... :-| Is it so that
we have to accept all or none of the requests?

	The quickest way to solve this I can think about right now, so we
don't have to accept all or none, is including the Correlation ID in the
parameter itself, both when making the request and when sending the answer,
in an "Error Cause Indication" or "Success report", and allowing these two
chunks to be sent in the INIT ACK chunk... :-/

	In that case we could differentiate the different requests and
answers even when they are not inside an ASCONF or ASCONF-REQ chunk. When
sending requests in the INIT, the answer could be sent in the INIT ACK
including the "Error Cause Indication" or "Success report" parameters (or
the "Unrecognized parameters" parameter, or even not any), and when sending
requests in the INIT ACK chunk, one could always include an ASCONF-REQ chunk
with the Serial Number set to the Initiate Tag of the INIT ACK chunk, and
the necessary "Error Cause Indication" or "Success report" parameters
including the Correlation ID values that appeared inside every parameter (or
again, sending an ERROR chunk bundled with the COOKIE ECHO and containing
the "Unrecognized Parameters" cause of error, or not including anything at
all meaning that all the requests are accepted).

	However, this change would mean a lot of changes in the whole
draft... :-( I won't lists them here, just in case you are willing to modify
something related with this...

	Also, when sending the INIT chunk we don't know yet how many streams
is the peer going to accept and so we can be asking for limits in streams
that won't really exist. How should the peer (INIT receiver) behave in this
case? I guess that simply ignoring the information for streams that doesn't
exist is the best way of doing... :-0

	- Page 11. Section 3.3: The Cause Code Values are wrong. Instead of
0xC, 0xD and 0xE they should be 0x000C, 0x000D, 0x000E.

	- Page 14. Section 4.1: The B1) and B2) sections seems to be more or
less the same thing.

	- Page 16. Section 4.1.1. Last Paragraph of the section: Here it
says about what to do when receiving the "Unrecognized Chunk Type", however,
when sending ip/stream parameters in the INIT we will receive an
"Unrecognized Parameters" parameter in the INIT ACK, and when sending those
parameters in the INIT ACK chunk we will receive the "Unrecognized
Parameters" cause of error...

	Also, "... receives a Operational..." should be "... receives an
Operational...".

	- Page 16. Section 4.2: Maybe a section explaining what to do when
receiving the parameters inside an INIT/INIT ACK chunk would be needed as
well... Otherwise, there are several steps in the list that we can't
follow...

	- Page 18. Section 4.3. D6): Small typo: "... MUST NOT set a IP
header..." should be "MUST NOT set an IP header...".

	- Page 21. Section 4.4. First paragraph of the section: A Set
Primary is discarded if the Add IP is not processed before, but only if both
affect to the same address :-) What about:

    A sender of this option may elect to send this combined with
    a deletion or addition of an address. A sender SHOULD only send
    a set primary request to an address that is already considered
    part of the association. In other words if a sender combines
    a set primary with an add of a new IP address being the IP address
                                                  ^^^^^^^^^^^^^^^^^^^^ 
    to be added the same that is requested to be set as primary, the set
primary 
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    will be discarded unless the add request is to be processed 
    BEFORE the set primary (i.e. it precedes the set primary).

	- Page 21. Section 4.4. Third paragraph of the page: "... by NOT
placing an 'unrecognized parameter' error in the cookie.". Well, the error
is not included "in the cookie" but inside an ERROR chunk bundled with the
COOKIE ECHO chunk. Also, as in many many places, we have the problem of
"accepting all or none", since we can't tell to the INIT/INIT ACK by any
means that we accepted some request and rejected the rest...

	- Page 27. Last line: This is kind of anecdotal, but the draft
expires in 6 months from June, not May... :-)

	Thanks!

	BR Iván Arias Rodríguez

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Tue, 24 Jul 2001 14:31:08 -0500

Ivan:

Ok, I will work your comments in with Renee's as well 
for the -02 version:)

> "References" sections should be sections number 8 and 9 respectively...

Opps... you know me and spelling.. I keep forgetting to download
ispell so I can run the spelling checker on my FreeBSD laptop....

But I will fix this one manually :-0 It will be my punishment for
not getting ispell up :)

>         of existing associations.

Ok, I like your wording better (as usual) :)

>         I guess that the "to" should be replaced with a "from".

Opps.. good catch..

> Configuration Acknowledgement".

good catch.

> chunks to be sent in the INIT ACK chunk... :-/

Hmm.. I did not think of this... The limit additions to the
INIT/INIT-ACK
were via list suggestion... which seemed like a good idea at the time.

Now I wonder if it was such a good idea. Maybe it is better only
allow the set primary in the INIT/INIT-ACK and make the limits
come after the association is up.. Say bundle a ASCONF in the
COOKIE-ECHO
or COOKIE-ACK to get the limits right into effect... This would
simplify things I think.. I don't know if I am willing to add a
lot of complication to something that bundling an ASCONF into the
second and third legs could accomplish...

> something related with this...

I am leaning toward removing it from INIT/INIT-ACK and let it be
bundled in COOKIE-ECHO/COOKIE-ACK. This I think is better but
I will wait to do the edits just in case there is lots of
objections :0

> exist is the best way of doing... :-0

Yes.. even more reason to put it into the COOKIE-ECHO/COOKIE-ACK

> 0xC, 0xD and 0xE they should be 0x000C, 0x000D, 0x000E.

ok.. got it..

>         - Page 14. Section 4.1: The B1) and B2) sections seems to be more or

No there is a distinct difference. I killed the notes.. which Renee
suggested. One tells you to do the Destination address error counter
the otehr the association. These are two different counters and two
different thresholds...

> Parameters" cause of error...

Hmm.. but this is about the ASCONF chunk not the parameters. I think
there is wording (or should be) in each of the TLV discussion to
tell you not to send something if you get an "unrecognized parameters"

>         Also, "... receives a Operational..." should be "... receives an
Got it..

> well... Otherwise, there are several steps in the list that we can't

Hmm, I don't know.. the section is titled what to do when you get
an ASCONF chunk. The individual TLV's cover what to do with each
type. In the case of an INIT/INIT-ACK you are not getting an
ASCONF chunk :)... 

Maybe instead an additional section 4.x that says if TLV's come
in INIT/INTI-ACK follow the rules for the TLV? But of course
if we kill off the stream limits then we only have the
setprimary... which is what I originally had :)
> header..." should be "MUST NOT set an IP header...".

Got it..

>     a set primary with an add of a new IP address being the IP address

With slight word smithing I come up with:
"
    A sender of this option may elect to send this combined with a
    deletion or addition of an address. A sender SHOULD only send a set
    primary request to an address that is already considered part of the
    association.  In other words if a sender combines a set primary with
    an add of a new IP address and the IP address being added is the
    same address that is being requested to be set as primary, the set
    primary will be discarded unless the add request is to be processed
    BEFORE the set primary (i.e. it precedes the set primary).
"

> means that we accepted some request and rejected the rest...
How about saying "bundled with the cookie".. but I think we may be
taking this out if we go back to having an ASCONF be bundeld
with the COOKIE-ECHO/COOKIE-ACK...

> expires in 6 months from June, not May... :-)

And when I fix it of course it will move to 6 months from July.. but
I probably cant submit it until August :)

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)