Subject: RE: [Ieprep] Moving forward: draft-carlberg-ets-*.txt

From: "Gunn, Janet" <[email-masked]>
Date: Thu, 14 Nov 2002 16:43:48 -0500

Ran asked " From the folks worried about GETS-like stuff, please
focus on whether the core essentials did get documented clearly in those
two documents."

Here are my comments in response. Sorry it took so long.

Only a couple of comments on the "general" one.

On page 4, section 2.1,  There is a reference to "independent networks that
comprise the Internet".  I would like to see something somewhere (probably
section 2, Scope) that makes it clear that we may be interested in ANY
networks running the IP protocol suite, whether or not they are one of the
networks that "comprise the Internet".  In particular, the IP networks
within the "core" of a circuit switched network do not "comprise the
Internet".

Page 4 3. 2)
Labels from different layers are not required to be related to each other by
protocol, but there may be policies about their relationship.

In the "telephony" paper, some of the general requirement from the first
paper need to be expanded for telephony.

Page 2, section 2.1
What do you mean by "carriers"?  Does that include both ISPs and "common
carriers"?

Page 3 sec 3. 3)
This implies that we need translation of ALL "existing labels defined for
the PSTN".  I don't think we need that.  We DO need translation of "all
existing labels used to identify emergency and/or priority calls in the
PSTN".  And we WILL need translation of FUTURE labels used to identify
emergency or priority calls in the PSTN.

>From a GETS perspective, I would like to see CPC and Precedence mentioned by
name, but maybe that is too specific for this paper.

Page 3 3.1 1) Alternate paths

You might want to consider routing to an alternate IP/PSTN gateway if (for
whatever reason) you can't get to the originally specified IP/PSTN gateway.

Additional "Value Added"  points (not calling them "requirements" any more)

Increased probability of call set up (this is a telephony specific  example
of the "network Functionality" in the General paper).

Authorization is in the General paper.  It would make sense to include a
telephony specific version of authorization here.  E.g., the IP network
should accept authorization information from a trusted PSTN network element,
and vice versa.  The "trusted" part probably includes the existence of a
contractual relationship.

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]
Sent: Monday, November 04, 2002 5:54 PM
To: ieprep
Subject: [Ieprep] Moving forward: draft-carlberg-ets-*.txt

Hi,

1) I appreciate Hal's note suggesting that draft-carlberg-ets-*.txt be 
made
WG documents.  I would ask that they be targeted as the standards-track
requirements [1] documents for those aspects of the current charter,
subject to whatever editing turns out to be necessary to get them into
a form congruent with WG Rough Consensus.

2) I would also ask Scott that we have *discussion* time for those
two documents in Atlanta on the IEprep Agenda. [1]

3) I'd like to ask that folks here please take time now, before Atlanta,
to read and critique the documents from Ken Carlberg (I kibbutzed, but 
the work
and words are mostly Ken's).  They are short documents (and I hope also
sweet :-).

General IP Carrier Requirements:
	draft-carlberg-ets-general-00.txt

Application-specific Requirements for IP Telephony:
	draft-carlberg-ets-telephony-00.txt

3B) I'm looking for slightly different kinds of review from our two 
segments
of participants.  From the folks worried about GETS-like stuff, please
focus on whether the core essentials did get documented clearly in those
two documents.  From the operators, is the verbage clear enough that 
there
is no intent for unfunded mandates or that an operator has to deploy any
of this stuff ?  Of course, feel free to comment on anything, but those
two questions are my core concern for the above documents at this time.

Thanks,

Ran
[email-masked]

NOTES:
[1] IETF-definition for "requirements", not DoD-definition.  (I'd like 
to keep
Hal's document on what he thinks a GETS-like service might look like 
translated
into the global Internet, but that document doesn't contain 
IETF-requirements).
[2] I hate lots of presentations at IETF meetings, so I'm deliberately
asking for discussion time rather than presentation time.  I'd like to 
assume
that reasonable people will have read the drafts and that others will 
either
do so in real-time or keep quiet.

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Ken Carlberg <[email-masked]>
Date: Wed, 20 Nov 2002 15:06:05 +0000

> On page 4, section 2.1, There is a reference to "independent networks
> that comprise the Internet".  I would like to see something somewhere
> (probably section 2, Scope) that makes it clear that we may be
> interested in ANY networks running the IP protocol suite, whether or not
> they are one of the networks that "comprise the Internet".  In
> particular, the IP networks within the "core" of a circuit switched
> network do not "comprise the Internet".

ok, we can add some text that will make it clear that we are not excluding
private IP networks.

> protocol, but there may be policies about their relationship.\

ok.  there is agreement that this item needs to be expanded to clarify
what is meant.  We'll use some of the exchange on the subject of
policies & labels of a few weeks ago to do this.

> What do you mean by "carriers"?  Does that include both ISPs and "common

ISPs what the target of that passage.  I'll use the ISP instead in the
next version.

> emergency or priority calls in the PSTN.

ok, agreed that we don't need a mapping of ALL possible labels.  we'll
make it clear that the passage applies to labels used for or related to
emergencies.

> From a GETS perspective, I would like to see CPC and Precedence
> mentioned by name, but maybe that is too specific for this paper.

to specific for this document :-).  CPC is mentioned in the framework
document, and that is probably the best place for mentioning it.

> You might want to consider routing to an alternate IP/PSTN gateway if
> (for whatever reason) you can't get to the originally specified IP/PSTN
> gateway.

ok

> of the "network Functionality" in the General paper).

i'll give this some more thought.

> should accept authorization information from a trusted PSTN network
> element, and vice versa.  The "trusted" part probably includes the
> existence of a contractual relationship.

this seems to be a specific approach, and so crosses the line of what is
in scope.  if you feel strongly about the item, we could consider putting
it in the Framework document.

-ken