Subject: [Sip] WGLC draft-ietf-sip-consent-framework-00

From: [email-masked]
Date: Wed, 18 Oct 2006 01:25:07 +0000

I'm posting this from my private email as my Outlook server has been down this afternoon and doesn't appear to be recovering this evening.  

Draft:  draft-ietf-sip-consent-framework-00.txt
Reviewer: Mary Barnes [[email-masked]]
Review Date: 17 October 2006
Review Deadline: 17 October 2006
Status: WGLC 

Summary:  This draft is on the right track but has an issue and a few nits, described in the review.

Issues:
-------
- Section 4.3: I share the concern that Ben raised in his review with regards to this framework not making any recommendations about (or defining) a store-and-forward mechanism.  The off-line user issue is real and it would seem to be a large impediment to deployment of this functionality if there is not a recommendation for a must implement mechanism.  I don't expect this document to define the functionality since it is more general, but it does seem a requisite for this draft.

Nits:
------
- General: the term "Translation Logic" is used almost interchangeably with "Translation Operation", although only the latter term is defined in section 2. It would make this document a bit easier to follow, if a single term was used, provided they do mean the same thing.   Also, there is sometimes an "s" added to the use of the word "logic" - this likely is incorrect and should be changed if that term remains in the document. 

-Section 3, 1st paragraph following Figure 1: the wording is a bit awkward and reads as if it's redundant, although it's not. Propose rewording to something like the following:
OLD:
   Thus, an essential aspect of a relay is that of translation.  When a
   relay receives a request, it translates, following its translation
   logic, the Request-URI into one or more additional URIs.  That is,
   the relay can create outgoing requests to one or more additional
   URIs.  The translation operation is what creates the consent problem.
NEW:
   Thus, an essential aspect of a relay is that of translation.  When a
   relay receives a request, it translates the Request-URI into one or
   more additional URIs. Through this translation operation, 
   the relay can create outgoing requests to one or more additional
   URIs, thus creating the consent problem.

- Section 5.3, 5th paragraph, last sentence:
OLD:
  The MESSAGE request also carry ...
NEW: 
  The MESSAGE request also carries ...

- Section 5.9, 3rd paragraph, 1st sentence:
OLD: 
   ... this type of URI-list services behave in a slight different way...
NEW: 
   ... this type of URI-list services behave in a slightly different way...

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 25 Oct 2006 16:18:50 +0300

Hi Mary,

thanks for your comments. Answers inline:

[email-masked] wrote:
> I'm posting this from my private email as my Outlook server has been 
> down this afternoon and doesn't appear to be recovering this evening. 
>  
> - Section 4.3: I share the concern that Ben raised in his review with 
> regards to this framework not making any recommendations about (or 
> defining) a store-and-forward mechanism.  The off-line user issue is 
> real and it would seem to be a large impediment to deployment of this 
> functionality if there is not a recommendation for a must implement 
> mechanism.  I don't expect this document to define the functionality 
> since it is more general, but it does seem a requisite for this draft.

I already addressed Ben's comment regarding this issue in a previous email.

> Nits:
> ------
> - General: the term "Translation Logic" is used almost interchangeably 
> with "Translation Operation", although only the latter term is defined 
> in section 2. It would make this document a bit easier to follow, if a 
> single term was used, provided they do mean the same thing.   Also, 
> there is sometimes an "s" added to the use of the word "logic" - this 
> likely is incorrect and should be changed if that term remains in the 
> document.

I have removed the 's'es and added the following definition to the 
Definitions and Terminology Section:

   Translation logic: The logic that defines a translation operation at
       a relay.  This logic includes the translation's target and
       recipient URIs.

> -Section 3, 1st paragraph following Figure 1: the wording is a bit 
> awkward and reads as if it's redundant, although it's not. Propose 
> rewording to something like the following:
> OLD:

I have replaced the text per your suggestion, keeping AC's 
clarifications in brackets:

    Thus, an essential aspect of a relay is that of translation.  When a
    relay receives a request, it translates the Request-URI (target URI)
    into one or more additional URIs (recipient URIs).  Through this
    translation operation, the relay can create outgoing requests to one
    or more additional URIs, thus creating the consent problem.

>   The MESSAGE request also carries ...

Done.

>    ... this type of URI-list services behave in a slightly different way...

Done.

I have posted a working copy of the new revision of this draft at:

http://users.piuha.net/gonzalo/temp/draft-ietf-sip-consent-framework-01.txt

Cheers,

Gonzalo