Subject: [MIB-DOCTORS] Preliminary agenda for the 8/14 IESG Telechat

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 8 Aug 2008 18:55:02 +0200

Please find below the preliminary agenda of the 8/14 IESG telechat.
Please send me your questions, concerns and comments until 8/13 COB the
latest. 

Thanks and Regards,

Dan

2. Protocol Actions 
Reviews should focus on these questions: "Is this document a
reasonable basis on which to build the salient part of the Internet
infrastructure? If not, what changes would make it so?" 

2.1 WG Submissions
2.1.1 

- Information Model and XML Data Model for Traceroute Measurements
(Proposed Standard) - draft-ietf-ippm-storetraceroutes-10.txt 
- Transport Mapping for Syslog (Proposed Standard) -
draft-ietf-syslog-transport-tls-13.txt 
- Definitions of Textual Conventions for Pseudowires (PW) Management
(Proposed Standard) - draft-ietf-pwe3-pw-tc-mib-14.txt 
- Guidelines for Application Designers on Using Unicast UDP (BCP) -
draft-ietf-tsvwg-udp-guidelines-09.txt  
- Simple Network Management Protocol (SNMP) Context EngineID Discovery
(Proposed Standard) - draft-ietf-opsawg-snmp-engineid-discovery-03.txt
- Internet Message Store Events (Proposed Standard) -
draft-ietf-lemonade-msgevent-06.txt 

2.1.2 Returning Item        

- A Two-way Active Measurement Protocol (TWAMP) (Proposed Standard) -
draft-ietf-ippm-twamp-09.txt 

2.2 Individual Submissions
2.2.1 New Item         

- IANA Considerations for the IPv4 and IPv6 Router Alert Option
(Proposed Standard) - draft-manner-router-alert-iana-03.txt 
- Extensions to the IODEF-Document Class for Reporting Phishing, Fraud,
and Other Crimeware (Proposed Standard) -
draft-cain-post-inch-phishingextns-05.txt   
  
3. Document Actions

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         

- Basic Password Exchange within the Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational)
- draft-zhou-emu-fast-gtc-04.txt 
- Dynamic Provisioning using Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST) (Informational)
- draft-cam-winget-eap-fast-provisioning-09.txt
- Media Gateway Control Protocol Fax Package (Informational) -
draft-andreasen-mgcp-fax-08.txt 

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sat, 9 Aug 2008 10:38:23 +0200

Bert,

Hmmmm ... I am not crazy about it, but it may be acceptable as there is
no exact equivalent in the Bridge or IEEE 802.1 MIB TCs or I did not
find it. Did you? The PWE3 folks use 4097 as a special value for 16bit
VLAN range. Sure, one may ask what 'object is not relevant means'. And
it certainly would be better to have all VLAN-related TCs in one place,
but ...

Dan

> -----Original Message-----
> From: Bert Wijnen [mailto:[email-masked]] 
> Sent: Saturday, August 09, 2008 12:52 AM
> To: Romascanu, Dan (Dan); MIB Doctors (E-mail)
> Subject: draft-ietf-pwe3-pw-tc-mib-14.txt [was [MIB-DOCTORS] 
> Preliminary agenda for the 8/14 IESG Telechat]
> 
> Dan, I only did a very very quick scan of  
> draft-ietf-pwe3-pw-tc-mib-14.txt
> 
> 
> ANd I found this:
> 
>   PwVlanCfg ::= TEXTUAL-CONVENTION
>      DISPLAY-HINT "d"
>      STATUS      current
>      DESCRIPTION
>           "VLAN configuration for Ethernet PW.
>            Values between 0 and 4095 indicate the actual VLAN field
>            value.
>            A value of 4096 indicates that the object refers to
>            untagged frames, i.e., frames without a 802.1Q field.
>            A value of 4097 indicates that the object is not
>            relevant."
>      SYNTAX  Unsigned32 (0..4097)
> 
> 
> I wonder how that co-exists/conflicts with the VLAN TCs that 
> we have in our BRIDGEMIB documents and those in the new 
> 802.1ap MIB modules????
> 
> Bert
> 
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: <[email-masked]>; "MIB Doctors (E-mail)" 
> <[email-masked]>; "IETF DNS Directorate" 
> <[email-masked]>; <[email-masked]>
> Sent: Friday, August 08, 2008 6:55 PM
> Subject: [MIB-DOCTORS] Preliminary agenda for the 8/14 IESG Telechat
> 
> 
> > Please send me your questions, concerns and comments until 8/13 COB 
> > the latest.
> >
> > Thanks and Regards,
> >
> > Dan
> >
> > 2. Protocol Actions
> > (Proposed Standard) - 
> draft-ietf-opsawg-snmp-engineid-discovery-03.txt
> > - Extensions to the IODEF-Document Class for Reporting Phishing, 
> > Fraud, and Other Crimeware (Proposed Standard) - 
> > reasonable contribution to the area of Internet engineering 
> which it 
> > covers? If not, what changes would make it so?"
> >
> > 3.2.1 New Item
> >
> > - Basic Password Exchange within the Flexible Authentication via 
> > Secure Tunneling Extensible Authentication Protocol (EAP-FAST) 
> > (Informational)

