Documentation of IANA Assignments for Label Distribution Protocol (LDP), Resource ReSerVation Protocol (RSVP), and Resource ReSerVation Protocol-Traffic Engineering (RSVP-TE) Extensions for Optical UNI Signaling
draft-bala-uni-ldp-rsvp-extensions-04

Bert Wijnen and IANA have worked out a possible assignmnet based on this document. Checking with author if that is OK.
Turns out some clarifications are needed, so author
will send a new revision. This is in the area of
RSVP assignments for the GENERALIZED_UNI which need to be administered by IANA.

2003-01-12 - response from author
"Private" has been interpreted as a being private
to OIF uni implementations. The reason for choosing
private was to minimize the selection of IANA-administered
code points. To be sure, unique code points could
also be used, but I don't see any practical problem
with choosing private code points. Unlike unpublished
private use of code points, the OIF-compliant
UNI implementations will use the published code points.
(In this regard, OIF is the "site" where the private
code points are used).

My suggestion would be to leave it as private, unless
there is a serious issue.

Regards,

Bala Rajagopalan

2003-01-09 - note to author

Bala,
        The IESG discussed this ID today and this question came up

If I understand this correctly (a big if) this seems funny. "Private
use" means something specific, and is not something that vendors/SDOs
agree to use. 2434 sez:

      Private Use - For private or local use only, with the type and
          purpose defined by the local site. No attempt is made to
          prevent multiple sites from using the same value in different
          (and incompatible) ways. There is no need for IANA to review
          such assignments and assignments are not generally useful for
          interoperability.

          Examples: Site-specific options in DHCP [DHCP] have
          significance only within a single site.  "X-foo:" header
          lines in email messages.

So the question is, should private use really be used here or should a
globally unique value be assigned.

2003-01-12 - allison note to chair

Steve,

We in the IESG passed this document on Thursday - would the WG
want to tweak its wording?  I asked Scott (he handled it, I recused,
as an author) to hold for a possible RFC Editor note.

Please advise,

Allison

>
> Date:    Wed, 08 Jan 2003 20:14:30 PST
> To:      AVT WG
> From:    Stephen Casner
> Subject: [AVT] Comment on draft-ietf-avt-smpte292-video-08.txt
>
>
> This comment was triggered by an email from Chuck Harrison, which was
> intern triggerd by one of my questions in the RTP spec/profile series.
> Please take these comments as arriving under the IESG Last Call.
>
> draft-ietf-avt-smpte292-video-08.txt includes the following paragraph
> in its Section 6:
>
>    RFC1889 recommends transmission of RTCP packets every 5 seconds or at a
>    reduced minimum in seconds of 360 divided by the session bandwidth in
>    kilobits/second. At 1.485 Gbps the reduced minimum interval computes to
>    0.2ms or 4028 packets per second.
>
> I have three comments on this:
>
>  - I'm not sure why I did not trip on this before, but RFC 1889 does
>    _not_ recommend transmission of RTCP packets every 5 seconds.  It
>    recommends RTCP transmission based on a scalable timer with 50%
>    randomization and a minimum _average_ interval of 5 seconds.  It
>    is way too tempting already for implementers to put in a fixed
>    5-second timer.  Let's not reinforce that error.
>
>  - RFC 1889 does _not_ include the scaling of the minimum interval.
>    That was added in draft-ietf-avt-rtp-new.  If smpte292-video gets
>    to RFC first, well...
>
>  - Maybe it would appropriate to add another sentence saying that
>    4028 is likely to be excessive for most applications and perhaps
>    suggesting another value.  The rate only needs to be fast enough
>    to track clock skew and to provide enough packets during the
>    23-second octet-count wrap interval to reliably track the wraps.
>
>                                                        -- Steve

2002-10-22 - note to author

I was asked by teh IESG to take a look at draft-bala-uni-ldp-rsvp-extensions
as part of the IESG's role to advize the RFC editor on requests
to publish

I asked some of the IETF mpls folk about teh document and got this
response

> One issue - this draft also specifies status enquery / response
> messages for LDP.  I believe these are the same messages that are in
> draft-ietf-mmpls-lsp-query-04.txt.  Assuming that that document is
> moving forward, bala's doc should reference it.

if this is the case the messages should only be defined in one
place and I expect that would be the MPLS WG document 
(draft-ietf-mmpls-lsp-query) - can you check to see if this is
teh case and if so make a new version that references
draft-ietf-mmpls-lsp-query for the definitions

you should also be quite sure that the document does not
introduce any new security issues (teh Security ADs are
quite strict) - it would be good to mention
        1/ any old secuirty concerns that apply here
        2/ where the reader can look to learn what to do about them

Scott

2002-10-22 - from george

One issue - this draft also specifies status enquery / response
messages for LDP.  I believe these are the same messages that are in
draft-ietf-mmpls-lsp-query-04.txt.  Assuming that that document is
moving forward, bala's doc should reference it.

2002-10-13 - note to mpls & ccamp wg chairs

teh RFC Editor has been asked to publish draft-bala-uni-ldp-rsvp-extensions
as an infoamtional RFC

do any or you have any opinions on teh document?
do any of you think it would be good to ask your WG lists about the ID?