Re: [Int-area] [Ext] Re: Fwd: New Version Notification for draft-bchv-rfc6890bis-02.txt

[Daniel Migault <[e-mail]>]

Hi,

I believe I was confused as the draft defines a new attribute: "Globally
Reachable", but the values True/False/Boolean are not defined by the draft
- inferred from RFCs - , but by the referenced RFC itself. I believe this
example is a good one to indicate that "deprecation" as well as creation or
any updates requires an IETF standard Action. In this case RFC7526
obsoletes RFC3068. Maybe some text could be added to emphasize that this
draft is not supposed to define the values.

I agree the reference to RFC7526 is sufficient and no text needs to be
added. I apology for the confusion.

Yours,
Daniel




On Tue, Jan 24, 2017 at 11:28 PM, Brian E Carpenter <
[e-mail]> wrote:

> On 25/01/2017 15:25, Leo Vegoda wrote:
> > Hi,
> >
> > Brian Haberman wrote:
> >
> > [...]
> >
> >>>          +----------------------+-------------------------------+
> >>>          | Attribute            | Value                         |
> >>>          +----------------------+-------------------------------+
> >>>          | Address Block        | 192.88.99.0/24                |
> >>>          | Name                 | Deprecated 6to4 Relay Anycast |
> >>>          | RFC                  | [RFC7526]                     |
> >>>          | Allocation Date      | June 2001                     |
> >>>          | Termination Date     | March 2015                    |
> >>>          | Source               | N/A                           |
> >>>          | Destination          | N/A                           |
> >>>          | Forwardable          | N/A                           |
> >>>          | Globally Reachable   | N/A                           |
> >>>          | Reserved-by-Protocol | N/A                           |
> >>>          +----------------------+-------------------------------+
> >>>
> >>>                        Table 10: 6to4 Relay Anycast
> >>>
> >>>
> >>> MGLT: Maybe some text should be added to specify that a block even
> >>> expired remains registered. I assume that some information are set to
> >>> N/A as the block has expired. If that is correct, I believe we need a
> >>> note in section
> >>> 2.2.1 that explains the rule in as well as its the motivations.
> >>
> >> I think that relates to how IANA manages the block.
> >>
> >> Michelle or Leo?
> >
> > This registry is already quite wide and detailed. Adding additional text
> > within the registry entry might make it difficult for readers to get a
> > complete view of the registry without a particularly wide screen.
> Instead,
> > perhaps we could add a footnote that paraphrases the last sentence of
> the IC
> > section from RFC 7526:
> >
> > 7.  IANA Considerations
> >
> >    The document creating the "IANA IPv4 Special-Purpose Address
> >    Registry" [RFC6890] included the 6to4 Relay Anycast prefix
> >    (192.88.99.0/24) as Table 10.  Per this document, IANA has marked the
> >    192.88.99.0/24 prefix (originally defined by [RFC3068]) as
> >    "Deprecated (6to4 Relay Anycast)" and added a reference to this RFC.
> >    The Boolean values for the address block 192.88.99.0/24 have been
> >    removed.  Redelegation of this prefix for any use requires
> >    justification via an IETF Standards Action [RFC5226].
> >
> > Does that approach work for people? Does this need to be specified in the
> > document updating this registry?
>
> Hmm. Paraphrasing is always a risk - citing the exact text is safer. Or
> perhaps
> include a definition of 'deprecated' even though it is only used once.
>
> Something like:
>
> An address block marked as Deprecated remains reserved and might still
> be in operational use. It should not be used in new deployments and
> must not be redelegated except by IETF Standards Action [RFC5226].
>
>     Brian
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area
>