Subject: Re: [Tools-discuss] Idnits-1.85 - requesting a further feature

From: Allison Mankin <[email-masked]>
Date: Mon, 16 Jan 2006 08:36:13 -0800

Henrik,

> Of course, if a document proposes an explicit IANA allocation of
> a specific non-example prefix, that will violate this.

Yes, very good point.  Another type of violation will come
when examples of RFC 3761 (e164.arpa) addresses are given.

Another type it will catch is in an IPv6 address-related
document describing the significance of 0::0

But I think* these documents balance out fairly few against 
those that use examples.

> I could still issue a warning for this, which people who really
> were proposing a specific prefix allocation would have to ignore.

So what sounds right is to include the FQDN or address that
causes the violation in the warning, then the person checking
can be slightly annoyed or not, but know what the issue is.
The warning should probably say something like it's a violation
if the literal or FQDN was used as an arbitrary example, versus
some other use.  

> If the above looks sensible to you, I'll put it in the next version
> of idnits.

I like it, though it's good others are checking.  I do suggest
allowing that FQDNS can be constructed with capital letters.  We
don't see them too much, but I don't know why we'd rule it out.

Best,

Allison

> 
> Hi Allison,
> 
> on 2006-01-15 20:55 Allison Mankin said the following:
> > Hi, Henrik,
> > 
> > Would it be hard to add checking of Section 6A and 6B of
> > http://www.ietf.org/ID-Checklist.html to Idnits when you next
> > update?  
> 
> I assume you mean Section 3, items 6A and 6B.
> 
> > The shepherds and ADs vet a lot of example addresses.  It's
> > pretty easy to catch problem FQDNs by eye, but problem literals
> > can slip through more readily, especially if most of the literals
> > in a document have been switched to comply with RFC 3330/RFC 3849,
> > but a few have been missed.
> > 
> > The IESG ends up catching 6A/6B nits often.
> 
> The checks I can imagine for this would be
> 
>   1. Anything which matches a typical FQDN:
> 
> 	([a-z0-9-_]+\.)+[a-z0-9-_]+\.[a-z0-9-_]+
> 
> 	should also match
> 
> 	([a-z0-9-_]+\.)+example.(com|org|net)
> 
>   2. Anything which matches an explicit IPv4 address:
> 
> 	[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\
> 	
> 	should also match
> 
> 	192\.0\.2\.[0-9]+
> 
>   3. Anything which matches an explicit IPv6 address:
> 
> 	[0-9a-fA-F]+:(([0-9a-fA-F]*):)*
> 
> 	should also match
> 
> 	2001:DB8:(([0-9a-fA-F]*):)*
> 
> Of course, if a document proposes an explicit IANA allocation of
> a specific non-example prefix, that will violate this.
> 
> I could still issue a warning for this, which people who really
> were proposing a specific prefix allocation would have to ignore.
> 
> If the above looks sensible to you, I'll put it in the next version
> of idnits.
> 
> 
> Regards,
> 
> 	Henrik
> 
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tools-discuss

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 16 Jan 2006 22:57:59 +0100

Hi Allison,

> when examples of RFC 3761 (e164.arpa) addresses are given.

Right.  But those can be excempted, I guess.

> But I think* these documents balance out fairly few against 

Right.

> if the literal or FQDN was used as an arbitrary example, versus

Right.

> don't see them too much, but I don't know why we'd rule it out.

Good point.  I'll allow that.

Best regards,

	Henrik