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

[Mary Barnes <[e-mail]>]

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