headers
Wilson | 16 May 2002 11:47

Type definision issue in rfc2578

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi, Can someone help in the following issue..

I have some doubt in the types defined in the RFC2578, and its usage in
RFC3159.

In RFC2578 the type defintion for ExtUTCTime is said not to be imported by
any MIB definition,
but the RFC3159 is using the MIB definition convention to define the frame
work for PIB defintions, and it is importing the ExtUTCTime, as per the
RFC2578 which not to be allowed.
Permalink | Reply | 3 comments |
headers
Juergen Schoenwaelder | 16 May 2002 16:34
Picon
Picon

Re: Type definision issue in rfc2578


>>>>> Wilson  writes:

Wilson> I have some doubt in the types defined in the RFC2578, and its
Wilson> usage in RFC3159.

Wilson> In RFC2578 the type defintion for ExtUTCTime is said not to be
Wilson> imported by any MIB definition, but the RFC3159 is using the
Wilson> MIB definition convention to define the frame work for PIB
Wilson> defintions, and it is importing the ExtUTCTime, as per the
Wilson> RFC2578 which not to be allowed.

The COPS-PR-SPPI module contained in RFC 3159 is an ASN.1 module which
imports ExtUTCTime in order to define SPPI - but COPS-PR-SPPI is
certainly not a MIB module written to conform to the SMIv2 language as
defined in RFC 2578. So I do not really see a problem here.

/js

--

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>
Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 16 May 2002 16:45
Picon
Favicon

RE: Type definision issue in rfc2578

I think:

SPPI (RFC3159) is NOT defining a MIB or a PIB but instead
defining a "new language" or an "update to the SMI language".
So that is a quite different thing than defining another
MIB or PIB Module.

Bert 

> -----Original Message-----
> From: Wilson [mailto:Wilson <at> WSSPL.com]
> Sent: Thursday, May 16, 2002 11:47 AM
> To: 'rap <at> ops.ietf.org'
> Subject: Type definision issue in rfc2578
> 
> 
> [ post by non-subscriber.  with the massive amount of spam, 
> it is easy to
>   miss and therefore delete mis-posts.  so fix subscription 
> addresses! ]
> 
> Hi, Can someone help in the following issue..
> 
> I have some doubt in the types defined in the RFC2578, and 
> its usage in
> RFC3159.
> 
> In RFC2578 the type defintion for ExtUTCTime is said not to 
> be imported by
> any MIB definition,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Keith McCloghrie | 16 May 2002 18:33
Picon
Favicon

Re: Type definision issue in rfc2578

> Hi, Can someone help in the following issue..  
> 
> I have some doubt in the types defined in the RFC2578, and its usage in
> RFC3159.
> 
> In RFC2578 the type defintion for ExtUTCTime is said not to be imported by
> any MIB definition,
>
> but the RFC3159 is using the MIB definition convention to define the frame
> work for PIB defintions, and it is importing the ExtUTCTime, as per the
> RFC2578 which not to be allowed.

Let me explain:

1. ExtUTCTime is defined as part of SMIv2.
2. The SPPI imports ExtUTCTime because the SPPI is an enhanced subset of SMIv2.
3. The module within RFC 3159 which imports ExtUTCTime is the SPPI, which
   begins:

     COPS-PR-SPPI DEFINITIONS ::= BEGIN

     IMPORTS    ObjectName, SimpleSyntax, ExtUTCTime, mgmt
                                                FROM SNMPv2-SMI;

4. The SPPI is the rules for writing PIBs, but the SPPI is *not* itself a PIB.
5. RFC 3159 does not contain a MIB.
6. The PIB module within RFC 3159 begins:

     COPS-PR-SPPI-TC   PIB-DEFINITIONS ::= BEGIN
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 20 May 2002 20:20
Picon
Favicon

AD review of draft-ietf-rap-session-auth-03.txt

Before putting documents on the IESG agenda I review them first.
I have issued IETF Last Call for the document
   draft-ietf-rap-rsvp-authsession-02.txt
in which Last Call this informational is included (I expect).

So you can consider my comments as IETF Last Call comments

Here are my comments and questions:

1. Section 2 can be removed. These keywords (as far as I can tell)
   are not used in this document. This also means that reference
   to RFC2119 can go away

2. You talk about "districts" in section 3 qand figure 1 (and maybe
   other places). Where is this terminology used? Is it the same as
   "domain"... it seems it is, but I am not sure?? Maybe this
   term (District) is common place in the SIP space...
   In any event, you may want to indicate where it comes from.
   In 1st sentence on page23 you seem to refer to it as domain
   indeed.

3. You sometimes talk about "Session Manager" other times about
   Session Manager Server. I think to understand that the 
   "session manager" runs on the session server. But you may want 
   to make that clearer. For example, 2nd bullet in sect 4 talks
   about "Edge Router, Session Manager, and Policy Server" 
   I see 2 of them in the figure 1, but not the "Session Manager"
   instead I see "Session Manager Server", which I think is what 
   you mean. This happens in a few more places in the doc.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Wijnen, Bert (Bert | 20 May 2002 21:09
Picon
Favicon

AD review of: draft-ietf-rap-rsvp-authsession-02.txt

Before putting documents on the IESG agenda I review them first.
I have issued IETF Last Call for the document
    draft-ietf-rap-rsvp-authsession-02.txt
I would normally issue Last Call only after I have done the 
review and received responsess from authors. But it seems
that 3GPP wants this doc to become RFC soon (June 7th).
So therefor we do this in paralell

So you can consider my comments as IETF Last Call comments

Here are my comments and questions:

1. The RFC-Editor does not want references in the abstract section
   see draft-rfc-editor-rfc2223bis-02.txt for details
   You can replace [POL-EXT] with (RFC 2750) as a good alternative.

2. Sect. 2, talks about "DiffEdge". May want to explain that term.
   I see that you reference an RFC, yet a few words on that term
   may be good.

3. The way you specify the Policy element in sect 3.2 is
   different from what I have seen before. For example, RFC3181
   does it as follows:

      P-Type: 16 bits
         PREEMPTION_PRI  = 1

         This value is registered with IANA, see Section 7.

   I would strongly suggest to use the same/similar format.
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 20 May 2002 20:54
Picon
Favicon

Last Call: Session Authorization for RSVP to Proposed Standard


The IESG has received a request from the Resource Allocation Protocol
Working Group to consider Session Authorization for RSVP
<draft-ietf-rap-rsvp-authsession-02.txt> as a Proposed Standard.

The IESG will also consider Framework for session set-up with media
authorization <draft-ietf-rap-session-auth-03.txt> for publication as
an Informational RFC.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
iesg <at> ietf.org or ietf <at> ietf.org mailing lists by June 3, 2002.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rap-rsvp-authsession-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-rap-session-auth-03.txt
Permalink | Reply | 0 comments |

Gmane