Subject: [avtext] AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06

From: "Ben Campbell" <[email-masked]>
Date: Sun, 03 May 2015 16:54:49 +0100

Hi,

Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. 
Nothing here is sufficient to delay the IETF last call, but I'd like to 
at least see a response to the subtsantive comments.

Thanks!

Ben.

----------------

Substantive Comments:

-- I do not object to this being informational per se, but I wonder if 
people expect it to be normatively references by future standards track 
documents. Remember that a reference should be normative if it is needed 
to understand the dependent document. Terminology references often fall 
squarely into that category. If the answer is yes, has there been any 
considerations that this draft may need to be standards track?

-- Along the same lines, all the references informational. Could a 
reader be expected to understand this draft without reading _any_ of the 
references? I recognize this may not be important for an informational 
draft that is not a technical specification. But it may be more 
important if standards track docs normatively reference this doc.

Nits and Editorial Comments:

-- Abstract: "... attempts to define..."

Is there a concern that it may not have succeeded?  :-)

-- Section 1, 1st sentence:

Do you think RTP terminology will continue to be confusing and 
inconsistent after this draft is published? Also, please expand RTP in 
the first use in the body. (In addition to the abstract.)

-- 2.1.2:

Do you consider the meaning of the term "Media" to be clear enough that 
it doesn't need a definition here?

I find it hard to parse the following sentence:

"This data is due to its periodical sampling, or at least being timed 
asynchronous events, some form of a stream of media data. "

-- 2.1.2, 2nd bullet list entry:

s/support/supports

-- 2.1.4, first sentence

I find the sentence hard to parse:

-- 2.1.5

Was the "raw stream" not also time-progressing?

-- 2.1.9, first bullet list entry:

I can't parse the sentence. Is there a missing word towards the end?

-- 2.1.18 "... alarm subsequent transformations ... "

Do you mean "alert"?

-- 2.2.3, first bullet list entry:

is the SIP URI example assumed to be an Address of Record? If so, it 
might be worth mentioning that, since a SIP URI could also point to a 
device, and a participant might have more than one.

-- 3.7, last paragraph, 2nd sentence:

Sentence is convoluted and hard to read. Please consider splitting it 
into multiple simpler sentences.

-- 3.8, first paragraph, 2nd sentence:

Convoluted sentence.

-- 3.9, last paragraph:

Convoluted sentence.

-- 3.10, last paragaph, last sentence:

Convoluted sentence.

-- 3.11, last paragraph : "This requires to either use..."

Missing noun?  ("This requires XXX to use either", or "This requires the 
use of either...")

3.13, first paragraph, last sentence:

I can’t parse the sentence—is there a word missing? (i.e. “… and 
smaller number of flow based…”)?

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 5 May 2015 04:33:13 +0000

Thanks, Ben.  I'll let Bo, as editor, comment on the editorials/nits but I'll offer my perspective on the two major issues you raise.

Responses inline...

On May 3, 2015, at 11:55 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Here's my AD Evaluation of draft-ietf-avtext-rtp-grouping-taxonomy-06. Nothing here is sufficient to delay the IETF last call, but I'd like to at least see a response to the subtsantive comments.

Thanks!

Ben.

----------------

Substantive Comments:

-- I do not object to this being informational per se, but I wonder if people expect it to be normatively references by future standards track documents. Remember that a reference should be normative if it is needed to understand the dependent document. Terminology references often fall squarely into that category. If the answer is yes, has there been any considerations that this draft may need to be standards track?

There seems to be some subjectivity here based on some related discussions in the past with Pete Resnick on similar type documents. This can, does and will have documents referencing it normatively.  In fact, there is a document with the RFC Editor now that is being held up because of a normative reference to this document (as you are likely familiar: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/).  From that perspective I think this is Standards Track, but again,

-- Along the same lines, all the references informational. Could a reader be expected to understand this draft without reading _any_ of the references? I recognize this may not be important for an informational draft that is not a technical specification. But it may be more important if standards track docs normatively reference this doc.

Do you think RTP terminology will continue to be confusing and inconsistent after this draft is published? Also, please expand RTP in the first use in the body. (In addition to the abstract.)

-- 2.1.2:

Do you consider the meaning of the term "Media" to be clear enough that it doesn't need a definition here?

"This data is due to its periodical sampling, or at least being timed asynchronous events, some form of a stream of media data. "

s/support/supports

-- 2.1.4, first sentence

-- 2.1.5

Do you mean "alert"?

is the SIP URI example assumed to be an Address of Record? If so, it might be worth mentioning that, since a SIP URI could also point to a device, and a participant might have more than one.

Sentence is convoluted and hard to read. Please consider splitting it into multiple simpler sentences.

Convoluted sentence.

-- 3.9, last paragraph:

Convoluted sentence.

Convoluted sentence.

Missing noun?  ("This requires XXX to use either", or "This requires the use of either...")

I can’t parse the sentence—is there a word missing? (i.e. “… and smaller number of flow based…”)?

_______________________________________________
avtext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/avtext

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 5 May 2015 04:39:14 +0000

Sorry, writing this on phone and hit send prematurely.

Responses inline...

Hi,

Thanks!

Ben.

----------------

Substantive Comments:

There seems to be some subjectivity here based on some related discussions in the past with Pete Resnick on similar type documents. This can, does and will have documents referencing it normatively.  In fact, there is a document with the RFC Editor now that is being held up because of a normative reference to this document (as you are likely familiar: https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/).  From that perspective I think this is Standards Track, but again, thi seems a matter of opinion and I'm fine either way.

Again, I agree that there are Normative references, though I think for the purpose of a taxonomy document they can be used sparingly and there is I need to delay publication with a normative reference to an I-D.

Cheers,

Gonzalo

-- 2.1.2:

s/support/supports

-- 2.1.4, first sentence

-- 2.1.5

Do you mean "alert"?

Convoluted sentence.

-- 3.9, last paragraph:

Convoluted sentence.

Convoluted sentence.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 5 May 2015 09:39:39 +0000

In regard to the critical questions here, on whether this is a normative document, and whether standards track documents will need to make reference to this document.

1)	I would appreciate input as to whether there are other statements about the distinction between normative and informative references other than RFC 7322 (which is in itself informative!). What essentially boils down to two lines here do not really make things crystal clear to me.

