A. Jean Mahoney | 30 Jul 23:36 2015

Assignments for the 2015-08-06 Telechat

Hi all,

The following reviewers have assignments:

Reviewer            LC end       Draft
----------------------------------------------------------------------------------
Brian Carpenter     2015-07-23   draft-ietf-idr-flowspec-redirect-rt-bis-05 *

David Black         2015-07-23   draft-ietf-ccamp-flexi-grid-fwk-05

Dan Romascanu       2015-07-08   draft-ietf-xmpp-dna-10 **

Elwyn Davies        2015-06-24   draft-ietf-dane-ops-14 *

Joel Halpern        2015-07-08   draft-ietf-xmpp-posh-04 **

Meral Shirazipour   2015-07-16   draft-ietf-rtcweb-stun-consent-freshness-15 **
Meral Shirazipour   2015-07-09   draft-ietf-intarea-gre-ipv6-11 *

Roni Even           2015-07-02   draft-ietf-bmwg-issu-meth-01 **
Roni Even           2015-07-13   draft-ietf-6man-ipv6-address-generation-privacy-07
Roni Even           2015-08-02   draft-ietf-ccamp-wson-signal-compatibility-ospf-15

Russ Housley        2015-07-20   draft-ietf-dime-4over6-provisioning-04 *

Wassim Haddad       2015-07-23   draft-ietf-sidr-rfc6490-bis-04 **


* Earlier draft reviewed
** Already reviewed
(Continue reading)

A. Jean Mahoney | 30 Jul 23:32 2015

A *new* batch of IETF LC reviews - 2015-07-30

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Brian Carpenter   2015-08-11   draft-ietf-ippm-2679-bis-03

David Black       2015-08-11   draft-ietf-dnsop-dns-terminology-03

Joel Halpern      2015-08-11   draft-ietf-ippm-2680-bis-03

Meral Shirazipour 2015-08-13   draft-ietf-avtext-rtp-stream-pause-08

Robert Sparks     2015-07-25   draft-hansen-scram-sha256-03 *

Roni Even         2015-08-11   draft-ietf-dnsop-root-loopback-02

Suresh Krishnan   2015-08-13   draft-ietf-ospf-prefix-link-attr-06

Tom Taylor        2015-08-13   draft-ietf-trill-oam-mib-06

* 2nd LC

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html
(Continue reading)

Meral Shirazipour | 29 Jul 10:25 2015
Picon

Gen-ART Last Call review of draft-ietf-homenet-dncp-08

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 

Please resolve these comments along with any other Last Call comments you may receive.

 

Document: draft-ietf-homenet-dncp-08

Reviewer: Meral Shirazipour

Review Date: 2015-07-29

IETF LC End Date:  2015-07-29

IESG Telechat date: NA

 

 

Summary:

This draft is ready to be published as Standards Track RFC but I have some comments .

 

 

Major issues:

 

Minor issues:

 

Nits/editorial comments:

 

-Abstract, suggestion:

"uses Trickle"---->"uses the Trickle algorithm"

 

-Abstract, suggestion:

"DNCP is an abstract protocol, that"---->"DNCP is an abstract protocol, and"

 

-[Page 3], Intro, last paragraph the terms "infrequently" and "As the network of nodes, or the rate of data changes grows over a given time interval"

it would be good to give example values or ranges to better describe what is meant by these terms.

 

-[Page 3], "specifies transport method"---->"specifies the transport method"

 

-[Page 10], "higher then"---->"higher than"

 

-[Page 28], "Certifcate"---->"Certificate"

 

-Please consider adding caption and title to all figures.

 

Best Regards,

Meral

---

Meral Shirazipour

Ericsson

Research

www.ericsson.com

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
A. Jean Mahoney | 23 Jul 19:04 2015

A *new* batch of IETF LC reviews - 2015-07-23

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Roni Even         2015-08-02   draft-ietf-ccamp-wson-signal-compatibility-ospf-15

Suresh Krishnan   2015-08-17   draft-iab-crypto-alg-agility-06

Tom Taylor        2015-08-04   draft-ietf-httpbis-cice-01

Vijay Gurbani     2015-08-04  draft-ietf-precis-mappings-11

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

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

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Elwyn Davies | 23 Jul 18:32 2015

Gen-art LC review of draft-ietf-dime-ovli-08 - with summary

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dime-ovli-08.txt
Reviewer: Elwyn Davies
Review Date: 2015/07/23
IETF LC End Date: 2015/07/27
IESG Telechat date: (if known) -

Summary: Ready with nits.  A very well written document - thanks.  Some 
minor issues with out-of-date or OBE'd statements that need a bit of 
tweaking.

Major issues:

Minor issues:
s4.2:
Is there a need for and consequently how would one either cancel the 
current abatement algorithm or select a different one?  I guess this 
might happen if the reacting node that was running the algorithm went 
away or itself became overloaded.  However I I have no idea whether this 
is a reasonable question!  OK.. well I see in s5.1.1 that the abatement 
algorithm can be changed... a pointer in s4.2 would be useful.  But 
could it be turned off?

Appendix A.3:  The statements in this appendix are not 'future proof'. 
Referring to ongoing actions of the DIME WG will have little value in 
the future.  Maybe something like "There is an expectation that <these 
developments> will occur and can be integrated with the features 
described in this document."

Appendix C.1, para 1: There are some tense and past/future issues in 
this section - It is now mid 2015 and this para refers in the future to 
'end of 2014'.  Please rewrite to reflect current actualité and in a way 
that will be relevant when this is published as an RFC.

Appendix C.5:
> C.5.  No New Vulnerabilities
>
>     The working group believes that DOIC is compliant with the
>     requirement to avoid introducing new vulnerabilities.  However, this
>     requirement may warrant an early security expert review.
Hmm!  I fear that it would difficult to consider this draft 'ready' if 
there is no reasonable consensus that it hasn't introduced any new 
vulnerabilities.  Has the security expert review actually happened?

> REQ 13: The solution MUST NOT introduce substantial additional work
>             for a node in an overloaded state.  For example, a
>             requirement for an overloaded node to send overload
>             information every time it received a new request would
>             introduce substantial work.
>
>             *Not Compliant*. DOIC does in fact encourage an overloaded
>             node to send an OLR in every response.  The working group
>             that other mechanisms to ensure that every relevant node
>             receives an OLR would create even more work.  ****[Note: This
>             needs discussion.]****
Has this discussion occurred?  Does the WG have consensus that this 
derogation from the requirements is acceptable?

Nits/editorial comments:
General: s/i.e./i.e.,/ g; s/e.g./e.g.,/g
General: Consistent use of "non-supporting" vs "non supporting" (lots of 
places)

s2, Host-Routed Requests:
Expand acronym AVP (first use).

s5.2.1.1:
>     A host-type OCS entry is identified by the pair of application-id and
>     the node's DiameterIdentity.
>
>     A realm-type OCS entry is identified by the pair of application-id
>     and realm.
The application-id, DiameterIdentity and realm presumably come from the 
various messages taht are being piggybacked on.  A reference to the 
relevant section of the RFC that gives definitions of these (and which 
messages to get them from) would be helpful.  Later... this issue is 
partially resolved by s7.3.  A pointer to that section would be 
desirable.  s7.3 needs a reference to where the relevant messages are 
defined.

s5.2.1.4, last para:
>     A reporting node MUST keep an OCS entry with a validity duration of
>     zero ("0") for a period of time long enough to ensure that any non-
>     expired reacting node's OCS entry created as a result of the overload
>     condition in the reporting node is deleted.
Is it possible to offer any guidance on what constitutes 'long enough'?

s5.2.2 (in Note):
>   Any extension
>        that defines a new abatement treatment must also defined the
>        interaction of the new abatement treatment with existing
>        treatments.
s/defined/define/

s5.3, paras 2, 3, 5,  7  (but probably not the MUST NOT in para 6):
In line with the text in the previous comment, I think s/MUST/must/, 
s/MAY/may/ - they are not things the protocol does

s7:
Pointers are needed to the RFC sections that define the data types and 
the AVP syntax definition structure used in this section.

s7.3 - see comments on s5.2.1.1 above

s8, para 6: s/Diameter identity/DiameterIdentity/ (possibly)

s9.2:  It doesn't seem obvious to me that the values are supposed to 
have names in the registry.  Surely s/b
   (e.g.)
     Feature Vector Entry Name
     Feature Vector Entry Value
     Specification...

