It seems to me that there are two separate issues.
First, should this work be done within IETF, or would it be better done in
ITU (or ATIS, etc.)?
Second, if it is done within IETF, should it be done in IEPREP, or some
other working group?
In Sam's earlier emails, he seemed to be saying that this work belonged in
ITU. However his latest email accepts that a large amount of the work DOES
belong in IETF.
So that leaves the question of where (within IETF) the work should be
done. Since most of the "pieces" are related to existing IETF protocols,
in principle, the various extensions could each be addressed in the
relevant (non IEPREP) working group.
There are two problems with this. The FIRST is that there is a need to
coordinate and "system engineer" the different "pieces" so that they will
work together, both at the requirements level and at the deployment level .
That fits well within the original charter of IEPREP, in terms of both
Requirements documents, and BCP documents.
In the particular case of SIP RPH, IEPREP served us well in generating the
requirements document, which were passed on to SIPPING and SIP. Now that
RPH has become RFC4412, and as we attempt to deploy it in the field, it is
clear that there will be a need for at least one BCP addressing the best
way to USE RFC4412 to meet each set of objectives. (It is already clear
that there will be some distinct differences in the deployment of RFC4412
in the DoD "preemption-based" namespaces, and in the "public carrier"
"non-preemption-based" namespaces.)
There will also be new requirements. Long term plans include the expansion
from voice to other SIP-related services such as video conferencing, as
well as to non-SIP services such as email, file transfer, and even web
access. IEPREP is the right place to work through these requirements.
The IEPREP working group needs to continue (even if restricted to the
original charter) to address these points.
The SECOND problem is logistics. Every working group in IETF has limited
human resources to do the actual work. The ones where the IEPREP "pieces"
COULD be pursued seem to be particularly overworked. As a result, the
IEPREP-related IDs tend to be viewed as the "poor stepchild" and have
difficulty getting working group status. Even when they do get working
group status, they tend to progress rather slowly, because the working
group as a whole does not consider them high priority. IEPREP, however,
provides a context in which these "pieces" DO have the critical mass to
progress at a more reasonable rate. Coordination with all other relevant
working groups is, of course, essential.
There are also IEPREP related IDs (both requirements related and solution
related) that have been unable to find a "home" in any other working
groups. The ID addressing email priority in MTA to MTA transfer is such an
example.
It is for this reason (new work that cannot find a home in any of the
current working groups, as well as work that is the "poor stepchild" in
current working groups) that the IEPREP charter needs to be extended to
include "mechanisms" as well as just requirements and BCPs.
Janet
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
"Robert G. Cole"
<robert(_dot_)cole(_at_)jhua
pl.edu> To
Fred Baker <fred(_at_)cisco(_dot_)com>
11/06/2006 10:20 cc
AM Pekka Savola
<pekkas(_at_)netcore(_dot_)fi>,
ieprep(_at_)ietf(_dot_)org, Kimberly
King
<kimberly(_dot_)s(_dot_)king(_at_)saic(_dot_)com>, Brian E
Carpenter
<brc(_at_)zurich(_dot_)ibm(_dot_)com>,
Scott Bradner
<sob(_at_)harvard(_dot_)edu>,
Sam Hartman
<hartmans-ietf(_at_)mit(_dot_)edu>,
ietf(_at_)ietf(_dot_)org
Subject
Re: [Ieprep] Re: WG Review:
Recharter of Internet Emergency
Preparedness (ieprep)
I whole-heartedly agree. I believe the DoD must extend its notions of
Precedence and Preemption to all applications, voice, video, web, ftp,
mail, etc. Mechanisms/protocols must be defined and consistent across
applications and their interactions with services, e.g., DNS, SIP, etc.,
and with their interactions with transport protocols, e.g., TCP, and IP.
Mechanisms must apply for session and non-session based applications
and therefore cannot solely be handled through extensions to SIP
signaling. Mechanisms/protocols must provide the necessary security,
authentication and access controls for all of the applications types as
well.
I strongly believe that the IETF is the place to address these issues.
And I think they are best served in a coordinated fashion within the
guidance of a single working group with liaisons to other working groups
and organizations.
Thanks,
Bob
Fred Baker wrote:
I have to say that my discussions with US DoD and DHS/NCS, and with
their counterparts in other countries, doesn't suggest that the set of
technical mechanisms is all specified. If we're looking only at voice,
it is maybe so, but they're not looking only at voice. Questions abound
around the mechanisms for sending an email and ensuring that it is
delivered in a stated time interval on the order of minutes or that an
indication of failure is returned to the sender, and other things.
I am also not at this point convinced that the ITU is the right place
to have standards discussions regarding the Internet. There is not the
demonstrated expertise, in my opinion.
So this is not all about mailing liaisons back and forth. If you want
the standards done right, the experts on the topics need to be doing
them.
On Nov 4, 2006, at 11:31 AM, Brian E Carpenter wrote:
Hi,
We now have a fair amount of guidance on how to work with other
SDO's in general, which would certainly include ITU-T. Just to
summarise:
"IAB Processes for Management of IETF Liaison Relationships,"
BCP 102, RFC 4052, April 2005.
"Procedures for Handling Liaison Statements to and from the IETF,"
BCP 103, RFC 4053, April 2005.
"Guidelines for Acting as an IETF Liaison to Another Organization,"
RFC 4691, October 2006.
We also have some specific guidance on extensions, when another
SDO sees a need for IETF protocols to be extended to meet their
system requirements:
draft-carpenter-protocol-extensions-04.txt (approved as a BCP, in RFC
queue).
A lot of IEPREP work seems to belong in the extensions category.
The question in my mind is whether the IEPREP work items are in the
category where we can be confident that these mechanisms are sufficient
(i.e., we can rely on another SDO to provide realistic requirements
in the form of liaisons) or whether we need the requirements to be
developed in the IETF to get them right (i.e., realistic in terms of
what Internet technology can actually achieve). I think the history
of work related to IEPREP shows that it's all too easy for people
steeped in the connection-oriented world to come up with unrealisable
requirements for a packet network.
Brian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ieprep mailing list
Ieprep(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
Ieprep(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf