[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06
- To: Magnus Westerlund <magnus.westerlund at ericsson.com>
- Subject: Re: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06
- From: "Watson, Mark" <watson at qualcomm.com>
- Date: Tue, 2 Jun 2009 09:45:49 -0700
- Accept-language: en-US
- Acceptlanguage: en-US
- Cc: "draft-ietf-rmt-pi-alc-revised at tools.ietf.org" <draft-ietf-rmt-pi-alc-revised at tools.ietf.org>, "Rod.Walsh at nokia.com" <Rod.Walsh at nokia.com>, "rmt at ietf.org" <rmt at ietf.org>
- Delivered-to: rmt at core3.amsl.com
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson at qualcomm.com; q=dns/txt; s=qcdkim; t=1243961158; x=1275497158; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Watson,=20Mark"=20<watson at qualcomm.com>|To:=20M agnus=20Westerlund=20<magnus.westerlund at ericsson.com>|CC: =20"draft-ietf-rmt-pi-alc-revised at tools.ietf.org"=0D=0A =09<draft-ietf-rmt-pi-alc-revised at tools.ietf.org>,=0D=0A =20=20=20=20=20=20=20=20"Rod.Walsh at nokia.com"=0D=0A=09<Ro d.Walsh at nokia.com>,=0D=0A=20=20=20=20=20=20=20=20"rmt at iet f.org"=20<rmt at ietf.org>|Date:=20Tue,=202=20Jun=202009=200 9:45:49=20-0700|Subject:=20Re:=20[Rmt]=20AD=20comments=20 on=20draft-ietf-rmt-pi-alc-revised-06|Thread-Topic:=20[Rm t]=20AD=20comments=20on=20draft-ietf-rmt-pi-alc-revised-0 6|Thread-Index:=20AcnjgcPqyyvffeWBRwWXIE7lISPY8AAH9FVl |Message-ID:=20<C64AA54D.2E0BF%watson at qualcomm.com> |In-Reply-To:=20<4A250A14.7060107 at ericsson.com> |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C64AA54D2E0BFwatsonqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 300,2777,5634"=3B=20a=3D"18878287"; bh=vwRewIt5z1A7ejwIClccJdrjTWFEx4U45xbenmHGG90=; b=rjmtyTXkje78PhlCkCPoWFjBgggBrpQZHV6g/YpgiK2OSdRvZPHvClDn RbJgEwxSOLobkdU6fYRhifXfVq3k91pA8bZVxHQvvg2Svc0mLFkJqTquK yPtWJ7mto084vugSuHOKMGpuPDdKcTEGmcmUvVxcph+p2I2nEXK/RQsrl w=;
- In-reply-to: <4A250A14.7060107 at ericsson.com>
- List-archive: <http://www.ietf.org/mail-archive/web/rmt>
- List-help: <mailto:rmt-request@ietf.org?subject=help>
- List-id: Reliable Multicast Transport <rmt.ietf.org>
- List-post: <mailto:rmt@ietf.org>
- List-subscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=subscribe>
- List-unsubscribe: <https://www.ietf.org/mailman/listinfo/rmt>, <mailto:rmt-request@ietf.org?subject=unsubscribe>
- Thread-index: AcnjgcPqyyvffeWBRwWXIE7lISPY8AAH9FVl
- Thread-topic: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06
Title: Re: [Rmt] AD comments on draft-ietf-rmt-pi-alc-revised-06
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.
...Mark
On 6/2/09 4:16 AM, "Magnus Westerlund" <magnus.westerlund at ericsson.com> wrote:
Watson, Mark skrev:
> Magnus,
>
> We seem to repeat a variant of this discussion quite often. I wonder if
> the IESG could recommend a standard pattern for addressing ‘non-Internet
> domains of application’ ?. For example there could be a standard RFC
> section “Other domains of application” in which you can specify deltas
> to the requirements of the rest of the RFC for specific non-Internet
> application domains or domains with specific properties. This would make
> it possible for the body of the RFC to be clear about the requirements
> for the Internet, without needing different smallprint for every case.
No, I don't think so. Because the variations are different for different
protocols. Sure, congestion control comes up pretty often. However, it
is generaly need also for none Internet usage. It is only when you both
reserve resources and ensure that the traffic provided over that
resource matches the reservation that you can be pretty certain that you
don't need congestion control. Even in these cases you commonly need to
deal with failure modes.
So, no even if reoccurring what goes into this often has variations and
special considerations.
>
> It is not clear to me why the domain-specific standards bodies can’t
> specify the deltas themselves, but generally they do prefer to be able
> to use a straightforward reference (i.e. For the IETF to have done their
> domain-specific thinking for them).
>
Yes, for an SDO like DVB can clearly specify that you don't need to
implement congestion control because the traffic will always be ingress
filtered and shaped before being broadcasted. Thus congestion isn't a
real issue. However, I know that some IETFers do not like when other
SDOs profile our standards. There is a risk in profiling both from
interoperability and correct function.
Cheers
Magnus
_______________________________________________
Rmt mailing list
Rmt at ietf.org
https://www.ietf.org/mailman/listinfo/rmt