Subject: Re: Last Call: 'Internet Code Point Assignments' to Proposed Standard

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Aug 2005 23:03:51 +0300 (EEST)

On Wed, 10 Aug 2005, The IESG wrote:
> The IESG has received a request from an individual submitter to consider the
> following document:
>
> - 'Internet Code Point Assignments '
>   <draft-gray-rfc1888bis-01.txt> as a Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2005-09-07.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-gray-rfc1888bis-01.txt

The title is inappropriately generic.

Given RFC 4048, is there sufficient evidence that this would be useful 
to the operational (or any other) community ?

(Being more explicit on this draft's relationship to RFC 1888 and 4048 
would not hurt in general.)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 12 Aug 2005 14:43:08 +0200

Commenting as an individual (and as the culprit for
RFC 1888 and RFC 4048):

> The title is inappropriately generic.

I agree. Suggest

   Internet Code Point Assignments for NSAP Addresses

> Given RFC 4048, is there sufficient evidence that this would be useful to the operational (or any other) community ?

My understanding is that the ATM world needs this.

> (Being more explicit on this draft's relationship to RFC 1888 and 4048 would not hurt in general.) 

Slightly agree, see below.

1. Introduction

    ...
    The means RFC 1888 defined for encoding NSAP addresses in IPv6
    address format, was heavily annotated with warnings and limitations
    that apply should this encoding be used. Possibly as a result, these
    encodings are not used and appear never to have been used in any IPv6
    deployment. In addition, section 6 contains minor errors. As a result
    of these various considerations, an Internet Draft [BC] has been
    submitted recommending that RFC 1888 be made historical.

The last sentence, and the reference, is out of date. Suggest:

                                                              As a result
    of these various considerations, RFC 1888 has been obsoleted and
    declared Historic by RFC 4048 [ref RFC 4048].

2. IANA Considerations

    ...
    Remaining decimal values '2' through '9999' SHOULD be assigned on
    an IETF consensus basis, with IANA consent.

I don't understand "with IANA consent." Also SHOULD seems ambiguous.
Suggest:

    Remaining decimal values '2' through '9999' MUST be assigned on
    an IETF Consensus basis [ref RFC 2434].

but I wonder whether Expert Review wouldn't be sufficient? Do we
really need to trouble the whole IETF for this?

4. Security Considerations

    Security issues are not specifically addressed in this document, as
    the NSAP encoding of IPv4 and IPv6 addresses is compatible with the
    corresponding security mechanisms of RFC 1825 [1825].

I'd prefer to be told that this document doesn't directly affect
the security of the Internet, if that is the case. Also, RFC 1825
is obsolete - the current document is RFC 2401.

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Aug 2005 15:53:58 +0300 (EEST)

On Fri, 12 Aug 2005, Brian E Carpenter wrote:
>> Given RFC 4048, is there sufficient evidence that this would be useful to 
>> the operational (or any other) community ?
>

Even the ATM forum has died, having been abandoned by the operators 
almost 10 years ago.  I doubt anyone is developing the technology 
anymore.  V4 and v6 work just fine with ATM SVCs and PVCs as it is. 
It might be useful to describe (in the draft if this goes forward) why 
exactly these code point assingments are needed.

(Your other editorial suggestions seem OK to me..)

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Aug 2005 16:29:19 +0100

> really need to trouble the whole IETF for this?

IMHO, Expert Review would be sufficient, but does IETF have experts to 
review NSAPA allocations?

Alexey