Aaron Stone | 9 Feb 17:38
Gravatar

APPSDIR review of draft-ietf-payload-rtp-klv-03

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document: draft-ietf-payload-rtp-klv-03
Title: RTP Payload Format for SMPTE 336M Encoded Data
Reviewer: Aaron Stone
Review Date: Feb 6, 2012
IETF Last Call Date: unknown
IESG Telechat Date: 2012-02-16

Summary: This draft is ready for publication on the Standards Track.

Major Issues: None.

Minor Issues:

Introduction: How does the recipient know what the length of a Key is?
Reading this document as if I were going to implement the protocol, I
could not figure out how my code would figure out the length of the K
in KLV. There is a good description of discovering the length of the
Length field!

Please include a definition of "KLV universal key", as it is used in
the introduction and abstract without definition. Is there a key
registry maintained somewhere? Presumably the SMPTE maintains this
registry, rather than IANA. If so, please reference this registry.
(Continue reading)

Henry S. Thompson | 7 Feb 18:30
Picon
Picon
Favicon

Appsdir review of draft-ietf-oauth-v2-23

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-oauth-v2-23

Title: The OAuth 2.0 Authorization Protocol

Reviewer: Henry S. Thompson

Review Date: 2012-02-07

IETF Last Call Date: 2012-01-24

Summary: This draft is almost ready for publication as an Proposed
         Standard but has a few issues that should be fixed
         before publication

[Note - My expertise is in the areas of markup and architecture, with
only the average geek's understanding of security and cryptographic
technologies.  Any comments below on security issues are therefore of
the nature of general audience concerns, rather than technical worries.]

Major Issues: 

3.1.2.1  The failure to require TLS here is worrying.  At the very
(Continue reading)

Yves Lafon | 6 Feb 21:51
Picon
Favicon
Gravatar

(no subject)

Dear all,

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Document: draft-snell-atompub-tombstones-14
Title: The Atom "deleted-entry" Element
Reviewer: Yves Lafon
Review Date: 6 Feb 2012

Summary: This draft is almost ready for publication as Informational RFC, 
there is a minor issue with the ref. section, and a clarification request 
on a MUST-level requirement that is non-blocking.

First, the clarification request: I noted that in 3/ "The at:deleted-entry 
element"

It says:
<<
    An Atom feed MAY contain any number of at:deleted-entry elements, but
    MUST NOT contain more than one with the same combination of ref and
    when attribute values.
>>
then later
<<
    Implementors should note that the at:deleted-entry element is
    informative in nature only and may be ignored by Atom processors.
    The presence of an at:deleted-entry element does not guarantee that
    the atom:entry to which it is referring will no longer be available.
(Continue reading)

Tobias Gondrom | 6 Feb 15:29
Favicon

APPSDIR review of draft-ietf-tsvwg-source-quench-04

Hello,

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

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

Document:  draft-ietf-tsvwg-source-quench-04
Title:  Deprecation of ICMP Source Quench messages
Reviewer: Tobias Gondrom
Review Date: 2012-02-06
Abstract: This document formally deprecates the use of ICMP Source Quench
   messages by transport protocols, formally updating RFC 792, RFC 1122,
   and RFC 1812.  Additionally, it requests that the status of RFC 1016
   be changed to "Historic".


Summary:

This draft is ready for publication as an RFC.
And I agree with the conclusions of the Transport Area Working Group (tsvwg) to deprecate ICMP source quench, especially from a potential security perspective.

Comment/remark:
one of the reasons for deprecating ICMP source quench was given in the draft in section 1 as:
"- Virtually all popular host implementations have removed support
      for ICMP Source Quench messages since (at least) 2005 [RFC5927]"
Please note, that the reviewer did not test/verify this statement, but assumes that the transport working group has researched and confirmed this data in WGLC. If this is not the case, the transport are WG should reconfirm this assumption before the draft progresses to IESG.

Best regards, Tobias



Tobias Gondrom
email: tobias.gondrom <at> gondrom.org
mobile: +447521003005
_______________________________________________
apps-discuss mailing list
apps-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Enrico Marocco | 6 Feb 10:50
Picon
Favicon
Gravatar

APPSDIR review of draft-ietf-simple-chat-13

Document: draft-ietf-simple-chat-13
Title: Multi-party Chat Using the Message Session Relay Protocol (MSRP)
Reviewers: Alexey Melnicov and Enrico Marocco
Review Date: 2012-02-06
IETF Last Call Date: 2012-02-06

Summary: This draft is almost ready for publication as a Proposed
Standard, but has a major issue to be taken into consideration and a few
minor issues to be fixed.

Major Issue

The document doesn't describe allowed characters in Nicks and any
normalization that needs to be applied.

Minor Issues

