Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-05.txt

From: Lars Eggert <[email-masked]>
Date: Tue, 1 Apr 2008 17:20:29 -0700

Hi,

I checked with an APP AD about whether this paragraph

      Error Description

         A string of characters in US-ASCII padded with nulls (0x00)
         to a multiple of 4 bytes. If the Err Desc Len is zero then
         no bytes are supplied.

is OK with regards to internationalization, and they recommended to  
add a sentence that field might not be shown to all users (due to the  
use of US-ASCII) and should not contain crucial information. In other  
words, the crucial part is the User Error Value, and not this string.

Lars

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 5 Apr 2008 13:17:25 +0100

Hi Lars,

Yes, OK.

A
----- Original Message ----- 
From: "Lars Eggert" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: "tsvwg" <[email-masked]>
Sent: Wednesday, April 02, 2008 1:20 AM
Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-05.txt

> is OK with regards to internationalization, and they recommended to  add a
> sentence that field might not be shown to all users (due to the  use of
> US-ASCII) and should not contain crucial information. In other  words, the
> crucial part is the User Error Value, and not this string.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 9 Apr 2008 12:25:06 +0200

And updated again:-) comments on -06

Two areas in which this I-D might be more helpful.

Enterprise number; RFC2578 is sort of the reference for this but unhelpful when
it comes to doing anything about it.  For example, in the ietf-syslog-protocol
I-D, Reiner Gerhards included

"7.2.2.  enterpriseId

   The "enterpriseId" parameter MUST be a 'SMI Network Management
   Private Enterprise Code', maintained by IANA, whose prefix is
   iso.org.dod.internet.private.enterprise (1.3.6.1.4.1).  The number
   that follows is unique and may be registered by an on-line form at
   <http://www.iana.org/cgi-bin/mod_ent.pl>.  An enterprise is only
   authorized to assign values within the
   iso.org.dod.internet.private.enterprise.<enterprise ID> subtree
   assigned by IANA to that enterprise.  The enterpriseId MUST contain
   only a value from the
   iso.org.dod.internet.private.enterprise.<enterprise ID> subtree.  In
   general, only the IANA-assigned enterpriseID is needed (a single
   number).  An enterprise might decide to use sub-identifiers below its
   enterpriseID.  If sub-identifiers are used, they MUST be separated by
   periods and be represented as decimal numbers.  An example for that
   would be "0.1.2".  Please note that the id "0.1.2" is just an example
   and MUST NOT be used.  The complete up-to-date list of Enterprise
   Numbers is maintained by IANA at
   <http://www.iana.org/assignments/enterprise-numbers>.

   By specifying an enterpriseId, the vendor allows more specific
   processing of the message."

which, with a few changes from enterpriseId to Enterprise Number and some
elision, could help implementers more.

Likewise 'US-ASCII' is a bit vague; 7 bit, printable ???  Again the syslog I-D
is more specific and includes an ANSI reference, to whit

[ANSI.X3-4.1968] American National Standards Institute, "USA Code for
Information Interchange", ANSI X3.4, 1968.

Tom Petch

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: "tsvwg" <[email-masked]>
Sent: Tuesday, April 01, 2008 11:46 AM
Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-05.txt

> Updated after discussion with Jukka.
> Adrian
>
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> > Title           : User-Defined Errors for RSVP
> > Author(s)       : G. Swallow, A. Farrel
> > Filename        : draft-ietf-tsvwg-rsvp-user-error-spec-05.txt
> > Pages           : 8
> > Date            : 2008-04-01
> >
> > The Resource ReserVation Protocol (RSVP) defines an ERROR_SPEC object
> > for communicating errors.  That object has a defined format that
> > permits the definition of 256 error codes.  As RSVP has been
> > developed and extended, the convention has been to be conservative in
> > defining new error codes.  Further, no provision for user-defined
> > errors exists in RSVP.
> >
> > This document defines a USER_ERROR_SPEC to be used in addition to the
> > ERROR_SPEC to carry additional user information related to errors.
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-rsvp-user-error-spec-05.txt

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Apr 2008 10:26:34 +0100

Hi,

I think the IETF last call on this I-D just closed and perhaps we should 
take Tom's comment as a response to that last call.

Tom says...

> elision, could help implementers more.

I'm certainly in favour of making the I-D more helpful.

To be clear, the registry managed by IANA is the "Enterprise Numbers" 
registry created by RFC2578. It is only that number we require in this I-D. 
We don't require any of the object ID construct.

In view of this, most of the text Tom has quoted is not relevant. It 
explains how to construct the enterpriseId object ID.

I am also pretty cautious about using URLs as definitive references within 
RFCs. As it says at http://www.ietf.org/ID-Checklist.html ...
"A bare HTTP URL is not generally considered a stable reference."

However, we can reference the IANA registry by name to make it easier for 
people. That would mean...
OLD
     Enterprise Number

        A unique identifier of an organization encoded as a 32-bit
        integer.  Enterprise Numbers are assigned by IANA and managed
        through an IANA registry [RFC2578].
NEW
     Enterprise Number

        A unique identifier of an organization encoded as a 32-bit
        integer.  Enterprise Numbers are assigned by IANA and managed
        on a first come first served basis through the IANA registry named
        "Enterprise Numbers" [RFC2578].

> Information Interchange", ANSI X3.4, 1968.

Tom is right. We should not say "US-ASCII" without a reference. We should 
also be clearer that the content of the field is:
- implementation-specific
- typically printable

So...
OLD
     Error Description

        Note that the content of this field might not be shown to all
        users in all implementations (because it is limited to
        US-ASCII). Therefore, it SHOULD be limited to supplementary
        information and SHOULD NOT contain information critical to
        operating the network. Criticial information is present in the
        User Error Value field.
NEW
     Error Description

        A string of characters in US-ASCII [ASCII] padded with
        nulls (0x00) to a multiple of 4 bytes. If the Err Desc Len
        is zero then no bytes are supplied.

        Note that the content of this field is implementation-
        specific. It is typically printable, but might not be
        shown to all users in all implementations (because it is
        limited to US-ASCII). Therefore, the content of the field
        SHOULD be limited to supplementary information and SHOULD
        NOT contain information critical to operating the network.
        Criticial information is present in the User Error Value
        field.

At this stage, I believe I need the approval of an AD or document shepherd 
to make these changes.

Cheers,
Adrian

---

From: "tom.petch" <[email-masked]>
Date: Thu, 24 Apr 2008 09:41:49 +0200

----- Original Message -----
From: "Adrian Farrel" <[email-masked]>
To: "tom.petch" <[email-masked]>; "tsvwg" <[email-masked]>
Cc: "Magnus Westerlund" <[email-masked]>
Sent: Tuesday, April 22, 2008 11:26 AM
Subject: Re: [Tsvwg] I-D Action:draft-ietf-tsvwg-rsvp-user-error-spec-05.txt

> take Tom's comment as a response to that last call.
You are too kind:-)  (It was meant to be a response to Magnus' calls for another
reviewer but crossed in the post with the announcement of the Last Call for
which, my apologies)

The new text on ASCII is fine for me.

For the Enterprise numbers, I would still like to see that URL.  In syslog, we
did find an absence of information about Enterprise Numbers, hence the text that
was included (and yes, much of it can be elided).  That I-D is currently in the
RFC Editor queue and last I saw of it, the URL was still there.  My concern is
that the cited reference, RFC2578, really is unhelpful, preaching to the
converted, so I would like to be more helpful.  I also find the search facility
on the IANA web site somewhat unhelpful.

The IANA website talks about PEN (Private Enterprise Number) so I think that at
least we should use that expression.

Tom Petch

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Apr 2008 15:46:32 +0200

Hi,

If one goes to the IANA site and search for Enterprise Numbers one do 
find the right registry. However, the registry template at:
http://pen.iana.org/pen/PenApplication.page

Do call it Private Enterprise numbers. There is also the formal 
namespace indication.

As you may note, the URL has changed for the application form compared 
to the syslog text so that is one point in the possible problems with 
including a URL. So lets skip the URL. But a clearer indication of what 
is actually reference seem to be worth putting in with the different 
aliases.

Please also go ahead and update the Error Text.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------