Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind

[Shida Schubert <[e-mail]>]

Why don't we just reword it to say 

 "SIP proxy MAY insert the indication from R1" 

 Whether it is a can or MAY what we are ultimately trying to say is that 
proxy MAY insert the indication from R1 right? We are not preventing 
it and I am assuming as a spec, we want to let the implementer know 
that proxy MAY send requests with these values. 

 Regards
  Shida

On Jan 9, 2014, at 7:22 AM, Mary Barnes <[e-mail]> wrote:

> Then, why are those even requirements?  
> 
> Mary. 
> 
> 
> On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) <[e-mail]> wrote:
> The text from RFC 2119 states:
>  
>  5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
>    truly optional.  One vendor may choose to include the item because a
>    particular marketplace requires it or because the vendor feels that
>    it enhances the product while another vendor may omit the same item.
>    An implementation which does not include a particular option MUST be
>    prepared to interoperate with another implementation which does
>    include the option, though perhaps with reduced functionality. In the
>    same vein an implementation which does include a particular option
>    MUST be prepared to interoperate with another implementation which
>    does not include the option (except, of course, for the feature the
>    option provides.)
> My belief is that we are not defining an option here, and it is certainly not a vendor decision. Further we are not identifying an interoperability issue here.
> We are defining a possibility that a valid implementation can take. 
>  If you go to the procedures you will see both these items are covered with "If <condition> MUST" type sentences. There is no specified optionality.
>  Keith
> From: dispatch [mailto:[e-mail]] On Behalf Of Shida Schubert
> Sent: 09 January 2014 06:30
> To: Mary Barnes
> 
> Cc: DISPATCH
> Subject: Re: [dispatch] New Version of draft-vanelburg-dispatch-private-network-ind
> 
> 
> Hi Mary;
> 
>  Thanks for reviewing the document again. 
> 
> On Jan 6, 2014, at 3:03 PM, Mary Barnes <[e-mail]> wrote:
> 
>> Hi all,
>> 
>> I have reviewed the revised version and I just a few final comments.
>> 
>> - Section 1.5, first bullet in the bulleted list: either change "an emergency calls" to "an emergency call" or "emergency calls"
>> 
> 
>  I will fix it with "emergency calls"
> 
>> - Section 3.6.  "require the Specifying a Spec (T)." -> "require specifying a Spec(T)" or "require the specification of a Spec(T)"
>> 
>  
>  I will fix it with "require the specification of a Spec(T)"
> 
>> - Section 5, I had suggested the the requirements be consistent in usage of 2119 language.  One of the requirements (R6) was changed, but R2 and R3 were not.  Was there a specific reason not to make those suggested changes?   
>> 
>> R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy"   
>> R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy"
> 
>  So I reverted the change after Keith told that the requirements above is not stating 
> a normative behaviour and that he believes "can" is more appropriate. 
> 
>  I am okay either way. 
> 
>  I will create a version with "MAY". 
> 
>  Keith, please provide comments if you have a strong opposition to changing it to "MAY".
> 
>  Thanks! 
>   Shida
> 
>> 
>> Thanks,
>> Mary. 
>> 
>> 
>> On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes <[e-mail]> wrote:
>> In reviewing the document in preparation for the PROTO write-up, I have a few comments (minor and nits) that should be addressed prior to the document being progressed.
>> 
>> Regards,
>> Mary.
>> 
>> Comments:
>> ---------------
>> 
>> - General: domains used in this document must use a reserved domain such as "example.com" and must not use real domains. Thus, all occurrences of ericsson.com need to be changed to example.com
>> 
>> - Section 1.5.  Bulleted list, first bullet. I would suggest you just leave out the mention of LI.  Emergency services should be a sufficient example.  
>> 
>> - Section 1.5, last numbered list, item 2.  I had a hard time groking this sentence and had to read several times. I would suggest rewording something like (if I've properly interpreted the intent):
>> OLD:
>>        Different nodes spanning over different networks may need to be
>>        able to act differently on type of traffic, when implicit schemes
>>        are used, it would require distribution of such enterprise
>>        specific logic over multiple nodes in multiple operators.  That
>>        is clearly not a manageable architecture and solution.
>> 
>> NEW: 
>>        Nodes spanning multiple networks often need to have different 
>>        behavior depending upon the type of traffic.  When this is done using implicit
>>        schemes, enterprise specific logic must be distributed across multiple
>>        nodes in multiple operator's networks.  
>>        That is clearly not a manageable architecture and solution.
>> 
>> 
>> - Section 1.5, last sentence.  I don't think that statement is sufficient for what this document is doing. I would suggest you change that sentence to something like the following:
>> OLD:
>>    Given the above background this document will formulate requirements
>>    for SIP to support an explicit private network indication.
>> 
>> NEW: 
>>    Based on the background provided, this document formulates requirements
>>    for SIP to support an explicit private network indication and defines 
>>    a P-header, P-Private-Network-Indication, to support those requirements. 
>> 
>> 
>> - Section 3, next to last paragraph.  I'm not sure what is meant by "the filling out a Spec(T)". I don't see "filling" used as a concept in RFC 3324.  Perhaps, "specifying a Spec(T)" is more consistent with terminology in RFC 3324. 
>> 
>> - Section 5.  In general, the requirements are not specific consistently - i.e., some use 2119 language and others not and there is not consistent capitalization.  I would suggest the following changes.
>> R2:   "The indication from R1 can be inserted by a SIP proxy" -> "The indication from R1 MAY be inserted by a SIP proxy"   
>> R3: "The indication from R1 can be removed by a SIP proxy" -> "The indication from R1 MAY be removed by a SIP proxy"
>> R6: "must" -> "MUST"
>> 
>> - Section 6, 2nd paragraph. The "can" in the first sentence should be a "MAY" and the sentence needs to be split into two:
>> OLD:
>>    A proxy server which handles a message can insert such a P-Private-
>>    Network-Indication header field into the message based on
>>    authentication of the source of a message, configuration or local
>>    policy, and forward it to other proxies in the same administrative
>>    domain or proxies in trusted domain to be handled as private network
>>    traffic. 
>> 
>> NEW: 
>>    A proxy server which handles a message MAY insert such a P-Private-
>>    Network-Indication header field into the message based on
>>    authentication of the source of a message, configuration or local
>>    policy.  A proxy server MAY forward the message to other proxies in the 
>>    same administrative domain or proxies in a trusted 
>>    domain to be handled as private network traffic. 
>> 
>> 
>> 
>> Section 9.  You should be explicit about the header name in this section.  The text in the first paragraph needs some work.  At a minimum you need to change the "not supposed to" to something more definitive as all security issues arise because someone does something they're not supposed to.   I would suggest at least making the following change:
>> OLD:
>>    The private network indication defined in this document is to be used
>>    in an environment where elements are trusted and where attackers are
>>    not supposed to have access to the protocol messages between those
>>    elements.  Traffic protection between network elements is sometimes
>>    achieved by using IPsec and sometimes by physical protection of the
>>    network.  In any case, the environment where the private network
>>    indication will be used ensures the integrity and the confidentiality
>>    of the contents of this header field.
>> NEW:
>>    The private network indication defined in this document MUST only be used
>>    in an environment where elements are trusted and where attackers are
>>    do not have access to the protocol messages between those
>>    elements.  Traffic protection between network elements can be
>>    achieved by using IPsec and sometimes by physical protection of the
>>    network.  In any case, the environment where the private network
>>    indication will be used ensures the integrity and the confidentiality
>>    of the contents of this header field.
>> 
>> 
>> Nits:
>> ------
>> - Section 1.1:  "3rd-Generqation" -> 3rd-Generation  
>> - The terms "break-in" and "break-out" traffic are used several places in the document, but this term is never defined.  These terms should be defined in Section 3. 
>> - Figures should have Titles for readability
>> 
>> 
>> 
>> On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <[e-mail]> wrote:
>> Hi,
>> 
>> I have submitted the following draft:
>> 
>> http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-network-ind-03.txt
>> 
>> The draft reflects all the comments discussed in DISPATCH list.
>> 
>> The major changes are as follows:
>> 
>> - corrected the abstract
>> - corrected the term "common domain" to "pre-arranged domain"
>> - added 7.1.4 "P-Private-Network-Indication verification"
>> - editorial changes
>>                                                                                   Regards,
>> Mayumi
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
>> 
> 
>