Subject: [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for May 8, 2008 Telechat

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 May 2008 10:56:07 +0200

Please find below the list of documents for approval by the IESG as they
show up in the preliminary agenda of the 5/8 telechat. Please let me
know if there are any comments or concerns until Tuesday 5/6 the latest.
(this is one day earlier than usual, the reason being that I will be out
of office for the second part of the next week)

Thanks and Regards,

Dan

2.1 WG Submissions
2.1.1 New Item
  o draft-ietf-iptel-tel-reg-05.txt
    The Internet Assigned Number Authority (IANA) tel Uniform Resource 
    Identifier (URI) Parameter Registry (Proposed Standard) - 1 of 11 
    Note: Jonathan Rosenberg is Proto Shepherd 
    Token: Jon Peterson
  o draft-ietf-simple-imdn-07.txt
    Instant Message Disposition Notification (Proposed Standard) - 2 of
11
 
    Token: Jon Peterson
  o draft-ietf-pim-bsr-mib-05.txt
    PIM Bootstrap Router MIB (Proposed Standard) - 3 of 11 
    Token: David Ward
  o draft-ietf-l1vpn-basic-mode-04.txt
    Layer 1 VPN Basic Mode (Proposed Standard) - 4 of 11 
    Token: David Ward
  o draft-ietf-mpls-upstream-label-05.txt
    MPLS Upstream Label Assignment and Context-Specific Label Space
(Proposed 
    Standard) - 5 of 11 
    Token: Ross Callon
  o draft-ietf-mpls-multicast-encaps-09.txt
    MPLS Multicast Encapsulations (Proposed Standard) - 6 of 11 
    Token: Ross Callon
  o draft-ietf-l1vpn-ospf-auto-discovery-05.txt
    OSPF Based Layer 1 VPN Auto-Discovery (Proposed Standard) - 7 of 11 
    Token: David Ward
  o draft-ietf-l1vpn-bgp-auto-discovery-04.txt
    BGP-based Auto-Discovery for Layer-1 VPNs (Proposed Standard) - 8 of
11 
    Token: David Ward
  o draft-ietf-mpls-ldp-interarea-03.txt
    LDP extension for Inter-Area LSP (Proposed Standard) - 9 of 11 
    Token: Ross Callon
  o draft-ietf-lemonade-convert-18.txt
    IMAP CONVERT extension (Proposed Standard) - 10 of 11 
    Note: Eric Burger is the document shepherd 
    Token: Chris Newman
  o draft-ietf-tsvwg-rsvp-user-error-spec-07.txt
    User-Defined Errors for RSVP (Proposed Standard) - 11 of 11 
    Token: Magnus Westerlund

2.1.2 Returning Item
  o draft-ietf-ospf-ospfv3-update-21.txt
    OSPF for IPv6 (Proposed Standard) - 1 of 1 
    Token: David Ward

2.2 Individual Submissions
2.2.1 New Item
  o draft-klensin-rfc2821bis-10.txt
    Simple Mail Transfer Protocol (Draft Standard) - 1 of 1 
    Token: Lisa Dusseault

2.2.2 Returning Item
NONE

3. Document Actions

3.1 WG Submissions
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.1.1 New Item
  o draft-ietf-ipfix-testing-05.txt
    Guidelines for IP Flow Information eXport (IPFIX) Testing
(Informational) - 
    1 of 2 
    Note: Nevil Brownlee is the PROTO shepherd 
    Token: Dan Romascanu
  o draft-ietf-v6ops-addcon-07.txt
    IPv6 Unicast Address Assignment Considerations (Informational) - 2
of
2 
    Token: Ron Bonica

3.1.2 Returning Item
NONE

3.2 Individual Submissions Via AD
	Reviews should focus on these questions: "Is this document a
reasonable
	contribution to the area of Internet engineering which it
covers? If
	not, what changes would make it so?"

3.2.1 New Item
  o draft-vanelburg-sipping-served-user-05.txt
    The Session Initiation Protocol (SIP) P-Served-User Private-Header 
    (P-Header) (Informational) - 1 of 2 
    Token: Jon Peterson
  o draft-iijima-netconf-soap-implementation-07.txt
    Experience of implementing NETCONF over SOAP (Informational) - 2 of
2

    Token: Dan Romascanu

3.2.2 Returning Item
  o draft-wu-sava-testbed-experience-04.txt
    SAVA Testbed and Experiences to Date (Experimental) - 1 of 1 
    Token: Jari Arkko

3.3 Independent Submissions Via RFC Editor
	The IESG will use RFC 3932 responses: 1) The IESG has not
	found any conflict between this document and IETF work; 2) The
	IESG thinks that this work is related to IETF work done in WG
	<X>, but this does not prevent publishing; 3) The IESG thinks
	that publication is harmful to work in WG <X> and recommends
	not publishing at this time; 4) The IESG thinks that this
	document violates the IETF procedures for <X> and should
	therefore not be published without IETF review and IESG
	approval; 5) The IESG thinks that this document extends an
	IETF protocol in a way that requires IETF review and should
	therefore not be published without IETF review and IESG
approval.

	The document shepherd must propose one of these responses in
	the Data Tracker note and supply complete text in the IESG
	Note portion of the write-up. The Area Director ballot positions
	indicate consensus with the response proposed by the
	document shepherd.

	Other matters may be recorded in comments, and the comments will
	be passed on to the RFC Editor as community review of the
document.

3.3.1 New Item
  o Three-document ballot:  - 1 of 1
     - draft-irtf-dtnrg-ltp-09.txt
       Licklider Transmission Protocol - Specification (Experimental) 
       Note: Recommend RFC 3932 response #1: The IESG has not found any.

       conflict between this document and IETF work. 
     - draft-irtf-dtnrg-ltp-extensions-07.txt
       Licklider Transmission Protocol - Security Extensions
(Experimental) 
       Note: Recommend RFC 3932 response #1: The IESG has not found any.

       conflict between this document and IETF work. 
     - draft-irtf-dtnrg-ltp-motivation-06.txt
       Licklider Transmission Protocol - Motivation (Informational) 
       Note: Recommend RFC 3932 response #1: The IESG has not found any.

       conflict between this document and IETF work. 
    Token: Russ Housley

3.3.2 Returning Item
NONE

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review
  o Source Address Validation Improvements (savi) - 1 of 2
    Token: Jari Arkko
  o Data for Reachability of Inter/tra-NetworK SIP (drinks) - 2 of 2
    Token: Jon Peterson
4.1.2 Proposed for Approval
    NONE
4.2 WG Rechartering
4.2.1 Under evaluation for IETF Review
  o RADIUS EXTensions (radext) - 1 of 1
    Token: Dan Romascanu
4.2.2 Proposed for Approval
    NONE

_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 2 May 2008 11:56:09 +0200

W.r.t.
 
>     PIM Bootstrap Router MIB (Proposed Standard) - 3 of 11 

I get: 

  C:\bw\smicng\work>smicng bsr.inc
  E: f(bsr.mi2), (402,21) Index item "pimBsrCandidateBSRZoneIndex" 
     must be defined with syntax that includes a range
  E: f(bsr.mi2), (541,21) Index item "pimBsrElectedBSRZoneIndex"
     must be defined with syntax that includes a range

  *** 2 errors and 0 warnings in parsing

The InetZoneIndex ::= TEXTUAL-CONVENTION from RFC4001 is the SYNTAX
for those 2 objects. And that TC does not include a range.

The DESCRIPTION clause of the TC explains that value zero is a 
special value. It iss unclear to me if that special value of zero 
is a valid/acceptable value for the INDEX objects. If not, then 
it might be good to use

       SYNTAX     InetZoneIndex (1..4294967295)

If it is a valid value, then I can live with the Error msg.
The error msg could still be suppressed by doing:

       SYNTAX     InetZoneIndex (0..4294967295)

And if you do so, then you explicitly indicate that zero is indeed
a valid value for the INDEX object.

A NIT on the securitry Considerations:

   Even if the network itself is secure (for example by using IPSec),

s/IPSec/IPsec/

I would not be urprised if Russ makes that comment too.

Bert

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 May 2008 13:00:22 +0200

Bert,

Using libsmi the MIB module compiles cleanly. 

Is this again a case where smicng is more strict?  This may be rather a
warning case at worst and not an error case. 

As per RFC4181: 

   -   Unsigned32 with a range that excludes zero is RECOMMENDED for
       most index objects.  It is acceptable to include zero in the
       range when it is semantically significant or when it is used as
       the index value for a unique row with special properties.  Such
       usage SHOULD be clearly documented in the DESCRIPTION clause.

Assuming zero is a valid error and that a better explanation is provided
about the 'special case' in the DESCRIPTION I do not see a problem. 

Dan

> -----Original Message-----
> From: Bert Wijnen - IETF [mailto:[email-masked]] 
> Sent: Friday, May 02, 2008 12:56 PM
> To: Romascanu, Dan (Dan); David Ward; 
> [email-masked]; [email-masked]
> Cc: MIB Doctors; [email-masked]
> Subject: draft-ietf-pim-bsr-mib-05.txt [was: RE: 
> [MIB-DOCTORS] FW: PRELIMINARY Agenda and Package for May 
> 8,2008 Telechat]
> 
> W.r.t.
>  
> The InetZoneIndex ::= TEXTUAL-CONVENTION from RFC4001 is the 
> SYNTAX for those 2 objects. And that TC does not include a range.
> 
> The DESCRIPTION clause of the TC explains that value zero is 
> a special value. It iss unclear to me if that special value 
> of zero is a valid/acceptable value for the INDEX objects. If 
> not, then it might be good to use
> 
> And if you do so, then you explicitly indicate that zero is 
> indeed a valid value for the INDEX object.
>

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Fri, 2 May 2008 13:14:55 +0200

The errors are shwon indeed when I use STRICT checking with SMICng.
As I stated, I can live with it.
But (as per the rfc4181 quoted text below), it would be good to
make it clear in the DESCRIPTION clause that zero is indeed
a valid value for the index. That was/is not clear to me from
the text in the DESCRIPTION clauses. For example

   pimBsrElectedBSRZoneIndex OBJECT-TYPE
       SYNTAX     InetZoneIndex
       MAX-ACCESS not-accessible
       STATUS     current
       DESCRIPTION
               "The zone index uniquely identifies the zone on a
               device to which this Elected BSR is attached. There
               is one entry for each zone in ipMcastZoneTable.
               Scope-level information for this zone can be extracted
               from ipMcastZoneTable in IP MCAST MIB."

It speaks about the "index uniquely identifies".
It referes to the IP MCAST MIB module.
In there I see a lot of places where it states:
            listener address applies only within the given zone.  Zone
            index zero is not valid in this table."

And also, when used as an index there, it DOES exclude zero:

   ipMcastZoneIndex OBJECT-TYPE 
       SYNTAX     InetZoneIndex (1..4294967295)

So... If zero is value in the BSR MIB, then fine, but I would like to see 
that made explicit, so that everyone is sure that it did not happen by
accident.

The DESCRIPTION clause of InetZoneIndex states:

         The zone index may contain the special value 0, which refers
         to the default zone.  The default zone may be used in cases
         where the valid zone index is not known (e.g., when a
         management application has to write a link-local IPv6
         address without knowing the interface index value).  The
         default zone SHOULD NOT be used as an easy way out in
         cases where the zone index for a non-global IPv6 address
         is known."

So a zero valeu can mean "default zone" meaning that it is not known.
So is it a valid value?

THe 

Bert Wijnen 

> -----Oorspronkelijk bericht-----
> Van: Romascanu, Dan (Dan) [mailto:[email-masked]]
> Verzonden: vrijdag 2 mei 2008 13:00
> Aan: Bert Wijnen - IETF; David Ward; [email-masked];
> [email-masked]
> CC: MIB Doctors; [email-masked]
> Onderwerp: RE: draft-ietf-pim-bsr-mib-05.txt [was: RE: [MIB-DOCTORS] FW:
> PRELIMINARY Agenda and Package for May 8,2008 Telechat]
> 
> 
> Bert,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 May 2008 18:02:48 +0200

If zero is an invalid value then you must define a range, which means
that the MIB module needs a new version and the document needs a new
version. 

I will enter a DISCUSS. 

Dan

> From: Bharat Joshi [mailto:[email-masked]] 
> Sent: Friday, May 02, 2008 7:01 PM
> To: 'Bert Wijnen - IETF'; Romascanu, Dan (Dan); 'David Ward'; 
> [email-masked]'
> Cc: 'MIB Doctors'; [email-masked]'
> Subject: RE: draft-ietf-pim-bsr-mib-05.txt [was: RE: 
> Hi Bert,
>     In this case, I would like to say that I can add "Zone 
> index zero is not valid in this table" similar to what is 
> mentioned in IP MCAST MIB. I can also add the range 
> '(1..4294967295)' for these two objects.
> 
>     I shall wait for some more time if I get any more 
> comments on this draft and will publish another version after 
> fixing this.
> 
> Thanks,
> Bharat
> 
> > Sent: Friday, May 02, 2008 4:45 PM
> > To: Romascanu, Dan (Dan); David Ward; Bharat Joshi; [email-masked]
> > Subject: RE: draft-ietf-pim-bsr-mib-05.txt [was: RE: 
> [MIB-DOCTORS] FW:
> > But (as per the rfc4181 quoted text below), it would be 
> good to make 
> > it clear in the DESCRIPTION clause that zero is indeed a 
> valid value 
> > for the index. That was/is not clear to me from the text in the 
> > DESCRIPTION clauses. For example
> >
> > So... If zero is value in the BSR MIB, then fine, but I 
> would like to 
> > see that made explicit, so that everyone is sure that it did not 
> > happen by accident.
> >
> > > Is this again a case where smicng is more strict?  This may be 
> > > rather a warning case at worst and not an error case.
> > >
> > > As per RFC4181:
> > >
> > > Assuming zero is a valid error and that a better explanation is 
> > > provided about the 'special case' in the DESCRIPTION I do 
> not see a problem.
> > >
> > > Dan
> > >
> > >
> > > > To: Romascanu, Dan (Dan); David Ward; [email-masked]; 
> > > > [email-masked]
> > > > is a valid/acceptable value for the INDEX objects. If 
> not, then it 
> > > > might be good to use
> > > >
> **************** CAUTION - Disclaimer ***************** This 
> e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION 
> intended solely for the use of the addressee(s). If you are 
> not the intended recipient, please notify the sender by 
> e-mail and delete the original message. Further, you are not 
> to copy, disclose, or distribute this e-mail or its contents 
> to any other person and any such actions are unlawful. This 
> e-mail may contain viruses. Infosys has taken every 
> reasonable precaution to minimize this risk, but is not 
> liable for any damage you may sustain as a result of any 
> virus in this e-mail. You should carry out your own virus 
> checks before opening the e-mail or attachment. Infosys 
> reserves the right to monitor and review the content of all 
> messages sent to or from this e-mail address. Messages sent 
> to or from this e-mail address may be stored on the Infosys 
> e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>

---

From: Bharat Joshi <[email-masked]>
Date: Fri, 2 May 2008 21:30:33 +0530

Hi Bert,

    In this case, I would like to say that I can add "Zone index zero is not valid in this table" similar to what is mentioned in IP MCAST MIB. I can also add the range '(1..4294967295)' for these two objects.

    I shall wait for some more time if I get any more comments on this draft and will publish another version after fixing this.

Thanks,
Bharat

> Subject: RE: draft-ietf-pim-bsr-mib-05.txt [was: RE: [MIB-DOCTORS] FW:

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: David Ward <[email-masked]>
Date: Fri, 2 May 2008 11:05:21 -0500

Bharat -

Pls post a new draft by Tues of next week (May 6, 2008) so that we  
can refer to the latest draft that contains fixes for all comments to  
date in the IESG telechat.

Thanks

-DWard

On May 2, 2008, at 11:00 AM, Bharat Joshi wrote:

>
> Hi Bert,
>
>     In this case, I would like to say that I can add "Zone index  
> zero is not valid in this table" similar to what is mentioned in IP  
> MCAST MIB. I can also add the range '(1..4294967295)' for these two  
> objects.
>
>     I shall wait for some more time if I get any more comments on  
> this draft and will publish another version after fixing this.
>
> Thanks,
> Bharat
>
>>> rather a
>>> provided
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION  
> intended solely for the use of the addressee(s). If you are not the  
> intended recipient, please notify the sender by e-mail and delete  
> the original message. Further, you are not to copy, disclose, or  
> distribute this e-mail or its contents to any other person and any  
> such actions are unlawful. This e-mail may contain viruses. Infosys  
> has taken every reasonable precaution to minimize this risk, but is  
> not liable for any damage you may sustain as a result of any virus  
> in this e-mail. You should carry out your own virus checks before  
> opening the e-mail or attachment. Infosys reserves the right to  
> monitor and review the content of all messages sent to or from this  
> e-mail address. Messages sent to or from this e-mail address may be  
> stored on the Infosys e-mail system.

---

From: "Bert Wijnen - IETF" <[email-masked]>
Date: Sat, 3 May 2008 10:58:26 +0200

That wfm (works for me)

Bert Wijnen

> Van: Bharat Joshi [mailto:[email-masked]]
> Verzonden: vrijdag 2 mei 2008 18:01
> Aan: 'Bert Wijnen - IETF'; 'Romascanu, Dan (Dan)'; 'David Ward';
> [email-masked]'
> CC: 'MIB Doctors'; [email-masked]'
> zero is not valid in this table" similar to what is mentioned in
> IP MCAST MIB. I can also add the range '(1..4294967295)' for
> these two objects.
>
> intended solely for the use of the addressee(s). If you are not
> the intended recipient, please notify the sender by e-mail and
> delete the original message. Further, you are not to copy,
> disclose, or distribute this e-mail or its contents to any other
> person and any such actions are unlawful. This e-mail may contain
> viruses. Infosys has taken every reasonable precaution to
> minimize this risk, but is not liable for any damage you may
> sustain as a result of any virus in this e-mail. You should carry
> out your own virus checks before opening the e-mail or
> attachment. Infosys reserves the right to monitor and review the
> content of all messages sent to or from this e-mail address.
> Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.