Subject: [Tsvwg] FW: Comments on I-D ACTION:draft-ietf-sigtran-addip-sctp-00.txt

From: [email-masked]
Date: Tue, 20 Feb 2001 14:25:12 +0200

Hi all,

2nd attempt at sending this:

> -----Original Message-----
> Hi all,
> 
> I'm forwarding some comments on the Add IP extenstion to SCTP:
> 
> br,
> John
> 
>      1)  P.4:  Should a REL-ACK be sent for the failure in 
> setting up the
> requested primary address? Or, just keeping silence (for a 
> security reason)?
> 
>      2)  P.5-6:  Should "Address Parameter" be replaced as 
> "TLV-copied from
> REL-REQ" for both parameter option formats to Code 11 
> (Section 3.2.1) and
> Code 13 (Section 3.2.3)? It seems that they don't match the 
> given examples!
> 
>      3)  P.5:  Should the type code be 0xC2 instead of 
> 0xC005, as shown in
> the examples in Sections 3.2.1-3?
> 
>      4)  P.8:  It says that an endpoint MUST fail any 
> subsequent ADD and
> DELETE requests if one such previous request in that chunk 
> has failed.  May
> you tell me the motivation of why it does so, as it doesn't 
> seem necessary
> (e.g. ADD -> failure, DELETE, which could be succeed)?
> 

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

---

From: "Randall R. Stewart" <[email-masked]>
Date: Tue, 20 Feb 2001 07:42:21 -0600

> > requested primary address? Or, just keeping silence (for a

Well you always have to send a REL-ACK, you are required to.
Now, has I said to Jon Berger, it is an "advice/hint" and
as such it really does not make any sense to send an
error if you can't do it... 

> > Code 13 (Section 3.2.3)? It seems that they don't match the

Good point.. 

> > the examples in Sections 3.2.1-3?

Why would it be C2? The example is just the TLV being
inserted into the REL-ACK not the complete REL-REQ with
REL-ACK... if this were so it would be something like:

        +--------------------------------+
        |    C2  |  00   | Length = 28   |
        +--------------------------------+
        |    Rel-Request Correliatin ID  |
        +--------------------------------+
        | Type = 0xC005  | Length = 20   |
        +--------------------------------+
        |  Cause=12      | Length = 16   |
        +----------------+---------------+
        |  Type=49153    | Length = 12   |
        +--------------------------------+
        |  Type=5        | Length = 8    |
        +----------------+---------------+
        |       Value=0x0a010101         |
        +----------------+---------------+

I suppose we could put this in.. but I don't know if it clearifies
anything...

> > (e.g. ADD -> failure, DELETE, which could be succeed)?

The idea behind this is that changes to an association like
this may well have inter-dependancies. In particular if you do
a

ADD
DEL

you may have a inter-dependancy setup between the add and delete.

We could I suppose take this restriction out, or for that matter
change the REL-REQ TLV type to 0x8xxx so that the rules of the
upper bits would effect the same thing :) But I really was hoping
not to have the whole REL-REQ fail if the ADD did..

R

-- 
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)