Integrated Services Digital Network (ISDN) Q.921-User Adaptation Layer
draft-ietf-sigtran-rfc3057bis-02

[Ballot comment]
Reviewed by Mary Barnes, Gen-ART

Her review:

Summary:
--------
Draft should be ready for publishing as a proposed standard
with the correction of the nits identified below.

Caveat:
-------
I primarily focused on the identified deltas from RFC 3057,
however, there were some things that were also in RFC 3057 that I
think should be corrected since they'll be editting anyways to correct
the template.

Nits:
-----
- Needs updating to new template reflecting RFC 3668/3667. Note also
  that the copyright in the back, as well as the front, needs updating
  as it's currently dated 2001.

- Section 1.4.3: "A set of primitives....are defined..." should read
  "A set of primitives...is defined..."

- Section 1.5.1: "TEI" and "SAPI" should be expanded here (they're not
  defined until section 3.2 on page 19 ).

- Section 2.0, I would suggest moving the reference to RFC 2119
  conventions to the beginning of section 1.2 since those conventions
  are used prior to section 2.0.

- Section 3.2, page 18, Figure 6 should be labeled as Figure 5 (this
  was an error left from the movement of Figure 2 in RFC 3057 to the
  appendix).

- Section 9.1, Reference [3], Is there not a draft name to associate
  with this reference or should this be RFC3788? [I didn't search the
  internet drafts archive for a bis draft, but didn't see one listed
  on the WG charter page.]

IANA Review Comments -  We see the registration of  IUA "1" in the SCTP Payload Protocol Identifiers registry found at

Will we need to udpate the reference for IUA in the registry to be this
document?  Other than that assignment being made, I'm not sure if all of the
IANA Actions were implemented when RFC3057 was published.  Is section
7.2 (7.2.1, 7.2.2, and 7.2.3) just saying that IT CAN BE extended yet
no one has done this yet - therefore there was nothing for IANA to do??

[Ballot comment]
The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
  is 9900.

It's an accident of (former) IANA practices that IUA has a UDP port number, which it will
never use, and confusing for it to be mentioned.  I think the mention should be excised.
Should the port also be de-assigned?

-------

Section 4.3.3.7 provides for an optional heartbeat use if SCTP is not used.  It really
should give guidance for the "provisional timer T(beat)" similar to the guidance in
sections 8.3 and 14 of RFC 2960 (SCTP) about setting HB.interval, jittering it, and
otherwise managing it for good engineering usage.

-------

Editorial:
  In these
  cases, the SCTP functions above MAY NOT be a requirement and TCP can
  be used as the underlying common transport protocol.

MAY NOT isn't even one of the RFC 2119 terms.  As a native English speaker, I make out
what they mean, but since "may not" often means "is not permitted to be", please change
this (with an RFC Editor Note is fine) to something like:

  In these cases, the SCTP functions MAY be found not to be a requirement and TCP MAY
  be used as the underlying common transport protocol.

[Ballot comment]
In these
  cases, the SCTP functions above MAY NOT be a requirement and TCP can
  be used as the underlying common transport protocol.

MAY NOT isn't even one of the RFC 2119 terms.  As a native English speaker, I make out
what they mean, but since "may not" often means "is not permitted to be", please change
this (with an RFC Editor Note is fine) to something like:

  In these cases, the SCTP functions MAY be found not to be a requirement and TCP MAY
  be used as the underlying common transport protocol.
 
-------

  The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
  is 9900.

It's an accident of (former) IANA allocation that IUA has a UDP port number, which it will
never use, and confusing for it to mention it.  I think the mention should be excised here.
Should the port also be de-assigned?

-------

Section 4.3.3.7 provides for an optional heartbeat use if SCTP is not used.  It really
should give guidance for the "provisional timer T(beat)" similar to the guidance in
sections 8.3 and 14 of RFC 2960 (SCTP) about setting HB.interval, jittering it, and
otherwise managing it for good engineering usage.

[Ballot comment]
The bit quoted below is infelicitous (as an IETF adept and native to English , I can parse this
MAY NOT, but it does have its meaning of not permitted.  I suggest an RFC Editor revising
this into "the SCTP functions above MAY be determined not to
be required, and TCP MAY be used...etc.

  In these
  cases, the SCTP functions above MAY NOT be a requirement and TCP can
  be used as the underlying common transport protocol.

-------

  The SCTP (and UDP/TCP) Registered User Port Number Assignment for IUA
  is 9900.

It's an accident of (former) IANA allocation that IUA has a UDP port number, which it will
never use, and confusing for it to mention it.  I think the mention should be excised here.
Should the port also be de-assigned?

[Ballot comment]
The bit quoted below is infelicitous (as an IETF adept and native to English , I can parse this
MAY NOT, but it does have its meaning of not permitted.  I suggest an RFC Editor revising
this into "the SCTP functions above MAY be determined not to
be required, and TCP MAY be used...etc.

  In these
  cases, the SCTP functions above MAY NOT be a requirement and TCP can
  be used as the underlying common transport protocol.

[Ballot comment]
The optional INFO String parameter can carry any meaningful 8-bit
  ASCII character string along with the message.  Length of the INFO
  String parameter is from 0 to 255 characters.  No procedures are
  presently identified for its use but the INFO String MAY be used for
  debugging purposes.

NIT--> The ASCII pointer is present in the references, but not listed
here. 

Also, I'm wondering if they considered using UTF-8 in INFO and rejected,
or it just wasn't on the table (not a blocking comment--just curious)

[Ballot discuss]
The Heading and the Abstract need to reflect the fact that this document
  obsoletes RFC 3057.

  Please add a subsection to the Introduction that summarizes the changes
  to RFC 3057 that are made in this document.

  RFC 3057 contains a pretty long security considerations section.  Why
  is that information being dropped?