Subject: Comments on draft-ietf-ipngwg-rfc2553bis-06.txt

From: Heikki Vatiainen <[email-masked]>
Date: 04 Sep 2002 15:43:40 +0300

Here are my comments about draft-ietf-ipngwg-rfc2553bis-06.txt

On many pages, null (the C null pointer constant) is sometimes written
as null and sometimes NULL. Also, the ASCII NUL terminated C strings
have different written forms. Currently the text has at least these
variants of null/NULL:

 o NULL pointer
 o NULL
 o null pointer
 o null terminated name
 o null-terminated string
 o null byte
 o null

For clarity, maybe all C null pointers could be written as "NULL".
When ASCII NUL byte terminated C strings are discussed, they could all
be written as "null-terminated string(s)".

On top of page 12, there is one instance of _SS_ALIGNMENT. This, I
suppose, should be _SS_ALIGNSIZE.

Also on page 12, in the example about struct sockaddr_storage on
systems with "sa_len", "#define _SS_PAD2SIZE" does not include sizeof
(uint8_t), the size of "ss_len" member.

On page 18, the printf seems to lack at least \n" and possibly more.

On page 19, the second paragraph from bottom, inet_ntop() is used as
an example of a function using standard IPv6 text forms. Should this
be inet_pton() since it, just like getaddrinfo, takes in character
strings (page 26, first paragraph)?

On page 22, it is said that freeaddrinfo() frees addrinfo lists with
"any additional storage associated with those structures". I take this
additional storage is memory pointed by ai_addr and ai_canonname
(unless ai_canonname points to the same place as nodename parameter)?
Maybe the wording could be made explicit that after freeaddrinfo() is
called, the caller MUST not refer to memory pointed by ai_addr members
of freed addrinfo structures. The same applies to ai_cannoname if
ai_canonname did not point to nodename.

-- 
Heikki Vatiainen                  * [email-masked]
Tampere University of Technology  * Tampere, Finland
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jack McCann <[email-masked]>
Date: Mon, 16 Sep 2002 14:46:58 -0400 (EDT)

Heikki,

Thank you for your comments, my responses inline below.
I'll fix what I can in the final rev of the spec.

- Jack

>From [email-masked] Wed Sep  4 08:53:02 2002
>To: [email-masked]
>Subject: Comments on draft-ietf-ipngwg-rfc2553bis-06.txt
>From: Heikki Vatiainen <[email-masked]>
>Date: 04 Sep 2002 15:43:40 +0300
>

I'll see what I can do about this.

>suppose, should be _SS_ALIGNSIZE.

Will fix.

>(uint8_t), the size of "ss_len" member.

Will fix.

>On page 18, the printf seems to lack at least \n" and possibly more.

Will fix.

>strings (page 26, first paragraph)?

Ah, this is cut/paste from 1003.1-2001, where "inet_ntop()" refers
to the reference page which defines both inet_ntop() and inet_pton().
I think we can reword as you suggest.

>ai_canonname did not point to nodename.

You take it correctly (except the part about ai_cannoname pointing
to nodename, that should not happen, getaddrinfo can't assume that
memory won't be freed or otherwise reused by the caller).

---

From: Jack McCann <[email-masked]>
Date: Wed, 18 Sep 2002 15:42:50 -0400 (EDT)

>I'll see what I can do about this.

Upon further reflection, I'd like to leave the null/NULL usage as is.
Most of it is taken verbatim from the IEEE/OpenGroup/ISO standard,
that would be the place to fix it.  And in all cases I believe the 
meaning is clear (NULL pointer vs.  null-terminated string).

- Jack