Subject: [Insipid] Review of draft-jones-insipid-session-id-02

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 07:21:04 +0800

I just reviewed the latest version. Here are some things I noted:

Formatting:

There is *something* wrong with this draft, but I'm not certain what. 
Both the idnits tool and the diff tool fail on it.

http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-jones-insipid-session-id-02.txt

http://tools.ietf.org/rfcdiff?url2=draft-jones-insipid-session-id-02.txt

Because of this I couldn't tell what was different since the prior 
version and just reviewed this one from scratch.

Syntax:

It is common practice to permit hex to be expressed in either lower or 
upper case, such as:

    sess-uuid = 32(HEXDIG) ; HEXDIG defined in 5234

Section 6:

    It should be noted that messages received by a UA might contain a
    "remote" parameter that does match the UAs UUID.  This might happen
    as a result of service interactions by intermediaries and MUST NOT be
    regarded as an error.

ISTM that this *is* an error, but not one that should be considered 
fatal. It might suggest some investigation to find out what is going on 
to cause it. The key behaviors are that this should not affect what the 
local id for this node and not cause an error.

    An endpoint MUST assume that the UUID value of the peer UA MAY change
    at any time due to service interactions.  However, once an UA
    allocates a UUID value for a communication session, the UA MUST NOT
    change that UUID value for the duration of the session, including
    when communication attempts are retried due to receipt of 4xx
    messages, when the session is redirected in response to a 3xx
    message, or when a session is transferred via a REFER message [6].

If I understand the intent, there is another case that should preserve 
the local uuid: a successful INVITE/Replaces.

Section 7:

    Intermediaries that wish to utilize the Session-ID MAY extract the
    UUID header-values from any SIP message.  Alternatively,
    intermediaries MAY observe the first UUID value in the Session-ID
    header for messages sent in each direction and use those values to
    locally construct the Session Identifier.

The portion of section 6 mentioned earlier says that one may receive a 
message with a remote part that doesn't match the one known locally, and 
that it should be ignored rather than replacing the local one.

If the same thing is observed in an intermediary, this paragraph says 
its ok to either ignore the changed one and stick with what was known, 
or else replace it. The particular choice will affect other nodes.

Section 9.2:

An ACK is shown after the REFER. That is wrong.

Section 9.6:

This example shows some unique behavior. But this behavior is not 
mentioned in the normative section 5 & 6. I don't think these examples 
are normative. So something is missing if you want these to be valid.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 8 Mar 2013 00:52:59 -0500

Paul,

> Both the idnits tool and the diff tool fail on it.

We saw that, too.  I also tried using Microsoft Word to do a diff on the
.docx version of these files and it hung on me.  I think there are ghosts in
the machines that do not want a diff produced of this text.
 
>     sess-uuid = 32(HEXDIG) ; HEXDIG defined in 5234

If I'm reading RFC 5234 correctly, HEXDIG is defined to use only uppercase.
Am I misreading that?

Anyway, what do we want here?  Upper, lower, or either?  I don't really have
a preference.
 
> local id for this node and not cause an error.

How about this:

    It should be noted that messages received by a UA might contain a
    "remote" parameter that does match the UAs UUID.  This might happen
    as a result of service interactions by intermediaries and MUST NOT
    negatively affect the communication session.  However, the UA may
    log this event for the purposes of troubleshooting.

> the local uuid: a successful INVITE/Replaces.

Yes; I will add that.
 
> that it should be ignored rather than replacing the local one.

Section 6 talks about what Alice would do if Bob sent her a "remote" value
that did not match her UUID.  She should ignore it, by and large.  The
intermediaries would not be privy to the knowledge Alice has.  As far as
they are concerned, the "remote" value from Bob is the correct one, so I can
appreciate that they would us it.  However, Alice will generate a reply to
Bob and she would insert her UUID in that reply. So, the intermediary will
learn what Alice's UUID is.  The intermediary should just assume it changed
again.

> or else replace it. The particular choice will affect other nodes.

