Subject: [Ietf-not43] crisp requirements matrix

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed May 21 17:32:32 2003

Are we planning to get a new matrix for the -05 reqs? I'm wanting to do an
analysis of FIRS' conformance.

on 3/26/2003 12:44 PM Andrew Newton wrote:
> Here is a first pass at the crisp requirements matrix.  The entries are 
> based on the latest draft in the repository.  Therefore, they will 
> change with the addition of the new text from the comments period and 
> the expected comments due in about 2 weeks.
> 
> If you have comments on the format or structure of the matrix, please 
> send them to the list.  It is provided in both HTML and ASCII text format.
> 
> -andy

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: anewton at ecotroph.net (Andrew Newton)
Date: Wed May 21 18:12:25 2003

> analysis of FIRS' conformance.

Yes.  I will try to get that out later this week.  I've just had other 
things to do.

-andy

---

From: edlewis at arin.net (Edward Lewis)
Date: Wed May 28 13:46:10 2003

In 4.5 you say that "any referral ... SHOULD provide multiple 
referrals."  Coming from a DNS background, I see this as an analog to 
having (a requirement for) multiple NS RR's at a delegation point and 
reminds me of an implementation bug that can be easily avoided.

Over time, having two or more NS RR's (in DNS) has become a de facto 
MUST - the DNS specs were written prior to RFC 2119 - even though it 
isn't necessary to do that to achieve the desired goal of 
availability via having multiple name servers which are topologically 
distributed.  It's not necessary to have multiple NS RR's to achieve 
this because I, in theory, can have multiple address RR's for a 
domain name, and more recently, I can make use of anycasting.

But, in DNS, there is still a need to have multiple NS RR's at a 
delegation because implementations have made the mistake of marking a 
name server's domain name as unresponsive if just one of the address 
records is unresponsive.  E.g., <zone.example.com NS ns1.example.com> 
may "point to" <ns1.example.com A 1.1.1.1> and <ns1.example.com A 
2.2.2.2>.  If 1.1.1.1 fails to answer, 2.2.2.2 isn't checked.

My suggestion is to add a blurb saying that a URI might resolve into 
multiple IP addresses and that each address ought to be checked, 
instead of blindly relying on a second URI for "backup."  This should 
stamp out (one of) the implementation bug(s) that plagues DNS.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Digital cameras are to film cameras as Etch-A-Sketches are to canvases.

---

From: edlewis at arin.net (Edward Lewis)
Date: Wed May 28 13:51:33 2003

Sorry - the 'question' as in the subj: got lost and became a suggestion...

At 13:46 -0400 5/28/03, Edward Lewis wrote:
>In 4.5 you say that "any referral ... SHOULD provide multiple referrals."

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Wed May 28 15:11:11 2003

> stamp out (one of) the implementation bug(s) that plagues DNS.

That's a good suggestion. I also added a blurb to the SRV processing
disucssion in the -core spec saying that each IP address should be tried
before moving to the next-preferred host.