Re: ADMD IMX document - comments

[Einar Stefferud <[e-mail]>]

Here are some responses to Allans comments...

--------
From your message Fri, 29 Oct 1993 17:21:24 +0000:
}
}Hi x400ops folk,
}
}Some comments to Stef's revised IMX draft.  I have retained only
}related portions of the text below.  My comments are marked with >>>.
}
}Cheers
}
}allan
}
}======================================================================
}OSI-X400ops Working Group        				 E. Stefferud
}INTERNET DRAFT: A=IMX        	          Network Management Associates, Inc.
}draft-ietf-x400ops-admd-03.txt        			         October 1993
}
}        		     C=US; A=IMX
}        	      (Expires: January 26 1993)
}
}>>> Need to change expiration date

Yeah!  I intended it to be 1994;-)...

}
}>>> Not sure we want to claim to meet all CCITT Recommendations,
}ISO standards, and regulatory practices for ADMDs.  We plan to
}establish a virtual ADMD, which may not meet some of the said
}recommendations.  (The F.400 series for ADMDs, for example.)  This
}document is restricted to naming and ADMD name registration.  I think
}that we should say that operational issues are outside the scope of
}this document and need to be addressed in a related future document.

I have a note to this effect in the text.
}
}>>> Don't DNS names have to start with a letter, not a digit?

Not any more -- e.g., 3COM ...

}>>> Can we specify that there is no charge for registration?

Well, there is no change for these things now, but we cannot assert in
this document that there will never be any charge.  Certainly we
cannot enforce any such statement.  Lets not get into it.

 ...
}  PRMD name in C=US; A=IMX because all such DNS names are already
}  unambiguous and uniquely assigned to registrants by the IANA in the
}  Internet DNS, and they only contain allowed characters.
}>>>                                   ^^^^^^^ prefer "legal" or "valid"

How about 'permitted"?  This is not a "legal" document.  Everytime we
use the word "legal" in the sense of "permitting" we cause confusion.
If not "permitted" then maybe "valid" is OK.

}>>> There is still a hole in the effort to avoid constraining the DNS
}name space in the future.  Look at section 7, number (2) immediately
}above.  It rules out all PRMD names that end with a dot character
}followed by other valid domain-name characters.  That's fine.  The
}hole comes with the examples of section 6, number (2) above.  In that
}paragraph, the following are listed as legal PRMD names:
}
}>>> P=ESnet;  P=NASA;  P=Boeing Seattle;  P=XYZZY;  P=CALTRANS
}
}>>> As an artifact of the way the DNS works, registering a PRMD name
}of "ZZ" is equivalent to also reserving the top-level domain ".ZZ" --
}or at least that's how it appears to me.  Am I wrong?  

Yes, you misunderstand!  .zz and zz are not the same string in a PRMD
name value!


}                                                       Or do we need
}to think about this some more?  In other words, by registering the
}above PRMD names, it appears to me that we are also reserving the
}top-level domain name spaces of ".esnet" , ".nasa" , ".xyzzy" , and
}".caltrans" .  Note that "Boeing Seattle" does not cause this problem
}because it contains an illegal domain-name character (space).

Not so, per the fact that teh dot is distinguishing.

}>>> One solution would be to decide that every PRMD name registered
}must contain a character which is invalid as a domain name:  space,
}apostrophe, parentheses, plus sign, comma, slash (/), colon, equals
}sign, or question mark.  I don't like that solution.

Great!  Now how do we do the 1327 mappings?

}>>> Another possibility is to assert that PRMD names which would be
}valid DNS names must be longer than a certain number of characters,
}say five or more.

But that declares that a DNS top level name cannot ever be more than
five or so characters long.  If we wnat to do this sort of thing, we
need to do it in a DNS specification, nopt in a PRMD Name spec.

}>>> Another possibility is to determine that what I think is a problem
}is not actually a problem, and that registering PRMD "top" is not
}really equivalent to reserving ".top" .

Now you're cooking!

}  NOTE: If and when this RFC is published as an Informational or
}        Experimental^A RFC, this Appendix may be removed
}>>>  a control-A ^^^^^^ char snuck in up above here.

Yes it did;-)... Sorry bout that...

One last comment -- By and large, my objective has been to keep this
A=IMX draft as lean, mean, and clean as possible.  I believe it is
critically important to keep it that way.

Cheers...\Stef