Given the above explanation, do you think we need to change the text?  I'm
not sure what to add, but will take input.
 
> An ACK is shown after the REFER. That is wrong.

Deleted.

> are normative. So something is missing if you want these to be valid.

We need to talk about this one.  James has this planned for discussion next
week.  I'll wait to do something here.

Thanks!
Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Mar 2013 23:28:07 +0800

> the machines that do not want a diff produced of this text.

I don't have a solution for you, but you need to find a solution. 
Ultimately the draft must pass idnits. I suspect the the problem is some 
artifact of using MSWord to format the draft. You could convert over to 
using xml2rfc for this.

> If I'm reading RFC 5234 correctly, HEXDIG is defined to use only uppercase.

People often get confused by this. In ABNF "A" matches both 'A' and 'a'. 
So HEXDIG matches both upper and lower case hex digits.

> Anyway, what do we want here?  Upper, lower, or either?  I don't really have

Common practice in most places I am aware of is to allow either.

>> be

WFM

> not sure what to add, but will take input.

I don't know. ISTM that consistency is valuable here - so either always 
use the first value seen or always use the most recent one. Always using 
the first value seen requires the intermediary to be stateful about 
this, so it might be undesirable.

Or perhaps an intermediary that *assigns* the initial value should be 
expected to remember it and behave like an endpoint, while one that did 
not assign the value should just take what comes.

> week.  I'll wait to do something here.

OK - I can wait if the draft is simply incomplete in this regard. But 
eventually we really need normative specification of expected behavior.

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 8 Mar 2013 12:01:07 -0500

Paul,

> > We saw that, too.  I also tried using Microsoft Word to do a diff on
> > the .docx version of these files and it hung on me.  I think there are
> > ghosts in the machines that do not want a diff produced of this text.
> 

It appears to be functional now.
 
> >> Syntax:
> >>
> >> It is common practice to permit hex to be expressed in either lower
> >> or upper case, such as:
> >>

OK.  I changed the production as you suggested.
 
> > Section 6 talks about what Alice would do if Bob sent her a "remote"
> > value that did not match her UUID.  She should ignore it, by and
> > large.  The intermediaries would not be privy to the knowledge Alice
> > has.  As far as they are concerned, the "remote" value from Bob is the
> > correct one, so I can appreciate that they would us it.  However,
> > Alice will generate a reply to Bob and she would insert her UUID in
> > that reply. So, the intermediary will learn what Alice's UUID is.  The
> > intermediary should just assume it changed again.
> >
> >> its ok to either ignore the changed one and stick with what was
> >> known, or else replace it. The particular choice will affect other
> nodes.
> >
> > Given the above explanation, do you think we need to change the text?
> > I'm not sure what to add, but will take input.
> 
> the first value seen requires the intermediary to be stateful about this,
> so it might be undesirable.

The intent was that devices would always use the most recent value seen.
State should not necessarily be maintained for these values, though I can
appreciate why some devices might want to maintain state (e.g., to highlight
endpoint changes when logging call signaling messages).
 
> not assign the value should just take what comes.

It would have to keep up with it when initiating the session, like it keeps
up with other parts of the SIP signaling.

This stuff gets into Section 7.  Is there something not covered or should be
changed?

Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 11 Mar 2013 02:50:56 +0000

Paul K.,

In respect of the WG call to adopt solution text, does your comment against 9.6 mean either, we should omit 9.6 from the WG adopted text (with a subsequent proposal to the list to provide the procedures and examples together), or we should put an open issue statement in either section 5 or 6 to indicate this needs to be completed?

Regards

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: 07 March 2013 23:21
> To: [email-masked]
> Subject: [Insipid] Review of draft-jones-insipid-session-id-02
> 
> _______________________________________________
> insipid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/insipid

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Mar 2013 10:57:36 +0800

> In respect of the WG call to adopt solution text, does your comment against 9.6 mean either, we should omit 9.6 from the WG adopted text (with a subsequent proposal to the list to provide the proce…

IMO it would be sufficient to open an issue that this needs to be defined.

	Thanks,
	Paul