The document strictly forbids multiple To: headers in the CPIM message,
that could be used for example to send public personal messages (i.e.
messages addressed to some particular individual, but shared with the
entire conference, a-la Twitter). If there's a reason for that, some
explanation would be useful.

Figure 1 seems to imply that MSRP relays are mandatory. Since they are
not -- and the draft is pretty clear about it -- I'd suggest to have
some of MSRP flows in the diagram flow straight from the client to the
switch.

A reference to the SDP mechanism defined in S. 8.  would be useful in in
S. 5.2., last paragraph, S. 6.2, last paragraph, and in any other part
that deals with discovering of client capability.

In Section 5.2:

    The conference focus of a chat room MUST learn the chat room

How can this be achieved? A forward pointer might be missing here.

    capabilities of each participant that joins the chat room.  The
    conference focus MUST inform the MSRP switch of such support in
    order to prevent the MSRP switch from distributing private messages
    to participants who do not support private messaging.  The recipient
    would not be able to render the message as private, and any
    potential reply would be sent to the whole chat room.

In Section 7.1:

    The reservation of a nickname can fail, e.g. if the NICKNAME request
    contains a malformed or non-existent Use-Nickname header field, or
    if the same nickname has already been reserved by another
    participant (i.e., by another URI) in the chat room.  The
    validation can also fail where the sender of the message is not
    entitled to reserve the nickname.  In any of these cases the MSRP
    switch MUST answer the NICKNAME request with a 423 response.  The
    semantics of the 423 response are: "Nickname usage failed; the
    nickname is not allocated to this user".

It would be better to use different response codes for different error
conditions.

Nits [Only the few that came out in non-nitpicking read]

S. 3, REQ-3: s/depend no/depend on/

S. 4, second paragraph after Figure 2: s/a text/text/

A few 2119 refuses can be also found in the text, e.g.:

S. 5.2, sixth paragraph: s/URI must not/URI MUST NOT/

Attachment (smime.p7s): application/pkcs7-signature, 4492 bytes
_______________________________________________
apps-discuss mailing list
apps-discuss <at> ietf.org
https://www.ietf.org/mailman/listinfo/apps-discuss
Ned Freed | 5 Feb 01:42

Re: [happiana] comments on draft-freed-media-type-regs

I've been reviewing past comments on the draft and realized I had missed
this one that was originally posted to the HAPPIANA list.

> <hat type='individual'/>

> Overall this looks quite good and is an improvement over RFC 4288.
> Thanks to the authors for working on this.

> I have a few small comments.

> 1. Non-Commercial Producers

> Section 3.2 says:

>    "Vendor" or "producer" are construed as
>    equivalent and very broadly in this context.

> Section 3.3 says:

>    Registrations for media types created experimentally or as part of
>    products that are not distributed commercially may be registered in
>    the personal or vanity tree.

> What about products that are distributed non-commercially, such as
> open-source software. Should the registrant use "vnd." or "prs."?

vnd. definitely. We already added text about industry consortia using
the vnd. tree but it is worth adding non-commercial to that. It will be
in the next revision.

> IMHO it would be better to define vendor/producer broadly enough to
> include non-commercial organizations.

Agreed.

> 2. Owners

> Sections 3.1 and 3.3 define the "owner" for a registration:

>    The "owner" of a media type registration in the standards tree is
>    assumed to be the standards body itself.

>    The owner of "personal" registrations and associated specifications
>    is the person or entity making the registration, or one to whom
>    responsibility has been transferred as described below.

> As far as I can see, such a definition is not provided for the vendor
> tree (despite the claim in Section 5.8). Thus arises the question: are
> third-party registrations allowed? I think they should be.

This is currently on the open issues list.

> 3. The "x." Tree

> Section 3.4 is somewhat at odds with draft-ietf-appsawg-xdash, which
> deprecates use of "x-" and similar constructions in application
> protocols. I doubt that we still need a special tree here. See also the
> naming restrictions in Section 4.2. I would be happy to discuss this
> further or propose text if desired.

Per my previous response, I'm taking a wait-and-see position on this one
for now. My preference would be to leave x. alone (it's never seen
any real use AFAIK) but remove the special status for x- entirely. But
let's see how the consensus develops.

> 4. "charset"

> Section 4.1 mentions things that are not media formats but charsets.
> Just to be sure, do we actually mean charset instead of one of the other
> terms (e.g., "character encoding") from BCP 166?

Absolutely not. Charset is the correct term to use here. For one thing, neither
character encoding nor coded character by themselves suffice to define a
complete way to encode characters as text - you have to combine them. And even
if you do, there are charsets that are defined in other ways. Charset really is
the most general term as it is defined as a mapping of octets to characters.

> 5. Encodings

> When mentioning "7bit US-ASCII text", perhaps reference RFC 5198.

Er, no. RFC 5198 doesn't even mention US-ASCII. And the Unicode format it
defines is 8bit, not 7bit!

> 6. Submission to the IESG

