Subject: [Disman] Propose Resolution to iesg-1 and iesg-5

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 19 Jan 2004 15:03:43 -0500

Hi

The following is the proposed resolution to the final two issues raised as a
result of the IESG reviews. I'd like to get the update to the document out
within the next day or two, so please provide any objections to the
resolutions as soon as possible.

Note that both of these issues were around allocation of probable cause
enumerations. See my email from January 13th for more information.

-----

The following is the proposed resolution to IESG-1 and IESG-5

In the description for IanaItuProbableCause, replace the description 

"ITU probable cause values. Duplicate values defined in X.733
           are appended with X733 to ensure uniqueness. Probable cause
           value 0 is reserved for special purposes.

           The Internet Assigned Number Authority (IANA) is responsible
           for the assignment of all Internet numbers, including
           various SNMP-related numbers, and specifically, new
           IANAItuProbableCause values. Values of
           IANAItuProbableCause less than 1024 are reserved for causes
           that correspond to ITU probable cause. IANAItuProbableCause
           of 0 is reserved for special purposes and therefore cannot
           be assigned. See http://www.iana.org"

With

"          ITU-T probable cause values. Duplicate values defined in X.733
           are appended with X733 to ensure syntactic uniqueness. Probable
cause
           value 0 is reserved for special purposes.

           The Internet Assigned Number Authority (IANA) is responsible
           for the assignment of all Internet numbers, including
           various SNMP-related numbers, and specifically, new
           IANAItuProbableCause values. IANAItuProbableCause
           of 0 is reserved for special purposes and MUST NOT
           be assigned.

           Values of IANAItuProbableCause in the range 1 to 1023 are
reserved 
           for causes that correspond to ITU-T probable cause. IANA will
align 
           causes with enumeration values within this range only as a result

           of requests received from the ITU-T via formal liaison
statements.

           All other requests for new causes will be handled on a
first-come, 
           first served basis and will be assigned enumeration values
starting 
           with 1025. Request should come in the form of well-formed SMI for

           enumeration names that are unique and sufficiently descriptive.

           While some effort should be taken to ensure that new probable
causes
           do not conceptually duplicate existing probable causes it is 
           acknowledges that the existence of conceptual duplicates in the
           starting probable cause list is an acknowledged industry reality.

           See http://www.iana.org

           "

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 Jan 2004 11:09:25 +0100

Inline
>            cause value 0 is reserved for special purposes.
> 

why this extra 2 lines above. It seems irrelevant, but then it possibly
does not hurt either.

>            Values of IANAItuProbableCause in the range 1 to 1023 are reserved 
>            for causes that correspond to ITU-T probable cause. IANA will align 
>            of requests received from the ITU-T via formal liaison statements.
> 
Not sure that formal Liaison statements is a good idea.
ITU-T does send such statements to IETF, but requests should go directly
to IANA. Normal way to request values is to send an email to [email-masked].
I guess what we need to define is a way how IANA can make sure that
the request comes from a valid/authoritative ITU-T SG ?

>            All other requests for new causes will be handled on a first-come, 
>            first served basis and will be assigned enumeration values starting 
I wonder:
- The MODULE-IDENTITY DESCRIPTION clause states that this TC is to represent
  ITU-T Probably Causes. Yet we have only 1024 numbers for them and some
  2 billion for random assignment. Does that sound right?
- Do we assume that iana understands the "well-formed SMI rules"??
  Would be good to point to the RFC and section number that explains it.

>            While some effort should be taken to ensure that new probable causes

How is IANA to evaluate?

>            acknowledges that the existence of conceptual duplicates in the

s/acknowledges/acknowledged/

>            starting probable cause list is an acknowledged industry reality.
s/acknowledged//
we have that in the previous line already

Now... how many requests do we really suspect to arrive?
Would it make sense to make it "expert review, expert to be appointed by OPS ADs
or by IESG" ? ANd can we make Sharon and Dan the experts to start with?

>            See http://www.iana.org
Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 Jan 2004 11:09:25 +0100

Inline

I wonder:

How is IANA to evaluate?

s/acknowledged//

