Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07

[Tom Taylor <[e-mail]>]

OK

On 18/03/2015 10:13 PM, Fuyu (Eleven) wrote:
> Hi Tom,
>
> Thank you for your review and comments.
>
> The main difference for the NAT management between the NATv2-MIB and DSLite-MIB is that the NATv2-MIB describe the tunnel information on the view of address level. But the DSLite-MIB define it on the view of interface.
>
> I think the NAT objects defined in DSLite-MIB should make in accordance with the tunnel management as the TUNNEL-MIB do.
>
> So do you feel OK if I described the following quoted statement as " The tunnel information defined in NATV2-MIB on the address level for DS-Lite scenario. Because the TUNNEL-MIB defined the objects on the view of interface, the DS-Lite-MIB need defined the tunnel objects to extend the NAT binding entry by interface for accordance."
>
> Best Regards
>
> Yu
>
>
> -----Original Message-----
> From: Tom Taylor [mailto:[e-mail]]
> Sent: Monday, March 16, 2015 8:30 AM
> To: Yong Cui; Fuyu (Eleven)
> Cc: [e-mail] WG; Krishnan Suresh
> Subject: Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07
>
> Sorry to let my review of the updated version slip.
>
> I think the key contribution of this document lies in its tunnel management aspect. I'm concerned that the NAT management part still has a considerable overlap with the NATv2-MIB
>       http://www.ietf.org/id/draft-perrault-behave-natv2-mib-02.txt
>
> Using the line numbers contained in the IDNits output generated by the URL at the bottom of this message, I have to say that the following statement is incorrect:
>
> <quote>
>              But the NAT
> 168	   binding entry defined in the NATV2-MIB are not extended by the object
> 169	   definded for the tunnel initiator.
> </quote>
>
> Here is what the NATv2-MIB document has, in the address binding table:
>
>      natv2AddressMapInternalAddress OBJECT-TYPE
>          SYNTAX InetAddress
>          MAX-ACCESS not-accessible
>          STATUS current
>          DESCRIPTION
>              "Source address of packets originating from the interior
>               of the association provided by this mapping.
>
>               In the case of DS-Lite [RFC 6333], this is the IPv6 tunnel
>               source address.  The mapping in this case is considered to
>               be from the combination of the IPv6 tunnel source address
>               natv2AddressMapInternalRealmAddress and the well-known IPv4
>               inner source address natv2AddressMapInternalMappedAddress to
>               the external address."
>          REFERENCE
>              "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
>               Section 6.6 on the need to have the IPv6 tunnel address in
>               the NAT mapping tables."
>          ::= { natv2AddressMapEntry 4 }
>
> ....
>
>      natv2AddressMapInternalMappedAddress OBJECT-TYPE
>          SYNTAX InetAddress
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>              "Internal address actually translated by this mapping. In the
>               general case, this is the same as
>               natv2AddressMapInternalRealmAddress. In the case of DS-Lite
>               [RFC 6333], this is the source address of the encapsulated
>               IPv4 packet, normally lying the well-known range
>               192.0.0.0/29. The mapping in this case is considered to be
>               from the combination of the IPv6 tunnel source address
>               natv2AddressMapInternalRealmAddress and the well-known IPv4
>               inner source address natv2AddressMapInternalMappedAddress to
>               the external address."
>          REFERENCE
>              "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
>               Section 6.6 on the need to have the IPv6 tunnel address in
>               the NAT mapping tables."
>          ::= { natv2AddressMapEntry 7 }
>
> and similarly in the port binding table:
>
>      natv2PortMapInternalRealm OBJECT-TYPE
>          SYNTAX SnmpAdminString (SIZE(0..32))
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>              "The realm to which natv2PortMapInternalRealmAddress belongs.
>               In the general case, this realm contains the address that is
>               being translated. In the DS-Lite [RFC 6333] case, this realm
>               defines the IPv6 address space from which the tunnel source
>               address is taken. The realm of the encapsulated IPv4 address
>               is restricted in scope to the tunnel, so there is no point
>               in identifying it separately."
>          REFERENCE
>              "RFC 6333 DS-Lite."
>          ::= { natv2PortMapEntry 7 }
>
>      natv2PortMapInternalAddressType OBJECT-TYPE
>          SYNTAX InetAddressType
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>              "Address type for addresses in the realm identified by
>               natv2PortMapInternalRealm."
>          ::= { natv2PortMapEntry 8 }
>
>      natv2PortMapInternalAddress OBJECT-TYPE
>          SYNTAX InetAddress
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>              "Source address for packets received under this mapping on
>               the internal side of the NAT instance. In the general case
>               this address is the same as the address given in
>               natv2PortMapInternalMappedAddress. In the DS-Lite case,
>               natv2PortMapInternalAddress is the IPv6 tunnel source
>               address."
>          REFERENCE
>              "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
>               Section 6.6 on the need to have the IPv6 tunnel address in
>               the NAT mapping tables."
>          ::= { natv2PortMapEntry 9 }
>
>      natv2PortMapInternalMappedAddressType OBJECT-TYPE
>          SYNTAX InetAddressType
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>              "Internal address type actually translated by this mapping.
>               Any value other than ipv4(1) or ipv6(2) would be unexpected.
>               In the general case, this is the same as given by
>               natv2AddressMapInternalAddressType. In the DS-Lite
>               case, the address type is ipv4(1)."
>          REFERENCE
>              "DS-Lite: RFC 6333."
>         ::= { natv2PortMapEntry 10 }
>
>      natv2PortMapInternalMappedAddress OBJECT-TYPE
>          SYNTAX InetAddress
>          MAX-ACCESS read-only
>          STATUS current
>          DESCRIPTION
>              "Internal address actually translated by this mapping. In the
>               general case, this is the same as
>               natv2PortMapInternalRealmAddress. In the case of DS-Lite
>               [RFC 6333], this is the source address of the encapsulated
>               IPv4 packet, normally selected from the well-known range
>               192.0.0.0/29. The mapping in this case is considered to be
>               from the external address to the combination of the IPv6
>               tunnel source address natv2PortMapInternalRealmAddress and
>               the well-known IPv4 inner source address
>               natv2PortMapInternalMappedAddress."
>          REFERENCE
>              "DS-Lite: RFC 6333, Section 5.7 for well-known addresses and
>               Section 6.6 on the need to have the IPv6 tunnel address in
>               the NAT mapping tables."
>          ::= { natv2PortMapEntry 11 }
>
>
>
> On 13/03/2015 10:34 PM, Yong Cui wrote:
>> Hi authors,
>>
>> We would like to advance the document.
>> Would you please update your document according to the following "Check nits" report once the submission system opens? I found there are still some issues in your new version draft-ietf-softwire-dslite-mib-08.
>>
>> http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/dr
>> aft-ietf-softwire-dslite-mib-08.txt
>>
>> I would also need to receive the confirmation to the chairs from each of your authors on the IPR issue:
>> Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?
>>
>> Thanks in advance,
>>
>> Yong
>>
>> On 2015-2-9, at 上午10:44, Fuyu (Eleven) <[e-mail]> wrote:
>>
>>> Hi Tom
>>>
>>> Yes. I have updated the DS-Lite MIB based on draft-perrault-behave-natv2-mib.
>>> Your review and comments will be very appreciated.
>>>
>>> Thanks
>>>
>>> BR
>>> Yu
>>>
>>> -----Original Message-----
>>> From: Softwires [mailto:[e-mail]] On Behalf Of Tom
>>> Taylor
>>> Sent: Friday, February 06, 2015 5:34 AM
>>> To: Yong Cui; [e-mail]
>>> Subject: Re: [Softwires] WGLC for draft-ietf-softwire-dslite-mib-07
>>>
>>> I finally got around to looking at this document, but I see I'm a bit late. In any event, I believe the authors are updating it based on the fact that [I-D.ietf-behave-nat-mib] is being replaced by draft-perrault-behave-natv2-mib. I will be happy to review the updated draft, because coordination between the two drafts is clearly required.
>>>
>>> Tom Taylor
>>>
>>> On 21/01/2015 7:05 AM, Yong Cui wrote:
>>>> Hi folks,
>>>>
>>>> This message starts a two week softwire working group last call on
>>>> advancing the draft of DS-Lite MIB as a Standards Track RFC.
>>>>
>>>> After we had the first wglc on draft-ietf-softwire-dslite-mib-02,
>>>> there were some major comments. The authors have revised the
>>>> document including the structure and detailed technical contents.
>>>> Now the authors believe that this version has addressed all the
>>>> issues.
>>>>
>>>> The latest version of the draft is available at:
>>>> http://www.ietf.org/id/draft-ietf-softwire-dslite-mib-07.txt
>>>>
>>>> Substantive comments and statements of support/opposition for
>>>> advancing this document should be directed to the mailing list.
>>>> Editorial suggestions can be sent directly to the authors. This last
>>>> call will conclude on February 3, 2015.
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yong & Suresh
>>>>
> ...
>