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

[Daniel Migault <[e-mail]>]

Hi,

Just to be more specific:
The introduction mentions:
"""
Furthermore, this memo defines:

   o  a common set of information that the registries will maintain
      regarding each special-purpose address block
   o  a common set of requirements for future entries
"""

I think it would be good to make clear that these requirements MUST
 be provided when future allocation are requested.

The reasons to insist on it might be that it has not been always the case,
this RFC changes one type, some values as well, some RFCs mentions
these information as "boolean values"....

I am not saying the text is not mentioned, but maybe we could be more
specific and not waiting for section 2.2 to have this clear.

"""
The "IANA Considerations" section MUST include all
   of the information specified in Section 2.2.1
<https://tools.ietf.org/html/draft-bchv-rfc6890bis-02#section-2.2.1>
of this document.
"""

Regards,

Daniel


On Thu, Jan 26, 2017 at 5:41 PM, Daniel Migault <[e-mail]
> wrote:

> 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
>>
>
>