Hi Martin, 

> On Apr 27, 2023, at 00:07, Martin Thomson <[email protected]> wrote:
> 
> This looks like a place where the document failed to include the standard RFC 
> 8792 boilerplate.  Adding that would solve the problem, I think.

What do you mean by the “stardard RFC 8792 boilerplate”? What do you feel is 
missing from the draft. 


> 
> https://datatracker.ietf.org/doc/html/rfc8792#section-7.1.1
> 
> That is, the backslash will go away if you extract the content with the 
> appropriate process.
> 
> Otherwise, those lines are really going to blow the 72 character limit.  
> Though perhaps the example would be cleaner if it used namespaces and moved 
> the declarations to the top.  It's a bit repetitive as it is and maybe you 
> don't need to invoke RFC 8792...
> 
>              <preference xmlns="urn:ietf:params:xml:ns:yang:\
>                ietf-rib-extension">30</preference>
>              <tag xmlns="urn:ietf:params:xml:ns:yang:\
>                ietf-rib-extension">99</tag>

Right. We need to fold these longer lines. 

Thanks,
Acee


> 
> 
> On Thu, Apr 27, 2023, at 09:34, Tim Bray wrote:
>> In the XML examples in Appendix B, we see things like this:
>> 
>>          <destination-prefix xmlns="urn:ietf:params:xml:ns:yang:\
>>            ietf-ipv4-unicast-routing">0.0.0.0/0</destination-prefix>
>> 
>> Since the \-escaped newline is not legal in XML, the example would 
>> cause failure if it were copy-and-pasted as is. So there should 
>> probably be an editorial note clarifying that the \-escaped newlines 
>> are there for clarity and should not be used in practice.  Or I guess 
>> if you put in a perfectly legal newline before the xmlns= and again 
>> before the ">", you might be able to avoid the escaping?
>> 
>> As with many other YANG namespaces, constructs such as 
>> 
>>      <address-family xmlns:v4ur="urn:ietf:params:xml:ns:yang:\
>>        ietf-ipv4-unicast-routing">v4ur:ipv4-unicast</address-family>
>> 
>> are not interoperable in general-purpose XML tools, and it seems a 
>> common practice in YANG-related RFCs neither to avoid this problem nor 
>> to acknowledge its existence, so while I will continue to mention it 
>> when I see it, I don't expect anyone to address it.
>> 
>> On Wed, Apr 26, 2023 at 2:23 PM David Dong via RT 
>> <[email protected]> wrote:
>>> Dear Tim and Martin (cc: rtgwg WG),
>>> 
>>> As the designated experts for the ns registry, can you review the proposed 
>>> registration in draft-ietf-rtgwg-yang-rib-extend for us? Please see
>>> 
>>> https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-rib-extend/
>>> 
>>> The due date is May 10, 2023.
>>> 
>>> If this is OK, when the IESG approves the document for publication, we'll 
>>> make the registration at
>>> 
>>> https://www.iana.org/assignments/xml-registry/
>>> 
>>> With thanks,
>>> 
>>> David Dong
>>> IANA Services Specialist
> 
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg

_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg

Reply via email to