Subject: [apps-discuss] RFC2326bis reviews received

From: Claudio Allocchio <[email-masked]>
Date: Mon, 30 Sep 2013 15:48:51 +0200 (CEST)

Hello all,

a couple of comments and reviews were sent to the WG chairs directly over 
the last week, thus maybe it it better to add the also here.

See below the messages.

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

>From [email-masked] Thu Sep 26 19:28:01 2013
Date: Thu, 26 Sep 2013 11:27:51 -0600
From: Peter Saint-Andre <[email-masked]>
To: [email-masked]
Cc: Claudio Allocchio <[email-masked]>
Subject: base64 and datetimes in 2326bis

Here is some brief feedback on 2326bis. I'm sorry that I don't have
time for a longer review.

BASE64

The usages of Base64 do not specify which exact encoding of Base64 they
require and what to do about padding bits. For example, Section 18.54
says:

          The binary MIKEY message SHALL
          be Base64 [RFC4648] encoded before being included in the value
          part of the parameter.

If the specification assumes that the rules from Section 4 of RFC 4648
are to be used, that text would be more accurate as:

          The binary MIKEY message SHALL
          be BASE64 [RFC4648] encoded before being included in the value
          part of the parameter, where the encoding adheres to the
          definition in Section 4 of RFC 4648 and where the padding bits
          are set to zero.

DATETIME FORMATS

Section 4.4.3 seems to be underspecified:

    Absolute time is expressed as ISO 8601 [ISO.8601.2000] timestamps,
    using UTC (GMT).  Fractions of a second may be indicated.

    Example for clock format range request for a starting time of
    November 8, 1996 at 14h 37 min and 20 and a quarter seconds UTC
    playing for 10 min and 5 seconds, a Media-Properties header's "Time-
    Limited UTC property for 24th of December 2014 at 15 hours and 00
    mins, and a Terminate-Readon headers "time" property for 18th of June
    2013 at 16 hours, 12 minutes and 56 seconds:

      clock=19961108T143720.25Z-19961108T144725.25Z
      Time-Limited=20141224T1500Z
      time=20130618T161256Z

ISO 8601 has many profiles. Is the profile defined in RFC 3339
supported? That would result in a datetime of the following form:

      1996-11-08T14:37:20.25Z

Also are timezone offsets allowed?

If the answers are "no" then it would be good to explain that in the text.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

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

>From [email-masked] Mon Sep 30 15:40:43 2013
Date: Mon, 30 Sep 2013 15:40:25 +0200 (CEST)
From: Claudio Allocchio <[email-masked]>
To: Magnus Westerlund <[email-masked]>
Cc: Claudio Allocchio <[email-masked]>, Gonzalo Camarillo <[email-masked]>, Peter Saint-Andre <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Review of rfc2326bis

Ok, here are the notes I did on v34, which I now checked against v37 
(they're from last June...)

1 Intro: - ok no isses

2 Protocol overview - ok no issues.

3.1 Notational Conventions: -

nits: "smaller-type" may not be a term which anybody understands 
immediatley, expecially when reading the official text based RFC-to-be.
*** this was fixed already ***

4.1: minore issue: "Leading zeros MUST be ignored by recipients and MUST 
NOT be sent."

Well, we do not really need both compulsory 
specifications... If leading zeroes MUST NOT be sent, then it will never 
happen that recipients get them :-) Either "SHALL NOT be sent" and "MUST 
be ingored" or change the sentence in a different way.

4.4.2: nit: "... not to be confused with the Network Time Protocol"  :-)
well.. then we have SNMP and SMTP etc etc... I would delete this part of 
the sentence and its reference.

minor issue: ISO.13818-6.1995 (same as your point).

10. Connections.

minor issue: should the chapter about connectionless mode be more 
explicit, stating something like "MUST NOT use connectionless mechanisms" 
? indeed the text say the same... but in a much more nromative way.

Security Considerations: I made an extensive check of this section and I 
find it OK, no issues.

IPv6 considerations in general:

minor issue: the whole specification is still very much 
IPv4 focused, apart making compulsory the acceptance of IPv6 literal 
addresses. But it should be made explicit in various sections (see for 
example proxies and NAT etc...) that there are IPv4 only specific parts.

I did not find other evident issues in the other sections.

Claudio