Re: AD comments on draft-ietf-rmt-pi-alc-revised-06

Hi Magnus,

I think you have overestimated the scope of my proposal (or I have overstated it). I am thinking something almost editorial in nature. I'm not suggesting that anyone try to write text which is generic across multiple protocols or multiple arbitrary domains.

What I'm suggesting is that if you have requirements for a specific protocol which are applicable to a *specific non-Internet domain*, then these should be collected into a "Requirements for non-Internet domains" section, rather than spread throughout the rest of the document. (Equally there could be requirements for non-Internet domains with specific well-defined properties - such as the text suggested by Rod for ALC which refers to "unidirectional fully provisioned (at a lower layer) channels".)

The advantages are

 *   if this section is deleted, you then have a complete protocol specification that meets the requirements for Internet usage and this would be a very clear and unambiguous policy.
 *   other SDOs have an clear place into which to propose their domain-specific requirements, without the usual confusion about whether those requirements mess things up for Internet usage.

It just seems to me that there is a process discussion about non-Internet requirements which we repeat every time, and perhaps with guidance from the IESG that repetition could be avoided.

...Mark

On 6/3/09 1:50 AM, "Magnus Westerlund" <[email protected]> wrote:

Watson, Mark skrev:
> Magnus,
>
> What I was suggesting as a standard RFC section a bit like "Security
> Considerations" in which the "Other domains" requirements should be
> collected, with guidelines as to what kind of thing should go in there.
> Then the rest of the document is unambiguously applicable to the
> Internet domain. Obviously the content of this section would be very
> dependent on the protocol being defined.
>
> In a sense, this section would be the IETF doing the necessarily
> profiling for other standards groups itself (hopefully avoiding the
> risks you cite below). This happens anyway, but I'm suggesting we make
> it more explicit so that we do not keep repeating the argument about
> whether Internet domain requirements are MUST or SHOULD for protocols
> which have other domains of applications.

Sorry Mark, I don't understand how I am going to be able to write such a
section without knowing which domain it is for. Only when you know your
domain and what features it has can you determine what you may not
require in terms of security protocol or congestion control, or
configuration support.

Maybe, I am misunderstanding you?

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email protected]
----------------------------------------------------------------------

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt