Subject: MTA MIB draft06 - AD comment #38 (RE: [ipcdn] RE: AD Review: draft06 draft-ietf-ipcdn-pktc-mtamib-06.txt)

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 5 Sep 2005 11:02:17 -0600

Thomas,

   Thank you for your input. 
   I am splitting the threads to separate emails. This one is in response to comment #38.

Jean-François
> > # Comment 38
> >
> >> - At various places in your MIB module you have FQDNs present.
> >>   I wonder if it would not be wise (for interoperability) to
> >>   specify WHEN such FQDNs are supposed to be resolved to IP
> addresses.
> >
> > Agree.
> >
> > Proposed new text:
> [...]
> > pktcMtaDevSnmpEntity
> >           The MTA must resolve
> >           the FQDN value before its very first network interaction
> >           with the SNMP entity during the provisioning phase.
> 
> Beware that pktcMtaDevSnmpEntity can in fact resolve to multiple IP
> addresses and the expected behaviour is complex. 
Yes. That's a good point.

> I'd prefer to
> reference
> the corresponding PacketCable Specifications instead.

Can you propose a reference?
Why instead? Why not in addition to (if your proposed reference if for multiple IPs as a result of DNS query)? 

The text Eugene and I proposed does not seem to overlap with a DNS query being resolved in multiple IPs, and your point seems to me a valuable extension for implementers to think about.

Please clarify your point. Thanks,
Jean-François

_______________________________________________
IPCDN mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipcdn

---

From: Thomas Anders <[email-masked]>
Date: Mon, 05 Sep 2005 22:55:49 +0200

Jean-Francois Mule wrote:
>>I'd prefer to reference

Why be more specific here then in the proposal for pktcMtaDevCmsFqdn? 
The equivalent proposal would be:

pktcMtaDevSnmpEntity
            [...]
            The MTA must resolve the FQDN of the SNMP entity as required
            by the PacketCable MTA Device Provisioning Specification.

Implementators are expected to seek ultimate guidance wrt. FQDN 
resolving in [PKT-SP-PROV] and this way we'll make sure we don't create 
conflicting requirements.

+Thomas

-- 
Thomas Anders (thomas.anders at blue-cable.de)