Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments

From: "Roni Even" <[email-masked]>
Date: Tue, 10 Jul 2012 17:59:01 +0200

Hi

Thanks to everyone who sent comments. I think we got a good number of WGLC
reviews. The next step is for the editors to address the comments and update
the document.

Note that the July 16th is the cutoff date for document submission. 

We will also have time to discuss open issues in the AVTcore session in
Vancouver

Roni Even

AVTcore co-chair

From: Roni Even [mailto:[email-masked]] 
Sent: 17 June, 2012 6:05 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: WGLC on draft-ietf-avtcore-idms-05

Hi,

I would like to start a WGLC on
http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for
inter-destination media synchronization.

The WGLC will end on July 10th, 2012

Please review the draft and send comments to the list.

For the draft authors;  Are you aware of any IPR that applies to
draft-ietf-avtcore-idms-05? If so,
has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?
The above question is needed for the document write-up when sent to
publication.

Thanks

Roni Even

AVTcore  co-chair

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 16 Jul 2012 13:03:51 +0000

Hi All,

First, I would like to thank all who performed a review of the document.

Second, I have just uploaded a new version of the document (-06) which hopefully addresses all of the comments we received during the WGLC process.

http://tools.ietf.org/html/draft-ietf-avtcore-idms-06

I'm not going to list all changes from the -05 version here (there are quite many of them), but you can find a diff here:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-idms-06

Best regards,

Ray van Brandenburg

From: Roni Even [mailto:[email-masked]]
Sent: dinsdag 10 juli 2012 17:59
To: [email-masked]
Cc: [email-masked]
Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments

Hi
Thanks to everyone who sent comments. I think we got a good number of WGLC reviews. The next step is for the editors to address the comments and update the document.
Note that the July 16th is the cutoff date for document submission.
We will also have time to discuss open issues in the AVTcore session in Vancouver

Roni Even
AVTcore co-chair

Hi,

I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-idms-05 , RTCP for inter-destination media synchronization.

For the draft authors;  Are you aware of any IPR that applies to draft-ietf-avtcore-idms-05? If so,

has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?

The above question is needed for the document write-up when sent to publication.

Thanks

Roni Even
AVTcore  co-chair

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 16 Jul 2012 15:49:14 +0200

I wrote on 28/06/2012:

"I do notice that the IETF document and the ETSI document define one and the same XR block. Is there an intention that the ETSI document gets modified to reference the IETF document when finally approved and published (i.e. that the IETF document takes ownership and updates the existing registration? Or is there some other strategy for this block type?"

>From the revisions of the document it appears that section 7 is now an informative restatement of the ETSI document. The IANA registration remains with ETSI, and there is no addition of a reference to this proposed RFC.

So what is the proposed strategy now for the ETSI document? Does it get revised to incorporate the rest of the material now normatively specified in this document, or does it ignore it?

If the ETSI document is getting revised, why not transfer the normative specification his RFC and then make reference to the whole of this RFC?

I'd also note that I believe the IANA considerations section of this document could be more precisely stated. It needs to be clearer what rows are added to the IANA tables and what are the contents of those rows. Specifically, I am not sure how:

" This document defines a new RTCP packet type called IDMS Settings
   packet in the IANA registry of RTP parameters, part of RTCP Control
   Packet types (PT), based on the specification in Section 11."

gets interpreted by IANA, given that section 11 talks very little about this new PT. When a value gets assigned, where are you going to write it in the specification, and where exactly does it appear in the coding?

Keith

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: 16 July 2012 14:04
To: [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments

Hi All,

Best regards,

Ray van Brandenburg

Hi

Roni Even
AVTcore co-chair

Hi,

Thanks

Roni Even
AVTcore  co-chair

---

From: "Stokking, H.M. (Hans)" <[email-masked]>
Date: Mon, 16 Jul 2012 14:12:09 +0000

Dear Keith,

On ETSI TISPAN status: TISPAN has officially been terminated by ETSI, so no changes will be made by ETSI. We started in the IETF to continue the work on IDMS that started within ETSI, but try to remain (backwards) compatible as much as possible. We didn't think that an official transfer of the IANA registration from ETSI to IETF was needed because the block type from ETSI could be re-used. Within the IETF we did decide on a new packet type for the sync settings, hence a new registration was needed.

On the reference to section 11, this is a typo in the document since at least a few versions. Thanks for spotting this, we shall change this to section 8 (which does specify the new packet type). Section 8 does give the coding of the new packet type and defines the various fields.

We will correct the reference in the next version, ok? We can also include the row specification for IANA, I guess that's mostly abbreviation and name, and for the new packet type I think the RFC Editor needs to fill in the PT number before publication. We can put in a sentence (reminder) for that as well then.

Best, Hans

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: maandag 16 juli 2012 15:49
To: Brandenburg, R. (Ray) van; [email-masked]
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-idms-05 - address comments

I wrote on 28/06/2012:

Keith

Hi All,

Best regards,

Ray van Brandenburg

Hi

Roni Even
AVTcore co-chair

Hi,

For the draft authors;  Are you aware of any IPR that applies to draft-ietf-avtcore-idms-05? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
The above question is needed for the document write-up when sent to publication.

Thanks

Roni Even
AVTcore  co-chair

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer _______________________________________________
Audio/Video Transport Core Maintenance
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 16 Jul 2012 17:59:21 +0200

ETSI TISPAN may be closed, but there is a new networks group in project E2NA that takes over responsibility for the documents produced by ETSI TISPAN. So in ETSI there is still the possibility of aligning with the new proposed RFC.

As regards the PT number, I suggest you discuss this with IANA (in conjunction with the WG chairs) in Vancouver, and agree on a value which you put in the next version.

Regards

Keith

> From: Stokking, H.M. (Hans) [mailto:[email-masked]]
> Sent: 16 July 2012 15:12
> To: DRAGE, Keith (Keith); Brandenburg, R. (Ray) van; [email-masked]
> On ETSI TISPAN status: TISPAN has officially been terminated by ETSI, so
> no changes will be made by ETSI. We started in the IETF to continue the
> work on IDMS that started within ETSI, but try to remain (backwards)
> compatible as much as possible. We didn't think that an official transfer
> of the IANA registration from ETSI to IETF was needed because the block
> type from ETSI could be re-used. Within the IETF we did decide on a new
> packet type for the sync settings, hence a new registration was needed.
> 
> On the reference to section 11, this is a typo in the document since at
> least a few versions. Thanks for spotting this, we shall change this to
> section 8 (which does specify the new packet type). Section 8 does give
> the coding of the new packet type and defines the various fields.
> 
> We will correct the reference in the next version, ok? We can also include
> the row specification for IANA, I guess that's mostly abbreviation and
> name, and for the new packet type I think the RFC Editor needs to fill in
> the PT number before publication. We can put in a sentence (reminder) for
> that as well then.
> 
> Best, Hans
> 
> "I do notice that the IETF document and the ETSI document define one and
> the same XR block. Is there an intention that the ETSI document gets
> modified to reference the IETF document when finally approved and
> published (i.e. that the IETF document takes ownership and updates the
> existing registration? Or is there some other strategy for this block
> type?"
> 
> From the revisions of the document it appears that section 7 is now an
> informative restatement of the ETSI document. The IANA registration
> remains with ETSI, and there is no addition of a reference to this
> proposed RFC.
> 
> So what is the proposed strategy now for the ETSI document? Does it get
> revised to incorporate the rest of the material now normatively specified
> in this document, or does it ignore it?
> 
> If the ETSI document is getting revised, why not transfer the normative
> specification his RFC and then make reference to the whole of this RFC?
> 
> I'd also note that I believe the IANA considerations section of this
> document could be more precisely stated. It needs to be clearer what rows
> are added to the IANA tables and what are the contents of those rows.
> Specifically, I am not sure how:
> 
> gets interpreted by IANA, given that section 11 talks very little about
> this new PT. When a value gets assigned, where are you going to write it
> in the specification, and where exactly does it appear in the coding?
> 
> Keith
> 
> Second, I have just uploaded a new version of the document (-06) which
> hopefully addresses all of the comments we received during the WGLC
> process.
> 
> I'm not going to list all changes from the -05 version here (there are
> quite many of them), but you can find a diff here:
> 
> reviews. The next step is for the editors to address the comments and
> update the document.
> I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-
> avtcore-idms-05 , RTCP for inter-destination media synchronization.
> 
> For the draft authors;  Are you aware of any IPR that applies to draft-
> ietf-avtcore-idms-05? If so, has this IPR been disclosed in compliance
> with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> _______________________________________________

---

From: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Tue, 17 Jul 2012 07:06:43 +0000

Hi Keith,

Yes, you're right, E2NA has taken over the responsibilities of TISPAN. However, while theoretically possible, in practice it is almost impossible to get E2NA to open up the current document even for fixing up some typos, let alone changing its contents. 

As for the PT number: good idea, I will discuss this with IANA in Vancouver. 

Ray

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: maandag 16 juli 2012 17:59
To: Stokking, H.M. (Hans); Brandenburg, R. (Ray) van; [email-masked]
Subject: RE: WGLC on draft-ietf-avtcore-idms-05 - address comments

Regards

Keith

> On ETSI TISPAN status: TISPAN has officially been terminated by ETSI, 
> so no changes will be made by ETSI. We started in the IETF to continue 
> the work on IDMS that started within ETSI, but try to remain 
> (backwards) compatible as much as possible. We didn't think that an 
> official transfer of the IANA registration from ETSI to IETF was 
> needed because the block type from ETSI could be re-used. Within the 
> IETF we did decide on a new packet type for the sync settings, hence a new registration was needed.
> 
> On the reference to section 11, this is a typo in the document since 
> at least a few versions. Thanks for spotting this, we shall change 
> this to section 8 (which does specify the new packet type). Section 8 
> does give the coding of the new packet type and defines the various fields.
> 
> We will correct the reference in the next version, ok? We can also 
> include the row specification for IANA, I guess that's mostly 
> abbreviation and name, and for the new packet type I think the RFC 
> Editor needs to fill in the PT number before publication. We can put 
> in a sentence (reminder) for that as well then.
> 
> Best, Hans
> 
> "I do notice that the IETF document and the ETSI document define one 
> and the same XR block. Is there an intention that the ETSI document 
> gets modified to reference the IETF document when finally approved and 
> So what is the proposed strategy now for the ETSI document? Does it 
> get revised to incorporate the rest of the material now normatively 
> specified in this document, or does it ignore it?
> 
> If the ETSI document is getting revised, why not transfer the 
> normative specification his RFC and then make reference to the whole of this RFC?
> 
> document could be more precisely stated. It needs to be clearer what 
> rows are added to the IANA tables and what are the contents of those rows.
> gets interpreted by IANA, given that section 11 talks very little 
> about this new PT. When a value gets assigned, where are you going to 
> write it in the specification, and where exactly does it appear in the coding?
> 
> Keith
> 
> Thanks to everyone who sent comments. I think we got a good number of 
> WGLC reviews. The next step is for the editors to address the comments 
> and update the document.
> draft- ietf-avtcore-idms-05? If so, has this IPR been disclosed in 
> compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> Audio/Video Transport Core Maintenance [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Tue, 17 Jul 2012 21:31:25 +0100

Ray,

This addresses the comments I made on the earlier version.

Thanks,
Colin

On 16 Jul 2012, at 14:03, Brandenburg, R. (Ray) van wrote:
> I’m not going to list all changes from the -05 version here (there are quite many of them), but you can find a diff here:
>  

-- 
Colin Perkins
http://csperkins.org/