>> than either sC.6 or sC.7 (or expand in all of them).
>>
>> sC.11, para 1: s/lower transport/lower layer transport/, s/to be
>> meet/to be carried out/ (or at least s/meet/met/).
>>
>> sC.11, bullet 3: s/RTP info/RTP-info/???
>>
>> sD.1.1
nd V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", draft-ietf-
avtcore-rtp-circuit-breakers-03 (work in progress), July
2013.
This is included in the template, and
he publication process."
>
> This document references a bunch of I-Ds. Since all of the references
> are informative, it would be helpful to know if this document ought to
> proceed to publication or whether it should wait until these I-Ds are
> published as RFCs.
>
ne can do."
>
> * Section 4.1.4
>
> s/will be more relevant then/will be more relevant than/
>
> This sentence is hard to read. Please consider rewording
>
> "Commonly by provisioning the verifier with the public part of a root
> certificate, this enables t
RTP session (and hence the
>> RTP and RTCP traffic) and the key-management protocol becomes
>> important to determine what security claims can be made”. Hopefully
>> this is clearer.
>>
>> Cheers,
>> Colin
>>
>>
>> On 17 Dec 2013, at 07:25,
hen the NAT is showing
the behavior that this method can't support. This method also
suggest using the RTP NO-OP payload format [I-D.ietf-avt-rtp-no-op]
for key-alives of the RTP traffic in the client to server direction.
This can be replaced with another form of UDP packet as will
Saturday, June 14, 2014 10:57 PM
To: Magnus Westerlund (magnus.westerl...@ericsson.com); thomas.z...@gmail.com;
General Area Review Team (gen-art@ietf.org); ops-...@ietf.org
Cc: mmu...@ietf.org; i...@ietf.org; Black, David
Subject: Gen-ART and OPS-Dir review of draft-ietf-mmusic-rtsp-nat-evaluation
we must ensure that something like ISMAcrypt is
clearly defined, because then we do need to split the RTP packetization
transformation into two parts.
Cheers
Magnus Westerlund
--
Services, Media and Network features, Ericss
s was sketching out proposed new text for the document.
Well,
I didn't promised text. But, I am working with Bo, so he can produce a
proposal for addressing this.
cheers
Magnus Westerlund
--
Services, Media and Networ
"this requires
each media type to use"
-[Page 14], some references are expired. Should they remain cited?
[I-D.ietf-avtcore-multiplex-guidelines],
Yes, this document should be revived by next IETF meeting.
[I-D.lennox-payload-ulp-ssrc-mux]
This, is more uncertain if it will
h: I think that this paragraph is important since
> it is asking WGs to do something specific at some time, and it is documenting
> the current behaviour that the WG should change. As such, I would advise that
> the gravity of this be provided accordingly. The suggested paragraph bel
?
> Or is it referring to a user?
See your point. In some cases it is the user or a system designer.
Great, thanks.
The below nits we will go through and update the document.
Sounds good. Thanks again for your time.
Cheers,
- vijay
--
Magnus Westerlund
-
consumption by a MIDI player
NEW:
Interoperability considerations: This media type is for
consumption by a MIDI player
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
---
ss these can be fixed with a revision after the IESG telechat?
Colin
--
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
--
Ericsson AB| Phone +46 8 4048287
Torshamsgatan 23 | Fax
dled at the RFC Editor stage.
A number of these have been handled in a updated already available.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
--
Ericsson AB| Phone +46 8 4048287
Tors
that we handle these changes as notes to the RFC
Editor. But if you prefer producing a new draft, that's also fine.
I am fine with receiving RFC-editor style change notes.
Cheers
Magnus Westerlund
IETF Transport Area Director & TS
vacation etc. Please do the
right thing directly
Having said that, Authors you better respond ASAP and include me in the
discussion.
Cheers
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
--
Multim
should be expanded at the first appearance, e.g., NAT
>>>and ICMP in the title, ICMP in the Abstract as well, etc.
>>
>> [suresh] OK, I will expand NAT to be "Network Address translator" in
>> the title.
>> However, I dont believe, it is necessary t
over the
> weekend.
> But I will try to get them in earlier if possible.
>
> Magnus, ADs/Chairs:
> After I make the changes, should I submit a new version to "ietf-drafts" ??
Please do
Cheers
Magnus Westerlund
lticast. If it is just a
> typo it can be fixed with just an RFC-Editor note.
>
> Cheers
> Suresh
>
>
--
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
--
Multimedia Technologies, Ericsson
h using Word to generate draft.
>
> * S4.2.2.2: s/.Note: if any media/Note: if any media
>
> * S4.3.3.5: Is a sub-section warranted at all if there aren't
> any remarks?
>
Well, we are trying to keep with
Vijay K. Gurbani skrev:
> Magnus: Thanks for the attention to the review. More inline.
>
> Magnus Westerlund wrote:
>>> I am curious: I don't believe that SIP re-INVs are used to affect
>>> the sort of codec control messages being discussed in this draft.
>
> There is a normative reference to RFC 3533, which is Informational.
>
> Thanks,
>
> Gonzalo
>
>
--
Magnus Westerlund
IETF Transport Area Director & TSVWG Chair
--
Multimedia Technologies, Ericsson Res
review we only lost a week.
Cheers
Magnus
>
> On Wed, Jun 11, 2008 at 1:00 AM, Magnus Westerlund
> <[EMAIL PROTECTED]> wrote:
>> Thanks for the review.
>>
>> Regarding the normative reference. I did make a mistake to not call this
>> out. However, also RF
should be kept.
> - 3 page 11: Video classes -> Video classes: ?
> - 6 page 12 (title): Acknowledgements -> Acknowledgments
> - 6 page 12 (last character): , -> .
>
> Regards
>
> [EMAIL PROTECTED]
--
Magnus Westerlund
IETF Transport Area Directo
dards track QOSM
>> documents on an Informational RFC. Also, this document includes
>> guidelines to follow in future IANA allocations.
>>
>>
>> Minor:
>> In describing the constraints parameters, the text in section 3.3.2
>> carefully
ve reference to an Informational draft:
> draft-ietf-nsis-qspec (ref. 'I-D.ietf-nsis-qspec')
>
> From my perspective, the document seems to be ready for publication.
>
> /Miguel
--
Magnus Westerlund
IETF Transport Area Director
es:
> -
>
> I am surprised there is no clear indication where the substantive change
> to
> RFC 4995 lies. If I was an implementor, I would want to know what I have
> to
> fix. A note in t
nism that is defined in draft-ietf-avtcore-ecn-for-rtp
and as that draft is just about ready for WG last call I think we can
instate the registry first and then let the registration happen at the
time that work is approved.
Cheers
Magnus Westerlund
---
or
192.168.0.0/16 address in their candidate lists. Thus to keep the
example correct considering that the SDP represents a client attached to
a NATed network and have multiple candidates I do need to use a private
range address i
t feedback implosion actually can be seen
as an implosion event. All the feedback traffic generated are
concentrated at the target for the feedback. Thus causing an implosion
of the feedback target under the "weight" of all the feedback.
But, seriously "Feedb
uot;.
>
> Section 4.3, first sentence: "middlebox devices" -> "middleboxes" unless
> this a specific usage from I-D.ietf-6man-udpzero.
>
> Section 4.3, second sentence: "needs&quo
when we introduced this type of
pipelining 7 years ago. Making any changes to this at this stage is
counter productive. The reality is that all the "nice" features and
necessary clarifications has been retrofitted into RTSP 1.0 by the ones
that have been using RTSP 1.0. So changing
Hi Elwyn,
On 2013-06-07 14:26, Elwyn Davies wrote:
> On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote:
>> Hi Elwyn,
>>
>> Many thanks for the detailed review. We will address the nits you have
>> raised, but I cut them out of this reply to focus on the mor
On 2013-06-07 17:40, Elwyn Davies wrote:
> On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote:
>
>>> Appendix F: I missed that the text/parameter format appeared in the
>>> examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the
>>> defin
recent release dated 2011 and numbered 3.5.2 - I do not know if there is
> any diff in the relevant content, but pointing to the most updated review
> seems appropriate.
>
> [Ray: Thanks for noticing, I will update the reference to the latest ETSI
> release].
>
> 9: Did t
e a
> reliable transport with no request retransmission, so there should never
> be gaps at the receiver. Should the receiver check and react some way if
> there are gaps? I think you should explicitly tell them not t
- what happens then? Affects s13.1, para 3 also.]
Actually, I don't think it is specific to the media resource. The issue
with making it specific to a media resource is that a RTSP client needs
to be able to look into the future and supply an answer for a media
resource it may not yet k
9 range, unless it is to adopt an HTTP extension
also to RTSP. The reason is to enable any HTTP extension to be adopted
to RTSP without needing to renumber any related status codes.
Regarding experimental and private I am very torn about such range.
Unl
Hi,
Now getting to implement your response in our source.
Some few additional comments or notes below.
On 2013-06-25 14:47, Elwyn Davies wrote:
>
> On Mon, 2013-06-24 at 16:51 +0200, Magnus Westerlund wrote:
>> Elwyn,
>>
>> Follow up on some of the nits that is not simp
the Delay Tolerant Networking Research Group.
>
> SB> Is it simply adapted? What is the relative standing of the two?
> As far as I can see this Standard relies on definitions provided by that RFC.
To my understanding the actual BPv7 protocol definition should be stand-alone,
but sh
Hi Elwyn,
Please see inline for a comment on your suggestion and thank you for the nits.
The updated proposal and the nits correction (some modified) have been written
up as PR:
https://github.com/gloinul/draft-ietf-avtcore-rtp-payload-registry/pull/2
From: Elwyn Davies via Datatracker
Date:
42 matches
Mail list logo
