Re: [Gen-art] Gen-art LC review of draft-ietf-insipid-session-id-24
Elwyn Davies <elwynd@folly.org.uk> Wed, 10 August 2016 15:05 UTC
Return-Path: <elwynd@folly.org.uk>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0D812B036; Wed, 10 Aug 2016 08:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eISG7Xx4RdLD; Wed, 10 Aug 2016 08:05:38 -0700 (PDT)
Received: from auth.a.painless.aa.net.uk (auth.a.painless.aa.net.uk [90.155.4.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CD8127078; Wed, 10 Aug 2016 08:05:38 -0700 (PDT)
Received: from brdgfw.folly.org.uk ([81.187.254.242] helo=[192.168.0.128]) by a.painless.aa.net.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <elwynd@folly.org.uk>) id 1bXUET-0002iP-Cn; Wed, 10 Aug 2016 15:11:46 +0100
Date: Wed, 10 Aug 2016 15:11:39 +0100
Message-ID: <e8724e55-e971-79cb-a045-cad04aaf5b66@folly.org.uk>
Importance: normal
From: Elwyn Davies <elwynd@folly.org.uk>
To: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_117725355565270"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ypoth3itkWSlY6nsq3QHeVmDHiQ>
Cc: General area reviewing team <gen-art@ietf.org>, draft-ietf-insipid-session-id.all@ietf.org
Subject: Re: [Gen-art] Gen-art LC review of draft-ietf-insipid-session-id-24
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Aug 2016 15:05:42 -0000
Hi, Paul.
Unfortunately, I should have pointed out that if you leave your
two primary definitions in RFC 7206, I think this becomes a
normative reference. RFC 7206 is informative rather than
standards track and so becomes the dreaded downref. Apart from
the process hassle this entails, you may be hard pushed to
persuade people that this is an appropriate downref. Copying them
over (and in the process checking they are still correct) is
rather less hassle IMO - and makes the RFC more
self-contained as regards its basic functionality.
Otherwise, this looks fine. I have looked into the INVITE/CANCEL
story a bit deeper, and think I see that all is well.
Regards,Elwyn
On 08/08/2016 19:32, Paul Giralt
(pgiralt) wrote:
Elwyn,
I went ahead and published an update that
incorporates your feedback.
https://www.ietf.org/rfcdiff?url2=draft-ietf-insipid-session-id-25
Note that I chose not to include the definition of
communication session in the draft because paragraph 1 of
section 3 already references RFC7206 for the definition.
Hopefully this addresses your concerns.
-Paul
On Aug 4, 2016, at 6:17 PM, Elwyn Davies <elwynd@folly.org.uk> wrote:
Hi.
Thanks for the very rapid response.
Most of this looks just fine.
Couple of points:
- On the conference CANCEL issue: My SIP
knowledge is severely lacking... could the CANCEL ever
apply to the original INVITE? If not it is probably
sufficient just to remind people that the M' UUID
would be used once the conference was joined. I guess
you might want to use M1 etc if the conferece joining
failed in some way. In any case I'd add a few words
to clarify which UUID they should be using - I'm not
sure it is totally obvious.
- On the s11 nit.. whether you need to do
something here depends on what the decision on the
spec of sess-uuid settles as.
I'd be happy to scan a pre-release of the
updated draft before publishing if you send it along.
Cheers,
Elwyn
Sent from Samsung tablet.
-------- Original message --------
From: "Paul Giralt (pgiralt)" <pgiralt@cisco.com>
Date: 04/08/2016 21:40 (GMT+00:00)
To: Elwyn Davies <elwynd@folly.org.uk>
Cc: General area reviewing team <gen-art@ietf.org>,
draft-ietf-insipid-session-id.all@ietf.org
Subject: Re: Gen-art LC review of
draft-ietf-insipid-session-id-24
Elwyn,
Thank you for the review. We should be
able to address these issues. See my comments
inline..
Minor issues:
Interoperability with H.323
The requirements for the Session Identifier
[RFC7206] Section 4.2 stresses
interoperability with H.323. This is
mentioned in passing in s1 and in a bit more
detail in s3. I think it would be worth
mentioning this somewhat more prominently and
that the relevant interoperability will
potentially be achieved since the format of
the Session-ID in H.460.27 appears to match
the one defined in this draft. To this end, I
suggest:
- Mentioning the interoperability in the
abstract and stating the ITU rec number - this
effectively indicates its 'use' in H.323 per
the end of para 1 in the abstract.
- Say a bit more about about interoperability
in s1, mention H.460.27 and give it as a
reference there also.
ok - sounds reasonable.
GIven that H.323 now supports the use of
Session Identifiers, it might be useful to
indicate how Session-IDs need to be handled at
SBCs [Caveat: I am not a SIP expert and this
may be trivial, but I think something probably
needs to be mentioned.]
An SBC interworking between H.323 and
SIP should still follow the rules of an
intermediary. This draft will define its behavior
for the SIP call leg and H.460.27 will define its
behavior for the H.323 call leg. I can put some
verbiage to this effect.
s4.1: Para 2 mentions the possible use of
Version 4 or Version 5 UUIDs. The last para
constrains stateless intermediaries to using
Version 5 UUIDs 'to ensure consistent
generation'. I am confused about whether
this consistency would be maintained if
endpoints and/or stateful intermediaries
generated Version 4 UUIDs, or whether in fact
all UUIDs should be Version 5?
Both Version 4 and Version 5 UUIDs
would be maintained for endpoints / stateful
intermediaries because they can retain the value
of the generated Version 4 UUID as part of that
state. The reason stateless intermediaries must
use Version 5 is they need a way to generate the
same UUID for the session without storing the UUID
between messages and a Version 4 UUID would not
provide this consistency.
s8, bullet 5, s6 , s7 and s9: If an endpoint
is involved in a multi-point conference has to
send a CANCEL message, which remote UUID
should it be using? The one that came back
with the original INVITE response or the one
used to identify the conference that is sent
in the re-INVITEs from the conference focus?
(e.g., in s10.4, for Alice M1 or M'). [Note
lack of SIP expertise: I am not sure if there
are circumstances in which this would arise.]
CANCELling a re-INVITE would be
unusual and unlikely to happen in the scenario you
describe, but is technically possible. As
mentioned in s8, bullet 5, the Session-ID header
field value in the CANCEL request MUST be
identical to the Session-ID header field value in
the corresponding INVITE. In this case, because
the CANCEL corresponds to the re-INVITE, the
Session-ID header field value would be that of the
re-INVITE, as that is the transaction being
cancelled. I think the draft as it stands is clear
enough on the expected behavior but can modify if
you feel strongly that this should be clarified.
Nits/editorial comments:
s1, paras 1 and 3; s2, last para : s/like/such
as/ (total of 3 places)
Will change. Thanks.
s2: There is no definition of the term
'communication session' in the draft. A
definition is given in s3.2 of RFC 7206 and
H.460.27 has:
3.2.1
communication session: A communication
session, or simply ''session'', refers to a
call or series of calls initiated or
received by an endpoint for which the
endpoint utilizes the same universally
unique identifier (UUID) value in call
signalling messages. From a calling user's
perspective, this would be all call
signalling messages from the time the user
initiates a call until the time the call is
terminated. From the called user's
perspective, this would be all call
signalling messages from first message
received by the user's terminal until the
call is terminated.
I’m good with copying this text from
7206 into Section 2.
In the light of the interoperability question,
should the definition say something about
SBCs? And how the session identifier is
generated/interpreted in a 'session' that
extends across an interconnected SIP/H.323
network? Would SBC be an 'intermediary'
within the meaning of the definition in s2?
Yes, it would be considered an
intermediary except Section 2 specifically calls
out intermediaries as being “any SIP entity”. It
might be softening the language there to include
any intermediaries that are interworking between
SIP and another protocol that also supports the
Session Identifier defined in this draft.
Section 7, which discusses the
behavior of intermediaries, already notes that
SBC’s are a type of intermediary, so don’t think
we need to make that callout.
s2,
last para: The expansion of the B2BUA acronym
occurs on the second instance rather than the
first that is a couple of lines earlier.
Good catch. Thanks.
s4.2, end of para 2 and in many places
thereafter: The 'null UUID' is known as the
'nil UUID' in s4.1.7 of RFC 4122. For
consistency s/null/nil/g. A reference to
s4.1.7 of RFC 4122 should be added to the
first instance in s4.2.
Thanks for this. I wasn’t aware of this and makes
sense to use consistent naming from 4122.
s5: Given that RFC 7329 will be obsoleted by
this document, it would be desirable to copy
the gist of the statements in the first para
of s7 of RFC 7329:
This document adds the "Session-ID" token to the definition of the
element "message-header" in the SIP message grammar. The Session-ID
header is a single-instance header.
Something like an additional para at the
beginning of s5:
This document replaces the definition of
the "Session-ID" token that was added to the
definition of the
element "message-header" in the SIP message
grammar by [RFC7329]. The Session-ID
header is a single-instance header.
Sounds reasonable. I can add something
along those lines for clarity.
s5, para 3:
OLD:
The UUID values for each endpoint are inserted
into the "Session-ID"
header field of all transmitted SIP
messages.
This is potentially confusing when it comes to
conference calls as there may be more than two
endpoints involved in a communication session
if it is a multi-point conference. Maybe
NEW:
Any SIP message associated with a
communication session has the UUIDs for the
session created by the message source and
destination endpoints inserted into the
"Session-ID header field of the transmitted
SIP message.
END
Let me see how I might be able to
clarify this for the multipoint use case where
there are more than two endpoints in the session.
I don’t think your new version is as clear as it
could be either.
s5, last para:
The Session-ID header field value is technically case-INSENSITIVE,
but only lowercase characters are allowed in the sess-uuid
components. Receiving entities MUST treat sess-uuid components as
case-insensitive and not produce an error if an uppercase hexadecimal
character is received.
I know this is partly carried over from RFC
7329, but, as currently drafted, it seems
pointless. Can we not just have:
sess-uuid = 32(DIGIT /
%x41-46 / %x61-66) ;32 chars of [0-9A-Fa-f]
If the reasoning is that sending upper case to
'old' implementations will break them, then it
would be better to be explicit about it.
Perhaps, replace the para with:
To allow interoperation
with implementations conforming to the
pre-standard specification in [RFC7329],
implementations SHOULD use
only lower case letters ("a" - "f") in
the sess-uuid field.
To be honest I’m not sure why this was
written this way originally and, like you say, it
was just carried over from 7329. Will look into
whether we should make a change here.
s6, para 2: There could be some minor
confusion as to whether the 'no change of
UUID' rule is broken when a conference focus
(per s9 and the examples in s10) changes its
UUID after processing the initial INVITE and
issuing a re-INVITE with a different UUID
associated with the conference. Some words
covering (I guess) the idea that the
conference itself is a different communication
session from the setup request(s) would be
useful. See also the comments on s10.4 in
Minor Issues above.
Section 6 describes Endpoint behavior
so don’t think a change is needed there, but could
possibly add some text in Section 9 that describes
what is shown in the example in section 10.4.
s6 and s7, next to last paras: These are near
duplicates. They could be replaced by a
single instance at the end of s5, but no big
deal.
I’m not totally sure if it makes sense
as-is in section 5, but could probably modify
slightly to make it fit into section 5.
s7, para 12: Expand 3PCC on first use.
Will do. Thanks.
s7, para 12:
s/locally-frabricated/locally-fabricated/
Thanks.
s8, bullet 5: s/487/Request Terminated (487 -
see Section 15.1.2 of [RFC3261])
Ok. Thanks.
s10.1, start of expansion of SIP messages:
I think there is a missing 'example.'...
OLD:
INVITE sip:bob@biloxi.com
SIP/2.0
NEW:
INVITE sip:bob@biloxi.example.com
SIP/2.0
END
Nice catch. Thanks!
s11: Effectively there is another new/old
requirement: the sess-uuid field has to use
lower case letters (probably).
The old and the new both specify the
identifier is lowercase, so not sure what needs to
change here.
s12, para 3:
I think 'inherit' is not what you mean here...
OLD:
Because of the inherit property that Session
Identifiers are conveyed
end-to-end
NEW
Because of the inherent property that Session
Identifiers are conveyed
end-to-end
END
Yes, thanks for the correction.
s13.2: As of this moment, no header parameters
have been registered for the old RFC 7329
Session-ID header. I don't know if any
proprietary, non-documented parameters are
around given the status of RFC 7329, but would
it be worth explicitly banning the
registration of any new parameters under the
old scheme - and maybe explicitly not allowing
any other parameters than 'remote' for the
new version, to avoid issues of privacy etc.
If not it might be necessary to copy over some
of the words about the nature of parameters in
Session-ID headers and what B2BUAs might have
to do from the security considerations of RFC
7329.
I’d actually prefer to leave
generic-param as allowed so that this version could
interoperate with any potential future version that
might add additional parameters. Explicitly banning
such additional parameters could cause issues if we
decide to extend the capabilities in a future draft.
That said, some mention along the same lines as
specified in 7329 are worth considering so that
arbitrary additional parameters are not added which
could then lead to privacy issues. Let me chew on
this one…
-Paul
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
- Re: [Gen-art] Gen-art LC review of draft-ietf-ins… Elwyn Davies
- Re: [Gen-art] Gen-art LC review of draft-ietf-ins… Paul Giralt (pgiralt)
- Re: [Gen-art] Gen-art LC review of draft-ietf-ins… Paul Giralt (pgiralt)
- Re: [Gen-art] Gen-art LC review of draft-ietf-ins… Paul Giralt (pgiralt)
- Re: [Gen-art] Gen-art LC review of draft-ietf-ins… Elwyn Davies
- Re: [Gen-art] Gen-art LC review of draft-ietf-ins… Paul Giralt (pgiralt)
- [Gen-art] Gen-art LC review of draft-ietf-insipid… Elwyn Davies