2)	Other SDO's have different approaches. The original ISO rules I believe made the terminology clause of documents normative. ETSI in updating those rules for its own use have made such section informative (I believe because terminology sections are required to contain no normative requirements).

3)	The underlying terminology definition for all RFCs is Websters dictionary. Is this normative material?

As document shepherd for this document, I had no problem with the "Informational" status of this document based on the fact that it contained no normative provisions. 

A document referencing this document will therefore not be able to import any normative provisions. Therefore at that level any references to the document can be informative. 

The problem comes with the second part of "essential to implementing or understanding the content of the RFC" (RFC 7322). At what level to understanding the content does a reference to terminology have to become normative? I'd note that in existing RFCs many more normative references would be required, and many informative references become normative, if a very rigorous interpretation of this part is made.

Conclusion. I need more input, and list discussion would be appreciated.

Keith

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]] 
> Sent: 03 May 2015 16:55
> To: [email-masked]; 
> [email-masked]
> Subject: AD Eval of draft-ietf-avtext-rtp-grouping-taxonomy-06
> 
> Hi,
> 
> Here's my AD Evaluation of 
> draft-ietf-avtext-rtp-grouping-taxonomy-06. 
> Nothing here is sufficient to delay the IETF last call, but 
> I'd like to at least see a response to the subtsantive comments.
> 
> Thanks!
> 
> Ben.
> 
> ----------------
> 
> Substantive Comments:
> 
> -- I do not object to this being informational per se, but I 
> wonder if people expect it to be normatively references by 
> future standards track documents. Remember that a reference 
> should be normative if it is needed to understand the 
> dependent document. Terminology references often fall 
> squarely into that category. If the answer is yes, has there 
> been any considerations that this draft may need to be 
> standards track?
> 
> -- Along the same lines, all the references informational. 
> Could a reader be expected to understand this draft without 
> reading _any_ of the references? I recognize this may not be 
> important for an informational draft that is not a technical 
> specification. But it may be more important if standards 
> track docs normatively reference this doc.
> 
> 
> Do you think RTP terminology will continue to be confusing 
> and inconsistent after this draft is published? Also, please 
> expand RTP in the first use in the body. (In addition to the 
> abstract.)
> 
> -- 2.1.2:
> 
> Do you consider the meaning of the term "Media" to be clear 
> enough that it doesn't need a definition here?
> 
> "This data is due to its periodical sampling, or at least 
> being timed asynchronous events, some form of a stream of 
> media data. "
> 
> is the SIP URI example assumed to be an Address of Record? If 
> so, it might be worth mentioning that, since a SIP URI could 
> also point to a device, and a participant might have more than one.
> 
> Sentence is convoluted and hard to read. Please consider 
> splitting it into multiple simpler sentences.
> 
> I can't parse the sentence-is there a word missing? (i.e. "... 
> and smaller number of flow based...")?
> 
> 
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 05 May 2015 11:57:48 +0100

I have some discussion with other ADs on this. The rules are a bit 
subjective. On my two questions:

1) Does this draft need to be standards track:

It's not necessary at this point. It might have made things slightly 
easier for future drafts that need to reference it, but its probably not 
worth changing at this point in the process.  We have a process for 
allowing normative references to lower maturity documents. Doing so to 
incorporate terminology from informational docs is a common use for 
this.

2) Do any of the references in this draft need to be normative?

tl;dr:

Informative dependencies of the form of "See [XXX] for term definitions" 
have been attractive targets for discuss positions for the currently 
sitting IESG.

Long Answer:

I agree we have not been consistent about this. But there is 
considerable risk one or more sitting ADs will consider the complete 
lack of normative references as a red flag. If that really is the right 
thing to do, we will need to be prepared to defend it.

The "essential to understand" rule should be considered. Whether a given 
dependency for terminology purposes should be normative really depends 
on whether that terminology is necessary to understand this doc.
The authors and working group are probably in the best position to judge 
if this applies to any specific dependency. The fact that this draft is 
itself informational doesn't really change anything, although there's 
some vagueness about how that rule applies for drafts that do not 
contain specifications. (It's also vague whether "terminology" can count 
as specification.)

I realize here that some of the impetus to avoid normative references 
comes from the fact that many of the dependencies are to 
works-in-progress. But in general, that should not be the deciding 
factor, except in cases where the decision would have been a coin flip 
otherwise.

Thanks!

Ben.

On 5 May 2015, at 10:39, DRAGE, Keith (Keith) wrote:

> In regard to the critical questions here, on whether this is a 
> normative document, and whether standards track documents will need to 
> make reference to this document.
>
> 1)	I would appreciate input as to whether there are other statements 
> about the distinction between normative and informative references 
> other than RFC 7322 (which is in itself informative!). What 
> essentially boils down to two lines here do not really make things 
> crystal clear to me.
>
> 2)	Other SDO's have different approaches. The original ISO rules I 
> believe made the terminology clause of documents normative. ETSI in 
> updating those rules for its own use have made such section 
> informative (I believe because terminology sections are required to 
> contain no normative requirements).
>
> As document shepherd for this document, I had no problem with the 
> "Informational" status of this document based on the fact that it 
> contained no normative provisions.
>
> A document referencing this document will therefore not be able to 
> import any normative provisions. Therefore at that level any 
> references to the document can be informative.
>
> The problem comes with the second part of "essential to implementing 
> or understanding the content of the RFC" (RFC 7322). At what level to 
> understanding the content does a reference to terminology have to 
> become normative? I'd note that in existing RFCs many more normative 
> references would be required, and many informative references become 
> normative, if a very rigorous interpretation of this part is made.
>

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 05 May 2015 11:59:18 +0100

Hi Gonzalo,

I saw Keith's mail first, and replied to it. Please let me know if that 
failed to cover anything from your email.

Thanks!

Ben.
On 5 May 2015, at 5:39, Gonzalo Salgueiro (gsalguei) wrote:

> Thanks, Ben.  I'll let Bo, as editor, comment on the editorials/nits 
> but I'll offer my perspective on the two major issues you raise.
>
> Responses inline...
>
> On May 3, 2015, at 11:55 PM, Ben Campbell 
> <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hi,
>
> Nothing here is sufficient to delay the IETF last call, but I'd like 
> to at least see a response to the subtsantive comments.
>
> Thanks!
>
> Ben.
>
> ----------------
>
> Substantive Comments:
>
> people expect it to be normatively references by future standards 
> track documents. Remember that a reference should be normative if it 
> is needed to understand the dependent document. Terminology references 
> often fall squarely into that category. If the answer is yes, has 
> there been any considerations that this draft may need to be standards 
> track?
>
> There seems to be some subjectivity here based on some related 
> discussions in the past with Pete Resnick on similar type documents. 
> This can, does and will have documents referencing it normatively.  In 
> fact, there is a document with the RFC Editor now that is being held 
> up because of a normative reference to this document (as you are 
> likely familiar: 
> https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/).  From 
> that perspective I think this is Standards Track, but again, thi seems 
> a matter of opinion and I'm fine either way.
>
> reader be expected to understand this draft without reading _any_ of 
> the references? I recognize this may not be important for an 
> informational draft that is not a technical specification. But it may 
> be more important if standards track docs normatively reference this 
> doc.
>
> Again, I agree that there are Normative references, though I think for 
> the purpose of a taxonomy document they can be used sparingly and 
> there is I need to delay publication with a normative reference to an 
> I-D.
>
> Cheers,
>
> Gonzalo
>
>

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 5 May 2015 13:29:57 +0200

Hi,

I am of the view that this type of documents should continue to be 
informational. Yes, it creates a terminology that is useful in other 
documents to provide clear message to the reader. However, it is still 
just a possible way of describing a small part of the world.