Bert

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 20 Jan 2004 09:23:26 -0500

-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:[email-masked]] 
<clip>

<bert>
why this extra 2 lines above. It seems irrelevant, but then it possibly does
not hurt either.
</bert>

I think I got an extra line wrap that I wasn't expecting.

<clip>
<bert>
Not sure that formal Liaison statements is a good idea.
ITU-T does send such statements to IETF, but requests should go directly to
IANA. Normal way to request values is to send an email to [email-masked]. I
guess what we need to define is a way how IANA can make sure that the
request comes from a valid/authoritative ITU-T SG ?
</bert>

Well, an liaison is more or less an email. Could we then say that the email
would be received from the ITU-T. If the ITU-T chose to send it as a
liaison, then it will have formal ITU-T header information which indicates
its source.

We could simply say the following:

"
IANA will align causes with enumeration values within this range only as a
result of formal requests received from the ITU-T."

<clip>
<bert>
I wonder:
</bert>

Yes, but if ITU-T SG 4 is happy with being allocated this range, isn't that
enough?

<bert>
<bert>

Excellent suggestion.

causes
>            do not conceptually duplicate existing probable causes it 
<bert>
How is IANA to evaluate?
<bert>

It is a difficult things for anyone to evaluate given the nature of probable
cause. We could push the responsibility onto the person applying or have it
quickly reviewed as you suggest below.

<bert>

s/acknowledged//
<bert>

Yes, I only noticed these after I sent the email.

<bert>
Now... how many requests do we really suspect to arrive?
Would it make sense to make it "expert review, expert to be appointed by OPS
ADs or by IESG" ? ANd can we make Sharon and Dan the experts to start with?
</bert>

It's hard to predict how may we would get. Would it be possible to start
with having expert review and if we determined it wasn't really adding value
or a good use of time we drop it later on?

Sharon

---

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 20 Jan 2004 09:23:26 -0500

-----Original Message-----

<bert>

<clip>
<bert>

"

<clip>
<bert>
I wonder:

<bert>

Excellent suggestion.

causes
<bert>
How is IANA to evaluate?
<bert>

<bert>

s/acknowledged//

<bert>

Sharon

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 Jan 2004 16:41:02 +0100

Inline
> <bert>
> why this extra 2 lines above. It seems irrelevant, but then 
> it possibly does not hurt either.
> </bert>
> 
I did not mean the blank lines. But the text 
           The Internet Assigned Number Authority (IANA) is responsible
           for the assignment of all Internet numbers, including
           various SNMP-related numbers, and specifically, new
           IANAItuProbableCause values.
would it not be better to just say:
           The Internet Assigned Number Authority (IANA) is responsible
           for the assignment of new IANAItuProbableCause values.
Cause the piece I removed is irrelevant for this MIB module.

> liaison, then it will have formal ITU-T header information 
> which indicates its source.
> 
But IANA and ITU do not have a "liaison agreement".
And if ITU sends it to the IETF Liaison person (Scott Bradner),
then that is just an additional in-between step that seems to serve
no purpose to me.

> IANA will align causes with enumeration values within this 
> range only as a result of formal requests received from the ITU-T."
> 
I bet that IANA is going to wonder "how can we identify/verify that a
request is a formal request from ITU".

> Yes, but if ITU-T SG 4 is happy with being allocated this 
> range, isn't that enough?
> 
Yes, it is enuf for ITU, but give the numbers, it seems weird to claim
that it is an ITU thing if by far the largest piece fo the namespace is
for FCFS (i.e. anybody can come up with their own what-ever).

> >            do not conceptually duplicate existing probable 
> causes it 
> > is
> <bert>
> How is IANA to evaluate?
> <bert>
> 
> >            acknowledges that the existence of conceptual 
> duplicates in 
> > the
> 
I think so.
I think that maybe the best is to make it so that IANA can assign (based
on the guidelines/rules we write up in the DESCRIPTION clause" with an
added expert review (as appointed by OPS ADs) for IANA to consult.

Bert

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 20 Jan 2004 16:41:02 +0100

Inline

I think so.

Bert