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

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