[SIPForum-techwg] Interoperability Draft v3 - scope andconformance

[Chris Sibley]

Alan Johnston wrote:

> RFC 3261 deprecates Basic Authentication, so we do not want to
recommend
> it here.  The previous RFC referenced here was the MD5 spec, and I
> suggested it be changed to RFC 2617 since this is what RFC 3261
> references.  However, I am also uncomfortable with the mention of
> Basic.  This should either be qualified to say excluding Basic
> Authentication, or instead reference Section 22.4 of RFC 3261.

I am comfortable with removing the explicit reference to RFC 2617, since
(as Alan pointed out) RFC 3261 references it specifically, along with
some important caveats (e.g. you can't use basic authentication.)

Assuming all agree, my suggestion would be to 1) remove the references
to 2617 and 2) improve the wording in section 9.1 for the next draft
revision.

Thanks,

--Chris


> 

**********************************************************************
This email may contain confidential information. If you are not
the intended recipient, please advise by return email and delete
immediately without reading or forwarding to others.
 - Cbeyond 
**********************************************************************-----Original Message-----
> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On
> Behalf Of Alan Johnston
> Sent: Tuesday, December 13, 2005 12:01 PM
> To: Horvath Ernst
> Cc: SIP Forum Tech WG
> Subject: Re: [SIPForum-techwg] Interoperability Draft v3 - scope
> andconformance
> 
> Hi Ernst,
> 
> I have a few responses to your excellent comments, as some of the text
> you are questioning was my suggestion.  I'll leave the rest for Chris
;-)
> 
> Thanks,
> Alan Johnston
> sip:ajohnston at tello.com
> 
> Horvath Ernst wrote:
> 
> >Chris,
> >
> >Section 5, standards support, is a formal statement of conformance
> >requirements and should therefore be as clear and exact as possible.
> >Unfortunately this is not the case since section 5 does not explain
what
> >support of an RFC exactly means - nearly all the RFCs listed define
> >various roles and functions which may not all be relevant in our
case.
> >IOW, a global conformance request is not specific enough in many
cases.
> >
> >Perhaps it would help if you added some text to section 5 to say that
> >the RFCs must be supported as specified in subsequent sections of
this
> >specification.
> >
> >Another big problem is that for some of the RFCs listed in section 5
> >there are no use cases in the rest of the document although they are
> >marked as mandatory (e.g. REFER, Referred-by, event framework, MWI).
My
> >proposal is to either remove those RFCs for this 1st edition or add
some
> >text in subsequent sections with at least a rudimentary description
of
> >their intended use (for example, must the SAS or PBX be able to act
as
> >subscriber or as notifier or both? Must the SAS or PBX be able to
send
> >or to receive REFER messages, and what can be included in a REFER?).
> >
> >Finally, in section 16, references, nearly all informative references
> >(16.2) are marked M in section 5, so should those references be
> >normative and moved to 16.1?
> >
> >
> >Some nits:
> >
> >- In section 3 change "legal" to "conformant".
> >
> >- In section 3 a firewall would not provide address/port translation
- a
> >NAT would do that.
> >
> >- In section 4, point 2 says that signalling considerations between
the
> >SIP Application Server, Trunking Gateway and Signalling Gateway are
> >outside scope. Should there be a similar statement about signalling
> >considerations between the IPPBX and IP phones?
> >
> >- Also in section 4, is signalling between a SIP Proxy Server and a
SIP
> >Application Server or between a SIP Proxy Server and an IPPBX within
or
> >outside the scope of this document?
> >
> >- Depending on the answers to the previous two comments, is the scope
of
> >this document limited to signalling between the two SIP Proxy
Servers?
> >
> >- In section 5, RFC 3264 could be implemented by phones without any
PBX
> >involvement, so why is it mandated for PBX? Similarly for RFC 2833,
and
> >for recommended RFC 3959 and 3960.
> >
> >- Also in section 5, what is the relevance of Basic Authentication
(RFC
> >2617)?
> >
> >
> >
> RFC 3261 deprecates Basic Authentication, so we do not want to
recommend
> it here.  The previous RFC referenced here was the MD5 spec, and I
> suggested it be changed to RFC 2617 since this is what RFC 3261
> references.  However, I am also uncomfortable with the mention of
> Basic.  This should either be qualified to say excluding Basic
> Authentication, or instead reference Section 22.4 of RFC 3261.
> 
> >- What is the relevance of 3rd party call control, which is M for the
> >SAS and R (receive only) for the PBX? How can the PBX recognise a
3pcc
> >call?
> >
> >
> Support of 3pcc by a UA (not acting as a controller) requires a few
> things - accepting O/A exchanges in the 200 OK/ACK instead of
INVITE/200
> OK exchange and also some SDP such as held SDP and SDP with no media
> lines (see Section 5 of
> http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-answer-
> examples-06.txt).
> Perhaps these should be explicitly mentioned in this recommendation.
> 
> >- Mandatory PKI support is implied by text on TLS, but the only
> >reference related to PKI is RFC 2560 (OCSP). Why was this particular
one
> >picked - an implementation can use other ways of checking a
certificate.
> >Should other PKI RFCs be added as well?
> >
> >
> >
> I don't agree that mandatory PKI support is required by this
> recommendation.  I do agree that the text only mentioning OCSP is not
> quite right.   I  think it should say something like the following:
> 
> Certificates received over TLS MUST be verfied and MAY be validated.
> Verification steps include verifying that the certificate has not
> expired, that the issuing CA is one the PBX trusts, and finally that
the
> subject of the certificate matches the server's host name or SIP URI.
> Validation can be performed using a CRL, OCSP, or other approaches.
> 
> If you agree with a statement such as the one above, are there any
other
> PKI RFCs that need to be referenced?
> 
> >Thanks,
> >Ernst Horvath
> >Siemens AG
> >
> >
> >
> >_______________________________________________
> >techwg mailing list
> >Send mail to: techwg at sipforum.org
> >Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg
> >
> >
> >
> >
> 
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg