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

[Shida Schubert <[e-mail]>]

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
> 
>