Even when using this document, along the line:

"Informative dependencies of the form of "See [XXX] for term 
definitions" have been attractive targets for discuss positions for the 
currently sitting IESG."

I still believe using this as an informational reference is fine. I 
would note that we use informational reference to protocols also in some 
situations, its the usage of the term that matters. I think the 
difference really. For example: This protocol is a high layer foo that 
can be used over any reliable protocol, such as TCP, SCTP, etc. Then TCP 
and SCTP is informative.

In most cases this general terminology isn't used in such a strict 
fashion that it must be a normative statement.

I also think we need to consider the long term implications if we think 
that anything that provides a definition of any term that is needed to 
be understand must be normative and the document must be standards 
track. Then we will have extremely few uses for informational documents.

I do note that this discussion similarly applies to the AVTCORE 
Topologies document. That is a document which provides a general 
understanding of what something means, but not always pin-point precise. 
This documents predecessor RFC 5117 has been cited at least by 14 other 
RFCs. More than half of these are standard tracks document. I can't 
remember that we have had any issues with its status. It is also not 
listed in the downref registry.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 05 May 2015 15:09:11 +0100

To be clear, I don't think this needs to change to standards track.

My main concern is that _this_ draft has no normative dependencies. 
There are at least some sections that seem, on the surface, to require 
the reader to read the referenced document to understand the section. 
This will almost certainly get questioned during IESG review. (I have 
seen a number of DISCUSS positions on informational "terminology" 
references.

I am open to arguments that this is not true for any specific reference, 
but I haven't seen such an argument yet.

And of course, the related issue is that many of those currently 
informational dependencies point to works-in-progress.

On 5 May 2015, at 12:29, Magnus Westerlund wrote:

> definitions" have been attractive targets for discuss positions for 
> the currently sitting IESG."
>
> would note that we use informational reference to protocols also in 
> some situations, its the usage of the term that matters. I think the 
> can be used over any reliable protocol, such as TCP, SCTP, etc. Then 
> TCP and SCTP is informative.
>
> I also think we need to consider the long term implications if we 
> think that anything that provides a definition of any term that is 
> needed to be understand must be normative and the document must be 
> standards track. Then we will have extremely few uses for 
> informational documents.
>
> understanding of what something means, but not always pin-point 
> precise. This documents predecessor RFC 5117 has been cited at least 
> by 14 other RFCs. More than half of these are standard tracks 
> document. I can't remember that we have had any issues with its 
> status. It is also not listed in the downref registry.
>
> Cheers
>
> Magnus Westerlund
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 6 May 2015 10:25:21 +0200

> informational dependencies point to works-in-progress.

If this is the case for this document, I think the IESG members are 
misinterpreting the current IESG statement. I would note that the 
emphasis in the text is clearly on specifying technology.

"Normative references specify documents that must be read to understand 
or implement the technology in the new RFC, or whose technology must be 
present for the technology in the new RFC to work."

"Informative references are not required to implement the technology in 
the RFC."

"Note 3: The normative/informative distinction is relevant in any 
document that amounts to a technical specification, even if its intended 
status is Experimental or Informational."

This document clearly do not specify a technology that can be 
implemented. It provides a description of components, many in an 
abstract way, and how their relation can be described. Thus enabling a 
technology to be more precise in the description for when it applies.

Cheers

Magnus Westerlund

---

From: "Ben Campbell" <[email-masked]>
Date: Fri, 08 May 2015 16:42:30 +0100

On 6 May 2015, at 9:25, Magnus Westerlund wrote:

> "Normative references specify documents that must be read to 
> understand or implement the technology in the new RFC, or whose 
> technology must be present for the technology in the new RFC to work."
>
> "Informative references are not required to implement the technology 
> in the RFC."
>
> document that amounts to a technical specification, even if its 
> intended status is Experimental or Informational."
>

I agree that the IESG statement speaks to "specifications". But some ADs 
believe we should apply similar approaches to all drafts, where the 
standard is "if you have to read that to understand this it should be 
normative". (I am personally on the fence on this.) ** In any case, I am 
not going to block the draft on this point--I only mean to point out the 
potential for a DISCUSS.**

This may be mostly moot, though. I went back through the draft on a 
per-reference basis. The only references I find problematic are RFCs 
3350 and 4566, and I-D.ietf-clue-framework. It would be no problem 
making the RFC references normative if the authors choose to do so.

The clue framework is trickier, since that is still in progress--but is 
has at least been pubreqed. And the only reason I think it might need to 
be normative is that Section 4 imports terms from it without local 
descriptions. That section locally describes the terms imported from the 
other drafts. If the authors were to add local descriptions for the clue 
framework terms, it would be easier to justify that reference as 
informational.