Re: Fwd: Expert review ofdraft-vanelburg-sipping-private-network-indication-03

Draft has been uploaded as
http://tools.ietf.org/html/draft-vanelburg-dispatch-private-network-ind-00

Best Regards,
/Hans Erik van Elburg

On Mon, Jul 6, 2009 at 11:42 AM, Hans Erik van Elburg <
[email protected]> wrote:

> Hi John,
>
> 1. Done, moved 10 up and inserted as 1.2. Added the following sentence to
> 1.1:
> "3GPP and ETSI TISPAN have identified a set of requirements that can be met
> by defining a new SIP P-header, according to the procedures in RFC 3427
> [RFC3427]."
> 2. Done
> 4a. Done
> 4b. Done
> 4c. Done
> 5. I added the following terminology description:
>
> "3.1. Traffic
>
> In the context of this document the term traffic is understood as all
> communication pertaining to and/or controlled by a SIP transaction or
> dialog."
>
> 8. Done
>
> Will upload this as cutoff day for 00 drafts is today.
>
> /Hans Erik van Elburg
>
>
>
> On Mon, Jul 6, 2009 at 8:52 AM, Elwell, John <
> [email protected]> wrote:
>
>> Hans Erik,
>>
>> > -----Original Message-----
>> > From: [email protected]
>> > [mailto:[email protected]] On Behalf Of Hans Erik van Elburg
>> > Sent: 03 July 2009 15:17
>> > To: Elwell, John; DRAGE, Keith (Keith)
>> > Cc: IETF Sipping List
>> > Subject: [Sipping] Fwd: Expert review
>> > ofdraft-vanelburg-sipping-private-network-indication-03
>> >
>> > Resent and history removed as otherwise rejected by mailing list.
>> >
>> > Hi John,
>> >
>> > 1. Again the required applicability statement is in section
>> > 10 of the main body. (Same pattern has been followed in
>> > RFC5502, 5002 and 4457) which I took as examples. Together
>> > with the additional text in the abstract that should be
>> > sufficient. If the text in section 10 needs to be improved
>> > then please indicate so.
>> [JRE] I must have written the original comment 1 before I got down to
>> section 10. Basically section 10 is far too late in the document, and I
>> would have expected the statement, perhaps as section 1, or perhaps as a
>> section 1.2 before the existing 1.2.
>>
>>
>> >
>> > 2. Took in your nits, the abstract now reads:
>> >       "This document specifies the SIP P-Private-Network-Indication
>> > P-header. The use of this private network indication extension
>> > is only applicable inside an administrative domain with
>> > previously agreed-upon policies for generation, transport and
>> > usage of such information.  A private network indication
>> > allows nodes in such a domain to treat private network traffic
>> > according to a different set of rules then than the set
>> > applicable to public network traffic. The indication also
>> > distinguishes traffic from one private network from another
>> > private network."
>> [JRE]
>> Delete the word "then".
>>
>> >
>> > 4a. Regarding 1.2 item b). Would the following rewrite help?:
>> > OLD:
>> > " b) business trunking application, where the NGN hosts
>> > transit capabilities between NGCN's, break-in capabilities
>> > from NGN to NGCN and break-out capabilities from NGCN to NGN; and"
>> > /OLD
>> >
>> >
>> > NEW:
>> > " b) business trunking application, where the NGN hosts
>> > transit capabilities between NGCN's, break-in capabilities
>> > where the NGN converts public network traffic to private
>> > network traffic for delivery at a served NGCN and break-out
>> > capabilities where the NGN converts private network traffic
>> > from a served NGCN to public network traffic; and"
>> >
>> > /NEW
>> >
>> > If not please suggest an improved sentence that covers your
>> > concern. Please note that in the example that you gave it is
>> > not the business trunking application that does the
>> > conversion, but the hosted enterprise application.
>> [JRE] That would do.
>>
>>
>> >
>> > 4b. "normal rules"
>> > Looking at the definition, would the following rewrite help:
>> > OLD
>> > " Traffic sent to or received from a public telecommunication
>> > network for processing according to the normal rules."
>> > /OLD
>> >
>> > NEW
>> > " Traffic sent to or received from a public telecommunication
>> > network for processing according to the rules for ordinary
>> > subscribers of a public telecommunication network."
>> > /NEW
>> [JRE] That would do.
>>
>> >
>> > 4c. NGN is a public telecommunication network
>> > >       - "To summarize a few example reasons for a public
>> > telecommunication network to make the distinction between the
>> > two types of traffic" Isn't it an NGN that needs to make the
>> > distinction?
>> > > [HE] NGN is a public telecommunication network. But we can
>> > rephrase to: "To summarize a few example reasons for a public
>> > NGN to make the distinction between the two types of traffic" [/HE]
>> [JRE] OK
>>
>> >
>> > [JRE] I think that is the problem I am having. I believe an
>> > NGN is a network infrastructure that supports both public
>> > network traffic and private network traffic, or in other
>> > words it supports both a public network and a number of
>> > private networks.[/JRE]
>> > [HE2]Yes, but its main purpose is to serve as a public
>> > network with all the regulations that apply to such networks
>> > etc. This does not prohibit an NGN to be used as a private
>> > network of course, but still it has been designed from the
>> > perspective of having to serve the needs of public network
>> > operators. That is why the "normal"/default  procedures are
>> > for public network traffic. As we want to introduce the
>> > capability for such a public network (NGN) to also support
>> > private network traffic that has to be processed to a
>> > different set of rules, the Private-Network-Indication is
>> > needed.[/HE2]
>> >
>> >
>> > 5. Traffic --> SIP traffic
>> > Calling traffic SIP traffic suggest that the media is not
>> > part of the traffic, is that what we want??
>> [JRE] The point is, it is not HTTP traffic or FTP traffic or SMTP
>> traffic or whatever.
>>
>> >
>> >
>> > 6. Example private network traffic can also exist between two
>> > different enterprises
>> > Where would you like to see this? Obviously section 1.2 is
>> > not the right place for such an example.
>> > Isn't this too obvious, if you imagine that two companies
>> > have agreed to form a cooperation and communicate under this
>> > agreement?
>> > Would you like to see this as an additional example in section 4?
>> [JRE] I was not necessarily seeking a further example. However, given
>> that the private network indication identifies the particular private
>> network, what form does this indication take when traffic is between two
>> enterprises? Is there some interworking function where the identifier
>> changes from that of the first private network to that of the second
>> private network?
>>
>> >
>> >
>> > 8. calling line identification
>> > Yes we agree fully on that "calling line identification is
>> > not an adequate distinction". I think that is what the
>> > current text tries to explain. Actually what I dont like
>> > about this text is that it starts explaining what the
>> > indication is not about. I propose that we completely remove
>> > the 1st paragraph in section 1.3 and the 1st word "Rather"
>> > from the 2nd paragraph.
>> [JRE] Yes. And in the second paragraph, perhaps we could enhance:
>> "This
>>   indication is not for the end user on the private network."
>> to say:
>> "This indication does not identify an end user on a private network and
>> is not for delivery to an end user on the private network."
>>
>>
>> John
>>
>>
>> >
>> > /Hans Erik van Elburg
>> >
>> >
>> >
>> >
>>
>
>

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP