Hi Ben,
I have also read the draft and everything was clear to me and seemed
easy to read until I reached 6.1 and 6.2.
One suggestion I have to make the text more readable is to separate
the
problem description from the solution. Meaning today it's:
1. Problem 1 & actions
2. Problem 2 & actions
3. Problem 3 & actions
I'm proposing to change it to
l. Problem 1
2. Problem 2
3. Problem 3
Describe each problem/scenario without describing the solution and
give
examples if needed.
Following that provide all the recommended actions.
Implementers should have an easy way to see and understand all the
changes they require to conform to the RFC. For example, In RFC 4320
it's easy to follow through because it describes the changes very
simply
(the problems are described in more detail in RFC 4321). I'm not
suggesting changing this draft into 2 RFCs, just asking to focus on
the
problems and then focus on the actions.
In any case maybe there's a different solution for this and maybe it's
just me, but I fear that if the text would not be clear enough then
many
vendors would have a hard time assessing the effort needed to
implement
it and thus the adoption rate of this spec would be affected.
Final note - section 7 has a summary that may or may not provide all
necessary actions, but I simply had a lot to go through in section 6
that I almost never reached section 7.
Thanks,
Gilad
-----Original Message-----
From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of
Dean Willis
Sent: Friday, August 14, 2009 12:12 AM
To: BONNAERENS Ben
Cc: sip at ietf.org
Subject: Re: [Sip] draft-ietf-sip-record-route-fix-08 Changes
On Aug 13, 2009, at 6:46 AM, BONNAERENS Ben wrote:
Hello Dean,
Sorry to make your head hurt ;-)
To me the -09 sentence was clear but I do think you have a point on
the
compound sentences.
Still I would like to comment on the "only" in following sentence of
the
text you proposed:
"The second is for the URI placed in the Record-Route to be
constructed
such that application of RFC
3263 resolution procedures to that URI produces a result reachable
only
using TLS."
Why should that URI _only_ be reachable via TLS?
The DNS for that URI can be populated with NAPTR records
for multiple transports with TLS as preferred I assume.
Dunno WHY it should say that; that's what I thought I read in the
compound sentence I was trying to straighten out.
Hmm. Could it be that since SIPS (draft-ietf-siip-sips) requires e2e
TLS even more strongly than did 3261 for original sips URIs. So if a
URI used in a record-route resolves both TLS and non-TLS, there's a
possibility that the return stroke might not use TLS, thereby breaking
the e2e TLS requirement. But your proposed wording change seems to
have the same effect.
I would also replace "sips: URI" by "SIPS URI" to be consistent
across
the document.
That makes sense; I responded in the wording I thought Robert had
used. But consistency with the document would be preferred. Your
usage is also consistent with draft-ietf-sip-sips.
Resulting in following updated text:
"When TLS is used on the transport on either side of the proxy,
the URI placed in the Record-Route header field MUST encode
a next-hop that will be reached using TLS. There are two
ways for this to work. The first way is for the URI placed in the
Record-Route to be a SIPS URI.The second is for the URI placed in
the Record-Route to be constructed such that application of
[RFC3263] resolution procedures to that URI results in TLS being
selected.
Proxies compliant with this specification MUST NOT use a
"transport=tls"
parameter on the URI placed in the Record-Route because the
"transport=tls" usage was deprecated by RFC 3261."
Can we agree on this text?
Looks OK to me.
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip