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

From: Mary Barnes <[email-masked]>
Date: Mon, 6 Jan 2014 17:03:53 -0600

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 <[email-masked]>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 <[email-masked]
> > 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
>

---

From: Shida Schubert <[email-masked]>
Date: Wed, 8 Jan 2014 22:29:49 -0800

Hi Mary;

 Thanks for reviewing the document again. 

On Jan 6, 2014, at 3:03 PM, Mary Barnes <[email-masked]> wrote:

> - 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 <[email-masked]> 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:
> - 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:
> - 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:
> 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 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. 
> On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <[email-masked]> wrote:
> Hi,
> 
> http://www.ietf.org/internet-drafts/draft-vanelburg-dispatch-private-network-ind-03.txt
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 9 Jan 2014 11:05:45 +0000

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:[email-masked]] 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;

On Jan 6, 2014, at 3:03 PM, Mary Barnes <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

 I am okay either way.

 Thanks!
  Shida

Thanks,
Mary.

On Tue, Oct 29, 2013 at 9:11 AM, Mary Barnes <[email-masked]<mailto:[email-masked]>> 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<http://example.com/>" and must not use real domains. Thus, all occurrences of ericsson.com<http://ericsson.com/> need to be changed to example.com<http://example.com/>

NEW:

NEW:

NEW:

NEW:

Nits:
------

On Wed, Sep 11, 2013 at 9:19 PM, Mayumi Ohsugi <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

- corrected the abstract
[email-masked]<mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Thu, 9 Jan 2014 09:22:48 -0600

Then, why are those even requirements?

Mary.

On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

> 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.
>
>   ------------------------------
> *From:* dispatch [mailto:[email-masked]] *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;
>
>  - 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
>>  - 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, 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:
>>
>>  - 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:
>>
>>  - 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
>>  - 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.
>>  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:
>>

---

From: Shida Schubert <[email-masked]>
Date: Mon, 13 Jan 2014 12:32:17 -0800

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 <[email-masked]> wrote:

> On Thu, Jan 9, 2014 at 5:05 AM, DRAGE, Keith (Keith) <[email-masked]> wrote:

---

From: Mary Barnes <[email-masked]>
Date: Mon, 13 Jan 2014 14:37:48 -0600

That works for me.

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

>>  - 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?
>>
>>
>>> 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
>>>  - Section 6, 2nd paragraph. The "can" in the first sentence should be
>>> a "MAY" and the sentence needs to be split into two:
>>> OLD:
>>>
>>> - 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.