Re: draft-ietf-sip-record-route-fix-08 Changes

Hi Gilad -

This document is already very far along the process, we are doing fine- 
tuning based on IESG review
and while I truly appreciate insight that will make a document more  
readable, it would not be appropriate
to restructure the text at this time.

I hope more reviewers of future documents show the same kind of  
concern for the implementer you
exhibit here.

RjS

On Aug 14, 2009, at 9:28 AM, Gilad Shaham wrote:

> 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: [email protected] [mailto:[email protected]] On Behalf Of
> Dean Willis
> Sent: Friday, August 14, 2009 12:12 AM
> To: BONNAERENS Ben
> Cc: [email protected]
> 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 [email protected] for questions on current sip
> Use [email protected] 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 [email protected] for questions on current sip
> Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip