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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ieprep mailing list
Ieprep@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf