Subject: [Tools-discuss] behave docs, example addresses, and idnits

From: "David Harrington" <[email-masked]>
Date: Tue, 17 Aug 2010 17:18:29 -0400

Hi,
 
Behave docs draw warnings from idnits because they use addresses that
are 
not consistent with the approved example addresses for ipv6. This is
becuase 
we are defining new special purpose prefixes, and give examples for
the use 
of those prefixes:

  draft-ietf-behave-dns64-10.txt(353): Found possible IPv6 address
'64:FF9B::' in
  position 46 in the paragraph; this doesn't match RFC 3849's
suggested
2001:DB8::
  /32 address range or RFC 4193's Unique Local Address range FC00::/7.

And searching draft-ietf-behave-dns64 quickly reveals the first
occurence of the string 64:FF9B is this text:

      The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96
reserved
      by [I-D.ietf-behave-address-format] for the purpose of
      representing IPv4 addresses in IPv6 address space.

This shows an error that will likely be flagged for multiple reaons.
Idnits should be updated to not flag any IPv6 addresses that embed
IPv4 addresses, as long as:
1) the IPv6 prefix is a "well-known" prefix (e.g. 6to4, Teredo,
64:FF9B, etc.) AND
2) the embedded IPv4 address is in the IPv4 documentation range.

Can we get idnits updated?	

David Harrington
Area director
IETF Transport Area

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 19 Aug 2010 16:44:01 +0200

Hi David,

On 2010-08-17 23:18 David Harrington said:
> Hi,
> 
> Behave docs draw warnings from idnits because they use addresses
> that are not consistent with the approved example addresses for ipv6.
> This is becuase we are defining new special purpose prefixes, and
> give examples for the use of those prefixes:
> 
> '64:FF9B::' in position 46 in the paragraph; this doesn't match RFC
> 3849's suggested 2001:DB8:: /32 address range or RFC 4193's Unique
> Local Address range FC00::/7.
> 
> 
> The Pref64::/n can be the Well-Known Prefix 64:FF9B::/96 reserved by
> [I-D.ietf-behave-address-format] for the purpose of representing IPv4
> addresses in IPv6 address space.
> 
> IPv4 addresses, as long as: 1) the IPv6 prefix is a "well-known"
> prefix (e.g. 6to4, Teredo, 64:FF9B, etc.) AND 2) the embedded IPv4
> address is in the IPv4 documentation range.
> 

I'm happy to update idnits to do better flagging, but in order to do
so I need to know what to look for.  If you'll provide the set of
IPv6 prefixes which should be acceptable with embedded IPv4 documentation
addresses, I'll put it in.

However, I have some reservations I'd still like to mention:

0) The idnits output for the non-RFC3849 addresses already contains a
reservation: "If these are example addresses, they should be changed."
The intention is of course to get the author to actually look at the
document from the viewpoint of using RFC3849 example addresses where
appropriate; there clearly are cases where new prefixes are in the
process of being defined where this message should pop up, but be
seen as not relevant.  Maybe the message should be changed from an
error to a warning?

1) I don't see off-hand that this would have improved the case
substantially for draft-ietf-behave-dns64-10.txt; the '64:FF9B::'
address which is flagged by idnits doesn't contain an embedded IPv4
address in 6 of the 10 flagged cases; so the message would still appear
given that idnits had been updated with an 'embedded-IPv4-example-address'
fix, and would still require inspection of the situation.

2) The '64:FF9B::' prefix is still in the process of being standardised;
should we really update idnits with new prefixes before the defining
documents have become RFCs?  (Hmm, looking at the tracker status of
the -address-format draft I see it has actually been approved, so this
should be OK...)

Best,

	Henrik

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 20 Aug 2010 12:51:30 -0700

> -----Original Message-----
> From: [email-masked] [mailto:tools-discuss-
> [email-masked]] On Behalf Of Henrik Levkowetz
> Sent: Thursday, August 19, 2010 7:44 AM
> To: David Harrington
> Cc: [email-masked]
> Subject: Re: [Tools-discuss] behave docs, example addresses, and idnits
> 
> Hi David,
> 

To accommodate the well-known prefix defined in
draft-ietf-behave-address-format, we would want to allow an IPv6 address
starting with 64:FF9B, with anything in the middle, and an RFC3330
documentation address at the end in decimal or hex.  So all of these should
pass:

  64:ff9b:1::192.0.2.0
  64:ff9b:1:2:3::192.0.2.0
  64:ff9b:1::0c00:0200          < 192.0.2.0 in hex
  64:ff9b:1:2:3::0c00:0200

To accomodate the network-specific prefix defined in
draft-ietf-behave-address-format, the existing support in idnits for the
IPv6 documentation prefix (2001:db8) should be extended to allow an RFC3330
IPv4 dotted decimal address in the last 32 bits, such as:

  2001:db8:1::192.0.2.0