---

From: "Bert Wijnen \(IETF\)" <[email-masked]>
Date: Sat, 9 Aug 2008 16:00:42 +0200

Well....

>            A value of 4097 indicates that the object is not

First of all, if I understand 802.1 well enough, then the values 0 and 4095 
are NOT
permitted in the VLAN-ID field in 802.1 PDUs. Not sure if they are allowed 
in
Ethernet PW. But for my gut feeling, it seems better to stay in sync with 
real
VLAN technology and NOT allow the values zero and 4095.

Further, in the IEEE8021-TC-MIB we see in the IEEE8021VlanIndexOrWildcard TC
that values 4096, 4097 and further can be used as indices and represent 
VLANs with
local scope (whereas 1-2094 are of glovbal scope). So I can see risks that 
in the
future these values 4096 and 4097 might cause trouble.

If we look at RFC4364, we see TCs for VlanId, VlanIdOrAny and 
VlanIdOrAnyOrNone.
It seems to me that the VlanIdOrAnyOrNone would be a GOOD TC for PWE3 to use
where they make 0 to mean Untagged and 4095 to mean object is not relevant.
But this is just my opinion after a quick check/scan of the various 
documents.

Bert

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Bert Wijnen" <[email-masked]>; "MIB Doctors (E-mail)" 
<[email-masked]>
Cc: "Orly Nicklass" <[email-masked]>
Sent: Saturday, August 09, 2008 10:38 AM
Subject: RE: draft-ietf-pwe3-pw-tc-mib-14.txt [was [MIB-DOCTORS] Preliminary 
agenda for the 8/14 IESG Telechat]

Bert,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 10 Aug 2008 09:14:07 +0200

I will enter a DISCUSS. We need indeed to understand the usage that PWE3
are making of these 'special values'. 

Dan

> From: Bert Wijnen (IETF) [mailto:[email-masked]] 
> Sent: Saturday, August 09, 2008 5:01 PM
> Cc: Orly Nicklass
> Subject: Re: draft-ietf-pwe3-pw-tc-mib-14.txt [was 
> [MIB-DOCTORS] Preliminary agenda for the 8/14 IESG Telechat]
> 
> Well....
> 
> First of all, if I understand 802.1 well enough, then the 
> values 0 and 4095 are NOT permitted in the VLAN-ID field in 
> 802.1 PDUs. Not sure if they are allowed in Ethernet PW. But 
> for my gut feeling, it seems better to stay in sync with real 
> Further, in the IEEE8021-TC-MIB we see in the 
> IEEE8021VlanIndexOrWildcard TC that values 4096, 4097 and 
> further can be used as indices and represent VLANs with local 
> scope (whereas 1-2094 are of glovbal scope). So I can see 
> risks that in the future these values 4096 and 4097 might 
> cause trouble.
> 
> It seems to me that the VlanIdOrAnyOrNone would be a GOOD TC 
> for PWE3 to use where they make 0 to mean Untagged and 4095 
> to mean object is not relevant.
> But this is just my opinion after a quick check/scan of the 
> various documents.
> 
> Bert
> 
> Subject: RE: draft-ietf-pwe3-pw-tc-mib-14.txt [was 
> [MIB-DOCTORS] Preliminary agenda for the 8/14 IESG Telechat]
> 
> 
> Bert,
> 
> Hmmmm ... I am not crazy about it, but it may be acceptable 
> as there is no exact equivalent in the Bridge or IEEE 802.1 
> MIB TCs or I did not find it. Did you? The PWE3 folks use 
> 4097 as a special value for 16bit VLAN range. Sure, one may 
> ask what 'object is not relevant means'. And it certainly 
> would be better to have all VLAN-related TCs in one place, but ...
> 
> Dan
> 
> 
> > I wonder how that co-exists/conflicts with the VLAN TCs 
> that we have 
> > in our BRIDGEMIB documents and those in the new 802.1ap MIB 
> > modules????
> >
> > Bert
> >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 10 Aug 2008 11:05:47 +0200

You probably mean RFC4363 all over ....