Skip to main content

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

Discuss


Yes

(Jon Peterson)

No Objection

(Alex Zinin)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Russ Housley)
(Scott Hollenbeck)
(Steven Bellovin)

Note: This ballot was opened for revision 02 and is now closed.

Thomas Narten Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2004-10-14) Unknown
IANA considerations needs work; placeholder for more detailed comments to follow...
Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Alex Zinin Former IESG member
No Objection
No Objection () Unknown

                            
Allison Mankin Former IESG member
No Objection
No Objection (2004-10-13) Unknown
 

   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.
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Harald Alvestrand Former IESG member
No Objection
No Objection (2004-10-14) Unknown
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.]
Margaret Cullen Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Scott Hollenbeck Former IESG member
No Objection
No Objection () Unknown

                            
Steven Bellovin Former IESG member
No Objection
No Objection () Unknown

                            
Ted Hardie Former IESG member
No Objection
No Objection (2004-10-12) Unknown
   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)