Lakshminath Dondeti wrote:
> > <LD> Terminology again: why not use the phrase "address pair"
> > instead of path. I realize that it results in a large number
> > of changes in the document, but this is still a -00-
> > </LD>
>
> Mainly because "path" is shorter and leads IMHO to more
> understandable text. RFC 2960 (SCTP) also uses the word "path"
> with pretty much the same meaning in many places.
>
> <LD>
> I read that draft just now and found this definition:
>
> "Path: The route taken by the SCTP packets sent by one SCTP
> endpoint to a specific destination transport address of
> its peer SCTP endpoint. Sending to different destination
> transport addresses does not necessarily guarantee getting
> separate paths."
>
> That is closer to the dictionary definition of the word path
> than MOBIKE uses, no? I think address pair is still better,
> while not as convenient path, it imparts the correct meaning.
> </LD>
Well, RFC 2960 continues at that point: "Primary Path: The
primary path is the destination and source address that will
be...", so it's also using the word path to refer to an address
pair in some cases.
> > o When the window size allows, sends an INFORMATIONAL
> > request containing the CHANGE_PATH notification payload
> > (which does not contain any data), and clears the
> > "pending_update" flag.
> >
> > <LD> Since this is optional, suggest using the keyword MAY
> > or OPTIONAL </LD>
>
> Which part are you referring to?
>
> <LD>
> Ok, this may be a bit of nitpicking but I am trying to have
> documents "spell out" what's clearly optional. "When the
> window size allows" does mean that sending CHANGE_PATH
> notification is optional. Or are you saying that "when the
> window size allows" it is a MUST.
> </LD>
That text is part of the process the initiator follows when it
already has decided to change the path; that involves sending a
CHANGE_PATH notification, so it's not optional (once you've
made the decision).
"When the window size allows" simply means that initiator may
have to wait for responses to previous requests before it can
send a new request. Since it's just descriptive text and not a
new requirement, probably there's no need for any RFC 2119
keywords.
> > o Replies with an INFORMATIONAL response:
> >
> > Initiator Responder
> > ----------- -----------
> > <-- HDR, SK { N(COOKIE2),
> > [N(NAT_DETECTION_*)] }
> >
> > <LD>
> > Should the other optional Notification payloads be present in
> > this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are
> > discussed below, but are not in the above message.
> > </LD>
>
> Hmm, actually no, since this step in the process is never
> reached if the NAT_PREVENTED or UNACCEPTABLE_PATH cases happen
> (they're already handled in earlier steps).
>
> <LD>
> Ok, I should have read a bit more carefully! There is some
> inconsistency in that page though. The case of
> UNACCEPTABLE_PATH is inline with the text and the case of
> NAT_DETECTION_* is specified with headers and such. Please
> make it consistent in the future versions -- or perhaps use my
> suggestion and say that the resultant message after
> considering all the steps would be HDR, SK{N(COOKIE2), [N()],
> N[]}. Perhaps your way of separating them out is better, but
> please make it consistent.
> </LD>
Currently the logic is that the "normal case" (when everything
succeeds) is shown in a separate message diagram, but error
cases (which hopefully occur only rarely) are described in-line
with the text. But I'll try to make it more consistent in future
versions..
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.