advancing tuba internet-drafts

[Dave Piscitello <[e-mail]>]

IPng folks,

I received the following comments from 
Luc Rooijakkers <[e-mail]> on the three i-d's we are about
to forward. Here's my recommendation:

>All three drafts use backspace for overstriking; my equipment could
>not handle this and it may not in general be a good idea. Especially
>the checksum calculation appendix gets messy; I see things like
>	o + c0 <- c0 + Bi

I'll try to take care of this; our nroff support is tacky at best:-(

>During the NAT bof, the idea of passing a DNS name with the PORT command
>instead of an address came up; in some ways this would be a much better
>solution than passing addresses. There are several ways your LPORT
>command could incorporate this; the most consistent way would
>be to send the ASCII coding of the domain name as the address octets,
>using address family zero. E.g. abc.com:100 would be
>	LPORT 0,7,97,98,99,46,99,111,109,2,0,100
>but this is not very human-friendly. You could also make address family zero
>a special case that encodes domain name and port number printably,
>as in
>	LPORT 0,abc.com,2536
>
>Thus, the syntax would then be
>	LPORT 0,<domain>,<port>
>
>where <port> is a string of decimal digits.
>
>Alternatively, you could include an extra command "NPORT" (for Named
>PORT), with syntax like
>	NPORT <SP> <domain> <SP> <port>

I prefer the "named port" alternative here. Is there general agreement
that we include this before I post, or should I leave this for additional
discussion?

>It would also be nice ;if the 512 response included a list of supported
>address families, like
>	512 Supported address families are (af1,af2,...,afn)
>The general format of this response could be
>	512 <text not including "(" or ")"> "(" <af-list> ")"

I think this is a good idea, but I'm unsure whether you mistyped my
original reply code number of 521 and are suggesting a replacement,
or whether you are suggesting an additional "information response".
Please clarify.

Luc has comments on draft-ietf-tuba-sysids-01:

>The draft leaves it unclear excactly why IEEE addresses do not clash
>with your TTQQ encoding; it this a reserved part of the IEEE address
>space or what? Please add wording clarifying this.

I've added them. When QQ is 00 or 01, then the address is globally 
assigned (initial Q=0), and either individual/group (denoted by second Q)

>Also, in figures 7a and 7b, the value of DFI should be "foo" and "bar",
>respectively, not "1".

I think you've misinterpreted the figures; the "1" indicates the # of
octets of the DFI, no? Perhaps the actual acronym "DFI" should be
replaced by "foo" and "bar". Is this an improvement?

>Section 4, Note 1 says that Figure 4-1 depicts destination and source
>address as having 19 bytes, including PROTO/rsvd. Counting bytes in
>the picture gives me 20, however! Or you should say "excluding
>PROTO/rsvd".

There is a much more embarrassing problem with the figure; it depicts
the dest address correctly (19 octets plus proto) but the source
address *incorrectly* (20 octets plus proto). I will fix this.

>It is unclear to me what encapsulation is used for CLNP-over-X;

Like IP, there isn't a single encapsulation for all underlying technologies.

>Section 4.9 uses the phrase "NSAPA adresses"; doesn't the last A already
>stand for "address"?.

OK

>Section 4.9.2 is unclear when exactly to use protocol value 29;
>should it be used for TP4-over-CLNP only? The text seems to suggest that
>it should *always* be used if the implementation supports OSI as well as
>TUBA.

It's my understanding that unless you follow the guidelines here,
you could have a clash. I've changed this to "must" rather than "should".

>Section 4.13.5 is missing "or" in its 3rd sentence (just before the
>first occurrence of "Partial").

done

>Also, what does "I'll be back..." in this section mean?

:-) Ask Arnold Schwartzenagger... this is from the movie, "the
terminator"; I'll remove the comic relief.

>With regard to section 5: Host requirements states "more then 8 octets
>MAY be sent". I have also somewhere seen the recommendation that

OK

>The last paragraph of section 6 has an extraneous "that" before "the
>Protocol field" and is missing a full stop after "0x0011 for UDP".

OK

>This section also talks about "address length indicators" that I haven't

If you had been able to read the title of sections 4.9.1 and up, you
would have seen these:-)

Also, the lengths of certain NSAPA values when encoded in binary may not be
an integral number of octets, so the sum of the fields is not
strictly speaking an integral number of octets unless you add a
trailing nibble, right Dino?

>I don't see the value of including "Protocol"; isn't it already conveyed

I answered this in our private exchange.



I have posted revised versions of the 3 internet-drafts on
thumper.bellcore.com in the directory: pub/dave under:


draft-ftp-bigports-03.txt
draft-ietf-tuba-clnp-04.txt
draft-tuba-sysids-03.txt

barring any objections, I'll forward these to the IETF secretariat
on Thursday. It is my understanding that the tuba group wishes
to have the "bigports" i-d become an experimental RFC; the "sysids"
i-d to become an informational RFC; and the "clnp for tuba" i-d 
become a proposed standard.

regards,


dave