Textual Conventions for Internet Network Addresses
draft-ietf-ops-rfc3291bis-06

[Ballot discuss]
Under InetScopeType, SiteLocal (5)
Please place a note next to this citing the update to RFC 3513 which deprecates site-local,
and (I think) make this a normative reference.  I think the explanatory text could state
that there are MIB reasons why there are site local scope addresses still to be seen, but
is it not appropriate for an updated rfc3291 to be really up-to-date? 

Again, since site-local has been deprecated, it would be better not to use a
site-local example:
          (e.g., a management
            application needs to write a site-local IPv6 address without
            knowing the site index value).

[Ballot discuss]
The draft gives InetAddressDNS as:

InetAddressDNS ::= TEXTUAL-CONVENTION
      DISPLAY-HINT "255a"
      STATUS      current
      DESCRIPTION
          "Represents a DNS domain name. The name SHOULD be fully
            qualified whenever possible.

            The corresponding InetAddressType is dns(16).

            The DESCRIPTION clause of InetAddress objects that may have
            InetAddressDNS values must fully describe how (and when) such
            names are to be resolved to IP addresses.

            This textual convention SHOULD NOT be used directly in object
            definitions since it restricts addresses to a specific format.
            However, if it is used, it MAY be used either on its own or in
            conjunction with InetAddressType as a pair."
      SYNTAX      OCTET STRING (SIZE (1..255))

and further describes this in 4.4.

I am concerned that the " must fully describe" text is not normative.
The related text in 4.4 *is* normative at a SHOULD level.  Though
this text has not changed from 3291, and I am concerned about
requesting a change, I believe this has to be a MUST.

As it stands now, an InetAddress object without that DESCRIPTION
and with only this InetAdddressType (which the SHOULDs allow) may
be unaddressable. A user/device attempting to resolve it may not know
whether to query for an A or a AAAA record and may run into problems
with split DNS similar to the global/local scopes for IP addresses.  I
am concerned about this primarily because there might be cases where
the same DNS name would point to different hosts with at A and AAAA
or different hosts on different sides of the split DNS, so this
is not just a failed connection case, but possibly a wrong data case.

[Ballot comment]
Is this supposed to update or obsolete RFC 2851?  It includes a section describing changes from 2851, but doesn't say anywhere if 2851 is being updated or obsoleted.  It _does_ say that 3291 is being obsoleted in the document header, though, so it should probably say something similar for 2851.

[Ballot comment]
Is this supposed to update oir obsolete RFC 2851?  It includes a section describing changes from 2851, but doesn't say anywhere if 2851 is being updated or obsoleted.  It _does_ say that 3291 is being obsoleted in the document header, though.