[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Procedures for Modifying RSVP to a BCP
- To: ccamp <ccamp@ops.ietf.org>, mpls <mpls@uu.net>
- Subject: Re: Last Call: Procedures for Modifying RSVP to a BCP
- From: Stephen J Trowbridge <sjtrowbridge@lucent.com>
- Date: Thu, 04 Dec 2003 14:45:46 -0700
- Organization: Lucent Technologies
- References: <3FCFA9B6.5010404@lucent.com>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)
> All,
> I am not sure I fully understand what is being proposed by this
> document in terms of values to be assigned to RSVP entities for
> standards organizations outside of IETF. In section 1, there is
> the paragraph:
>
> " A standards body other than the IETF that wishes to obtain an
> assignment for an RSVP entity must decide from which type of
> name/number space they desire their assignment be made from, and then
> submit the appropriate documentation."
>
> I would suppose that "appropriate documentation" is to leave the
> door open that we eventually have a real liaison process by which
> an incoming liaison statement has some sort of status within IETF,
> and I have no difficulty leaving the language here loose enough to
> accomodate this possibility.
>
> However I have more difficulty later on understanding what ranges
> would apply for RSVP entities defined by standards bodies outside
> of IETF. These would not seem to meet the "vendor private use" or
> "expert review" categories, so by process of elimination, they
> would seem to be "standards action" assignments.
>
> However, it is not generally a good idea to have more than one
> normative source for a particular standards element. If a specification
> appears in more than one place, it should be clear which is the
> controlling document (which one should be paid attention to if
> the specifications differ) and where someone should go in order
> to propose changes.
>
> What we have done in the past with these sorts of things is to have
> an informational RFC in IETF that references the external standard.
> But in reading this document, it seems that "standards action"
> codepoints could only be assigned to values for standards track
> RFCs within IETF.
>
> I think the document needs to be clearer about assignment of
> codepoints for RSVP entities defined by other standards bodies.
> If approving an informational RFC as we have done in the past is
> considered to be some kind of standards action, and can therefore
> be used for these kinds of assignments, I think a few more words are
> needed to clarify that we can still do these things as in the past.
>
> But if the intent is that any such assignments in the future actually
> be in standards track RFCs, then we have the problem of multiple
> normative sources, and I think more discussion is needed to make
> sure that this is really what we want.
>
> If the procedures to be followed by other standards organizations are
> to change, it will also be necessary to comminucate that change
> to those other organizations so that they will know the appropriate
> procedure to follow for their applications of RSVP.
> Regards,
> Steve
>