s10.3, last para:
>     Requirement 28 [RFC7068] indicates that the overload control solution
>     cannot assume that all Diameter nodes in a network are trusted, and
>     that malicious nodes not be allowed to take advantage of the overload
>     control mechanism to get more than their fair share of service.
I can't parse the last phrase of this (from "and that malicious..." 
onwards.  I know what you mean..
Suggest s/trusted, and that/trusted.  It also requires that/

s10.4, last para:
>     At the time of this writing, the DIME working group is studying
>     requirements for adding end-to-end security features
>     [I-D.ietf-dime-e2e-sec-req] to Diameter.
This statement has pretty much been OBE'd.  the draft is in WG last 
call.  I take it we can assume that the draft knows what is being 
specified: thus
> These features, when they
>     become available, might make it easier to establish trust in non-
>     adjacent nodes for overload control purposes.
It should be possible to make a more concrete statement here.

App C.1, para 1: s/normative references/a normative  reference/

App D.1, para 1: s/identity/entity/ (I think)

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Elwyn Davies | 23 Jul 18:25 2015

Gen-art LC review of draft-ietf-dime-ovli-08

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-dime-ovli-08.txt
Reviewer: Elwyn Davies
Review Date: 2015/07/23
IETF LC End Date: 2015/07/27
IESG Telechat date: (if known) -

Summary:

Major issues:

Minor issues:
s4.2:
Is there a need for and consequently how would one either cancel the 
current abatement algorithm or select a different one?  I guess this 
might happen if the reacting node that was running the algorithm went 
away or itself became overloaded.  However I I have no idea whether this 
is a reasonable question!  OK.. well I see in s5.1.1 that the abatement 
algorithm can be changed... a pointer in s4.2 would be useful.  But 
could it be turned off?

Appendix A.3:  The statements in this appendix are not 'future proof'.  
Referring to ongoing actions of the DIME WG will have little value in 
the future.  Maybe something like "There is an expectation that <these 
developments> will occur and can be integrated with the features 
described in this document."

Appendix C.1, para 1: There are some tense and past/future issues in 
this section - It is now mid 2015 and this para refers in the future to 
'end of 2014'.  Please rewrite to reflect current actualité and in a way 
that will be relevant when this is published as an RFC.

Appendix C.5:
> C.5.  No New Vulnerabilities
>
>     The working group believes that DOIC is compliant with the
>     requirement to avoid introducing new vulnerabilities.  However, this
>     requirement may warrant an early security expert review.
Hmm!  I fear that it would difficult to consider this draft 'ready' if 
there is no reasonable consensus that it hasn't introduced any new 
vulnerabilities.  Has the security expert review actually happened?

> REQ 13: The solution MUST NOT introduce substantial additional work
>             for a node in an overloaded state.  For example, a
>             requirement for an overloaded node to send overload
>             information every time it received a new request would
>             introduce substantial work.
>
>             *Not Compliant*. DOIC does in fact encourage an overloaded
>             node to send an OLR in every response.  The working group
>             that other mechanisms to ensure that every relevant node
>             receives an OLR would create even more work.  ****[Note: This
>             needs discussion.]****
Has this discussion occurred?  Does the WG have consensus that this 
derogation from the requirements is acceptable?

Nits/editorial comments:
General: s/i.e./i.e.,/ g; s/e.g./e.g.,/g
General: Consistent use of "non-supporting" vs "non supporting" (lots of 
places)

s2, Host-Routed Requests:
Expand acronym AVP (first use).

s5.2.1.1:
>     A host-type OCS entry is identified by the pair of application-id and
>     the node's DiameterIdentity.
>
>     A realm-type OCS entry is identified by the pair of application-id
>     and realm.
The application-id, DiameterIdentity and realm presumably come from the 
various messages taht are being piggybacked on.  A reference to the 
relevant section of the RFC that gives definitions of these (and which 
messages to get them from) would be helpful.  Later... this issue is 
partially resolved by s7.3.  A pointer to that section would be 
desirable.  s7.3 needs a reference to where the relevant messages are 
defined.

s5.2.1.4, last para:
>     A reporting node MUST keep an OCS entry with a validity duration of
>     zero ("0") for a period of time long enough to ensure that any non-
>     expired reacting node's OCS entry created as a result of the overload
>     condition in the reporting node is deleted.
Is it possible to offer any guidance on what constitutes 'long enough'?

