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

[Mary Barnes <[e-mail]>]

That works for me.


On Mon, Jan 13, 2014 at 2:32 PM, Shida Schubert <[e-mail]> wrote:

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