> One topic we've discussed on and off is removing the IESG bottleneck for
> standards-tree registrations, enabling other SDOs to directly submit
> their registration requests to the IANA for review by the IESG (rather
> than having the SDO's initial contact be to the IESG). I don't think
> we've quite reached consensus on that approach, but I think we should do
> so before draft-freed-media-type-regs is approved.

Of course this is the entire focus of the most recent revision; any feedback
on how it has been implemented would be appreciated.

				Ned
internet-drafts | 4 Feb 17:10
Picon
Favicon

I-D Action: draft-ietf-appsawg-media-type-regs-01.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Applications Area Working Group Working Group of the IETF.

	Title           : Media Type Specifications and Registration Procedures
	Author(s)       : Ned Freed
                          John C. Klensin
                          Tony Hansen
	Filename        : draft-ietf-appsawg-media-type-regs-01.txt
	Pages           : 29
	Date            : 2012-02-04

   This document defines procedures for the specification and
   registration of media types for use in HTTP, MIME and other Internet
   protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-01.txt
internet-drafts | 4 Feb 01:14
Picon
Favicon

I-D Action: draft-ietf-appsawg-media-type-regs-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Applications Area Working Group Working Group of the IETF.

	Title           : Media Type Specifications and Registration Procedures
	Author(s)       : Ned Freed
                          John C. Klensin
                          Tony Hansen
	Filename        : draft-ietf-appsawg-media-type-regs-00.txt
	Pages           : 29
	Date            : 2012-02-03

   This document defines procedures for the specification and
   registration of media types for use in HTTP, MIME and other Internet
   protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-media-type-regs-00.txt
S Moonesamy | 2 Feb 19:57
Favicon

Apps Area Directorate Report for January 2012

Hello,

The Applications Area Directorate provides semi-formal reviews of 
Internet-Drafts as a way to improve the quality of IETF 
specifications.  The directorate consists of the Working Group Chairs 
of the Applications Area and recognized experts in the Applications Area.

The following reviews were performed in January 2012:

    Reviewer             I-D

  Glenn Parsons        draft-melnikov-smtp-priority-04
  S. Moonesamy         draft-ietf-v6ops-ipv6-discard-prefix-02
  Murray S. Kucherawy  draft-ietf-dnsext-xnamercode-00
  Alexey Melnikov      draft-kucherawy-authres-spf-erratum-01
  Claudio Allocchio    draft-ietf-sipclf-format-05
  Salvatore Loreto     draft-ietf-avtcore-srtp-vbr-audio-04
  Barry Leiba          draft-ietf-dane-protocol-14
  Carsten Bormann      draft-ietf-decade-arch-04
  Tim Bray             draft-ietf-oauth-v2-threatmodel-01
  Jiankang Yao         draft-ietf-dhc-dhcpv6-redundancy-consider-02
  Lisa Dusseault       draft-ietf-sidr-rpki-rtr-25

Pending reviews are listed at http://trac.tools.ietf.org/area/app/trac/report/1

Regards,
S. Moonesamy
On behalf of the Applications Area Directorate
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
Yoshiro YONEYA | 2 Feb 10:23
Picon
Favicon
Gravatar

APPSDIR review of draft-harkins-ipsecme-spsk-auth-06

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments
you may receive.  Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-harkins-ipsecme-spsk-auth-06
Title: Secure PSK Authentication for IKE
Reviewer: Yoshiro Yoneya
Review Date: 2012-02-02
IETF Last Call Date: 2012-02-14
IESG Telechat Date: 2012-03-15

Summary:

This draft is almost ready for publication as an Experimental RFC but
has a few nits that should be fixed before publication.

Major Issues:

Minor Issues:

Nits:

- Section 4.2

  Two elementx, X and Y, --> Two element, X and Y,

- Section 7

  [RFC5996]) --> [RFC5996]

- Section 8.2.2

  ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking") -->
  ske-value = prf+(ske-seed, "IKE SKE Hunting And Pecking")

- Section 8.5.1

  [RFC6467]) --> [RFC6467]

Regards,

--

-- 
Yoshiro YONEYA <yoshiro.yoneya <at> jprs.co.jp>
internet-drafts | 1 Feb 15:42
Picon
Favicon

I-D Action: draft-ietf-appsawg-mime-default-charset-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item
of the Applications Area Working Group Working Group of the IETF.

	Title           : Update to MIME regarding Charset Parameter Handling in Textual Media Types
	Author(s)       : Alexey Melnikov
                          Julian F. Reschke
	Filename        : draft-ietf-appsawg-mime-default-charset-00.txt
	Pages           : 6
	Date            : 2012-02-01

   This document changes RFC 2046 rules regarding default charset
   parameter values for text/* media types to better align with common
   usage by existing clients and servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-appsawg-mime-default-charset-00.txt

Gmane