s5.2.2 (in Note):
>   Any extension
>        that defines a new abatement treatment must also defined the
>        interaction of the new abatement treatment with existing
>        treatments.
s/defined/define/

s5.3, paras 2, 3, 5,  7  (but probably not the MUST NOT in para 6):
In line with the text in the previous comment, I think s/MUST/must/, 
s/MAY/may/ - they are not things the protocol does

s7:
Pointers are needed to the RFC sections that define the data types and 
the AVP syntax definition structure used in this section.

s7.3 - see comments on s5.2.1.1 above

s8, para 6: s/Diameter identity/DiameterIdentity/ (possibly)

s9.2:  It doesn't seem obvious to me that the values are supposed to 
have names in the registry.  Surely s/b
   (e.g.)
     Feature Vector Entry Name
     Feature Vector Entry Value
     Specification...

s10.3, last para:
>     Requirement 28 [RFC7068] indicates that the overload control solution
>     cannot assume that all Diameter nodes in a network are trusted, and
>     that malicious nodes not be allowed to take advantage of the overload
>     control mechanism to get more than their fair share of service.
I can't parse the last phrase of this (from "and that malicious..." 
onwards.  I know what you mean..
Suggest s/trusted, and that/trusted.  It also requires that/

s10.4, last para:
>     At the time of this writing, the DIME working group is studying
>     requirements for adding end-to-end security features
>     [I-D.ietf-dime-e2e-sec-req] to Diameter.
This statement has pretty much been OBE'd.  the draft is in WG last 
call.  I take it we can assume that the draft knows what is being 
specified: thus
> These features, when they
>     become available, might make it easier to establish trust in non-
>     adjacent nodes for overload control purposes.
It should be possible to make a more concrete statement here.

App C.1, para 1: s/normative references/a normative  reference/

App D.1, para 1: s/identity/entity/ (I think)

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Wassim Haddad | 22 Jul 10:00 2015
Picon

Gen-Art Review of draft-ietf-sidr-rfc6490-bis-04

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document: draft-ietf-sidr-rfc6490-bis-04
Reviewer:  Wassim Haddad
Review Date: 22 July 2015
IETF LC End Date: 23 July 2015
IETF Telechat Date: unknown

Summary:  This draft is ready for publication as proposed RFC

- Major Issues: None

- Minor Issues: None


Regards,

Wassim H.

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
Francis Dupont | 17 Jul 20:38 2015
Picon

review of draft-ietf-opsec-ipv6-host-scanning-07.txt

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-opsec-ipv6-host-scanning-07.txt
Reviewer: Francis Dupont
Review Date: 20150710
IETF LC End Date: 20150708
IESG Telechat date: unknown

Summary: Ready

Major issues: None

Minor issues: None

Nits/editorial comments:
 - Abstract page 1: usually there is no very explicit reference to the
  RFC the document obsoletes. IMHO this case could be a reasonable
  exception.

 - ToC page 3 and 18 page 25: Acknowledgements -> Acknowledgments
  (I use a US English spell checker, I am trying to switch to
   a UK one but both raise errors for the other alternative...
   I suggest to ask the RFC Editor to uniformize/uniformise the
   English variant...)

 - 1 page 3 and many other places: e.g. -> e.g.,

 - A.1 page 29 (and other places): I have a concern about OS names,
  for instance I prefer Microsoft Windows to simply Windows.
  BTW the current offical name of Mac OS (MacOS) X is (Apple) OS X.

Regards

Francis.Dupont <at> fdupont.fr
A. Jean Mahoney | 16 Jul 18:37 2015

A *new* batch of IETF LC reviews - 2015-07-16

Hi all,

The following reviewers have assignments:

Reviewer          LC end       Draft
---------------------------------------------------------------------
Francis Dupont    2015-07-27   draft-ietf-dime-ovli-08

Joel Halpern      2015-08-11   draft-ietf-dnsop-onion-tld-00

Meral Shirazipour 2015-07-29   draft-ietf-homenet-dncp-07

I have made the assignments in the review tool:
http://art.tools.ietf.org/tools/art/genart/

And the assignments are captured in the spreadsheets:
http://wiki.tools.ietf.org/dav/genart/gen-art.html
http://wiki.tools.ietf.org/dav/genart/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

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

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:
Tom Taylor | 15 Jul 16:58 2015
Picon

