[Gen-art] Review of draft-ietf-payload-melpe-04

[Brian Carpenter]

Reviewer: Brian Carpenter
Review result: Ready with Issues

Gen-ART Last Call review of draft-ietf-6tisch-minimal-17

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document: draft-ietf-payload-melpe-04.txt
Reviewer: Brian Carpenter
Review Date: 2016-12-26
IETF LC End Date: 2017-01-13
IESG Telechat date:  

Summary: Ready with minor issues


Major Issues: None
-


Minor issues:
-

> 3.1  MELPe Bitstream Definition
>
>   The total number of bits used to describe one frame of 2400 bps
>   speech is 54, which fits in 7 octets (with two unused bits). For
the
>   1200 bps speech the total number of bits used is 81, which fits in
11
>   octets (with seven unused bits). For the 600 bps speech the total
>   number of bits used is 54, which fits in 7 octets (with two
unused
>   bits).  Unused bits are coded as described in 3.3 in support of
>   dynamic bit-rate switching.

It would help the reader if the last sentence said something like:

   Unused bits, shown below as RSVA, RSVB, etc., are coded as
described
   in 3.3 in support of dynamic bit-rate switching.

> 3.3  Multiple MELPe frames in a RTP packet
...
>   When dynamic bit-rate switching is used and more than one frame
is
>   contained in a RTP packet, it is recommended to inspect the coder
>   rate bits contained in the last octet.  If the coder bit rate
>   indicates a Comfort Noise frame, then inspect the third last
octet
>   for the coder bit rate.  All MELPe speech frames in the RTP
packet
>   will be of this same coder bit rate.

I agree with the AD review that this should be RECOMMENDED.

> 4.2  Mapping to SDP
...
>   Alternative encoding name types,
>   "MELP2400", "MELP1200", and "MELP600", may be used in SDP to
convey
>   fixed bit-rate configurations. 

I think that should be MAY. If you really want to discourage this
usage,
you would need to say SHOULD NOT. Lower-case "may" is unclear in this
case.

> 6  Packet Loss Concealment

The "may" and "recommended" in this section are unclear - should they
be MAY and RECOMMENDED?

According to the writeup "There are existing implementations." It's a
shame
that there is no Implementation Status section (RFC 6982).

Nits:
-

"declaritive" should be "declarative" (twice)

> 3.4  Congestion Control Considerations
>
>   The target bitrate of MELPe can be adjusted at any point in time,
>   thus allowing efficient congestion control.  Furthermore, the
amount

I would rephrase "efficient congestion control", because at present
the
word "efficient" isn't really justified by the text. How about
"thus allowing straightforward congestion management"?

>   of encoded speech or audio data encoded in a single packet can be
>   used for congestion control, since the transmission rate is
inversely
>   proportional to the packet duration.

Make that "the packet rate", because "transmission rate" could refer
to the
bit rate or the packet rate. At the moment the reader might miss that
until
the following sentence.

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Review of draft-ietf-kitten-krb-auth-indicator-04

[Benjamin Kaduk]

Hi Robert,

Thanks for the review (I'm the shepherd, not the editor).

On Thu, Dec 22, 2016 at 11:41:12AM -0800, Robert Sparks wrote:
> Reviewer: Robert Sparks
> Review result: Ready with Nits
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-kitten-krb-auth-indicator-??
> Reviewer: Robert Sparks
> Review Date: 2016-12-22
> IETF LC End Date: 2017-01-06
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: Ready for publication as Proposed Standard, but
> with nits that should be considered before advancing
> 
> Nits/editorial comments:
> 
> Please remove the 2119 MUST from the Introduction - you already
> have that requirement expressed in the last paragraph of
> section 3. If the introduction needs to highlight that the
> requirement exists, say something similar to "Section 3
> requires that elements of this type appear within an AD-CAMMAC
> container."
> 
> The 3rd paragraph in section 4 has a MAY in its first sentence
> that is not an appropriate use of 2119. A lower case "may" is
> fine here - you're not placing a requirement on implementation.

Those first two comments look like good changes to me.

> That whole 3rd paragraph looks like an attempt to acknowledge
> a larger conversation without getting into the meat of that
> conversation. Rather than make the readers re-discover the
> problem on their own (right now they have to guess at what
> the problem really is, with your suggested guidance being
> the only hint), can you explicitly demonstrate the potential
> problem? Perhaps pointing to existing discussion in another
> document would be good? There's bound to be something in
> our various policy framework documents that captures why
> you need either only positive or only negative assertions
> if you are going to be combining them. We ran into pretty
> much this problem with presence - grep for "positive grants"
> in RFC5025 for instance. I suspect there's a better reference
> that I'm just not remembering at the moment.

This is also a good point, but I'm not sure I have a good suggestion
of a reference to insert.  To give a more concrete example relevant
to this document, at the moment, you can authenticate to kerberos
in many ways, including with a password, using an OTP value (within
a RFC 6113 FAST tunnel), and with PKINIT asymmetric crypto.  One
might be tempted to put in a value "without-password" to indicate
that a password was not used, but when an application server goes
to consume that authentication indicator, the assumption might be
that without-password means PKINIT, which is arguably a stronger
authentication than the OTP method.  Thus, there is the possibility
of the application server would make a bad decision based on the
negative "without-password" indicator, in contrast to an explicit
"pkinit" or "otp" indicator.

-Ben

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Review of draft-ietf-curdle-dnskey-eddsa-03

[Dan Romascanu]

Reviewer: Dan Romascanu
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-curdle-dnskey-eddsa-??
Reviewer: Dan Romascanu
Review Date: 2016-12-25
IETF LC End Date: 2016-12-16
IESG Telechat date: 2017-01-05

Summary: Ready. The minor issues noticed in the LC review were
addressed and the appropriate edits incorporated. 

Major issues:

Minor issues:

Nits/editorial comments: 


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art