[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Pseudo WG Last Call for: http://www.ietf.org/internet-drafts/draft-ietf-ops-taddress-mib-02.txt



[ ... another response to an almost forgotten thread ... ]

>>>>> sar  writes:

sar> Re: Ipv4OrIpv6 discussion

sar> After thinking about this for a while I've concluded that I agree
sar> with Juergen - that by the time one of these objects is
sar> instantiated you have a concrete address to use.  The case that I
sar> was considering was if an application wants to open a port on all
sar> addresses associated with the node.  In this case there might be
sar> a small value to being able to represent both v4 and v6 at the
sar> same time.  However I don't think that the value is worth the
sar> effort that would be required.  I think that requiring the
sar> application to insert two addresses (one for v4 and one for v6)
sar> is acceptable.

sar> I was wondering if it would be reasonable to add some more text
sar> to describe this possibility.

I do not know precisely what text would be reasonable to add. So I
will not take an action here.

sar> Re: global addresses in non-global formats

sar> I've been assuming that I would be able to represent a global
sar> address in one of the non-global formats (xxxIpv6z).  However
sar> after reading some of the discussion I'm not so sure.  What is
sar> the intention of the draft?

I think the draft should not preclude the usage of xxxIpv6z for global
addresses. I changed the wordings in the transportDomain*z definitions
be make to make the wordings less restrictive for only non-global
formats:

   transportDomainTcpIpv6z OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION
           "The TCP over IPv6 transport domain.  The corresponding
            transport address is of type TransportAddressIPv6z for
            scoped IPv6 addresses with a zone index."
       ::= { transportDomains 8 }

I all boils down to the interpretation of the zone index in the case
of a global address. What happens if the zone index is not zero and
identifies a zone which does not include the interface identified by
the address itself? I guess only the zone index 0 makes sense in this
case but I prefer to stay out of this discussion for the time being.

sar> And one new issue:

sar> The description of TransportAddress makes it sound like there
sar> must be a TransportAddressType or TransportDomain object
sar> associated with the TransportAddress type.  Is this what is
sar> intended or can a MIB pre-define an object to be of a specific
sar> type? (which is what some of the other text seems to allow).

I think this is a SHOULD. See also Margaret's recent posting to this
list. I carified the text accordingly.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>