Last Call review of draft-vinapamula-softwire-dslite-prefix-binding-07

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-vinapamula-softwire-dslite-prefix-binding-07
Reviewer: Tom Taylor
Review Date: 2015-07-15
IETF LC End Date: 2015-08-05
IESG Telechat date: 2015-08-20

Summary: technically straightforward and well written with nits and a 
minor issue. Most of the nits are to make the text sound better to an 
anglophone ear.

Major issues:

Minor issues:

In the Security Considerations section, it might be appropriate to 
discuss the security (privacy?) consequences of misdirected traffic due 
to address change (if the recommendations are not implemented), and to 
prefix change in any event.

Nits/editorial comments:

Sec. 1, para 1, fourth line: s/that is/which is/

Sec. 1, next-to-last para:
OLD
   to avoid the same prefix be assigned to the same customer
NEW
   to avoid assigning the same prefix to the same customer

Sec. 2, second para, second line: s/may be/maybe/
   "       "        , fifth line: s/no more/no longer/

Sec. 2, fourth para, second line: missing "of" after "fairness"
   "       "        , eighth line, missing "changes" after "IPv6 address"

Sec. 2, fourth para: the sentence
"To that aim, a subscriber should be identified by the
AFTR based upon the IPv6 prefix assigned to the corresponding CPE,
and not according to the derived B4's IPv6 address."
introduces a solution to the problem (redundantly, since that solution 
is stated at the end of the section) rather than simply identifying the 
problem. May I suggest replacing it with:
"If the derived B4's IPv6 address can change, resource tracking using 
that address will give incomplete results."

Sec. 3, second para, third line: s/to configure/configuring/

Sec. 4, bullet 1, indented para, first line: s/to mount/from mounting/
   "       "          "           fourth line: s/quota was/quota were/
    Subjunctive voice is grammatically correct here, but less commonly
    used these days, so the suggestion is totally optional.

Sec. 4, bullet 2, fourth line: missing "a" in front of "configured".

Sec. 4, bullet 3, sixth line: missing "the" in front of "B4's".

Sec. 4, bullet 6, sixth line: missing "having" in front of "to 
redirect", or alternatively, s/to redirect/redirecting/.

In the Acknowledgements section there is an XML2RFC issue with extra 
spaces after the periods delimiting the initials. Or is this the result 
of applying the space fixing program available on the Tools page?
Elwyn Davies | 13 Jul 13:58 2015

Gen-art 2nd LC review of draft-ietf-payload-vp8-16

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-payload-vp8-16.txt
Reviewer: Elwyn Davies
Review Date: 2015/07/10
IETF LC End Date: 2015/07/13
IESG Telechat date: (if known) -

Summary: Gosh, it has been a long time since the last review!

Major issues:

Minor issues:
s4.2: Various of the frame indices either SHOULD or, in the case of
KEYIDX, MAY start at random values.  The rationale(s) for these
requirements are not explained - nor is the reason why it it is only a
MAY for KEYIDX whereas it is SHOULD for PictureID and what might happen
were the MAY/SHOULD to be ignored.

Is the rationale something that should be mentioned in the security
considerations?

s10.1:  The downref to RFC 6386 identified by idnits was duly noted in the last call
announcement.  I don't have a problem with the downref.

Nits/editorial comments:

General: Consistent usage of "prediction and mode" vs "prediction/mode" would be desirable.

  s1, para 2: Needs to introduce the 'macroblock' jargon defined in RFC 6386. Suggest:
OLD:
  VP8 is based on decomposition of frames into square sub-blocks of
  pixels, prediction of such sub-blocks using previously constructed
  blocks, and...
NEW:
  VP8 is based on decomposition of frames into square sub-blocks of
  pixels known as "macroblocks" (see Section 2 of [RFC6386]).  Prediction
  of such sub-blocks using previously constructed blocks, and...
END

s2: There are a number of technical terms brought over from RFC 6386.
These should be listed in s2.  At least the following would be in the list:
key frame, interframe, golden frame, altref frame, macroblock.
Also the terms picture selection index (RPSI) and slice loss indication (SLI) from RFC 4585.

s3, para 2: Providing a reference to explain what temporal scalability
and the hierarchy selection is all about would be useful.  One possibility
would be:

Lim, J. Yang, and B. Jeon,”Fast Coding Mode Decision for Scalable Video Coding”,
10th Int’l Conf. on Advanced Communication Technology, vol. 3, pp. 1897-1900, 2008.

It would also help to add a pointer to the TL0PICIDX description in s4.2, thus:
ADD:
    Support for temporal scalability is provided by the optional TL0PICIDX and TID/Y/KEYIDX
fields described in Section 4.2.
END

ss3 and 4: The discussion of how the frame payload might or might not be distributed across
multiple packets is not very clear.   The draft has in mind a 'preferred use case' (para 1
of s4.4 says:

> In the preferred use case, the S bit and PID fields
>     described in Section 4.2 should be used to indicate what the packet
>     contains.

I think it would be helpful to be a bit more positive about this in s3, para 3:
OLD:
    This memo
    allows the partitions to be sent separately or in the same RTP
    packet.  It may be beneficial for decoder error-concealment to send
    the partitions in different packets, even though it is not mandatory
    according to this specification.
NEW:
Accordingly, this document RECOMMENDS that the frame is packetized by the sender
with each data partition in a separate packet or packets.  This may be beneficial
for decoder error concealment and the payload format described in Section 4 provides
fields that allow the partitions to be identified even if the first partition is
not available.  The sender can, alternatively, aggregate the data partitions into
a single data stream and, optionally, split it into several packets without
consideration of the partition boundaries.  The receiver can use the length
information in the first partition to identify the partitions during decoding.
END

s4/Figure 1: s/bytes/octets/ (2 places)

Figure 1, caption: s/sequel/Sections 4.2 and 4.3/

Figure 1: The format shown is correct only for the first packet in a frame.  Subsequent
packets will not contain the payload header and will have later octets of the frame payload.
This should be mentioned in drawing and/or in the caption.

s4.1, last two paras:
>     Sequence number:  The sequence numbers are monotonically increasing
>        and set as packets are sent.
>
>        The remaining RTP header fields are used as specified in
>        [RFC3550].
Redefining the Sequence Number field seems gratuitous and potentially dangerous,
given that it is *very carefully* defined in RFC 3550 and the overall intent does
not seem any different from that in RFC 3550.  OTOH a note about the (non?-)use of the X bit
and the Payload Type field (PT) would be useful.  I suggest replacing the paras above with:
NEW:
    X bit: MUST be 0.  The VP8 RTP profile does not use the RTP Header Extension capability.

    PT (Payload Type):  In line with the policy in Section 3 of [RFC3551], applications
       using the VP8 RTP payload profile MUST assign a dynamic payload type number to
       be used in each RTP session and provide a mechanism to indicate the mapping.
       See Section 6.2 for the mechanism to be used with the Session Description Protocol (SDP)
       [RFC4566].

       The remaining RTP Fixed Header Fields (V, P, CC, sequence number, SSRC and CSRC
       identfiers) are used as specified in Section 5.1 of [RFC5330].
END
Note that this may be considered to make the reference to RFC 3551 normative.

s4.2, X bit:  There is potential for confusion between the X bit in the fixed header
and the X bit in the VP8 Payload Descriptor.  Perhaps changing this to C for control bits
would avoid the problem.

s4.2, M bit: Similarly, it might be better to use B (for BIG) in place of M to avoid confusion.

s4.2, para 7 after Fig 2: For consistency:
OLD:
    When the X bit is set to 1 in the first octet, the extension bit
    field octet MUST be provided as the second octet.  If the X bit is 0,
    the extension bit field octet MUST NOT be present, and no extensions
    (I, L, T, or K) are permitted.
NEW:
    When the X [or C] bit is set to 1 in the first octet, the Extended Control Bits
    field octet MUST be provided as the second octet.  If the X [or C] bit is 0,
    the extension bit field octet MUST NOT be present, and no extensions
    (I, L, T, or K) are permitted.
END

s4.2: The issue of using either 'wrap' or 'restart' but not both for 
restarting number sequences has been raised in various comments by IESG 
members.

s4.2, TL0PICIDX: I think, given the statements in s3 about not defining 
the hierarchy, that more explanation is needed of what the 'lowest or 
base layer' actually means.

s4.2, TL0PICIDX:
>   If TID is larger than 0, TL0PICIDX
>           indicates which base layer frame the current image depends on.
>           TL0PICIDX MUST be incremented when TID is 0.
What happens if L=1 but both T=0 and K=0 so that there is no TID value 
present? Or indeed if T=0 but K=1 so that the TID field is there but 
'MUST be ignored by the receiver'  (definition of TID field)?

s4.3: It would be useful to include the section number (9.1) where the 
uncompressed data chunk specification is found.  I was somewhat 
surprised that the ordering is reversed in the protocol spec.

s4.3, VER: The receiver should validate this field - currently only 
values 0-3 are valid.

s4.3, SizeN:  Make it clear these are integer fields: s/in Size0,/in 
integer fields Size0,/

s4.3 and s4.4:  It would be helpful to implementers to explain what the 
offsets in the  first partition payload are for the additional partition 
count and additional partition sizes.  Having rummaged around in RFC  
6386, I have to say that I am unclear whether the values are placed 
after the full chunk of data indicated by 1stPartitionSize or are part 
of this data. And if the latter is the case, how to work out where the 
partition sizes are.  I guess that they ought to be at offset 
(1stPartitionSize+10 - key frame - or 1stPartitionSize+3 - interframe) 
in the VP8 Payload field as it is difficult to work out where they are 
without decoding the partition otherwise.  Also exactly how many 
partition sizes to expect - I think I read in RFC 6386 that the last 
partition size is implicit. Help!

In the course of clearing this up, it might be appropriate to move the 
last sentence of the first para of s4.4 and the second para of s4.4 into 
s4.3 as part of the explanation.  This is the relevant text:
>     Note that the length of the first partition can
>     always be obtained from the first partition size parameter in the VP8
>     payload header.
>
>     The VP8 bitstream format [RFC6386] specifies that if multiple DCT/WHT
>     partitions are produced, the location of each partition start is
>     found at the end of the first (prediction/mode) partition.  In this
>     RTP payload specification, the location offsets are considered to be
>     part of the first partition.

s4.4:  I found this section very difficult to parse.  It is a bit 
'stream of consciousness' and would benefit from a reordering and 
rewrite.  Suggestion (assuming the second para gets moved to s4.3):
NEW SECTION 4.4:
    An encoded VP8 frame can be divided into two or more partitions, as
    described in Section 1.  It is OPTIONAL for a packetizer implementing
    this RTP specification
    to pay attention to the partition boundaries within an encoded frame.
    If packetization of a frame is done without considering the partition
    boundaries, the PID field MAY be set to zero for all packets, and the
    S bit MUST NOT be set to one for any other packet than the first.

    If the preferred usage suggested in Section 3 is followed, with each 
packet
    carrying data from exactly one partition, the S bit and PID fields
    described in Section 4.2 SHOULD be used to indicate what the packet
    contains.  The PID field should indicate which partition the first
    octet of the payload belongs to, and the S bit indicates that the
    packet starts on a new partition.

    If the packetizer does not pay attention to the partition 
boundaries, one
    packet can contain a fragment of a  partition, a complete partition, 
or an
    aggregate of fragments and partitions.  There is no explicit 
signaling of
    partition boundaries in the payload and the partition lengths at the 
end of
    the first partition have to be used to identify the boundaries. 
Partitions
    MUST be aggregated in decoding order.  Two fragments from different
    partitions MAY be aggregated into the same packet along with one or 
more
    complete partitions.

   In all cases, the payload of a packet MUST contain data from only one 
video
   frame.  Consequently the set of packets carrying the data from a 
particular
   frame will contain exactly one VP8 Payload Header (see Section 4.3) 
carried
   in the first packet of the frame.  The last, or only, packet carrying 
data for the
   frame MUST have the M bit set in the RTP header.

s4.5.1:  Th algorithm only applies for the RECOMMENDED use case with 
partitions in separate packets.
This should be noted.

s5.2, last para: s/only parts of the frame is corrupted./only part of 
the frame is corrupted./

s6: s/This payload format has two required parameters./This payload 
format has two optional parameters./
[I think this is probably a hangover from the previous version.]

s7: s/Cryptographic system may also allow/The cryptographic system may 
also allow/

s7:
> the usage of SRTP [RFC3711] is recommended.
RECOMMENDED?

s10.2: I suspect that RFC 3551 is normative.

_______________________________________________
Gen-art mailing list
Gen-art <at> ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Gmane