We could argue that such an address shouldn't appear in an I-D due to rules
of draft-ietf-6man-text-addr-representation, but the rules of
draft-ietf-6man-text-addr-representation seem to apply to equipment, while
an I-D is trying to explain a technology.  This seems worthwhile to discuss
before making a change to idnits.  I haven't been closely involved with
draft-ietf-6man-text-addr-representation.

By the way, draft-ietf-6man-text-addr-representation is now an "RFC-to-Be",
so changing idnits to require lowercase IPv6 example addresses might be a
worthy thing to consider at the same time.

> seen as not relevant.  Maybe the message should be changed from an

During IESG review of our documents, it seems many IESG members
run IDNITS.  I don't know why, considering their time is valuable and
considering that PROTO already requires the shepherd run idnits
(1.g of RFC4858).

Many just seemed to see the output of idnits and ask authors and
chairs "has this been checked".  This resulted in wasted time 
with all parties.

I don't know how to best fix that, but perhaps changing the warning
that says:

  ** There are 10 instances of lines with non-RFC3849-compliant IPv6
addresses
     in the document.  If these are example addresses, they should be
changed.

to add "use verbose mode (--verbose) to see these instances" might encourage

further analysis by whoever is running idnits.
 
> fix, and would still require inspection of the situation.

Agreed that this change to idnits would not help that particular
document at all.

> the -address-format draft I see it has actually been approved, so this

Right.

-d

> 
> 
> Best,
> 
> 	Henrik
> _______________________________________________
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: "David Harrington" <[email-masked]>
Date: Mon, 23 Aug 2010 19:53:20 -0400

Hi,

The IESG is guilty of ignoring the warning part of the error:  "If
these are example addresses, they should be changed."

It MIGHT help to change this to a warning rather than an error, but it
appears IESG education is really what is required. sigh. My job, not
yours ;-)

I don't know that adding the prefixes to the tool would be that
helpful, and your time might be better spent on other features. If
it's convenient for you to chnage idnits to watch for these prefixes,
and check for embedded IPv4 examplke addresses, then it might help
some.

As Dan Wing pointed out in his email providing the known prefixes,
another check might be to flag uppercase hex use in addresses (not
that this really matters in the real world ;-)

dbh

> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Thursday, August 19, 2010 10:44 AM
> To: David Harrington
> > are not consistent with the approved example addresses for ipv6.
> > This is becuase we are defining new special purpose 
> prefixes, and give 
> > examples for the use of those prefixes:
> > 

> reserved by 

> I'm happy to update idnits to do better flagging, but in 
> order to do so I need to know what to look for.  If you'll 
> provide the set of
> IPv6 prefixes which should be acceptable with embedded IPv4 
> documentation addresses, I'll put it in.
> 
> The intention is of course to get the author to actually look 
> at the document from the viewpoint of using RFC3849 example 
> addresses where appropriate; there clearly are cases where 
> new prefixes are in the process of being defined where this 
> message should pop up, but be seen as not relevant.  Maybe 
> the message should be changed from an error to a warning?
> 
> 1) I don't see off-hand that this would have improved the 
> case substantially for draft-ietf-behave-dns64-10.txt; the
'64:FF9B::'
> address which is flagged by idnits doesn't contain an 
> embedded IPv4 address in 6 of the 10 flagged cases; so the 
> message would still appear given that idnits had been updated 
> with an 'embedded-IPv4-example-address'
> 2) The '64:FF9B::' prefix is still in the process of being 
> standardised; should we really update idnits with new 
> prefixes before the defining documents have become RFCs?  
> (Hmm, looking at the tracker status of the -address-format 
> draft I see it has actually been approved, so this should be OK...)
> 
> 
> Best,
> 
> 	Henrik
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 24 Aug 2010 14:01:33 +0200

Hi David,

Ok, given what you write below, my plan is this:

 1) Change idnits to emit a warning instead of an error for this,
    and add a note about using --verbose mode to see the instances.
    This can be done at once.

 2) Add RFC5952 compliance checks for IPv6 addresses.  There are a
    number of checks to perform, so coding this is no 5-minute fix.
    To be done when time permits.

 3) Add recognition of IPv6-address-with-embedded-IPv4-example-address
    to the example address warning code, to avoid warnings for these.
    To be done after 2) if time permits; low priority.

Works?

Best,

	Henrik

---

From: "David Harrington" <[email-masked]>
Date: Wed, 25 Aug 2010 19:05:29 -0400

WFM

dbh 

> Sent: Tuesday, August 24, 2010 8:02 AM
> To: David Harrington
>  3) Add recognition of
IPv6-address-with-embedded-IPv4-example-address

> order to do 
> >> 0) The idnits output for the non-RFC3849 addresses already
contains
> > a

> embedded IPv4 
> >> address in 6 of the 10 flagged cases; so the message would still 
> >> appear given that idnits had been updated with an 
> >> 'embedded-IPv4-example-address'
> >> (Hmm, looking at the tracker status of the -address-format draft
I 
> >> see it has actually been approved, so this should be OK...)
> >>
> >>
> >> Best,
> >>
> >> 	Henrik
> >>
> > 
> > 
>