Subject: [mile] Representing a domain name (or Issue #4)

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 15 Jan 2014 14:57:07 +0000

Hello!

Tracked in Issue #4, http://trac.tools.ietf.org/wg/mile/trac/ticket/4, is the need to make a modeling decision on how to represent domain name.  To summarize, we currently have two duplicate ways to represent a domain name for given Node.  RFC5070 defined Node/NodeName.  DomainData from RFC5901 was added to the Node class in RFC5070bis.  This change allows Node/DomainData/Name to also describe a domain name.

Both of these valid representations are shown in this XML snippet:

<System category="source">
   <Node>
      <NodeName>www.example.com</NodeName>
      <DomainData>
               <Name>www.example.com</NodeName>
               <DateDomainWasChecked>2013-01-02T05:54:02-05:00</DataDomainWasChecked>
      </DomainData>
      <Address category="ipv4-addr">10.1.1.1.</Address>
      <DateTime>2013-01-02T05:54:02-05:00</DateTime>
   </Node>
</System>

This will likely create implementation confusion.

As I see it, we have at least the following options:

(1) Remove NodeName and DateTime from Node in favor of DomainData

(2) Remove Name and DateDomainWasChecked from DomainData in favor of NodeName and DateTime

Option #1 break compatibility with RFC 5070.  Also, NodeName can represent any kind of host name.  As defined DomainData/Name only represents FQDN DNS names.

Option #2 redefines DomainData from RFC 5901 so we can't strictly cite the element.

Roman

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Wed, 15 Jan 2014 16:23:25 +0000

Hello!

I omitted an important detail in my earlier write-up.  The Service class also got a DomainData class in 5070bis (at least in the schema but not in the text).  Hence, there are actually three places to put the domain name.  Hence, the following XML-snippet would be legal:

<System category="source">...
   <Node>
   <Service>...
   </Service>
</System>

To expand upon the previously suggested options:

(1) Remove Node/NodeName and Service/DomainData/Name in favor of Node/DomainData/Name
 
(2) Remove Node/DomainData/Name and Service/DomainData/Name in favor of Node/NodeName

(3) Remove Node/DomainData/Name and Node/NodeName in favor of Service/DomainData/Name
 
> Option #1 break compatibility with RFC 5070.  Also, NodeName can represent
> any kind of host name.  As defined DomainData/Name only represents FQDN
> DNS names.
> 

Option #3 has the same disadvantages as #1 and would also requires further changes Service.  Currently, the Service class minimally expects port information.

Roman

> -----Original Message-----
> From: mile [mailto:[email-masked]] On Behalf Of Roman D. Danyliw
> Sent: Wednesday, January 15, 2014 9:57 AM
> To: [email-masked]
> Subject: [mile] Representing a domain name (or Issue #4)
> 
> Hello!
> 
> Tracked in Issue #4, http://trac.tools.ietf.org/wg/mile/trac/ticket/4, is the
> need to make a modeling decision on how to represent domain name.  To
> summarize, we currently have two duplicate ways to represent a domain
> name for given Node.  RFC5070 defined Node/NodeName.  DomainData from
> RFC5901 was added to the Node class in RFC5070bis.  This change allows
> Node/DomainData/Name to also describe a domain name.
> 
> Option #1 break compatibility with RFC 5070.  Also, NodeName can represent
> any kind of host name.  As defined DomainData/Name only represents FQDN
> DNS names.
> 
> _______________________________________________
> mile mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mile

---

From: Eric Burger <[email-masked]>
Date: Thu, 23 Jan 2014 11:47:05 -0500

All I care about is if one is describing a Domain Name Thing, then wherever one references the Domain Name Thing, one references it the same way.

How important is backwards compatibility with 5070 in this case? I would think tis would be one of the more commonly used data elements, but I could be wrong.

---

From: "Roman D. Danyliw" <[email-masked]>
Date: Fri, 24 Jan 2014 02:25:27 +0000

I tend to agree that domain information is important enough to break compatibility.  We've already done that with the Reference class.  Hence, my preference would be for Option #1.

Roman

> From: Eric Burger [mailto:[email-masked]]
> Sent: Thursday, January 23, 2014 11:47 AM
> To: Roman D. Danyliw
> Cc: [email-masked]
> Subject: Re: [mile] Representing a domain name (or Issue #4)
> 
> All I care about is if one is describing a Domain Name Thing, then wherever
> one references the Domain Name Thing, one references it the same way.
> 
> How important is backwards compatibility with 5070 in this case? I would
> think tis would be one of the more commonly used data elements, but I could
> be wrong.
> 
> > I omitted an important detail in my earlier write-up.  The Service class also
> got a DomainData class in 5070bis (at least in the schema but not in the text).
> Hence, there are actually three places to put the domain name.  Hence, the
> following XML-snippet would be legal:
> >
> > (2) Remove Node/DomainData/Name and Service/DomainData/Name in
> favor
> > of Node/NodeName
> >
> >> Option #1 break compatibility with RFC 5070.  Also, NodeName can
> >> represent any kind of host name.  As defined DomainData/Name only
> >> represents FQDN DNS names.
> >>
> > Option #3 has the same disadvantages as #1 and would also requires
> further changes Service.  Currently, the Service class minimally expects port
> information.
> >
> > Roman
> >
> >> Tracked in Issue #4,
> >> http://trac.tools.ietf.org/wg/mile/trac/ticket/4, is the need to make
> >> a modeling decision on how to represent domain name.  To summarize,
> >> we currently have two duplicate ways to represent a domain name for
> >> given Node.  RFC5070 defined Node/NodeName.  DomainData from
> >> RFC5901 was added to the Node class in RFC5070bis.  This change
> >> allows Node/DomainData/Name to also describe a domain name.
> >>
> >> (2) Remove Name and DateDomainWasChecked from DomainData in favor
> of
> >> NodeName and DateTime
> >>
> >> Option #1 break compatibility with RFC 5070.  Also, NodeName can
> >> represent any kind of host name.  As defined DomainData/Name only
> >> represents FQDN DNS names.
> >>