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

[Mary Barnes <[e-mail]>]

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"

- Section 3.6.  "require the Specifying a Spec (T)." -> "require specifying
a Spec(T)" or "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"

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