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

[Shida Schubert <[e-mail]>]

Hi Mary;

 Thanks for the thorough reviews and suggestions. 

 I will prepare a revised draft before and submit the 
draft after the blackout period is cleared  reflecting 
the suggestions and comments you and Paul provided. 

 Many Thanks
  Shida

On Oct 29, 2013, at 7: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
> 
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch