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-boun...@ietf.org [mailto:sip-boun...@ietf.org] On Behalf Of Dean Willis Sent: Friday, August 14, 2009 12:12 AM To: BONNAERENS Ben Cc: sip@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-implement...@cs.columbia.edu for questions on current sip Use sipp...@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-implement...@cs.columbia.edu for questions on current sip Use sipp...@ietf.org for new developments on the application of sip
