Skip to main content

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
RFC 3476

Revision differences

Document history

Date Rev. By Action
2015-10-14
04 (System) Notify list changed from  to (None)
2003-04-11
04 (System) Ballot writeup text was added
2003-04-11
04 (System) Last call text was added
2003-04-11
04 (System) Ballot approval text was added
2003-04-11
04 Natalia Syracuse RFC3476 published in March 2003
2003-04-04
04 Natalia Syracuse State Changes to RFC Published from RFC Ed Queue by Syracus, Natailia
2003-04-02
04 (System) RFC published
2003-01-29
04 Jacqueline Hargest State Changes to RFC Ed Queue from Approved-announcement sent by Hargest, Jacqueline
2003-01-23
04 Jacqueline Hargest State Changes to Approved-announcement sent from Approved-announcement to be sent by Hargest, Jacqueline
2003-01-23
04 Jacqueline Hargest State Changes to Approved-announcement to be sent from IESG Evaluation  :: AD Followup by Hargest, Jacqueline
2003-01-23
04 (System) IESG has approved the document
2003-01-20
04 (System) New version available: draft-bala-uni-ldp-rsvp-extensions-04.txt
2003-01-17
04 Bert Wijnen
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 …
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
04 Scott Bradner
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 …
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-12
04 Scott Bradner
2003-01-09 - note to author

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

If I understand this …
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
04 Scott Bradner 2003-01-09 - on IESG agenda - thomas had questions on use of private space
2003-01-12
04 Scott Bradner oops - document confusion - ignore last few comments
2003-01-12
04 Scott Bradner
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?  …
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
2003-01-12
04 Scott Bradner 2003-01-09 - on IESG agenda -
OKed except may need a RFC Ed note to clearup one issue
2003-01-12
04 Scott Bradner State Changes to IESG Evaluation  :: AD Followup from IESG Evaluation by Bradner, Scott
2003-01-07
04 Scott Bradner 2003-01-07 - revised version - back on IESG agenda
2003-01-07
04 Scott Bradner State Changes to IESG Evaluation from Publication Requested  :: Revised ID Needed by Bradner, Scott
2002-12-20
03 (System) New version available: draft-bala-uni-ldp-rsvp-extensions-03.txt
2002-12-14
04 Scott Bradner 2002-12-12 - response from author - working on revision
2002-12-11
04 Scott Bradner 2002-12-11 - sob note to author
any progress on this document - shoudl I remove it from the publication
requested queue?
2002-10-22
04 Scott Bradner 2002-10-22 - response from author

Thanks for the review. I'll look into the
draft you mention and also see what's needed
in the security section.
2002-10-22
04 Scott Bradner by sob
2002-10-22
04 Scott Bradner State Changes to Publication Requested  -- New ID Needed from Publication Requested  -- External Party by sob
2002-10-22
04 Scott Bradner
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 …
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
04 Scott Bradner by sob
2002-10-22
04 Scott Bradner
2002-10-22 - from george

One issue - this draft also specifies status enquery / response
messages for LDP.  I believe these are the same messages …
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-22
04 Scott Bradner by sob
2002-10-13
04 Scott Bradner
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 …
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?
2002-10-13
04 Scott Bradner by sob
2002-10-13
04 Scott Bradner State Changes to Publication Requested  -- External Party from Publication Requested by sob
2002-10-10
04 Stephen Coya Draft Added by scoya
2002-09-24
02 (System) New version available: draft-bala-uni-ldp-rsvp-extensions-02.txt
2002-08-12
01 (System) New version available: draft-bala-uni-ldp-rsvp-extensions-01.txt
2002-08-06
00 (System) New version available: draft-bala-uni-ldp-rsvp-extensions-00.txt